程序員項目需求分析

『壹』 如何進行需求分析

項目需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。 在原則上，需求階段監理應尊重承建方的項目管理和項目分析能力；在具體的任務開展上，以不深入、不幹擾承建方的自主權為主，除非在項目合作過程中發現承建方的項目管理以及項目分析能力存在很大的差距和不足。 為了保證項目的成功，監理方必須加強項目管理和項目分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。其中，需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。而項目的整體風險往往表現在需求分析不明確、業務流程不合理，用戶不習慣或不願意去用承建方的軟體。作為第三方的監理公司，必須提醒承建方、客戶方重視需求分析的重要性，採用必要的手段和方法來進行需求調研，同時監理方也應深入具體的需求調研中去。只有這樣才能切切實實地把握用戶的需求和方向，才能在將來的功能界定、開發范圍上有發言權。 需求分析不象偵探推理那樣需從蛛絲馬跡著手，而是應該先了解宏觀的問題，再了解細節的問題。 一個應用軟體系統（記為S）的涉及面可能很廣，可以按不同的問題域（記為D）分類，每個問題域對應於一個軟體子系統。 S={D1，D2，D3，…Dn} 問題域Di由若干個問題（記為P）組成，每個問題對應於子系統中的一個軟構件。 Di={P1，P2，P3，…Pm} 問題Pj有若干個行為（或功能，記為F），每個行為對應於軟構件中的實現介面。 Pj={F1，F2，F3，…Fk} 需求說明書應該對於那些只想了解宏觀需求的領導，和需要了解細節的技術員都合適。在寫需求說明書時應該注意兩個問題： 1.最好為每個需求注釋「為什麼」，這樣可讓程序員了解需求的本質，以便選用最合適的技術來實現此需求。 2.需求說明不可有二義性，更不能前後相矛盾。如果有二義性或前後相矛盾，則要重新分析此需求。 重點監控需求分析 由於項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟體需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本是由於以下情況造成的。 客戶說不清楚需求 有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多部門、機構、單位在進行應用系統以及網路建設時，客戶方的辦公人員大多不清楚計算機網路有什麼用，更缺乏IT系統建設方面的專家和知識。此時，用戶就會要求軟體系統分析人員替他們設想需求。工程的需求存在一定的主觀性，為項目未來建設埋下了潛在的風險。 需求自身經常變動 根據以往的歷史經驗，隨著客戶方對信息化建設的認識和自己業務水平的提高，他們會在不同的階段和時期對項目的需求提出新的要求和需求變更。事實上，歷史上沒有一個軟體的需求改動少於三次的！所以必須接受「需求會變動」這個事實，在進行需求分析時要懂得防患於未然，盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟體的核心建築在穩定的需求上，同時留出變更空間。咨詢監理方在需求分析的功能界定上擔任一個中間、公平、公正的角色，所以也必須積極參與到需求分析的准備中來，以便協助客戶方和承建方來界定「做什麼」、「不做什麼」的系統功能界限。 分析人員或客戶理解有誤 軟體系統分析人員不可能都是全才，更不可能是行業方面的專家。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以後的開發工作勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：「主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜裡能射出強光……有趣的是，車里住著一種叫作『人』的寄生蟲，這些寄生蟲完全控制了車。」所以分析人員知識的專一性也會造成需求分析的誤解和失敗。這時，咨詢監理公司就必須根據實際的項目需求調研計劃，提醒承建方加強業務了解程度和注重溝通技巧。 需求分析方法論 根據以往的工程經驗，需求分析工作方法，應該定位在「三個階段」（也稱「三步法」）。 第一階段：「訪談式」（Visitation） 這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的介面人。 實現手段：訪談、調查表格 輸出成果：調查報告、業務流程報告 第二階段：「誘導式」（Incement） 這一階段是在承建方已經了解了具體用戶方的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體實際、客觀的信息基礎上，結合現有的硬體、軟體實現方案，做出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶採用誘導式、啟發式的調研方法和手段，和用戶一起探討業務流程設計的合理性、准確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業務流程的設計合理性、准確性等等問題，及時地提出改進意見和方法。 實現手段：拜訪（誘導）、原型演示 輸出成果：調研分析報告、原型反饋報告、業務流程報告 第三階段：「確認式」（Afirm） 這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，並能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查業務流程報告、數據項表以及操作承建方提供的DEMO系統，來提出反饋意見，並對已經可接受的報告、文檔簽字確認。 實現手段：拜訪（回顧、確認），提交業務流程報告、數據項表；原型演示系統 輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見（後三者可以統一歸入需求分析報告中，提交用戶方、監理方進行確認和存檔） 整體來講，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和採用，對用戶和承建方都同樣提供了項目成功的保證。當然在系統建設的過程中，特別在採用迭代法的開發模式時，需求分析的工作需一直進行下去，而在後期的需求改進中，工作則基本集中在後兩個階段中。

『貳』 軟體項目需求分析難在哪裡

