3.1 理解需求

需求工程在設計和構造之間建立起聯系的橋梁，它開始于項目的干系人（如項目經理、客戶、最終用戶，也包括技術團隊），定義業務需求，刻畫用戶場景，描述功能和特性，識別項目約束條件；有人建議從寬泛的系統定義開始，此時軟件只是更大的系統范圍中的一個構件。但不管起始點在哪里，需求工程允許由軟件團隊檢查將要進行的軟件工作的內容，提交設計和構建的特定要求，完成指導工作順序的優先級定義，并影響隨后設計的信息、功能和行為。

需求工程為以下工作提供了良好的機制：理解客戶需要什么、分析要求、評估可行性、協商合理的方案、無歧義地詳細說明方案、確認規格說明、管理需求，以及將這些需求轉化為可運行系統。

3.1.1 建立根基

大多數項目都是當確定了商業要求或發現了潛在的新市場、新服務時才開始。業務領域的干系人（如業務管理人員、市場人員和產品管理人員）定義業務用例，確定市場的寬度和深度，進行粗略的可行性分析，并確定項目范圍的工作說明。

在項目起始階段中，要建立起基本的理解，包括對問題、誰需要解決方案、所期望解決方案的性質，以及項目用戶和開發人員之間達成初步交流合作的效果等。

在項目起始階段，干系人建立基本的問題需求，定義最重要的項目約束，以及陳述主要的特征和功能，必須讓系統表現出這些特征和功能以滿足其目標。該信息在導出階段得到提煉和延伸，在此階段中利用有主持人的會議和使用場景的開發進行需求收集活動。

在理想情況下，干系人和軟件工程師在同一個小組中工作（這是敏捷軟件開發方法的主要部分）。這時，需求工程就只是和組里熟悉的同事進行有意義的交談。但實際情況往往不是這樣，客戶或最終用戶可能位于不同的城市或地區，對于想要什么可能僅有模糊的想法，對于將要構建的系統可能存在有沖突的意見，他們的技術知識可能很有限，可能僅有有限的時間與需求工程師溝通。這些事情雖不希望遇到但又十分常見，開發團隊經常被迫在這樣的環境限制下工作。

1.確認干系人

所謂“干系人”，可以定義為“直接或間接地從正在開發的系統中獲益的人”。例如：業務運行人員、產品管理人員、市場銷售人員、內部和外部客戶、最終用戶、顧問、產品工程師、軟件工程師、支持和維護工程師，以及其他人員。每個干系人對系統都有不同的考慮，當系統成功開發后所能獲得的利益也不相同，同樣，當系統開發失敗時所面臨的風險也是不同的。

在開始階段，需求工程師應該創建一個人員列表（干系人名冊），列出那些有助于導出需求的人員。最初的人員列表將隨著接觸的干系人人數增多而變化。

2.識別多重觀點

因為存在很多方面的干系人，所以需求調研也將從不同的視角開展。例如，市場銷售部門關心能激發潛在市場的功能和特點；業務經理關注應該滿足已規定的市場限制；最終用戶可能希望系統的功能是他們所熟悉的并且易于學習和使用；軟件工程師可能關注那些軟件基礎設施所能夠支持的功能和特點；支持工程師可能關注軟件的可維護性。

這些參與者中的每一個人都將為需求工程過程貢獻信息。當從多個角度收集信息時，所形成的需求可能存在不一致性或相互矛盾。需求工程師要把所有干系人提供的信息（包括不一致或矛盾的需求）進行分類，以便決策者為系統選擇一個內部一致的需求集合。

3.協同合作

客戶和其他干系人及軟件工程人員團結協作，才能成功實現預定的系統。需求工程師的工作是標識公共區域（即所有干系人都同意的需求）和矛盾區域（即某個干系人提出的需求和其他干系人的需求相矛盾）。顯然，后一個分類更有挑戰性。

在項目需求導出時的提問應該是“與環境無關的”，所提的問題將有助于識別對構建軟件感興趣的干系人。此外，問題還確認了某個成功實現的可度量收益及定制軟件開發的可選方案。

3.1.2 導出需求

詢問客戶、用戶和其他人，系統或產品的目標是什么，想要實現什么，系統和產品如何滿足業務的要求，最終系統或產品如何用于日常工作。這些問題看似簡單，要實現卻很困難，其原因包括以下幾個。

