需 求 分 析
管 理 控 制 程 序
版 本：0．1版
制定人：CMM組
需求分析程序
1. 目的
對軟件產品需求分析活動進行控制，明確《用戶需求說明書》的要求
2. 適用范圍
適用于公司自主開發產品和合同項目軟件部分的用戶需求分析活動。
3. 崗位與職責
責任人 | 職責 | 說明 |
項目核心組 | 與用戶溝通，進行初期的用戶需求調研，形成文檔，決定需求是否有必要繼續進行； 對需求分析過程中的需求分析人員與用戶的關系進行協調； 對需求分析過程中遇到的不明確性進行判斷和決策； 形成《需求備忘錄》和《用戶需求說明書》，向部門負責人提出評審申請。 需求調研和需求評審由產品經理或項目經理或所在的產品部門負責。 建立《需求跟蹤記錄》。 | |
事業部/開發部負責人 | 對需求分析過程中出現的問題進行指導；按程序文件要求組織對 《用戶需求說明書》進行評審。 為項目組指定SQA、配置管理員、測試經理等相關資源 | |
配置管理員 | 《用戶需求說明書》評審后，納入配置管理 | |
SQA | 開始制定《軟件質量保證工作計劃》，并監督項目核心組的需求分析工作是否符合程序文件的要求，完成《軟件需求分析質量報告》 | |
測試經理 | 參與評審 | |
| | |
4. 程序
4.1. 流程圖
4.2. 總則
需求活動大致分三個階段：需求調研、需求分析和需求管理
4.2.1. 需求調研階段
a. 對自主產品而言，在用戶意向明確后，開發部負責人根據產品經理的申請，指定需求分析人員組成用戶需求分析小組，由產品經理負責組織開展用戶需求調研活動。
b. 對合同類項目而言，在用戶意向明確后，開發部負責人根據項目經理的申請，指定需求分析人員組成用戶需求分析小組，由項目經理負責組織開展用戶需求調研。
c. 此階段以調查用戶需求為主，生成《需求備忘錄》。
4.2.2. 需求分析階段
立項后，項目核心組對需求進行分析研究，細化，由產品經理或者項目經理負責對需求分析過程中的問題進行判斷和解決，關鍵問題或認為有必要時可向公司事業部或開發部負責人匯報和請示。此階段以分析為主，如遇不確切的需求，仍需進一步調查補充，生成《用戶需求說明書》。
4.2.3. 需求管理階段
評審后的需求文檔納入基線，按配置管理計劃進行變更管理（見《配置管理程序》)。
4.3. 用戶需求調研應了解的主要內容：
1. 用戶的工作流程、相關部門及職責；
2. 用戶原有系統的情況；
3. 用戶對產品的期望（包括功能，性能，使用方式，平臺，交付時間等）;
4. 用戶對產品的具體要求（包括各功能的具體含義);
5. 用戶業務中與待開發的產品有關的部分；
6. 用戶對產品與其生產流程的配合要求；
7. 產品與用戶原有系統的接口；
8. 用戶對軟、硬件平臺的限制和要求；
9. 產品的使用人員的技術水平
4.4. 需求調研的要求
在進行前期用戶需求調研時，應進行必要的記錄并整理保存，形成正式的《需求備忘錄》，并經內部審核和評定。產品立項或合同評審時，必須提供正式的《需求備忘錄》文檔。
4.5. 用戶需求說明書
在《需求備忘錄》的基礎上，用戶需求分析小組進行詳細的用戶需求分析，編寫出《用戶需求規格說明書》（內容和要求參見模板）。編寫時可根據具體的產品情況進行調整。必要時，可在有關章節中引述其它資料作為附件。
4.6. 評審
1. 《用戶需求說明書》形成后，需要由需求分析小組向事業部/開發部負責人申請評審，評審過程要求參見《評審控制程序》，最終形成《用戶需求說明書評審報告》。
2. 評審結論分為通過、有條件通過和不通過（即取消項目），對于有條件通過，由SQA進行跟蹤解決。
3. 評審主要內容：
a. 確定不完整和遺漏的需求
b. 評審需求以確定它們是否：
o 可行、適用于軟件實現
o 需求表達清楚、適當
o 彼此一致
o 可測試
c. 需求分析小組成員對有問題的需求給出解釋，并進行必要的修改。
d. 開發經理與測試、配置管理、協作部門等方就需求達成一致意見，或協商作出約定。
4.7. 納入配置管理
《用戶需求說明書》評審后應納入配置管理，按《配置管理程序》進行管理，進入需求管理階段。
4.8. 需求變更管理
無論是用戶原因還是公司自身原因，在需求評審通過后的設計、開發等活動中需要對《用戶需求說明書》進行修改時， 應執行《變更管理控制程序》。