有幾種原因使需求分析變得困難：(1)客戶說不清楚需求;(2)需求自身經常變動;(3)分析人員或客戶理解有誤。 1 客戶說不清楚需求 有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多政府機構在搞網路建設，這些單位的領導和辦公人員大多不清楚計算機網路有什麼用，反而要軟體系統分析人員替他們設想需求。這類工程的需求是如此的主觀，以致產生很多貪污腐敗現象。 有些客戶心裡非常清楚想要什麼，但卻說不明白。讀者可能很不以為然。就舉日常生活的事例吧，比如說買鞋子。我們非常了解自已的腳，但沒法說清楚腳的大小和形狀。只能拿鞋子去試，試穿時感覺到舒服才會買鞋(居然也有神通廣大的售貨員，看一眼客戶的手，就知道應該穿什麼樣的鞋)。 如果客戶本身就懂軟體開發，能把需求說得清清楚楚，這樣的需求分析將會非常輕松、愉快。如果客戶全不懂軟體，但信任軟體開發方，這事也好辦。分析人員可以引導客戶，先闡述常規的需求，再由客戶否定不需要的，最終確定客戶真正的需求。最怕的就是「不懂裝懂」或者「半懂充內行」的客戶，他們會提出不切實際的需求。如果這些客戶甚至覺得自己是上帝的爸爸，那麼溝通和協商都會很困難。 2 需求自身經常變動 唐僧曾說：「妖要是有了仁慈之心，就不再是妖，是人妖。「 連妖都會變心，別說人了。所以喜新厭舊乃人之常情，世界也因此變得多姿多彩。 軟體的需求會變化嗎? 答：據歷史記載，沒有一個軟體的需求改動少於三次。唯一隻改動需求兩次的客戶是個死人。這個可憐的傢伙還是在運送第三次需求的路上被車子撞死的。 讓我們先接受「需求會變動」這個事實吧，免得在需求變動時驚慌失措。明白「需求會變動」這個道理後，在進行需求分析時就要留點神： (1)盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求。以便在進行系統設計時，將軟體的核心建築在穩定的需求上，否則將會吃盡苦頭。 (2)在合同中一定要說清楚「做什麼」和「不做什麼」。如果合同含含糊糊，日後扯皮的事情就多。 3 分析人員或客戶理解有誤 有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：「主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜裡雙眼能射出強光。……有趣的是，車里住著一種叫作『人'的寄生蟲，這些寄生蟲完全控制了車。」 軟體系統分析人員不可能都是全才。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致開發人員白幹活，吃力不討好。我讀中學時候最怕寫作文逃題，如果逃題了，不管作文寫得多長，總是零分。所以分析人員寫好需求說明書後，要請客戶方的各個代表驗證。如果問題很復雜，雙方都不太明白，就有必要請開發人員快速構造軟體的原型，雙方再次論證需求說明書是否正確。 由於客戶大多不懂軟體，他們可能覺得軟體是萬能的，會提出一些無法實現的需求。有時客戶還會把軟體系統分析人員的建議或答復給想歪了。 有一個軟體人員滔滔不絕地向客戶講解在「信息高速公路上做廣告」的種種好處，客戶聽得津津有味。最後，心動的客戶對軟體人員說：「好得很，就讓我們馬上行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。」為什麼軟體系統分析員的工資要比普通程序員高?

『叄』 需求分析時應該建立哪些模型，如何建立

需求分析是指理解用戶需求，就軟體功能與客戶達成一致，估計軟體風險和評估項目代價，最終形成開發計劃的一個復雜過程。（這個和我在微軟體驗到的又不太一樣，微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接受程度，這一點也可以理解，因為公司的性質有根本差別）在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟體設計打下基礎。需求分析階段結束後，要求得到：1.SRS文檔 (System Requirement Specification); 2.DRM 文檔；3.Acceptance Plan.

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。

狹義上理解：需求分析指需求的分析、定義過程。

一、為什麼要需求分析

需求分析就是分析軟體用戶的需求是什麼.如果投入大量的人力，物力,財力,時間,開發出的軟體卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發一個軟體,最後卻不滿足用戶的要求,從而要重新開發過,這種返工是讓人痛心疾首的.(相信大家都有體會)比如,用戶需要一個for linux的軟體,而你在軟體開發前期忽略了軟體的運行環境,忘了向用戶詢問這個問題,而想當然的認為是開發for windows的軟體,當你千辛萬苦地開發完成向用戶提交時才發現出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.

需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟體開發的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟體系統的開發中,他的作用要遠遠大於程序設計.

二、需求分析的任務

簡言之,需求分析的任務就是解決"做什麼"的問題,就是要全面地理解用戶的各項要求,並准確地表達所接受的用戶需求.

三、需求分析的過程

需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規格說明,評審.

問題識別
就是從系統角度來理解軟體,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標准.這些需求包括：功能需求(做什麼),性能需求(要達到什麼指標),環境需求(如機型,操作系統等),可靠性需求(不發生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟體運行是所需的內存,CPU等),軟體成本消耗與開發進度需求,預先估計以後系統可能達到的目標.

分析與綜合
逐步細化所有的軟體功能,找出系統各元素間的聯系,介面特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最後,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什麼的模型).

制訂規格說明書
即編制文檔,描述需求的文檔稱為軟體需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交.

評審
對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過才可進行下一階段的工作,否則重新進行需求分析。

四、需求分析的方法

需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.

原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.

原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.

原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。

在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。

追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.

五、需求分析的20條法則

客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦（如一方要求而另一方不願意或不能夠滿足要求）。

1、 分析人員要使用符合客戶語言習慣的表達
需求討論集中於業務需求和任務，因此要使用術語。客戶應將有關術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。

2、分析人員要了解客戶的業務及目標
只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助於開發人員設計出真正滿足客戶需要並達到期望的優秀軟體。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新系統，那麼開發和分析人員應使用一下目前的舊系統，有利於他們明白目前系統是怎樣工作的，其流程情況以及可供改進之處。

3、 分析人員必須編寫軟體需求報告
分析人員應將從客戶那裡獲得的所有信息進行整理，以區分業務需求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客戶就能得到一份「需求分析報告」，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易於翻閱和理解的方式組織編寫。客戶要評審此報告，以確保報告內容准確完整地表達其需求。一份高質量的「需求分析報告」有助於開發人員開發出真正需要的產品。

4、 要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性「需求分析報告」的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的價值；雖然它們不太難於理解，但是客戶可能對此並不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。

5、 開發人員要尊重客戶的意見
如果用戶與開發人員之間不能相互理解，那關於需求的討論將會有障礙。共同合作能使大家「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間，同樣，客戶也應對開發人員為項目成功這一共同目標所做出的努力表示尊重。

6、 開發人員要對需求及產品實施提出建議和解決方案
通常客戶所說的「需求」已經是一種實際可行的實施方案，分析人員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的事情後，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人員還能提出增加一些用戶沒有發現的很有價值的系統特性。

7、 描述產品使用特性
客戶可以要求分析人員在實現功能需求的同時還注意軟體的易用性，因為這些易用特性或質量屬性能使客戶更准確、高效地完成任務。例如：客戶有時要求產品要 「界面友好」或「健壯」或「高效率」，但對於開發人員來講，太主觀了並無實用價值。正確的做法是，分析人員通過詢問和調查了解客戶所要的「友好、健壯、高效所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡，以確保做出合理的取捨。

8、 允許重用已有的軟體組件
需求通常有一定靈活性，分析人員可能發現已有的某個軟體組件與客戶描述的需求很相符，在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠降低新系統的開發成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們並不完全適合您所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。

9、 要求對變更的代價提供真實可靠的評估
有時，人們面臨更好、也更昂貴的方案時，會做出不同的選擇。而這時，對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。所以，客戶有權利要求開發人員通過分析給出一個真實可信的評估，包括影響、成本和得失等。開發人員不能由於不想實施變更而隨意誇大評估成本。