●范圍問題：系統的邊界不清楚，或是客戶或用戶的說明帶有不必要的技術細節，這些細節可能會導致混淆系統的整體目標。

●理解問題：客戶或用戶并不能完全確定需要什么，他們對其計算環境的能力和限制所知甚少，對問題域沒有完整的認識，與系統工程師在溝通上存在問題，忽略了一些“明顯的”信息，所確定的需求和其他客戶或用戶的實際需求相沖突，需求說明有歧義或不可測試。

●易變問題：需求隨時間變化。為了幫助解決這些問題，需求工程師必須有組織地開展需求收集活動。

導出需求（又稱需求收集）是與問題求解、精化、談判和規格說明等方面的元素結合在一起的。為了鼓勵合作，由干系人和開發人員共同組織的團隊將完成如下任務：確認問題，為解決方案的要素提供建議，商討不同的方法并描述初步的需求解決方案。

1.協同收集需求

不同的場景需要采用不同的協同需求收集方法，各種方法都以下面這些原則為基礎。

●會議由軟件工程師和其他的干系人共同舉辦和參與。

●制定籌備和參與會議的規則。

●擬定一個會議議程，這個議程既要足夠正式，使其涵蓋所有的重點，但也不能太正式，以鼓勵思想的自由交流。

●由一個“調解人”（可以是客戶、開發人員或其他人）控制會議。

●采用“方案論證手段”（可以是工作表、活動掛圖、不干膠貼紙或電子公告牌、聊天室或虛擬論壇）。

收集需求的目的是識別問題，提出解決方案的要素，協商不同的方法，以及在有利于完成目標的氛圍中確定一套解決需求問題的初步方案。

2.質量功能部署

質量功能部署（Quality Function Deployment，QFD）是一種將客戶要求轉化成軟件技術需求的質量管理技術，其目的是“最大限度地讓客戶從軟件工程過程中感到滿意”。為了達到這個目標，QFD強調理解“什么是對客戶有價值的”，然后在整個工程活動中部署實現這些價值。

QFD確認以下3類需求。

1）正常需求：這些需求反映了和客戶確定的針對某產品或系統的目標。例如所要求的圖形顯示類型、特定的系統功能，以及已定義的性能級別。

2）期望需求：這些需求隱含在產品或系統中，并且可能是非常基礎的，以至于客戶沒有顯式地說明，但是，缺少這些將導致客戶不滿。例如人機交互的易用性、整體運行的正確性和可靠性，以及軟件安裝的簡易性。

3）令人興奮的需求：這些需求反映了客戶期望之外的特點，如果實現這些特點，將會使客戶非常滿意。例如，新移動電話的軟件來自標準特性，但關聯了一些超出期望的能力（如多重觸控技術的觸摸屏、可視語音郵箱等）。

通過客戶訪談和觀察、調查，以及檢查歷史數據（如問題報告），QFD為需求收集活動獲取原始數據，然后把這些數據轉換成需求表——稱為客戶意見表，并由客戶和干系人評審。接著，使用各種圖表、矩陣和評估方法，抽取期望的需求并盡可能導出令人興奮的需求。

3.用戶場景

收集需求時，系統功能和特性的整體愿景開始具體化。但是，在軟件團隊弄清楚不同類型的最終用戶如何使用這些功能和特性之前，很難轉移到更技術化的軟件工程活動上。為此，開發人員和用戶可以創建一系列的場景，用以識別對將要構建系統的使用線索。場景通常稱為用例，它提供了將如何使用系統的描述。

4.導出工作產品

根據將要構建的系統或產品的規模不同，需求導出后產生的工作產品也不同。對于大多數系統而言，工作產品包括以下幾個。

●要求和可行性陳述。

●系統或產品范圍的界限說明。

●參與需求導出的客戶、用戶和其他干系人的名單。

●系統技術環境的說明。

●需求列表（按照功能加以組織）及每個需求適用的領域限制。

●一系列使用場景，有助于深入了解系統或產品在不同運行環境下的使用。

●任何能夠更好地定義需求的原型。所有參與需求導出的人員需要評審以上的工作產品。

3.1.3 開發用例

在起始和導出階段獲得的信息將進行擴展和提煉，該任務集中于開發一個精確的需求模型，用以說明軟件的功能、特征和信息的各個方面。

