1. 前言
1.1 意圖和價值
意圖： 明确需求，確定利益相關者的共同了解，并調整需求、計劃和工作産品。
價值： 確定客戶的需求和期望得到滿足。
1.2 适用範圍
本過程文檔是項目經理需求開發人員（包括：售前市場人員、需求調研人員等）執行需求開發與管理過程活動的依據和指導。本過程适用于公司所有軟體項目，且貫穿于整個生命周期。
1.3 名詞術語
² 使用者需求
是使用者對要建立的系統的要求描述，它主要說明使用者“要做什麼”、“想做什麼”的問題。
² 軟體需求
也叫産品需求，是軟體産品能否滿足使用者需求的要求描述，它主要說明軟體産品“能做什麼”、“不能做什麼”的問題。
2. 過程定義
2.1 角色和職責
| 角 色 | 職 責 描 述 |
| 高層經理 | 1. 評審、準許使用者需求、産品需求等過程産品，并參與本過程域重要的活動； 2. 解決在實施本過程域中所遇到的無法解決的問題 |
| 項目經理 | 1. 為需求開發工作提供各種必要的環境和條件； 2. 制訂需求開發計劃，并跟蹤維護該計劃； 3. 負責聯系使用者和需求人員進行需求開發工作； 4. 參與評審本過程域的工作産品； 5. 完成或協助完成本過程域的工作産品； 6. 對需求進行變更管理、跟蹤控制； 7. 向高層經理報告本過程域的實施情況； |
| 需求開發人員 | 1. 負責對市場、客戶的需求調研； 2. 收集、分析、細化、導出和描述使用者需要、期望、限制和接口，并把它們轉換成使用者需求； 3. 完成需求開發，編寫《使用者需求說明書》和《産品需求規格說明書》等需求文檔； 4. 負責對需求的後期跟蹤； 5. 負責執行需求的變更。 |
| 美工 | 1. 根據使用者需求和産品需求，在需求開發人員的指導下，完成開發原型Demo的制作； 2. 和需求開發人員一起，向使用者進行開發原型Demo示範。 |
| 項目組成員 | 參加需求開發與管理活動的評審。 |
| 客戶 | 1. 配合并參與需求的調研活動； 2. 評審并确認需求開發的所有文檔； 3. 對《使用者需求說明書》和《産品需求規格說明書》、需求Demo等進行确認； |
| CCB | 1. 評審需求文檔是否滿足了使用者的真實意願。 2. 審批需求變更申請。 |
| CM | 1. 為評審後的需求文檔進行配置管理。 |
| QA | 1. 檢查和監督需求管理活動的有效性和一緻性。 2. 将檢查出來的問題及時通報給項目經理及項目組成員，并跟蹤問題直到關閉。 |
2.2 入口準則
² 需求開發人員已經确定；
² 初步的《項目計劃》已經通過評審。
2.3 輸入
² 初步的《項目計劃》；
² 《項目合同》；
² 《技術解決方案》；
² 客戶原始需求文檔。
2.4 過程活動
需求階段包括需求開發和需求管理兩個過程活動。
² 需求開發過程
需求開發過程是擷取使用者需求并對使用者需求進行分析整理形成軟體需求的過程。需求開發過程可以包括使用者需求調研、使用者需求分析、軟體需求定義和軟體需求評審四個過程，也可以根據具體情況對該過程進行裁減。
需求開發的結果文檔包括使用者需求類文檔、軟體需求類文檔、有時為了滿足軟體産品前期設計的需要，也會制作形成業務模型、資料字典、系統開發原型（Demo）文檔等。
所有的需求文檔經過使用者和開發方雙方評審認可并簽字後，形成項目的需求基線。
² 需求管理過程
需求管理是在需求文檔基線化後，對需求實作的跟蹤以及當需求發生變更時，對需求變更進行控制和管理的過程。
需求管理包括變更控制、版本控制、需求跟蹤過程。需求管理同時包括變更的需求及相關需求之間的關系管理。
2.4.1 需求開發過程
需求開發過程
2.4.1.1 使用者需求調研
在項目正式立項後，項目經理組建需求開發團隊，需求開發人員根據初步《項目計劃》、客戶原始需求文檔（包括：市場人員從客戶那裡得到的初步需求文檔，投标檔案中定義的技術方案内容等），确定需求調研時間及需求擷取相關幹系人，并将此活動更新到《幹系人計劃》中，同時制定出《需求調研計劃》。在識别需求擷取幹系人時，需求開發人員需考慮以下幾準則：
l 相關幹系人要具備足夠的業務經驗。
l 相關幹系人要具有較強的表達能力。
l 相關幹系人至少具備初級的計算機水準。
在需求開發人員開始進行使用者需求調研之前，要進行充分的事前準備。需要準備的工作包括：
l 需求開發人員要提前了解該行業的标準、相關檔案、公司規章制度等。
l 需求開發人員從組織資産庫中尋找類似項目的需求資料，對相關需求資料有一個深入了解，以便迅速了解可以重用的業務需求内容，為與客戶深入、專業的需求溝通打下基礎。
l 需求開發人員确定需求調研方式，具體方式包括：客戶主動提供的需求說明文檔，與使用者面談或電話訪談或會議訪談、參觀使用者的工作流程、向使用者群體發調查問卷、與同行專家交談、分析已經存在的同類軟體産品等。
l 需求開發人員根據標明的調研方式，準備好《使用者需求調查單》。
需求開發人員根據《需求調研計劃》開展調研工作。調研工作需要需求開發人員和使用者協同完成。調研中需求調研人員要随時做好記錄，事後填寫好《使用者需求調查單》，作為原始使用者需求，有進行組織會議訪談的要填寫《需求訪談會議紀要》。
需求開發人員根據需求調研的訪談成果，對使用者的原始需求進行分析整理，提取需求的精華，對使用者需求進行歸納總結，把相同的需求進行歸類，把文檔盡可能的用使用者容易了解的語言撰寫（包括：用例圖/用例簡述/用例規約描述等）。按照歸納總結的使用者需求點，需求開發人員編寫《使用者需求說明書》。
《使用者需求說明書》的主要内容包括：
² 需求産生的背景
² 需求目标要求
² 需求内容範圍
² 使用者角色
² 功能性需求的描述
² 限制條件
² 非功能性要求等。
《使用者需求調查單》、《使用者需求說明書》編寫完成後，需要得到使用者和開發方雙方的共同确認，确認的方式開始是正式的、也可以是非正式的。一般通過内/外部評審會議、使用者簽字或非正式的其他方式（如确認郵件等）确認即可。
使用者需求确認後，需求開發人員建立《需求跟蹤矩陣》，并将使用者需求項填入《需求跟蹤矩陣》中。
使用者需求調研活動可參考《需求調研指南》。
2.4.1.2 使用者需求分析
使用者需求分析的目的是為了明确使用者需求的具體細節以及軟體産品實作的可行性，把使用者需求合理的轉化成軟體産品需求。使用者需求分析的主要内容包括：
² 分析使用者需求的實作可行性
在允許的成本、性能要求下，需求開發人員要分析每項使用者需求進行軟體産品實作的可行性，同時明确與每項需求實作相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙等。
² 确定需求的優先級别
應用需求分析方法來确定系統特性或單項需求實作的優先級别。以優先級為基礎确定軟體産品将包括哪些特性或哪類需求。
² 建立業務模型（可選）
有時為了滿足軟體産品前期設計的需要，或者需求開發人員對比較複雜的使用者需求難以了解時，一般對需求進行模組化分析，以幫助軟體開發人員更好地了解需求。
根據使用者需求分析得到的需求描述，借助于需求分析工具建立相應的業務模型。根據項目的實際情況，選擇不同的模組化方法。如：采用結構化的需求分析方法或采用面向對象的需求分析方法，通過UML方法來進行建立業務模型。
建議使用Rational Rose、MS Visio等模組化工具進行需求的模組化分析，通過分析系統的功能模型、結構模型和行為模型，進行系統模組化。模組化的過程包括系統功能模組化、系統資料模組化和體系結構模組化，在需求開發階段應至少完成功能模組化。功能模組化的方式包括靜态模組化和動态模組化。靜态模組化要求畫出用例圖、主要的類圖和對象圖，動态模組化要求畫出主要的狀态圖、時序圖、協作圖和活動圖等。另外在用例圖中，需标明每個用例的業務描述、業務資料、業務流程、入口條件、輸出結果、異常處理等要素。
² 建立資料字典（可選）
資料字典是使用者需求中的各類實體（業務對象、資料對象、業務流程對象等）的專業化名稱解釋，它能夠保證使用者和開發方對需求溝通、了解的一緻性，同時也是後續進行資料庫對象設計的最重要依據之一。
2.4.1.3 産品需求定義
首先，需求開發人員進行産品需求定義，把使用者需求向軟體需求轉化前，要确認《使用者需求說明書》已經通過了使用者确認。
由需求開發人員根據《使用者需求說明書》，對使用者需求進行更加詳細的專業化定義，形成使用者需求到軟體需求的映射。完成《産品需求規格說明書》的編寫。
當需求開發人員或使用者不能确定需求時，可以考慮實作一個系統開發原型（DEMO），這樣使得許多概念和可能發生的事更為直覺明了。使用者通過評價原型将使項目參與者能更好地互相了解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。
系統如果建立原型，則需向使用者示範原型，或請使用者試用原型系統，記錄使用中的問題并修訂原型直至客戶滿意。原型的格式和内容由項目經理、美工以及客戶協商自定。
※由于《使用者需求說明書》與《産品需求規格說明書》在内容上存在很多的共同之處，有時為了項目的具體需要，兩個文檔可以考慮合并成一個文檔。但合并成一個文檔時需注意：
² 要明确使用者需求和産品需求之間的對應關系，建立起使用者需求和産品需求之間的映射表（通過映射表可以建立起使用者需求和産品需求之間的需求跟蹤矩陣）；
² 使用者需求和産品需求之間的對應關系，特别是軟體産品無法實作的使用者需求内容，要在合并文檔中明确記錄，并向使用者詳細說明情況，取得雙方的溝通一緻；
² 合并的文檔内容要用使用者易于了解的語言進行表述，切勿使用軟體專業性強而使用者無法了解或了解有歧義的語言，一般考慮使用用例圖/用例規約的方式。
² 合并的文檔不僅僅給使用者看，還要滿足軟體産品後續設計的需要，是以内容的描述盡可能正确、完整、易于了解、無歧義。
2.4.1.4 産品需求評審
産品需求評審的目的是為了確定使用者和開發方雙方對需求的了解一緻，消除歧義，并取得雙方之間的共同認可。評審時由項目經理邀請客戶、相關幹系人參加，要對《産品需求規格說明書》中的内容逐條逐項進行驗證，如果發現存在問題，則由需求開發人員繼續調研，加以修改，直至評審通過。
軟體需求評審要注意如下幾點：
² 明确說明使用者需求和軟體産品需求之間的映射關系，對軟體産品不能實作或暫時無法實作的使用者需求，需求開發人員要向使用者詳細說明原因，取得使用者的認可。
² 可以通過示範系統原型（Demo）方式，直覺形象的向使用者進行軟體産品需求的示範，取得使用者的認可。
² 軟體需求确認不同于使用者需求的确認，使用者需求的确認可以是非正式（如郵件确認），軟體産品需求确認必須是正式的，《産品需求規格說明書》必須得到使用者的書面确認。産品需求确認後，形成正式的軟體産品需求基線，作為後續需求變更控制的基礎。
2.4.2 需求管理過程
需求管理過程包括：需求的變更控制、需求的實作跟蹤兩個方面。軟體需求包括 3 個不同的層次――業務需求、使用者需求和功能需求。除此之外，每個系統還有各種非功能需求。需求的分類是軟體需求階段必不可少的工作，它可以指導開發人員了解不同的行業的業務、了解使用者的真實需求，清楚這些之後确立好功能項；當開發人員對整體需求有了明确的目标後，就可以按部就班快速有效地進行功能項開發，一般就不會背離系統開發需求的初衷。
1、業務需求
業務需求（Business requirement）表示組織或客戶高層次的目标。業務需求通常來自項目投資人、購買産品的客戶、實際使用者的管理者、市場營銷部門或産品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目标。使用前景和範圍（ vision and scope ）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（ project charter 或 market requirement ）文檔。
2、使用者需求
使用者需求（user requirement）描述的是使用者的目标，或使用者要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達使用者需求的有效途徑。也就是說使用者需求描述了使用者能使用系統來做些什麼。
3、功能需求
功能需求（functional requirement）規定開發人員必須在産品中實作的軟體功能，使用者利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（ behavioral requirement ），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知使用者已接受其預定”。功能需求描述是開發人員需要實作什麼。
4、非功能性需求
4-1、系統需求（system requirement）用于描述包含多個子系統的産品（即系統）的頂級需求。系統可以隻包含軟體系統，也可以既包含軟體又包含硬體子系統。人也可以是系統的一部分，是以某些系統功能可能要由人來承擔。
4-2、業務規則包括企業方針、政府條例、工業标準、會計準則和計算方法等。業務規劃本身并非軟體需求，因為它們不屬于任何特定軟體系統的範圍。然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實作某些特定功能。有時，功能中特定的品質屬性（通過功能實作）也源于業務規則。是以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。
4-3、功能需求記錄在軟體需求規格說明（ SRS ）中。 SRS 完整地描述了軟體系統的預期特性。 SRS 我們一般把它當作文檔，其實， SRS 還可以是包含需求資訊的資料庫或電子表格；或者是存儲在商業需求管理工具中的資訊；而對于小型項目，甚至可能是一疊索引卡片。開發、測試、品質保證、項目管理和其他相關的項目功能都要用到 SRS 。除了功能需求外， SRS 中還包含非功能需求，包括性能名額和對品質屬性的描述。
4-4、品質屬性（quality attribute）對産品的功能描述作了補充，它從不同方面描述了産品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對使用者或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實作的限制。
4-5、限制（constraint）限制了開發人員設計和建構系統時的選擇範圍，如局限于軟體工程學科。
注：厘清楚那些是業務需求、哪些是使用者需求、哪些是功能性需求和非功能性需求對軟體的開發有着重大的指導意義，絕不可以以偏概全，錯誤地去揣摩使用者的心思；對于開發者而言，所有軟體功能的開發我們都應該一一征求使用者的意見，對需求有了清晰的認識後再進行實質性的開發工作。
2.4.2.1 需求變更控制
1、 需求變更申請
對于一、二級變更，變更申請人必須填寫《需求變更申請單》，送出項目經理。三級變更可以不填寫《需求變更申請單》，直接告知項目經理即可；
2、 變更評估
項目經理對變更申請進行變更影響分析、評估，确定是否變更、變更影響範圍及變更時機。
3、 變更決策
對于三級變更，項目經理直接審批是否變更及變更時機，并進行後續的變更實施處理；
對于一、二級變更，需要送出CCB（軟體配置控制委員會）、高層經理審批是否變更及變更時機。
l 如果允許變更，項目經理安排變更任務，必要時制定詳細的變更計劃。變更内容主要有：
² 更新受影響的《項目計劃》、《項目進度表》等管理文檔；
² 更新受影響的各類技術文檔（需求、設計、開發、測試文檔等）；
² 更新項目配置庫；
l 如果不允許變更，則直接跳轉到“6、變更溝通存檔”步驟。
4、 變更實施
變更責任人根據變更任務實施變更。
項目經理或CCB進行變更後的審批及釋出，通知受影響的組或個人。對于影響較小的變更可以暫時不更新基線，對于影響較大的變更（需更新基線時），由相關責任人送出《基線建立申請單》，審批通過後建立新的基線。
5、 變更驗證
項目經理對變更進行跟蹤驗證、直到變更結果和預期相符，相關内容進行了更新，工作産物符合版本管理要求為止。
QA監督變更過程活動，如有協商不一緻的問題，則記錄到《不一緻項問題跟蹤表》中，并送出給高層。
6、 變更溝通存檔
将變更後的内容通知可能會受到影響的人員，并将變更記錄彙總歸檔，如提出的變更在變更決策時被否決，其初始記錄也應與儲存。
需求變更按照嚴重程度，分為一、二、三級變更：
² 一級變更
是指該變更會導緻工作量延遲超出整個工程過程階段計劃總工作量的10%（或超過10個工作日）的變更，對項目的進度、成本、品質等關鍵要素造成嚴重影響，需要重新定義需求工作，大量開發代碼需要重新編寫。
² 二級變更
是指該變更會導緻工作量延遲整個工程過程階段計劃總工作量的5～10%（或超過5個工作日，小于10個工作日）的變更，對項目的進度、成本、品質等關鍵要素未造成重大影響。
² 三級變更
是指該變更會導緻工作量延遲小于整個工程過程階段計劃總工作量的5%（或小于5個工作日）的變更，幾乎不會對項目的進度、成本、品質等關鍵要素造成較大影響。
三種級别的需求的變更均可以由項目經理、需求開發人員或者相關使用者提出，需求變更提出後，交予項目經理确認，由項目經理分析變更影響，初步确定變更級别。
确認為一、二級的需求變更，經項目經理送出CCB。如果CCB同意了該變更申請，則由項目經理組織項目組成員和需求開發人員進行需求變更工作，即重新進行需求開發、需求确認，更新《使用者需求說明書》和《産品需求規格說明書》，填寫《需求變更記錄表》，需求開發人員及時更新《需求跟蹤矩陣》。如果變更申請被拒絕，CCB則需要在變更申請中說明理由，項目則繼續按原計劃進行。
确認為三級的需求變更，需求的變更人無需填寫《需求變更申請書》，經項目經理确認後将變更項填入《需求變更記錄表》中即可，然後直接進行後續的變更操作，無需再交由CCB進行評審。但當三級變更數量達到20條以上範圍時，或累積産生的影響達到一、二級變更的影響時，應當引起項目經理高度注意，查找問題所在，并送出使用者确認。
所有的一、二級變更項，須得到使用者的确認簽字，三級的需求變更定期告知使用者即可，無須使用者的正式确認簽字；但當三級變更累積産生的影響達到一、二級變更的影響時，則需要提請使用者予以确認簽字。
所有的一、二級變更項經過處理後，需要變更需求相關文檔的版本号，從VX.Y版本變更到VX.(Y+1)版本，超出整個工程過程階段計劃總工作量的20%或成本超出整個工程過程階段計劃總成本的20%以上的一級變更，從VX.Y版本直接變更到V(X+1).0版本。
2.4.2.2 需求跟蹤
當《使用者需求說明書》編寫完成，經過需求評審、使用者簽字後，需求開發人員建立需求跟蹤矩陣，需要填寫具體使用者需求編号，需求類别，目前狀态等。
需求跟蹤矩陣建立完成後，需求開發人員需要在以下時機成熟時更新該矩陣：
l 每周例會時：
需求開發人員在每周例會上根據本周完成的需求或與此需求相關的工作産品完成情況更新《需求跟蹤矩陣》。
l 軟體需求評審通過時：
《産品需求規格說明書》及其附件内容（業務模型、資料字典、系統Demo等）評審通過并且使用者确認簽字後，需求開發人員更新《需求跟蹤矩陣》。
l 項目裡程碑時：
在項目進入裡程碑階段（需求結束、系統測試結束等）時，也要及時進行更新。需求開發人員更改所有相關需求文檔，以及相應的工作産品，使得每一個軟體的需求均能夠與後續工作成果保持一緻。
l 需求變更時：
當需求發生變更時，項目變更或者需求開發人員發現需求與項目實施過程存在不符合項時，也要及時更新《需求跟蹤矩陣》。
2.5 輸出
² 《使用者需求調研記錄》及《使用者需求調查單》
² 《使用者需求說明書》
² 《産品需求規格說明書》
² 系統開發原型Demo、業務模型、資料字典等
² 《需求評審報告》
² 《需求跟蹤矩陣》
² 《需求變更申請單》
² 《需求變更記錄》
2.6 出口準則
項目結項。
2.7 過程度量
| № | 度量點 | 執行人 | 度量時機|頻率 | 存儲位置 |
| M-1 | 需求變更數 | 需求開發人員 | 每周 | 《需求跟蹤矩陣》 |
| M-2 | 需求變更工作量 | 需求開發人員 | 每周 | 《需求跟蹤矩陣》 |
2.8 裁剪說明
| 裁剪對象 | 類型（過程活動或工作産品） | 裁減要素（增加、删除、修改） | 裁減條件 |
| 産品 | 業務模型、資料字典 | 删除 | 使用者需求易于了解時 |
| 産品 | 系統開發原型（Demo） | 删除 | 使用者需求易于了解時 |
3. 相關指南
² 《需求調研指南》
² 《用例指南》
【軟體開發過程所有文檔擷取--關注--私信】