10、 獲得滿足客戶功能和質量要求的系統
每個人都希望項目成功，但這不僅要求客戶要清晰地告知開發人員關於系統「做什麼」所需的所有信息，而且還要求開發人員能通過交流了解清楚取捨與限制，一定要明確說明您的假設和潛在的期望，否則，開發人員開發出的產品很可能無法讓您滿意。

11、 給分析人員講解您的業務
分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析人員能把握客戶業務的細微潛在之處，他們可能不知道那些對於客戶來說理所當然的「常識」。

12、 抽出時間清楚地說明並完善需求
客戶很忙，但無論如何客戶有必要抽出時間參與「頭腦高峰會議」的討論，接受采訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點，而過後發現還需要您的講解，這時請耐心對待一些需求和需求的精化工作過程中的反復，因為它是人們交流中很自然的現象，何況這對軟體產品的成功極為重要。

13、 准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的。由於處理細節問題不但煩人而且耗時，因此很容易留下模糊不清的需求。但是在開發過程中，必須解決這種模糊性和不準確性，而客戶恰恰是為解決這些問題作出決定的最佳人選，否則，就只好靠開發人員去正確猜測了。

在需求分析中暫時加上「待定」標志是個方法。用該標志可指明哪些是需要進一步討論、分析或增加信息的地方，有時也可能因為某個特殊需求難以解決或沒有人願意處理它而標註上「待定」。客戶要盡量將每項需求的內容都闡述清楚，以便分析人員能准確地將它們寫進「軟體需求報告」中去。如果客戶一時不能准確表達，通常就要求用原型技術，通過原型開發，客戶可以同開發人員一起反復修改，不斷完善需求定義。

14、 及時作出決定
分析人員會要求客戶作出一些選擇和決定，這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切，盡快做處理，做決定，因為開發人員通常只有等客戶做出決定才能行動，而這種等待會延誤項目的進展。

15、 尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本。客戶所希望的某些產品特性可能在技術上行不通，或者實現它要付出極高的代價，而某些需求試圖達到在操作環境中不可能達到的性能，或試圖得到一些根本得不到的數據。開發人員會對此作出負面的評價，客戶應該尊重他們的意見。

16、 劃分需求的優先順序
絕大多數項目沒有足夠的時間或資源實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，是需求開發的主要部分，這只能由客戶負責設定需求優先順序，因為開發者不可能按照客戶的觀點決定需求優先順序；開發人員將為您確定優先順序提供有關每個需求的花費和風險的信息。 在時間和資源限制下，關於所需特性能否完成或完成多少應尊重開發人員的意見。盡管沒有人願意看到自己所希望的需求在項目中未被實現，但畢竟是要面對現實，業務決策有時不得不依據優先順序來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。

17、 評審需求文檔和原型
客戶評審需求文檔，是給分析人員帶來反饋信息的一個機會。如果客戶認為編寫的「需求分析報告」不夠准確，就有必要盡早告知分析人員並為改進提供建議。更好的辦法是先為產品開發一個原型。這樣客戶就能提供更有價值的反饋信息給開發人員，使他們更好地理解您的需求；原型並非是一個實際應用產品，但開發人員能將其轉化、擴充成功能齊全的系統。

18、 需求變更要立即聯系
不斷的需求變更，會給在預定計劃內完成的質量產品帶來嚴重的不利影響。變更是不可避免的，但在開發周期中，變更越在晚期出現，其影響越大；變更不僅會導致代價極高的返工，而且工期將被延誤，特別是在大體結構已完成後又需要增加新特性時。所以，一旦客戶發現需要變更需求時，請立即通知分析人員。

19、 遵照開發小組處理需求變更的過程
為將變更帶來的負面影響減少到最低限度，所有參與者必須遵照項目變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最後做出合適的決策，以確定應將哪些變更引入項目中。

20、 尊重開發人員採用的需求分析過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性，分析人員採用的方法有其合理性。也許客戶認為收集需求的過程不太劃算，但請相信花在需求開發上的時間是非常有價值的；如果您理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術，那麼整個過程將會更為順利。

「需求確認」意味著什麼

在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標志行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文檔的最後一行下面簽名，於是我就簽了，否則這些開發人員不開始編碼。」

這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上簽了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」

同樣問題也會發生在僅把「簽字確認」看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著「需求分析報告」說：「您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什麼，您應早些告訴我們。」

這兩種態度都是不對的。因為不可能在項目的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。

對「需求分析報告」的簽名是建立在一個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文檔表述了我們對項目軟體需求的了解，進一步的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和項目階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦來源於項目的改進和需求的誤差或市場和業務的新要求等。 需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成一個持續良好的客戶與開發人員的關系，為項目的成功奠定了堅實的基礎。

六、點評需求分析誤區

要想說什麼是好的需求分析，不如說什麼是不好的需求分析，知道什麼是不好的，自然也就知道了什麼是好的。以下就是一些不好的情況：

（1）創意和求實
毋庸質疑的，每個人都會為自己的一個新的Idea而激動萬分，特別是當這個Idea受到一些根本不知道你原本要幹嘛的人的驚贊時。但是請注意，當你激動得意的時候，你可能已經忘了你原本是在描述一個需求，而不是在策劃一個創意、創造一個概念。很多剛開始做需求分析的人員都或多或少的會犯這樣的錯誤，陶醉在自己的新想法和新思路中，卻違背了需求的原始客觀性和真實性原則。

永遠別忘了：需求不是空中樓閣，是實實在在的一磚一瓦。

（2）解剖的快感
幾乎所有搞軟體的人，做需求分析的時候，一上來就會把用戶告訴你的要求，完完整整的作個解剖，切開分成幾個塊，再細分成幾個子塊，然後再條分縷析。可是當用戶迷惑的看著你辛辛苦苦做出來的分析結果問你：我想作一個數據備份的任務，怎麼做？這時，你會發現，需要先後打開三個窗口才能完成這個任務。

永遠別忘了：分解是必需的，但最終的目的是為了更好的組合，而不是為了分解。

（3）角度和思維
經常聽到這樣的抱怨：「用戶怎麼可以提出這樣苛刻的要求呢？」。細細一了解，你會發現，用戶只不過是要求把一個需要兩次點擊的功能，改成只有一次點擊。這樣會導致需要改變需求、改變編碼、甚至重新測試，增加工作量。可是，如果換個角度來想想，這個功能，開發的時候只用了幾次、幾十次，可是用戶每天都要用幾百次甚 至幾千次幾萬次，改動一下就減少了一半的工作量，對他來說，這樣的需求難道會苛刻嗎？