精化是由一系列的用戶場景建模和求精任務驅動的。這些用戶場景描述了如何讓最終用戶和其他參與者與系統進行交互。解析每個用戶場景以便提取分析類——最終用戶可見的業務域實體。應該定義每個分析類的屬性，確定每個類所需要的服務，確定類之間的關聯和協作關系，并補充完成各種圖形。

本質上，用例講述了能表達主體場景的故事：最終用戶如何在一特定環境下和系統交互。這個故事可以是敘述性的文本、任務或交互的概要、基于模板的說明或圖形表示。不管其形式如何，用例從最終用戶的角度描述了軟件或系統。

撰寫用例的第一步是確定故事中所包含的“參與者”，即在將要說明的功能和行為環境內使用系統或產品的各類人員（或設備），代表了系統運行時人（或設備）所扮演的角色。更為正式的定義是：參與者是任何與系統或產品通信的事物，且對系統本身而言參與者是外部的。當使用系統時，每個參與者都有一個或多個目標。

需要注意的是，參與者和最終用戶并非一回事。典型的用戶可能在使用系統時扮演了多種角色，而參與者作為外部實體（人員），在用例中僅扮演一種角色。例如，考慮一個機床操作員（一個用戶），他和生產車間（其中裝有許多機器人和數控機床）內的某個控制計算機交互。在仔細考察需求后，控制計算機的軟件需要4種交互模式（角色）：編程模式、測試模式、監測模式和故障檢查模式。因此，4個參與者可定義為程序員、測試員、監控員和故障檢修員。有些情況下，機床操作員可以扮演所有這些角色，而有些情況下，每個參與者的角色可能由不同的人員扮演。

需求導出是一個逐步演化的活動，因此在第一次迭代中有可能識別主要的參與者，但并不能確認所有的參與者。對系統了解更多之后，才能識別出次要的參與者。主要參與者直接且經常使用軟件獲取所需的系統功能并從系統得到預期收益。次要參與者支持系統，以便主要參與者能夠完成他們的工作。

3.1.4 構建需求模型

精化階段進一步把需求擴展為分析模型——基于場景、類、行為和面向數據流的模型元素的集合。模型可能對分析模式和在不同的應用系統中重復出現分析問題的解決方案加以注解。

分析模型的目的是為基于計算機的系統提供必要的信息、功能和行為域的說明。隨著軟件工程師更多地了解將要實現的系統，以及其他干系人更多地了解他們到底需要什么，模型將動態地變更。

1.需求模型的元素

有很多方法來考察計算機系統的需求，不同的表達模式將促使軟件團隊從不同的角度考慮需求。但是，一些普遍的元素對大多數分析模型來說都是通用的。

1）基于場景的元素：使用基于場景的方法可以從用戶的視角描述系統。例如，基本的用例及其相應的用例圖演化成更精細的基于模板的用例。需求模型基于場景的元素通常是正在開發模型的第一部分。同樣，它們也作為創建其他建模元素時的輸入。圖3-1描繪了一張使用用例引發的需求，并表達了它們的UML活動圖，給出了最終基于場景表示的三層詳細表達。

圖3-1 導出需求的UML活動圖

2）基于類的元素：每個使用場景都暗示著當一個參與者和系統交互時所操作的一組對象，這些對象被分成類——具有相似屬性和共同行為的事物集合。例如，SafeHome是某個正在研發的家庭安全管理產品，可以用UML類圖描繪SafeHome安全功能的傳感器Sensor類，如圖3-2所示。注意，UML類圖列出了傳感器的屬性（如name、type）和可以用于修改這些屬性的操作（如identify、enable等）。除了類圖，其他分析建模元素描繪了類之間的協作，以及類之間的關聯和交互。

3）行為元素：基于計算機系統的行為能夠對所選擇的設計和所采用的實現方法產生深遠的影響。因此，需求分析模型必須提供描述行為的建模元素。

狀態是任何可以觀察到的行為模式，而狀態圖是一種表現系統行為的方法，該方法描繪了系統狀態及導致系統狀態改變的事件。此外，還指明了在某個特殊事件后采取的動作。

