如何進行軟件需求分析
1、需求分析的重要性
軟件需求是指用戶對目標軟件系統在功能、行爲、性能、設計約束等方面的期望。
通常，軟件生存週期包括可行性分析與開發項計劃、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等活動。
常用的三種軟件生命週期（瀑布模型、迭代式模型和快速原型模型）中，需求分析中都佔據了舉足輕重的作用，是系統分析、軟件編程、軟件測試和系統維護的輸入物。
1.1 瀑布模型
瀑布模型由於酷似瀑布聞名，（Waterfall Model）首先由Royce提出。在該模型中，首先確定需求，並接受客戶和SQA小組的驗證。然後擬定規格說明，同樣通過驗證後，進入計劃階段…可以看出，瀑布模型中至關重要的一點是隻有當一個階段的文檔已經編制好並獲得SQA小組的認可纔可以進入下一個階段。這樣，瀑布模型通過強制性的要求提供規約文檔來確保每個階段都能很好的完成任務。但是實際上往往難以辦到，因爲整個的模型幾乎都是以文檔驅動的，這對於非專業的用戶來說是難以閱讀和理解的。
瀑布模型圖示如下：
從上圖可看出，需求分析的產出物《需求規格說明書》（有的項目組還會產出軟件原型，例如靜態HTML原型等）是後續設計、編碼、測試和系統維護的基礎。
可將瀑布模型的“需求分析”階段細分爲“軟件概念”和“用戶需求分析”兩個階段，前者用於收集用戶的原始需求，包括用戶在功能、行爲、性能、設計約束等方面的期望，並經過初步分析後形成《用戶需求說明書》，而後經過進一步分析，將用戶需求精確化、完全化，最終形成《需求規格說明書》。
可將瀑布模型中的“系統設計”細分爲“架構設計”和“詳細設計”兩個階段，前者在總體上把握，更關注架構層面，包括系統的總體架構，以及各個子系統或各個模塊之間的關係。後者更注重細節，包括系統設計的方方面面都要在詳細設計中有所體現。
作爲系統分析師，或系統架構師，主要在“需求分析”和“系統設計”階段體現自己的作用，後續的各個階段主要通過與項目組成員的溝通貫徹自己的設計。
1.2 迭代式模型
迭代式模型是是RUP（Rational Unified Process，統一軟件開發過程，統一軟件過程)推薦的週期模型。在RUP中，迭代被定義爲：迭代包括產生產品發佈（穩定、可執行的產品版本）的全部開發活動和要使用該發佈必需的所有其他外圍元素。
在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程（編碼流程）和測試工作流程。實質上，可將它理解爲多個小型的瀑布式項目。每一次的迭代都會產生一個可以發佈的產品，這個產品是最終產品的一個子集。
迭代式原型圖示如下：
在每一個迭代中，“需求分析”階段與瀑布模式一樣，是後續系統分析、編碼和測試階段依賴的基礎。如果需求分析有較大偏差，勢必造成迭代過程中產生的一個產品子集有較大偏差。
1.3 快速原型模型
快速原型（Rapid Prototype）模型在功能上等價於產品的一個子集。注意，這裏說的是功能上。瀑布模型的缺點就在於不夠直觀，快速原型法就解決了這個問題。一般來說，根據客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。
在得到用戶的需求之後，原型將被拋棄。因爲原型開發的速度很快，設計方面是幾乎沒有考慮的，如果保留原型的話，在隨後的開發中會爲此付出極大的代價。
在快速原型模型中，原型最重要的目的是爲了確定用戶的真正需求。從某種程度上，可以將快速原型理解爲需求分析的一種更直觀的方式，也是業界比較認可和取得良好效果的一種方式。
2、需求分析的目標
通過對應問題及其環境的理解與分析，爲問題涉及的信息、功能及系統行爲建立模型，將用戶需求精確化、完全化，最終形成需求規格說明，這一系列的活動即構成軟件開發生命週期的需求分析階段。
需求分析是介於系統分析和軟件設計階段之間的橋樑。一方面，需求分析以系統規格說明和項目規劃作爲分析活動的基本出發點，並從軟件角度對它們進行檢查與調整；另一方面，需求規格說明又是軟件設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或儘早剔除早期錯誤，從而提高軟件生產率，降低開發成本，改進軟件質量。
3、如何進行需求分析
3.1 需求分析的困難
需求分析的目標，說得通俗一點，就是確定“做什麼，不做什麼”。但需求分析卻不像想象的那麼簡單，主要因爲如下原因：
3.1.1 客戶需求自身經常變動
這世間的一切，只有“變化”是絕對的，從這點來理解，軟件系統的需求不斷變化也是可以理解的。老聽設計人員和開發人員抱怨客戶的需求老是變化，其實應該將“需求變化”理解爲一種常態。
引起需求變化的原因諸多，例如：
（1）因爲某些前置條件未滿足，之前按照“妥協”方案實現，但若在某個時間點上這些前置條件被滿足，於是引起了需求的變化。
（2）某個後臺操作之前不需要走審批流程，但因爲客戶的某個內部流程改變，需要走審批流程，勢必引起需求 -> 設計 -> 編碼 -> 測試的一系列變更。
【對策】：因爲需求變動無可避免，系統分析師在進行需求分析時需要明確：
（1）儘可能地分析清楚哪些是穩定的需求，哪些是易變的需求。以便在進行系統設計時，將軟件的核心建築在穩定的需求上，否則將會吃盡苦頭。
（2）在合同中一定要說清楚“做什麼”和“不做什麼”。如果合同含含糊糊，日後扯皮的事情就多。小的變動影響不大，也不致影響進度，但是對於一些改動會引起設計重大改變的需求，需要在合同中清楚說明。
3.1.2 客戶說不清楚需求，分析人員理解錯誤
客戶的計算機水平、對需求的理解、表達程度都參差不齊。有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。有些客戶心裏非常清楚想要什麼，但卻說不明白。有的客戶本身就懂軟件開發，能把需求說得清清楚楚，這樣的需求分析將會非常輕鬆、愉快。
不同性格、不同水平、與客戶交流前準備情況不同的的系統分析師去跟客戶討論需求時，會得到很不不一樣的結果。
作爲系統分析師，可以引導客戶，先闡述常規的需求，再由客戶否定不需要的，最終確定客戶真正的需求。一個好的系統分析師，能從客戶的一兩句話中提出很多自己的觀點或可進行拓展，進而進一步挖掘客戶需求，或者若與之前的需求矛盾，可進行正確需求導向。
【對策】：若客戶說不清楚需求，爲了不造成理解錯誤，系統分析師可採用多次溝通的方式，例如第一次通過客戶初步瞭解需求，回去分析哪些是合理需求，那些是自相矛盾或不合理的需求，以及哪些是需要進一步明確的需求。經過細化後，第二次交流可提供PPT或簡單的Word文檔與客戶進行第二次深入交流。第三次交流可通過建立快速模型進一步與客戶交流得到精確的需求。需求分析也可參考“迭代式模型”來進行不斷迭代，一直到挖掘出客戶所有的潛在需求爲止。
3.1.3 客戶在沒看到原型或完整系統時，有一些潛在需求未被挖掘
甚至有不少這樣的客戶，去進行需求溝通時提不出太多的需求，但是在你做完整個系統時，潛在需求突然迸發出來。
【對策】：爲了避免此種情況對項目造成破壞性影響，建議相關人員爲一些大的功能模塊建立快速原型讓客戶進行確認，並在合同中一定要說清楚“做什麼”和“不做什麼”
3.1.4 多個相關方需求相互衝突，需求有二義性
若些需求若牽涉客戶不同部門，若有不一致意見，若私自按某一方的意見進行修改，很可能在後期涉及到按另一個部門的想法進行改造。
【對策】：對於這種客戶內部有衝突的需求，需求組織客戶方相關部門一起討論，由客戶更高領導層決定實現哪一方的需求，或者採用折衷方案。需求說明不可有二義性，更不能前後相矛盾。如果有二義性或前後相矛盾，則要重新分析此需求。
3.2 需求分析的活動
3.2.1 需求獲取
通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求。
軟件需求常見的獲取方法（在《軟件需求獲取方法》一文中寫得很詳細）如下：
Ø 面談
個人覺得面談是獲取軟件需求的最有用的方法，也是需求分析時常用的方法。通過多方面談，得到的信息最多，進行我們現在所做的系統，與移動集團客戶部、業務支撐部、網管中心、系統運營人員等都進行過面談。
面談需準備的內容：面談對象和麪談問題。
面談對象：需要儘量讓面談對象包括可與系統相關的涉衆，並具有代表性，保證涵蓋到每個角色。一般包括誰爲系統付費，購買系統？誰使用系統？誰會受到系統結果的影響？誰來監管該系統？誰來維護系統？
Ø 問卷調查
調查問卷無法取代面談在需求獲取階段的作用，問卷調查的問題和答案具有一定的引導性，在某種程度上會影響結果。
問卷調查的結果好壞與問卷的設計有直接的關係，在做這個項目時，運營人員在進行前期推廣會議上，也給企業客戶發過調查問卷，但因爲諸多原因，效果不甚理想，基本沒爲我們項目需求分析出多少力。
Ø 小組討論
小組討論是指將與項目某個問題相關的人員聚集在一起開會討論。優勢：容易在內部取得對方案的認同，有利於項目的開展；在討論會上每個相關人員都可發表自己的意見，保證了獲取信息的全面性。缺點：不容易把握。
對於涉及系統邊界的需求，或一些相互衝突的需求，採取該種方式是非常可取的。
Ø 情景串聯
由於軟件產品的抽象性，大部分涉衆在腦海子未有一個清晰的產品輪廓，影響涉衆對產品的理解。基於此可考慮編寫清晰、完整的情景描述文檔。
1、採用PPT加圖片的方式描述情景：一個好的PPT能更直觀的描述各種情景；
2、採用原型法（比較推薦這種方法）。
Ø 參與、觀察業務流程
涉衆描述的業務流程可能由於某些原因會遺漏掉重要的信息，需求分析人員可申請參與到他們具體的工作，觀察、體驗業務操作過程。需求分析員在觀察業務操作過程時，可根據實際的情況提問並詳細記錄，記錄業務操作員操作過程，操作過程中碰到的難題，可獲取真實的材料和理解整個業務。
Ø 現有產品和競爭對手的描述文檔
閱讀現有產品文檔有利於瞭解當前系統情況，從中也可以瞭解業務流程，對操作員反映的系統問題有着更深層次的理解。
3.2.2 需求建模
要有效地收集需求，您要做的第一步是建模，它包括創建體系結構的表示形式以捕獲需求、就解決方案方法進行交流、以及分析所提出的系統設計。其目的是使用模型來表現系統中的關鍵方面。然後，您可以在形式化的分析、模擬和原型設計中使用這些模型，以研究預期的系統行爲，並且可以在編寫文檔或總結時使用這些模型，以便就係統的性能和外觀進行交流。
Ø 域建模
域建模指的是，您對問題域創建相應的模型並且把它劃分爲若干個內聚組的過程。然後，您可以在抽象模型中捕獲業務流程、規則和數據。
域模型是一種用於理解問題域的工具。您需要從信息系統之外的角度來理解這個域，這一點是很重要的。
Ø 用例建模
用例模型描述了各種參與者（人和其他系統）和要分析的系統之間的主要交互。用例應該說明系統如何支持域和業務流程模型中的業務流程。
用例模型應該將系統放到上下文環境中，顯示系統和外部參與者之間的邊界，並描述系統和參與者之間的關鍵交互。用例建模可以描述利益相關者（例如，用戶和維護人員）所看到的系統行爲。
Ø 組件和服務建模
組件模型爲子系統、模塊和組件的層次結構分配需求和職責。每個元素作爲一個自包含的單元，以用於開發、部署和執行的目的。組件模型的元素由它們所提供和使用的接口來進行規定。在這裏，沒有考慮其中的內部細節。
服務模型將應用程序定義爲一組位於外部邊界（用例）、架構層之間的抽象服務接口，並且提供了通用的應用程序和基礎結構（安全、日誌記錄、配置等等）。支持應用程序需求的這組服務可以與現有的內部和外部提供的接口規範相匹配。所得到的分析結果可以確定預置策略，並將項目活動劃分爲特定類型的部分，這取決於給定的服務是否已經存在（內部或者外部的，並且其中每個服務都具有適當的活動）、存在但需要進行修改（定義一個新的接口，並規劃其實現）、或者必須構建新的服務。
Ø 性能建模
可以通過各種各樣的方式來度量性能，最顯而易見的方式是，應用程序執行其關鍵操作任務的速度。然而，作爲一名架構師，必須考慮性能建模過程中其他的幾個方面：
l 構建和部署應用程序的速度如何？
l 構建、維護和運行需要多少花費？
l 該應用程序能在多大程度上滿足其需求？
l 對於必須使用該應用程序的人來說，需要爲其付出多大的開銷？
l 該應用程序會對其他應用程序和基礎結構產生怎樣的影響？
【說明】需求建模是一門深奧的學問，在做這個項目時，需求建模基本只是用到了“用例建模”，對一些典型流程進行用例建模。域建模、組件和服務建模和性能建模基本是空白狀態，希望在下一個項目中有所改進。
3.2.3 形成《需求規格說明書》
生成需求模型構件的精確的形式化的描述，作爲用戶和開發者之間的一個協約。
3.2.4 需求驗證
以需求規格說明爲輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性。
3.2.5 需求管理
支持系統的需求演進，如需求變化和可跟蹤性問題。
要在需求變更時，同步更新《需求規格說明書》以及相關文檔，要知道，一個正確的文檔是指導軟件系統不同階段的參考，但一個沒有同步更新的文檔是對軟件系統有破壞性作用的，相關人員會受到錯誤引導。
4、參考文檔
1、《需求分析的作用及如何進行需求分析》（張友生）：
http://www.educity.cn/se/requirement/200903310923051492.htm
2、《軟件生命週期_百度百科》：http://baike.baidu.com/view/3110371.htm
3、《軟件項目需求分析困難的原因》：
http://developer.51cto.com/art/200512/15979.htm
4、《需求建模》：http://blog.csdn.net/weishaofei/article/details/4371584
5、《軟件需求獲取方法》：http://blog.sina.com.cn/s/blog_646b84760100s645.html
6、《系統域建模技術》：
http://wenku.baidu.com/view/8423fb97dd88d0d233d46ace.html