永遠別忘了：沒有任何需求是不對的，不對的只是你的需求分析。試著站在用戶的思維角度想想，你的需求分析就會更加的貼近用戶，更加的合理。軟體應該是以人為本的。

（4）程序員邏輯
從程序員成長為系統分析員是一個普遍的軌跡，但並不是一個好的程序員就必然能成為一個好的系統分析員。一些程序員的固化邏輯，使得他們在做需求分析的時候往往鑽進了一些牛角裡面。比如說1／0邏輯（或者是說黑白邏輯），認為不是這樣就是那樣，沒有第三種情況。可實際情況往往是，在一定的時候是這樣，其它時候是那樣。又比如窮舉邏輯，喜歡上來就把所有一二三可能的情況列舉出來，然後一個一個分別處理，每個佔用三分之一的時間；可是實際的情況往往是，三分之一的情況佔了99％的比例，其它兩種情況一年都不會遇到一次。實際中還有很多這樣的例子，不一一列舉了。

永遠別忘了：需求分析和程序設計不盡相同，合理、可行是才是重要的。跳出程序設計的圈子，站在系統的角度上來看問題，你的結論會截然不同。

『肆』 我一名程序員，老闆讓我寫項目的需求分析，關鍵他們還沒搞清楚想要什麼樣的功能，我無從下手，很糾結 時間

程序員是要根據項目的需求分析來寫程序的，而項目的需求分析是得根據客戶的需求寫的，如果客戶還不清楚想要什麼樣的功能，你也只能等他清楚了才能開始寫，要不然程序就白做了。如果時間緊，老闆有讓你快趕出來的話，你也只能先抓住客戶的其中一些需求來寫，以後好慢慢補充進去

『伍』 程序員就業前景分析

從行業的整體情況來看，程序員的工作相對來說還是具有一定壓力的，而且不少程序員的工作周期也比較長。雖然程序員的工作壓力比較大，但是從IT行業的基本面來看，未來IT行業的發展前景還是不錯的。

程序員就業分布較為集中的區域為省會城市、北京、上海與深圳，其中省會城市就業比例為39%。在IT行業發展迅速、產業鏈比較發達的北京、上海、深圳及省會城市，因為就業崗位需求的數量較多、薪資待遇較好，吸引了超過9成多的就業程序員選擇在以上區域尋求個人發展。

程序員屬性：

從表面上看，程序員是會使用計算機語言編寫程序的群體。實質上，程序員是聯結精神世界與物質世界的最有效的中介，將人語轉變為物語創造財富。以前所說的技術，是分科的技術，程序員的技術是全面涵蓋的技術。

從人的意識到物的結果的全面流程看，程序員所用的從應用層到物理層的分層次體系是一種嚴密有效的邏輯結構，這正是經濟建設需要而傳統文化沉澱缺乏的要素。

『陸』 怎樣寫軟體開發需求分析

1、需求分析文檔的重要性
在軟體項目開發的生命周期中，可以說需求分析文檔占據著很重要的作用。
（1）它是和用戶進行交流得出的一個規范結果
（2）它是衡量和評價項目功能是否達到用戶需要的標准
（3）它對後期的資料庫設計、概要設計、詳細設計以及整個編碼開發、系統測試起著指引的作用

『柒』 如何在敏捷開發中做需求分析

