**自：http://.mypm.net/articles/show_article_content.asp?articleid=5369
1、編寫需求文件
需求文件可以使用自然語言或形式化語言來描述，還可以新增圖形的表述方式和模型表徵的方式。需求文件應該包括使用者的所有需求（功能性需求和非功能性需求）。
2、評審需求文件
需求文件完成後，需要經過正式評審，以便作為下一階段工作的基礎。一般的評審分為使用者評審和同行評審兩類。使用者和開發方對於軟體專案內容的描述，是以需求規格說明書作為基礎的；使用者驗收的標準則是依據需求規格說明書中的內容來制訂，所以評審需求文件時使用者的意見是第一位的。而同行評審的目的，是在軟體專案初期發現那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到專案的後續階段。
3、管理需求
圖1 需求變更流程
需求的變更是不可避免的，如何以可控的方式管理軟體的需求，對於專案的順利進行有著重要的意義。如果匆匆忙忙地完成使用者調研與分析，則往往意味著不穩定的需求。所以需求管理要保證需求分析各個活動都得到了充分的執行。對於需求變更的管理，則主要使用需求變更流程和需求跟蹤矩陣的管理方式。需求變更流程和需求跟蹤矩陣分別如圖1和圖2所示。
圖2 需求跟蹤矩陣
常見問題及建議
q、客戶與終端使用者的區別是什麼？
a、可以借助圖3來說明它們之間的區別。
圖3 需求獲取渠道示意圖
軟體需求來自系統工程與客戶兩個方面，其中客戶是主要的需求提供者（系統工程需求也來自於客戶）。客戶需要蒐集其終端使用者的需求並考慮自身的需求，然後再提供給開發方。假如客戶並未去認真蒐集終端使用者的需求，開發方便需要做到這一點，因為系統最終要滿足終端使用者的需求。
q、如何進行使用者訪談？
a、首先，一定要事先確定訪談的目的和提綱。其次，因為使用者往往並不知道應該提供哪些方面的需求，所以需要開發人員引導。
q、使用者訪談內容是什麼？
a、首先，請使用者描述他們如何完成自己當前的工作，並與使用者一起抽象出乙個工作流程或工作模型。然後，在得到使用者的認可後，向使用者解釋自己是怎樣來實現這些功能的，並說明哪些環節可以用自動化方式實現等。
q、採用哪一種方式做需求分析最好？
a、不同的需求分析有不同的特點。還沒有哪一種方法可以完全替代別的方法，否則，現在就不會存在不同的需求建模方式了。一般來說，可以使用dfd＋erd來描述那些功能層次比較清晰的需求；而use case則適於描述功能結構複雜的需求。做需求分析的目的是為了建立需求的模型，不同的子系統有可能使用不同的建模方法。
q、怎樣做原型，原型的目的是什麼？
a、通常使用原型分析方法來幫助開發方進一步獲取使用者需求或讓使用者確認需求。開發方往往先向使用者提供乙個可視介面作為原型，並在介面上布置必要的元素以演示使用者所需要的功能。可以使用***語言（例如visual basic、delphi等）來快速生成使用者介面，也可以使用frontpage等網頁製作工具來生成使用者可視的頁面流。
原型的目的往往是獲取需求。但有時也使用原型的方式來驗證關鍵技術或技術難點。對於技術原型，介面則往往被忽略掉。
專案管理 怎樣做需求分析（一）
如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者 需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階...
怎樣做需求分析（之二）
撥開需求分析的迷霧 像這樣的對話經常出現在軟體開發的過程中。客戶 專案經理的需求對分析人員來講，像 霧裡看 花 般模糊並令開發者感到困惑。那麼，我們就撥開霧影，分析一下需求的具體內容 業務需求 反映了組織機構或客戶對系統 產品高層次的目標要求，通常在專案定義與範圍文件中予以說明。使用者需求 描述了使...
怎樣做需求分析
如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階段...