itpub論壇2009-06-15
文字tag：
需求分析
【it168 技術文章】
最近正在做新產品的需求分析，對需求分析階段的很多問題又有了重新的認識，在此結合以前的經驗，就軟體 需求分析階段的各個任務，做一下總結，與大家分享。
眾所周知，軟體需求分析是軟體生命週期的第二階段，主要對前期軟體定義及計畫階段提到的任務及計畫進行概要的補充，需求分析的主要任務不是確定將來的系統 怎麼完成某項工作，這是設計階段的事情，而是明確系統將要完成什麼功能，對目標系統將要完成的功能提出完整、準確的描述等；在我們國內很多軟體公司裡，需 求分析階段與設計階段沒有明確的界線，需求分析階段的很多任務作，都會放到設計階段來做或乾脆不做，一般很少嚴格按照軟體工程的方法來執行（通過cmm認證 的軟體公司還好些），大多數人理解下的需求分析階段的任務主要還是分三部分：需求的收集、需求整理與編寫及最終的評審，在此就這幾個階段中經常遇到的問題 作一下大體描述。
一、需求的收集
無論是老產品的改造還是新產品的開發，都需要收集大量的需求作為改造的重點物件，需求的收集也可籠統的分二大部分：內部需求與外部需求；內部需求一般包括 軟體在維護過程中客戶反饋的未處理的需求、公司內部其它各部門在實施軟體過程中反饋的需求及設計或研發人員在工作當中總結的對軟體易用性、效率等方面的需 求，還包括研究競爭對手的軟體而得出的需求等；外部需求一般包括軟體實施人員或**商對產品提出的改造建議、設計人員直接到客戶現場調研、通過與客戶溝通 而得到的需求等。在收集需求的過程中常會遇到以下幾方面的問題：
1、 誤解客戶需求，一般情況下需求分析人員與客戶在業務術語表達上有所不同，交流過程中可能會理解有誤，特別對於有二義性的需求，會導致分析人員誤解客戶的需求，也可以理解為需求表達比較模糊，不同的人有不同的理解。
2、 需求的不確定性，一是分析人員對需求把握不准，有些從各個渠道反饋回來的需求有些失真，不能完全表達客戶的意願；二是客戶需求的變動較大，不確定，不到真正實用很難表達清楚要實現的功能。
3、 對時間的合理規劃，收集過程中經常感覺時間太緊，無法完整的收集到客戶的需求，這一點主要還是跟事先沒有計畫好有關，需求的收集是乙個長期的過程，而不是在某一時間段內就能收集完的，好的需求在於平時的積累，是在日常維護工作中逐漸收集形成的。
善於主動尋找需求，而不是坐等需求，收集需求的過程中，要通過各種途徑來收集，主動跟客戶或同事交流，這樣才能在溝通過程中得到很多需求，這點主要還是在於分析人員的溝通能力。
二、需求的整理與編寫
需求收集完成後，此階段的任務主要對需求進行過慮、分類整理及編寫需求規格，需求的整理不權是分分類、寫寫需求規格，還要對每個需求進行分析，確定這個需 求將來做不做，及實現的優先順序是什麼（是高、中還是低），這一階段對分析人員的要求比較高，要縱觀全域性來考慮，充分考慮到每個需求點對整個系統的影響等， 最終形成軟體需求規格說明書。這一階段常見的問題有以下幾方面：
1、 缺乏對需求的深入理解，需求分析這個崗位在很多軟體公司都是虛擬的，沒有專人負責，一般由設計或開發人員來負責，這樣往往會導致對業務的需求不能深入理解，在系統把握能力上略顯不足，導致編寫出的需求規格不全面。
2、 要正確表達所描述的需求，需求規格作為設計階段的依據，首先要保證其正確性，對每乙個需求都應有一種合理正確的解釋，不能存在二義性，所以分析人員在表達需求時要認真嚴謹，不能模稜兩可，更不能含糊其詞。
3、 要完整表達所描述的需求，完整性是需求規格的重要特徵之一，乙個好的需求規格應該說明什麼需求做，什麼需求不做，而不需要說明怎麼去做，需求規格只是巨集觀 的描述，為設計階段劃定範圍，不應該包含不確性因素在裡面，要麼做，要麼不做，不能遺留任何待解決的問題，而且還要保證需求的完整性。
4、 對優先順序的排列，任何需求在整理過程中都要分優先順序，即問題的重要程度，解決時的優先順序，需求收集過程中會彙總大量的客戶需求，在這些需求當中，有些是 客戶急需解決的，有些是起錦上添花作用的，這時就需要分析人員結合軟體的現狀，根據問題的急緩，來劃分一下將來處理問題的優先順序，也是為設計和開發階段 的相關人員提供可參照的依據。
三、 需求的評審
在我們看來需求的評審是軟體需求分析的最後一步，將整理好的需求規格進行評審，最終決定下一步如何執行，需求的評審一般由專業人士來完成，主要包括公司的 內部專家及外部專家，公司內部一般包括分析設計人員、各部門開發經理、維護經理、專案經理及資深開發人員；外部專家包括典型客戶代表、實施人員代表等，評 審的目的主要就軟體需求規格中定義的各事項做進一步討論，根據評審過程中各專家提出的問題再作整理、修改，最終確定需求的狀態。評審過程中常見的問題有以 下幾方面：
1、 需求的評審流於形式，需求的評審是最後的把關階段，有時會遇到這種情況：需求規格編寫完成後，在評審的過程中只是簡單的走一遍，或者評審過程中討論激烈，評審後該幹麼幹麼，沒有事後監督與執行，感覺這一點是導致後續軟體不急定的主要原因。
2、 對評審人員的要求要嚴格，不是任何人都可以參與評審的，人多了反而效果不好，參與人員應主要是與需求密切相關的，能對需求能提出改進建議的專家，而不是隨便找幾個人完事。
3、 沒有典型客戶參與，需求的整個過程最好讓具有代表性的客戶參與進來，哪怕客戶不明白自己真正的想要實現的東西是什麼，但在整個過程中客戶自始至終起到指導 作用，軟體是個比較抽象的東西，客戶不會多過的關注開發的過程，舉個例子：如果你跟客戶討論的是在建工程或大型裝置的安裝，那麼客戶肯定會重點關注很多細 節，提出很多建議，因為客戶明白專案完工後再改造帶來的影響，但對於軟體，作為客戶他考慮不到軟體開發完成後，後期變更所帶來的麻煩，所以在討論需求時比 較馬虎，描述不清楚需求，導致開發者開發出的軟體與客戶的期望存在巨大差異。
4、 使用者需求不斷的增加，這也是最常見的問題之一，在需求評審的過程中，往往評審人員根據討論的結果會提出新的需求，會導致不斷的更改，所以在編寫需求規格的時候要把握乙個度，不是任何需求都要列入。
5、 對需求做全面的檢查，從需求的幾個特性去綜合考慮，如：需求的完整性、正確性、無二義性、可驗證性等。
作為客戶如果得到的最終軟體產品不能滿足某項功能，就會讓開發人員修改，雖然開發人員後期不管費多大力氣最終能修改完客戶的需求，客戶感覺是理所當然的事 情，但作為開發人員來講，如果程式開發完成後再去修改，也是一件很頭疼的事，因為要放下手頭的工作，優先去處理客戶的問題。這一切的問題都是由於在需求的 收集或驗證的過程的疏忽造成的。
需求驗證的最終結果是得到乙個完整、正確、可執並且無二義性的需求規格，這樣才可為後續工作提供保障，在整個軟體生命週期中，乙個錯誤發現的越晚，修復錯 誤的費用越高，軟體需求分析階段可以說是發現錯誤的階段，可見其重要性，需求分析階段看似沒有明確的目標，實則不然，這期間對任何問題的疏忽，都會導致系 統問題呈扇形擴張，估計做過需求分析的同行都能認識其重要性。任何形式的需求規格說明書都不能保證完全沒有錯誤和缺陷，我們在編寫的過程中只能盡量按照軟 件工程的規範去執行，盡量避免問題的發生。
細談軟體需求分析過程
軟體的需求分析必須要有對原業務的乙個深入了解 提取 抽象 昇華的過程，管理軟體需求分析尤其如此。軟體的需求分析是從使用者的業務中提取出軟體系統能夠幫助使用者解決的業務問題，通過對使用者業務問題的分析，規劃出我們的軟體產品。這個步驟是對使用者業務需求的乙個昇華，是乙個把使用者業務管理流程優化，轉化為軟...
個人軟體過程（PSP）需求分析
1 引言 1.1背景 沒有確定很明確的開發目標。同時由於專業知識有點薄弱，做專案的時候經常延期，對整個團隊產生比較大的影響。2 任務概述 2.1 目標 對於每個團隊，使用個人軟體過程開發工具進行進度管理比較明智，根據每個人的實際情況，分配相應的任務，並 進度，極大的提高了專案及時高效完成的機率。ps...
ANR分析思路簡析
1.anr介紹 1.2 為什麼會產生anr 1 keydispatchtimeout 谷歌default 5s，mtk平台上是8s 主要型別 按鍵或觸控事件在特定時間內無響應 2 broadcasttimeout 10s broadcastreceiver在特定時間內無法處理完成 3 service...