【敏捷項目沒有需求分析嗎?】 在很多人的印象中，敏捷軟體開發是種類似黑客行為的過程，是程序員最愛的勾當。不寫文檔，不作需求分析，沒有項目經理，做什麼東西完全是程序員自己的行為。所以他們認為這樣的過程無法滿足真正大型項目和復雜項目的需要，因此在經過考慮後，放棄了敏捷方法。 項目經理圈子真的是這樣嗎?敏捷過程到底是如何做需求分析?用戶故事和用例有什麼區別?敏捷過程如何去管理需求的?這些是一些想要實踐敏捷的人一直在困惑的事情。 我們常常看到書中講，程序員拿到一個用戶故事後，怎麼計劃，怎麼分解，怎麼寫單元測試，怎麼小步前進，怎麼持續集成。這是典型的程序員視角。事實上，敏捷方法分為三部分，敏捷項目管理，敏捷需求分析，敏捷軟體開發。上述書中提到的完全是敏捷開發中的實踐，很多人了解到的敏捷，只是敏捷的三分之一。 【敏捷項目中誰來做需求分析?】 在敏捷的團隊中，作一個敏捷程序員確實是非常舒服的事情。從程序員的角度來看，只需要選擇一張他感興趣的故事卡片，了解清楚該卡片的需求，開始從功能測試寫代碼，等通過了所有測試就完工。基本上不需要考慮太多的事情，非常輕松愉快。但程序員向誰去問清楚需求?故事卡片是怎樣寫出來的呢?讓我們來關注開發前發生的事情。 了解敏捷過程的人都知道，Kent Beck在XP過程中提到了現場客戶，如果一個敏捷團隊能夠有現場客戶，這當然是最棒的事情。但多數情況下，客戶都是很忙碌的，很難全力投入到軟體開發過程中。這時候，我們就需要商務分析師這個角色，來充當客戶的角色。 我在公司的團隊中曾擔任的就是商務分析師這個角色。商務分析師最重要的職責就是與客戶交談，了解和分析需求，將其製作成用戶故事並將需求轉述給程序員。同時，商務分析師也要代替客戶負責功能驗收測試。 【敏捷項目中如何進行需求分析?】 敏捷思想的核心是人與交流。需求問題實際上是一個交流問題。商務分析師要和客戶交流，搞清楚客戶到底需要什麼，到底為什麼需要這些東西。商業價值是商務分析師關注的最終目標。有了目標的指向，就可以不迷失方向。和客戶進行交流，最終目的就是挖掘出客戶的商業目標。可能大家會經常有這樣的經驗，客戶說，我要這個功能，我想要怎麼怎麼樣。這時候要特別注意，他說的這些東西並不是真正的需求。商務分析師需要詳細的問客戶為什麼，挖掘出他真正的目標。 在這個目標下，商務分析師開始進行需求的分析：我們到底是否真的需要這個需求?有沒有更好的解決方案?有沒有簡單並且低廉的方式?換一種形式是不是也能達到這樣的需求?這個需求有多少地方涉及到以前的軟體變更? 搞清楚這些事情後，就可以寫出用戶故事。用戶故事的書寫遵循一定的原則，一般包括三部分："作為(系統的一個涉眾)，我想要(做一件事)，從而(達到一個商業價值)"。在書寫的時候格式比較隨意，可以在故事卡背面寫上注釋或疑問，甚至畫上界面原形圖。 舉一個最常見的用戶故事例子，「作為一個普通用戶，我希望能夠用用戶名和密碼登錄，以便我能享受到個性化的服務」。其中，用戶是系統涉眾，登錄是他想要做的事情，而他的目標是獲得個性化的服務。 從這個例子我們可以想像到，這個頁面可能存在兩個文本框，用於輸入用戶名和密碼，有一個按鈕來登錄，並且不登錄就不能看到個人資料，另外，如果用戶輸入錯誤需要提示「登錄失敗請重試」。這就是可見性，也可以稱為可測試性。我們可以根據這樣的可見性寫出功能測試，從而驅動這個用戶故事的開發，這被稱為 Acceptance Driven Development。 用戶故事的作用有兩個，一個是作為進度跟蹤的依據，一個是作為與人交談的備忘錄。用戶故事卡片並不是很精確的需求，因此不需要把事情描述的非常清楚。將需求的詳細分析推遲到實現前夕來完成，這是敏捷需求分析的精華所在。任何提前做好的東西都會導致浪費，敏捷過程提倡足夠就好，避免浪費。 不少人對用戶故事和用例的區別感到疑惑。用戶故事的作用是備忘功能，而不是文檔。而用例需要詳細的描述其操作步驟，以及每個異常路徑，因而起到了文檔的作用。用戶故事是可見的商業價值，而不是功能描述。每個用戶故事的粒度和工作量都相差不多，這和用例有很大的區別。用戶故事是小粒度的，可測試的，可見的，並且是有價值的。 【敏捷項目需求分析案例】 公司有個項目組作的是一個網游物品交易平台。該平台是典型的互聯網項目，在開工的時候客戶對功能需求還不明確，但需要快速推出搶占市場，正是最適合敏捷過程的項目。 在項目伊始，商務分析師和客戶做了深入的談話，了解他的商業構想，他的盈利模式，搞清楚宏觀的結構，然後思考並整理獲得的結果，花1-2天時間將客戶需求大略整理為幾十個用戶故事。這些用戶故事並不完善，不足以做好整個系統。但對於我們開始項目的前一陣，已經足夠了。我們可以從這里開始項目。敏捷方法希望快速交付可用的軟體。實現軟體的快速交付是通過迭代來完成。在迭代開始前，由一組有經驗的開發人員大致評估一下用戶故事，標記出不同的難度和風險，並提出問題供商務分析師來獲得更詳細的信息，商務分析師會和相關涉眾去討論。然後商務分析師將推薦優先順序最高的一組用戶故事給客戶來挑選，客戶可以選擇這些用戶故事，或者指出從他的視角看到的優先順序更高的用戶故事。這些將成為下一個迭代的內容。 項目經理圈子客戶看到每個迭代交付的可運行的軟體後或者得到用戶反饋後，常常會有新的想法冒出來。有些想法是好的，有些想法就屬於看到別家網站有這個功能，不假思索的提出的功能。這些不同的需求都需要經過認真的分析，找出哪些是值得我們立即考慮的，哪些是不用急迫的去實現的。 有一次和客戶談話時，他說到希望增加拍賣功能。那麼，我們為什麼需要拍賣呢?客戶說希望讓用戶拍賣物品以獲得最高價格。經過考慮，我們發現網游物品的實時性和唯一性決定了系統不適合使用拍賣機制。拍賣的時效性無法滿足實時交易的要求，因此，用戶最終放棄了這個特性。 另一次，客服人員提出增加一個查詢用戶交易的功能，而此時我們有其他更加重要的功能需要先去考慮，查詢用戶交易功能可以由技術人員臨時通過資料庫直接代為查詢，因為項目運營初期交易不是很多，暫時還不需要專門的後台功能來支持客服的工作。所以把這個需求卡片一直貼在牆壁上，始終沒有排到最高的優先順序。 客戶一開始也不是很能夠接受敏捷需求中強調商業價值和優先順序的做法。但經過幾個月的磨合，客戶也逐漸適應了許多敏捷思想，甚至我在和客戶討論時，偶然提起了後期的某種可能的情況，他們還能夠幫我糾正應當考慮目前的情況，為近期的情況作計劃。 用戶故事的跟蹤和管理是由項目經理來進行。每個迭代跟蹤卡片的進展，是否已經開始實現?是否已經完成代碼開發?是否已經開始功能測試?不同的卡片在迭代前都會評估為不同的大小。我們一般分為大中小三級。等實踐過幾個迭代後，團隊的開發速度基本保持恆定，我們就可以很容易的知道每個迭代能做多少個用戶故事，這樣就可以安排下一迭代的開發。 每個迭代內分析好恰好足夠下一個迭代開發的需求，就是商務分析師每個迭代的主要工作內容。商務分析師的需求分析工作在上一個迭代完成，包括需求的了解，分析，評估和排列優先順序。 在每個迭代開始的時候，由商務分析師主持召開迭代計劃會議，在會議上向所有的程序員解釋這個迭代要完成的用戶故事，然後由程序員自由提問，知道他們能夠獲得足夠開始實現該功能的信息。 在程序員完成一個用戶故事後，商務分析師還要來代表客戶做功能驗收測試，查看是否完成了預計的功能，是否有程序員還沒有想到的異常情況。如果存在問題需要退回給程序員繼續完成。這在一定程度上保證了系統完成的需求不偏離客戶的要求。當然，更多的測試還需要QA來完成。 我們的實踐充分表明了，敏捷過程並不是沒有需求分析，而是把需求分析過程分散到整個開發的過程中，讓開發和需求分析並行進行。這就是公司敏捷方法實施成功的秘訣之一。而商務分析師在這個過程中，起到了紐帶和橋梁的作用，是一個團隊不可缺少的角色 。

『捌』 java項目需求分析怎麼寫

目前， 國內外信息化建設已經進入基於Web應用為核心的階段， Java作為應用於網路的最好語言，前景無限看好。然而，就算用Java建造一個不是很煩瑣的web應用，也不是件輕松的事情。概括一下，實施Java的WEB項目需要掌握的技術如下：

lJava語言

l面向對象分析設計思想

l設計模式和框架結構

lXML語言

l網頁腳本語言

l資料庫

l應用伺服器

l集成開發環境

下面我們具體地看每個技術.

1、Java語言

Java語言體系比較龐大，包括多個模塊。從WEB項目應用角度講有JSP、Servlet、JDBC、JavaBean(Application)四部分技術。

