摘要當今，經濟和社會生活對軟體的依賴程度急劇增長，軟體需求日益複雜，軟體開發成為一項跨越技能，職責範圍和時間階段的綜合團隊活動。實踐證明，良好的需求管理過程對於降低開發成本和保障專案成功至關重要。
我們將需求管理過程分為三個大的階段：
● discover階段，
● define階段，
● 和需求維護階段。
本文的內容羅列如下：
第一部分：軟體需求管理過程涉及到的角色
第二部分：軟體需求管理過程的概貌。
第三部分：discover階段的具體活動。
第四部分：define階段的具體活動。
第五部分：需求維護階段的具體活動。
1、 角色及職責
2、軟體需求管理過程的概貌
需求可定義為「（正在構建的）系統必須符合的條件或具備的功能」，也有人定義為「使用者解決某一問題或達到某一目標所需的軟體功能」。
而需求管理是一種獲取、組織並記錄系統需求的系統化方案，以及乙個使客戶與專案團隊對不斷變更的系統需求達成並保持一致的過程。需求管理的目的是在顧客和將處理顧客需求的軟體專案組之間建立對顧客需求的共同理解。
需求管理的目標是：
使軟體需求受控，並建立供軟體工程和管理使用的基線。
使軟體計畫、產品和活動與軟體需求保持一致。
discover階段
本階段的目的是了解客戶的問題，分析並確定公司是否開展此行業的專案。這裡的客戶不一定針對乙個企業，有可能是乙個行業。在進行具體的調研時，目標是本行業的乙個或幾個典型使用者。
市場人員主要對客戶的問題，客戶的現狀，和客戶的業務模式三方面進行了解，然後對照公司的業務發展方向和實際現狀進行可行性分析，並負責編寫可行性分析報告。
然後發起可行性分析會議，邀請公司高層，行業專家和利益相關者一起來商議公司是否開展此專案。一旦決定做此專案，下來將尋找有意向的使用者。找到合適的使用者後，就可以正式開始建立開發團隊進行開發系統的定義，設計，編碼等工作。
define階段
目的是得到一套客戶認可的詳細的需求說明文件，用來指導後期的軟體開發工作。開發專案經理通過與客戶溝通交流，分析專案目標和成功因素，識別專案風險和假設，以及系統的功能需求和技術需求，最終整理出一套詳細的需求說明文件，包括總體系統的需求資訊，每個子系統的需求資訊，資料字典，等。
為了指導後期的開發和跟蹤需求實現的狀態和範圍，專案經理需要根據需求來建立本專案的scope matrix。在scope matrix中隨時跟蹤每項功能的in或out，以及現在處於開發的什麼階段。
所有需求文件完成之後，由專案經理發起並組織階段審核會議，並邀請客戶和行業專家參加。審核的內容包括所有需求文件和scope matrix。一旦審核通過，則開始制定下階段的計畫，準備進入概念階段。
需求維護階段
目的是管理需求的變更。在軟體開發過程中，需求不可避免會有大或小的更改。為了更有效地管理需求的變更，這裡規範了需求變更，需求跟蹤，和需求配置管理的要求。
對每項內容的詳細內容，將在後面進行介紹。
3、discover階段
3.1 理解客戶的需求
活動：與客戶溝通交流，了解他們的原始需求。並分析公司開發此專案的業務機遇，業務目標，客戶和市場的需求，以及業務風險等問題。
職責：由公司高層負責，市場人員具體執行。
3.2 了解客戶的現狀
活動：評估客戶的現狀，如資訊化程度，人員的計算機技能水平，業務模式等。
職責：由公司高層負責，市場人員具體執行。
3.3 了解客戶的業務模式
活動：了解客戶當前的業務模式，包括業務角色及其關係。
職責：由公司高層負責，市場人員具體執行。
3.4 編寫可行性分析報告
活動：根據前面三項內容，對本專案做評估，分析是否開展此專案
職責：由公司高層負責，市場人員具體執行
模板：依據提供的「可行性分析報告的模板」整理。根據實際內容，允許對模板進行裁剪。
3.5 可行性問題的決策
活動：審核可行性分析報告的內容；決定是否開展此專案
參與人：市場人員（發起者和組織者），行業專家，公司高層決策人員。
主要溝通內容：可行性分析報告
輸出：作出結論的可行性分析報告
職責：市場人員發起，組織，和主持會議，做會議記錄。負責可行性分析報告的修訂和決策記錄。
說明：決定開展此專案後，方可進入define階段。在進入define階段之前，需要由專案經理確定專案的整體計畫和define階段的詳細計畫。
4、define階段
4.1 準備
活動：了解discover階段的輸出文件，安排交流的客戶代表
職責：市場人員幫助開發專案經理了解可行性分析報告中的內容，並共同聯絡客戶代表；開發專案經理理解可行性報告中的相關內容，為後面工作的開展作好準備。
4.2 分析專案目標和成功因素
活動：通過與客戶的溝通，定義專案目標和成功的關鍵因素
職責：開發專案經理完成，市場人員可協助。
4.3 識別專案的風險和假設
活動：通過與客戶的溝通，識別專案的風險和假定，並分析他們對專案的影響，給出風險的減緩方法。
職責：開發專案經理同完成，市場人員可協助。
4.4 獲取功能需求和技術需求
活動：通過與客戶的溝通，獲取功能需求和技術需求，即明確系統的功能需求和使用什麼樣的技術
職責：開發專案經理完成，市場人員可協助。
4.5 編寫需求說明文件
活動：根據前面幾個步驟的溝通結果，整理專案的需求文件。需求文件不一定是乙個，可以是幾個文件。
但必須包括內容：總體系統的需求資訊，每個子系統的需求資訊，資料字典。公司建議將總體系統的需求資訊與每個子系統的需求資訊分開寫成文件。
在總體系統的需求中，從系統整體出發來闡述，而每個子系統的需求只針對子系統本身來闡述。
職責：開發專案經理完成。
模板：依據提供的「總體系統的需求說明模板」「子系統的需求說明模板」「資料字典的模板」整理。根據實際內容，允許對模板進行裁剪。
高質量的需求說明文件的關鍵特點：
完整:不應該遺漏要求和必需的資訊。發現缺少的資訊很難，因為根本不存在。
如果你知道已缺少一些資訊，使用tbd（to be determined）標準標誌可以突出這些缺陷，當你在構建產品的相關部分時，就可以從乙個給定的需求集中解決所有的缺陷。
一致性：一致性需求就是不要於其他的軟體需求或高階別的系統（商業）需求發生衝突。
可修改性：每個需求必須相對於其他需求有其單獨的標示和分開的說明，便於清晰的查閱。通過良好的組織可以使需求易於修改，如：將相關的需求分組，建立目錄表，索引，以及前後參考（照）。
4.6 建立scope matrix
活動：根據系統的需求建立scope matrix，以指導後期的開發。scope matrix的所有內容必須忠實於整理出來的需求文件。
如果需求文件的內容不足以得到完整細緻的scope matrix，可以回過頭來完善需求文件；如果實在確定不下來的內容，可以在scope matrix中標註出來，待以後確定。
職責：開發專案經理完成。
模板：依據提供的「scope matrix的模板」整理。根據實際內容。
如何在scope matrix中描述功能域：
羅列所有的詳細功能點，而與流程無關。
有關的功能限制也可列入。
禁忌用冗長的描述性語言陳述。這樣不容易將功能點劃開。
每個功能點用一句簡短的話來描述。如果乙個功能點需要兩句話才能描述清楚，則將其劃為兩個功能點。
4.7 define階段的審核
活動：以會議的形式溝通需求的內容，對需求進行quality review.
參與人：專案經理（發起者和組織者），行業專家，和客戶
審核內容：資料字典，總體系統的需求說明，各子系統的需求說明，scope matrix
輸出：review notes。review notes要求填寫在公司規定的quality review notes的模板中。
職責：專案經理發起，組織，並主持審核會議，做會議記錄。會後總結review notes.
說明：define階段審核通過後，方可進入設計階段。
5、需求維護
需求維護的關鍵內容是需求變更管理。需求的變更是不可避免的，如何以可控的方式管理軟體的需求，對於專案的順利進行有著重要的意義。對於需求變更的管理，我們主要使用需求變更控制流程，需求跟蹤矩陣，和需求配置的管理方式。
5.1 變更控制流程
5.2 需求跟蹤
活動：使用scope matrix來跟蹤每項需求是否要求實現，以及需求實現的狀態
職責：由開發專案經理負責維護scope matrix。
5.3 需求配置管理
活動：儲存需求方面的所有文件的所有版本
職責：每個有關需求的文件以及公升級文件均要求儲存到配置管理系統中。
要求：所有資料均放入配置管理系統。
按照規定的目錄存放資料。
檔案的每個修改版本都要求儲存。
1軟體需求管理過程
海恆達遠資訊科技 2002年12月26日 目錄軟體需求管理過程 1 1 前言 3 1.1 目的 3 1.2 範圍 3 1.3 文件內容 3 1.4 有關的角色及職責 3 2 軟體需求管理過程的概貌 4 2.1 過程圖 4 2.2 註解 4 3 discover階段 5 3.1 過程圖 5 3.2 活...
軟體配置管理過程 ITECHS SCM PRS
軟體配置管理過程 文件編號 文件資訊 實驗室級別過程檔案 文件名稱 軟體配置管理過程 文件類別 支援過程類 密級 內部 版本資訊 1.5 建立日期 2003 11 5 建立人 審核者 批准人 批准日期 保管人 存放位置 spi cmmi l4 documents process scm 編輯軟體 m...
SPI E REQM P01 需求管理過程檔案
編碼 xx spi e reqm p01 xx有限責任公司 需求管理過程檔案 更改控制頁 目錄1 目的 1 2 範圍 1 3 術語定義 1 4 職責 2 5 裁剪指南 2 6 過程 3 6.1 依據需求建立跟蹤矩陣 3 6.1.1 概要圖 3 6.1.2 啟動條件 4 6.1.3 輸入 4 6.1....