為了更好地說明狀態圖的使用，考慮將軟件嵌入到SafeHome的控制面板，負責讀取用戶的輸入信息。簡化的UML狀態圖如圖3-3所示，SafeHome的控制面板如圖3-4所示。另外，作為一個整體的系統行為表達也能夠基于各個類的行為建模。

圖3-2 SafeHome傳感器的類圖

圖3-3 UML狀態圖表示

圖3-4 SafeHome控制面板

4）面向數據流的元素：信息在基于計算機的系統中流動時會被轉換，系統接受多種形式的輸入，使用函數將其轉換，生成多種形式的輸出。輸入可以是操作人員輸入的數字，也可以是網絡上傳送的信息包或從備份存儲器取回的龐大數據文件。轉換可能由單一的邏輯比較、復雜的數值算法或專家系統的規則推理方法構成。輸出可能是點亮一個發光二極管或生成一份200頁的報告。

2.分析模式

分析模式即來自概念性業務模型的模式。有需求工程經驗的人會注意到，在特定的應用領域內，某些事情會在不同的項目甚至是不同的應用領域中重復發生。例如用戶接口的特點和功能都是共有的。這些分析模式在特定應用領域內提供了一些解決方案（如類、功能和行為），在為許多應用項目建模時可以重復使用。

使用分析模式有兩個優點。首先，通過提供可重復使用的分析模型捕獲具體問題的主要需求，例如關于優點和約束的說明，從而提高了抽象分析模型的開發速度。其次，通過建議的設計模式和可靠的通用問題解決方案，有利于把分析模型轉變到設計模式。

通過參照模式名把分析模式整合到分析模型中，同時存儲在數據庫中以便需求工程師能通過搜索工具發現并應用。在標準模板中會提供關于分析模式（和其他類型模式）的信息。

3.1.5 協商需求

雖然只給予了有限的業務資源，而客戶和用戶卻提出了過高的要求，或者，不同的客戶或用戶提出了相互沖突的需求并堅持其重要性，這些都是常有的事。需求工程師必須通過協商過程來調解這些沖突。應該讓客戶、用戶和其他干系人對各自的需求排序，然后按優先級討論沖突。使用迭代的方法給需求排序，評估每項需求對項目產生的成本和風險，表述內部沖突，刪除、組合和（或）修改需求，以便參與各方均能達到一定的滿意度。

在確定需求并且創建分析模型時，軟件團隊和其他項目干系人協商優先級、可用性和每個需求的相對成本。協商的目標是開發一個現實可行的項目計劃。此外，將按照客戶需求確認每個需求和整個需求模型，以確認將要構建的系統對于客戶的要求是正確的。

在一個理想的需求工程情境中，起始、導出和精化工作能確保得到足夠詳細的客戶需求，以開展后續的軟件工程步驟。而實際上，在多數情況下要讓干系人以成本和產品投放市場的時間為背景，平衡功能、性能和其他的產品或系統特性。其目的是保證所開發的項目計劃，在滿足干系人要求的同時反映軟件團隊所處真實世界的限制（如時間、人員和預算）。

最好的協商是爭取“雙贏”的結果，即干系人“贏”在獲得滿足客戶大多數需要的系統或產品，而軟件團隊“贏”在按照實際情況、在可實現的預算和時間期限內完成工作。

3.1.6 確認需求

軟件需求規格說明（SRS）是在項目商業化之前必須建立的詳細描述軟件各個方面的文檔。當軟件由第三方開發時，當缺少規格說明導致嚴重業務問題時，或是當系統非常復雜或涉及十分重要的業務時，需求規格說明是非常必要的。

在編制規格說明時必須保持其靈活性。對大型系統而言，文檔最好采用自然語言描述和圖形化模型來編寫。而對于技術環節明確的較小產品或系統，使用場景可能就足夠了。

下面這一套提綱模板可以為建立完整的需求規格說明書提供指導。

在這一步將對需求工程的工作產品進行質量評估，保證已無歧義地說明了所有的系統需求，已檢測出不一致性、疏忽和錯誤并得到糾正，工作產品符合為過程、項目和產品建立的標準。正式的技術評審是最主要的需求確認機制。確認需求的評審小組包括軟件工程師、客戶、用戶和其他干系人。

基于計算機系統的需求變更要求貫穿于系統的整個生存期。需求管理是用于幫助項目組在項目進展中標識、控制和跟蹤需求及需求變更的一組活動。