（1）、Java Database Connectivity(JDBC)技術

在Java Web應用開發中，資料庫管理系統（RDBMS）的使用是不可缺少的。JDBC(Java Database Connectivity) 是一種用於執行SQL 語句的 Java API。它由一組用 Java 編程語言編寫的類和介面組成。JDBC 為工具/資料庫開發人員提供了一個標準的API，使他們能夠用純Java API 來編寫資料庫應用程序。

簡單地說，JDBC 可做三件事：

l與資料庫建立連接，

l發送SQL 語句，

l處理結果。

（2）、Servlet技術

Servlet是運行在伺服器端的程序，可以被認為是伺服器端的applet。servlet被Web伺服器（例如Tomcat）載入和執行，就如同applet被瀏覽器載入和執行一樣。servlet從客戶端(通過Web伺服器)接收請求，執行某種操作，然後返回結果。

Servlet的主要優點包括

lServlet是持久的。servlet只需Web伺服器載入一次，而且可以在不同請求之間保持服務(例如一次資料庫連接)。

lServlet是與平台無關的。如前所述，servlet是用Java編寫的，它自然也繼承了Java的平台無關性。

lServlet是可擴展的。由於servlet是用Java編寫的，它就具備了Java所能帶來的所有優點。Java是健壯的、面向對象的編程語言，它很容易擴展以適應你的需求。servlet自然也具備了這些特徵。

lServlet是安全的。從外界調用一個servlet的惟一方法就是通過Web伺服器。這提供了高水平的安全性保障，尤其是在你的Web伺服器有防火牆保護的時候。

lServlet可以在多種多樣的客戶機上使用。由於servlet是用Java編寫的，所以你可以很方便地在HTML中使用它們。

（3）、JavaServer Pages(JSP)技術

JSP是從Servlet上分離出來的一小部分，簡化了開發，加強了界面設計。JSP定位在交互網頁的開發。運用Java語法，但功能較Servlet弱了很多，並且高級開發中只充當用戶界面部分。JSP容器收到客戶端發出的請求時，首先執行其中的程序片段，然後將執行結果以HTML格式響應給客戶端。其中程序片段可以是：操作資料庫、重新定向網頁以及發送 E-Mail 等等，這些都是建立動態網站所需要的功能。所有程序操作都在伺服器端執行，網路上傳送給客戶端的僅是得到的結果，與客戶端的瀏覽器無關，因此，JSP 稱為Server-Side Language。

JavaServer Pages的主要優點包括

●一次編寫，各處執行(Write o­nce, Run Anywhere)特性

作為Java 平台的一部分，JavaServer Pages 技術擁有Java語言「一次編寫，各處執行」的特點。隨著越來越多的供貨商將JavaServer Pages 技術添加到他們的產品中，您可以針對自己公司的需求，做出審慎評估後，選擇符合公司成本及規模的伺服器，假若未來的需求有所變更時，更換伺服器平台並不影響之前所投下的成本、人力所開發的應用程序。

● 搭配可重復使用的組件

JavaServer Pages技術可依賴於重復使用跨平台的組件（如：JavaBean或Enterprise JavaBean組件）來執行更復雜的運算、數據處理。開發人員能夠共享開發完成的組件，或者能夠加強這些組件的功能，讓更多用戶或是客戶團體使用。基於善加利用組件的方法，可以加快整體開發過程，也大大降低公司的開發成本和人力。

● 採用標簽化頁面開發

Web 網頁開發人員不一定都是熟悉Java 語言的程序員。因此，JSP 技術能夠將許多功能封裝起來，成為一個自定義的標簽，這些功能是完全根據XML 的標准來制訂的，即JSP 技術中的標簽庫(Tag Library)。因此，Web 頁面開發人員可以運用自定義好的標簽來達成工作需求，而無須再寫復雜的Java 語法，讓Web 頁面開發人員亦能快速開發出一動態內容網頁。

今後，第三方開發人員和其他人員可以為常用功能建立自己的標簽庫，讓Web 網頁開發人員能夠使用熟悉的開發工具，如同HTML 一樣的標簽語法來執行特定功能的工作。

●N-tier 企業應用架構的支持

有鑒於網際網路的發展，為因應未來服務越來越繁雜的要求，且不再受地域的限制，因此，

必須放棄以往Client-Server的Two-tier 架構，進而轉向更具威力、彈性的分散性對象系統。由於JavaServer Page 技術是Java 2 Platform Enterprise Edition (J2EE)集成中的一部分，它主要是負責前端顯示經過復雜運算後之結果內容，而分散性的對象系統則是主要依賴EJB ( Enterprise JavaBean )和JNDI ( Java Naming and Directory Interface )構建而成。

（4）、JavaBean(Application)應用組件技術
Application是Java應用程序，在WEB項目和一些開發中主要應用JavaBean。它就是Application的一部分，邏輯運算能力很強，能極大的發揮Java語言的優點。JavaBean 被稱為是Java 組件技術的核心。JavaBean 的結構必須滿足一定的命名約定。JavaBean能提供常用功能並且可以重復使用，這使得開發人員可以把某些關鍵功能和核心演算法提取出來封裝成為一個組件對象，這樣就增加了代碼的重用率和系統的安全性。

高級的WEB項目會應用到以上所有技術，它們之間聯合使用和協作開發會提高開發的效率和系統的性能。

2、面向對象分析設計思想

Java語言是完全面向對象的語言，所以在項目設計時會有很大的幫助，在設計時應盡量舍棄以往的面向過程的設計方式。

在分析項目業務關系的時候，應用一些UML(Unified Modeling Language)圖,例如常用的用例圖(use case diagram)，類圖(class diagram)，時序圖(sequence diagram)等等,會有很大的幫助，這樣能盡快找出業務邏輯主要面對的對象，然後對每個對象進行行為劃分，最後再實現對象之間的集成和通信。

3、設計模式和框架結構

Java從語言角度來講不是很難，但是從整體設計角度來講我們還需要了解一些高級應用框架。如果要設計一個良好的框架結構，單單只掌握Java語言遠遠不夠。這就涉及到一個設計模式，還有和設計模式相關的一些知識。

設計模式在Java項目實施過程更是重中之重。主要在與兩層的設計模式、三層的設計模式和N層的設計模式。它直接決定著項目的應用、部署和實際開發設計。

