五步走：軟件需求的管理過程

摘要 

　　當今，經濟和社會生活對軟件的依賴程度急劇增長，軟件需求日益復雜，軟件開發成為一項跨越技能，職責范圍和時間階段的綜合團隊活動。實踐證明，良好的需求管理過程對于降低開發成本和保障項目成功至關重要。 

　　這里是我們采用的需求管理過程，希望能與大家分享，互相學習和借鑒。歡迎留言！ 

　　我們將需求管理過程分為三個大的階段：Discover階段，define階段，和需求維護階段。本文的內容羅列如下： 

　　第一部分：軟件需求管理過程涉及到的角色 

　　第二部分：軟件需求管理過程的概貌。 

　　第三部分：Discover階段的具體活動。 

　　第四部分：Define階段的具體活動。 

　　第五部分：需求維護階段的具體活動。 

　　1、角色及職責 

　　角色————職責描述 

　　市場人員————負責discover階段所有工作，并幫助開發項目經理在define階段初期很快地了解業務和客戶 

　　開發項目經理————協調discover階段的所有活動；負責完成需求文檔；維護scope matrix。 

　　行業專家————提供行業咨詢 

　　高層團隊————指導discover和define階段的工作 

　　SEPG 負責過程的培訓，提供過程支持，負責過程的跟進和改進 

　　2、軟件需求管理過程的概貌 

　　需求可定義為“（正在構建的）系統必須符合的條件或具備的功能”，也有人定義為“用戶解決某一問題或達到某一目標所需的軟件功能”。 

　　而需求管理是一種獲取、組織并記錄系統需求的系統化方案，以及 一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。需求管理的目的是在顧客和將處理顧客需求的軟件項目組之間建立對顧客需求的共同理解。 

　　需求管理的目標是： 

　　使軟件需求受控，并建立供軟件工程和管理使用的基線。 

　　使軟件計劃、產品和活動與軟件需求保持一致。 



　　Discover階段 

　　本階段的目的是了解客戶的問題，分析并確定公司是否開展此行業的項目。這里的客戶不一定針對一個企業，有可能是一個行業。在進行具體的調研時，目標是本行業的一個或幾個典型用戶。市場人員主要對客戶的問題，客戶的現狀，和客戶的業務模式三方面進行了解，然后對照公司的業務發展方向和實際現狀進行可行性分析，并負責編寫可行性分析報告。 

　　然后發起可行性分析會議，邀請公司高層，行業專家和利益相關者一起來商議公司是否開展此項目。一旦決定做此項目，下來將尋找有意向的用戶。找到合適的用戶后，就可以正式開始創建開發團隊進行開發系統的定義，設計，編碼等工作。 

　　Define階段 

　　目的是得到一套客戶認可的詳細的需求說明文檔，用來指導后期的軟件開發工作。開發項目經理通過與客戶溝通交流，分析項目目標和成功因素，識別項目風險和假設，以及系統的功能需求和技術需求，最終整理出一套詳細的需求說明文檔，包括總體系統的需求信息，每個子系統的需求信息，數據字典，等。 

　　為了指導后期的開發和跟蹤需求實現的狀態和范圍，項目經理需要根據需求來建立本項目的Scope Matrix。在Scope Matrix中隨時跟蹤每項功能的In或Out，以及現在處于開發的什么階段。 

　　所有需求文檔完成之后，由項目經理發起并組織階段審核會議，并邀請客戶和行業專家參加。審核的內容包括所有需求文檔和Scope Matrix。一旦審核通過，則開始制定下階段的計劃，準備進入概念階段。 

　　需求維護階段 

　　目的是管理需求的變更。在軟件開發過程中，需求不可避免會有大或小的更改。為了更有效地管理需求的變更，這里規范了需求變更，需求跟蹤，和需求配置管理的要求。對每項內容的詳細內容，將在后面進行介紹。 

　　3、Discover階段 



　　3.1 理解客戶的需求 

　　活動：與客戶溝通交流，了解他們的原始需求。并分析公司開發此項目的業務機遇，業務目標，客戶和市場的需求，以及業務風險等問題。 

　　職責：由公司高層負責，市場人員具體執行。 

　　3.2 了解客戶的現狀 

　　活動：評估客戶的現狀，如信息化程度，人員的計算機技能水平，業務模式等。 

　　職責：由公司高層負責，市場人員具體執行。 

　　3.3 了解客戶的業務模式 

　　活動：了解客戶當前的業務模式，包括業務角色及其關系?！　?nbsp;

　　職責：由公司高層負責，市場人員具體執行。 

　　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 需求配置管理 

　　活動：保存需求方面的所有文檔的所有版本 

　　職責：每個有關需求的文檔以及升級文檔均要求保存到配置管理系統中。 

　　要求： 

　　所有資料均放入配置管理系統。 

　　按照規定的目錄存放資料。 

　　文件的每個修改版本都要求保存。 

原文轉自：http://www.anti-gravitydesign.com