在普通的WEB項目中很多採用兩層的開發結構。JSP+Servlet或JSP+JavaBean。當對開發要求高的項目中使用很多的還是MVC的三層開發結構，也就是JSP+Servlet+JavaBean。它能分有效的分離邏輯開發，使開發人員能專注於各自的開發。同時也能時整個開發結構流程更清晰，但是需要比較高的開發配合度。
在項目中，我們經常使用著名的Model-View-Controller(MVC)架構。MVC架構是隨著smalltalk language語言的發展提出的，它是一個著名的用戶界面設計架構。經典的MVC架構把一個組件（可認為是整個應用程序的一個模塊）劃分成三部分組 Model管理這個模塊中所用到的數據和業務邏輯。而View 管理模塊如何顯示給用戶，Controller 決定如何處理用戶和該模塊互動式時候產生的事件 如用戶點擊一個按鈕等。

4、XML語言

在伺服器和設計模式結構中會應用到自定義文件，而且在應用高級設計時也會定義自用的標簽，現在流行的是用XML去定義配置，所以XML語言應該有一定掌握。

當前，Java 2平台企業版（J2EE）架構在廠商市場和開發者社區中倍受推崇。作為一種工具，可擴展標記語言（XML）簡化了數據交換、進程間消息交換這一類的事情，因而對開發者逐漸變得有吸引力，並開始流行起來。自然，在J2EE架構中訪問或集成XML解決方案的想法也很誘人。因為這將是強大系統架構同高度靈活的數據管理方案的結合。

XML的應用似乎是無窮無盡的，但它們大致上可以分為三大類：
1、簡單數據的表示和交換（針對XML的簡單API（SAX）和文檔對象模型（DOM）語法解析，不同的文檔類型定義（DTDs）和概要（schemas））
2、用戶界面相關、表示相關的上下文（可擴展樣式表語言（XSL），可擴展樣式表語言轉換（XSLT））
3、面向消息的計算（XML-RPC（遠程過程調用），基於SOAP協議的Web 服務（Web Services），電子化業務XML（ebXML））

5、網頁腳本語言

為了提高WEB項目的整體性能，提高人機交互的友好界面，網頁的腳本語言是很有用處的，有的時候可以解決很大的難題或提高程序的性能和應用性。

網頁腳本語言的執行都是在客戶端執行的，速度很很快，並且大多的操作與伺服器沒有交互運算，所以在一些應用中非常理想。在設計WEB項目的應用中，網頁的腳本語言起著不能忽視的作用，所以如果設計WEB項目的應用中，對JavaScript應有一定的了解。

JavaScript是一種基於對象(Object Based)和事件驅動(Event Driven)並具有安全性能（Secure）的腳本語言。使用它的目的是與HTML超文本標記語言、Java 腳本語言（Java小程序）一起實現在一個Web頁面中鏈接多個對象，與Web客戶交互作用。從而可以開發客戶端的應用程序等。它是通過嵌入或調入在標準的HTML語言中實現的。它具有以下幾個基本特點：

1.它是一種腳本編寫語言
JavaScript是一種腳本語言，它採用小程序段的方式實現編程。像其它腳本語言一樣,JavaScript同樣已是一種解釋性語言,它提供了一個易的開發過程。
它的基本結構形式與C、C++、VB十分類似。但它不像這些語言一樣，需要先編譯，而是在程序運行過程中被逐行地解釋。它與HTML標識結合在一起，從而方便用戶的使用操作。

2.基於對象的語言。
JavaScript是一種基於對象的語言，同時以可以看作一種面向對象的。這意味著它能運用自己已經創建的對象。因此，許多功能可以來自於腳本環境中對象的方法與腳本的相互作用。

3.簡單性
JavaScript的簡單性主要體現在：首先它是一種基於Java基本語句和控制流之上的簡單而緊湊的設計, 從而對於學習Java是一種非常好的過渡。其次它的變數類型是採用弱類型，並未使用嚴格的數據類型。

4.安全性
JavaScript是一種安全性語言，它不允許訪問本地的硬碟，並不能將數據存入到伺服器上，不允許對網路文檔進行修改和刪除，只能通過瀏覽器實現信息瀏覽或動態交互。從而有效地防止數據的丟失。

5. 動態性
JavaScript是動態的，它可以直接對用戶或客戶輸入做出響應，無須經過Web服務程序。它對用戶的響應，是採用以事件驅動的方式進行的。所謂事件驅動，就是指在主頁(Home Page)中執行了某種操作所產生的動作，就稱為「事件」(Event)。比如按下滑鼠、移動窗口、選擇菜單等都可以視為事件。當事件發生後，可能會引起相應的事件響應。

6、開發工具

（1）、資料庫

在主要的應用中，資料庫相關的環節應用很多，所以對資料庫應該有一定了解。不能單單只了解一種資料庫，因為在很多實際開發中會提出很多資料庫解決方案，所以只有在了解多種資料庫的情況下才能有一個比較方案。

對於資料庫應該了解他的性能和一些基本的操作常識，還有該資料庫的特點。而針對與Java語言WEB項目的資料庫開發則主要是對JDBC的應用，還有資料庫事務處理和連接池等高級概念的應用。

（2）、Web伺服器

同資料庫一樣，應該了解該伺服器的性能，特點和一些常識。

在應用方面，Web伺服器主要是針對於配置和部署，對目錄的配置，調試；對配置文件屬性的修改；對訪問許可權和並發性的控制；Java類的部署等。

（3）、集成開發環境（IDE）：

「公欲善其事， 必先利其器」. 對於Web應用開發人員來講，好的集成開發環境（IDE：Integrated Development Enviroment）是非常重要的。目前在市場上佔主導位置的一個集成開發工具就是Eclipse.

『玖』 初級程序員如何提高項目需求分析能力

找本需求分析的書來看看。其實初級程序員不需要太強的需求分析能力。

『拾』 如何做需求分析

隨著技術的不斷發展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟體工程，也越來越復雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規范的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。

網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網路和Web

伺服器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關系管理。）等項目管理中。

按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業務流程分析
3. 系統分析及軟體建模
4. 界面設計、交互設計及程序開發
5. 系統測試和文檔編寫
6. 客戶培訓、技術支持和售後服務

需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。

（一）如何做好需求分析及變更管理？

業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。

一：讓客戶暢所欲言，羅列出所有的需求

讓用戶將所有的想法盡可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕「勾引」起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求准確地記錄下來就完成了第一步的工作。

很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用伺服器、資料庫還是程序全部要重新開發！

二：透過現象分析潛在的需求

很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。

客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。

比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理伺服器；設計網路電子商店時今後增加庫存產品進銷存統計分析等等；限於時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今後的需求變更除了使項目開發更加順利以外，也為今後業務的進一步深入打下了更好的基礎。

筆者曾負責一個大型新聞網站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發現有四十頁的內容對程序開發來說都是重復的，而在其中一頁的角落卻畫了個「搜索其他網站相關新聞」的按鈕，並且沒有做任何說明，僅僅這10個字所完成的工作量完全頂的上其他整整四十頁重復贅述所做的工作，客戶完全不知道這個要求引發的問題實際就是一個搜索引擎的開發，通過協商，客人同意了修改成站內搜索的引擎。

三：利用自然的語言描述項目模型

在業務員與客戶進行溝通和調查時撰寫的需求分析，盡可能用自然的語言進行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發的各個成員都能清楚地理解需求含義，不至於在理解上產生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，並能以此為測試和驗收的依據。

請比較以下兩份關於需求的描述，
「用戶在訪問首頁的時候可以在點擊『客戶通道』按鈕，彈出填寫『用戶名』和『密碼』的窗口，輸入正確後在新窗口打開客戶通道的首頁，在該頁顯示所有可操作的功能的導航條和最新的導讀新聞鏈接列表 。」

「站點分為公開和加密兩種狀態，通過身份驗證機制使特有的用戶可以訪問到加密信息，並提供不同於普通用戶的功能。」

前段描述我們就很容易想像的出來設計完成的網站是什麼樣子，而後一段的描述可能會做出無數不同的版本，造成對需求理解的歧意。

四：利用示意圖和圖表將用戶的需求表現出來

需求分析無論文字上怎麼樣表述都還是抽象的，對客戶而言理解畢竟是困難的，將基本確定的需求製作出示意圖是最直觀有效的。

製作示意圖可以有很多種方式，用PowerPoint或Visio製作流程示意，用Html文檔製作界面示意都是可行的，最簡單利用畫圖和Word表格方式也完全可以，關鍵是利用示意圖將客戶的需求和即將開始設計的系統體現起來，在進行系統分析和程序開發之前，雙方對今後要完成的產品就能夠有直觀的認識，換言之，就是在產品還沒有真正進入開發階段的時候，雙方就對工作的結果達成統一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發過程，保證項目往正確的方向進行。

在RUP中有這樣的描述：

利用電影、卡通、圖片、表格和動畫片等製作示意圖開始，告訴我們用戶是誰，要發生什麼事情，如何發生。

以用戶友好的方式幫助收集並改進用戶需求。

鼓勵更有創造性、更加創新的設計解決方案。

鼓勵團隊復審，並避免所有人都不希望出現的特徵。

確保以可理解、直觀的方式實施特徵。

使訪談過程變得輕松，避免出現訪談沒有結果的現象。

簡單地說，製作示意圖就是使用工具向用戶 (主角) 說明（有時是動畫演示）系統如何適應組織的需要，並表明系統將如何運轉。協調員將初始示意板展示給小組，小組成員提供意見。之後，在舉辦研討班期間，示意板也進行「實時」演進。所以，您需要一種可以輕松更改示意板的畫圖工具。為了避免分散注意力，一般最好使用簡單的工具，比如圖表、白板或PowerPoint。

五：什麼人要看需求分析報告

項目經理、系統分析員、開發經理、交互設計師、測試人員、文檔人員包括客戶代表都應該看需求分析，並進行共同的討論，達成一致的意見。

我們經常會遇到業務人員辛辛苦苦談下來的項目，對開發人員來說卻是難以實現的，而技術人員設計的產品卻常常得不到客戶的認可，甚至發生糾紛，因此參與項目開發的人員都應該對這份需求有統一清晰的認識，並根據自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現的目標。

例如：

項目經理通過需求分析才能組建所需要的團隊包括配置工作環境，制定開發周期。
開發周期的限制和功能上的要求可能會影響到程序員採用什麼樣的語言和工具進行編寫；
操作用戶的技能水平將影響到交互設計師進行前台設計時做到什麼樣的精度；
界面設計人員根據項目的性質和定位確定表現方式。
測試人員了解測試環境和條件後才能對項目質量進行跟蹤和檢測；

通過下表，我們可以看的出不同角色根據需求的變更所進行的工作流程：

六：建立需求變更日誌，製作新版本的需求分析報告

盡管我們費了許多功夫在需求分析進行了最大可能的努力，但幾乎可以肯定的是，這份需求分析在開發過程中一定會發生變化，也許是出自客戶的遺漏，也可能是在開發過程中被激發出來的，這種變更有時是如此的頻繁和瑣碎，以至於往往不能將變更及時反饋到項目的各個角色中，那麼做好需求變更日誌就顯得非常重要。

在需求分析後面附上變更日誌，並將修改後的需求分析製作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調整。

在新版本的需求分析中，將變更多部分用特殊方式表明出來，並在日誌中記錄變更多重的明細。

關於需求分析和變更管理可以參照下圖示意：

七：本階段重點工作角色

在需求分析和變更管理的過程中，工作量最大的角色為客戶代表、業務員和項目經理。

客戶代表提出需求，業務員幫助整理和分析，項目經理對整個項目進行評估。

在實際工作中，很多項目失敗的起因都和需求分析有關。 客戶代表和業務員通常並非從事技術開發的專業人員，在討論需求的時候往往對項目的技術難度、工作量、時間進度把握不準確，這時候需要項目經理或技術人員進行參謀。

為了降低項目的風險，提高工作效率，有必要設計規范的需求管理計劃書，幫助客戶代表和業務員更好的完成任務。

以下提供一份需求管理計劃的模板可作為參考：

八：總結

根據筆者的經驗，要盡快做好需求分析掌握以下要點，也許能事半功倍：

仔細聆聽，羅列客戶的所有要求；
將需求進行分析，確認可操作的系統模型；
利用最自然的語言將系統進行描述，使每個開發人員不會產生歧意；
迅速確定網站的用戶角色；
比如訪客、會員、重要客戶、前台管理員、網站管理員、業務員等；
分析確定每個角色的許可權及可操作的功能；
比如會員可以查看特別信息、修改個人信息、退出登陸等；
前台管理員能夠登錄管理系統，能夠發布編輯修改信息，能夠審查會員資格等；
網站管理員可以更改欄目、修改網站界面等；
製作流程圖和示意圖將需求表現出來；
讓客戶參與到示意圖的設計中，及時正確的反應出需求變更。
製作需求變更日誌，保留升級版本，通過版本控制進行需求管理；
通過需求《管理計劃書》使每個參與人員看到共同的努力目標。