【系統分析師】軟件需求工程——第11章學習筆記（上）

軟件需求工程是包括創建和維護軟件需求文檔所必需的一切活動的過程。

可分為兩大工作：

需求開發
- 需求獲取
- 需求分析
- 需求定義（編寫需求規格說明書）
- 需求驗證
需求管理
- 定義需求基線
- 處理需求變更
- 需求跟蹤

在需求開發階段需要確定軟件所期望的用戶類型，獲取每種用戶類型的需求，了解實際的用戶任務和目標，以及這些任務所支持的業務需求。同時還包括分析源于用戶的信息，對需求進行優先級分類，將所收集的需求編寫成需求規格說明書和需求分析模型，以及對需求進行評審等工作。

11.1 軟件需求概述

11.1.1 需求的層次

簡單地說，軟件需求就是系統必須完成的事以及必須具備的品質。

需求是多層次的，包括業務需求、用戶需求和系統需求，這三個不同層次從目標到具體，從整體到局部，從概念到細節。

業務需求
- 反映企業或客戶對系統高層次的目標要求，通常來自項目投資人，購買產品的客戶，客戶的管理人員，市場營銷部門或產品策劃部門等
用戶需求
- 描述用戶的具體目標，或用戶要求系統必須能完成的任務
系統需求
- 從系統的交付說明軟件的需求，包括功能需求（行為需求），非功能需求，設計約束等

11.1.2 質量功能部署

質量功能部署(Quality Function Deployment，QFD)是一種將用戶要求轉化成軟件需求的技術，其目的是最大限度地提升軟件工程過程中用戶的滿意度。

為了達到這個目標，QFD將軟件需求分為三類:常規需求、期望需求和意外需求。

常規需求。
- 用戶認為系統應該做到的功能或性能，實現越多用戶會越滿意
期望需求。
- 用戶想當然認為系統應具備的功能或性能，但并不能正確描述自己想要得到的這些功能或性能需求。如果期望需求沒有得到實現，會讓用戶感到不滿意。
意外需求。
- 意外需求也稱為興奮需求，是用戶要求范圍外的功能或性能(但通常是軟件開發人員很樂意賦予系統的技術特性)，實現這些需求用戶會更高興，但不實現也不影響其購買的決策。

11.1.3 軟件需求

軟件包含以下方面的內容：

用戶解決問題或達到目標所需條件或權能。
系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所需具有的條件或權能。
一種反映上面(1)或(2)所述條件或權能的文檔說明，即需求規格說明。它包括功能性需求及非功能性需求，非功能性需求對設計和實現提出了限制，比如性能要求、質量標準或者設計限制。

在統一過程(UP)中，需求按照“FURPS+”模型進行分類。“FURPS+”中的“FURPS具體指以下需求:

功能性(Functional):特性、功能、安全性
可用性(Usability):人性化因素、幫助、文檔。
可靠性(Reliability):故障頻率、可恢復性、可預測性。
性能(Performance):響應時間吞吐量、準確性、有效性、資源利用率。
可支持(Sptability):適應性、可維護性、國際化、可配置性。

“FURPS+”中的“+”是指一些輔助性的和次要的因素，用來強調各種不同的屬性。比如:

實現(Implementation):資源限制、語言和工具、硬件等。
接口(Interface):強加于外部系統接口之上的約束。
操作(Operation):對其操作設置的系統管理。
包裝(Packaging):例如物理的包裝盒。
授權(Legal):許可證或其他方式。

11.1.4 需求工程

人們逐漸意識到需求分析活動不僅限于軟件開發的最初階段，它貫穿于系統開發的整個生命周期。

需求工程是指：應用已證實有效的原理，方法，通過合適的工具和幾號，系統地描述開發系統及其行為特征和相關約束。

主要被劃分為以下幾個階段：

需求獲取
需求分析
形成需求規格（需求文檔化）
需求確認與驗證
需求管理

11.2 需求獲取

11.2.1 用戶訪談

最基本的一種需求獲取手段。其形式包括結構化和非結構化兩種。

結構化是指事先準備好一系列問題，有針對地進行
非結構化是列出一個粗略的想法，根據訪談的具體情況發揮。

系統分析師需要再三個方面進行組織：準備訪談，主持訪談，訪談的后續工作

準備訪談
- 確定訪談的目的
- 確定包括哪些用戶
- 準備一些詳細的問題
  - 開放式
  - 封閉式
- 作出最終的訪談安排，并通知所有參與者
主持訪談
- 限制訪談時間
- 尋找異常和錯誤情況
- 深入調查細節
- 認真記錄
訪談的后續工作
- 吸收，理解，記錄訪談所獲得的信息

11.2.2 問卷調查

可以收集到大量的信息，以低廉的代價短時間內收集到大量的回答，但缺乏靈活性

最好的做法事先問卷調查，進行仔細整理和分析，針對結果進行小范圍用戶訪談。

11.2.3 采樣

從種群中系統地選出有代表性的樣本集的過程，通過認真研究所選出的樣本集，可以從整體上揭示種群的有用信息。這里，系統的文檔就是采樣種群。

選擇樣本的方式有隨機采樣，分層采樣，聚類采樣，系統采樣等

采樣不僅可以用于收集數據，還可以采集訪談用戶或者采集觀察用戶。

11.2.4 情節串聯板

很多用戶對信息系統沒有直觀認識，這樣也很容易產生盲區，這時候，需要系統分析師用情節串聯版技術來幫助用戶消除盲區

情節串聯版通常是一些列圖片，系統分析師通過圖片來講故事。比如流程圖，交互圖，報表等

類型包括被動式，主動式，交互式，其復雜程度依次遞增

被動式
- 草圖，圖片，PPT，系統分析師簡述場景
主動式
- 看到類似“電影”內容，自動播放，自動簡述
交互式
- 用戶親自體驗，比如仿真器，實物模型，拋棄式原型。

優點：直觀，生動，用戶友好，交互性強

缺點：花費的時間很多，需求獲取速度大大降低

11.2.5 聯合需求計劃

聯合需求計劃(Joint Requirement Planning，JRP)是一個通過高度組織的群體會議來分析企業內的問題并獲取需求的過程，它是聯合應用開發(JointApplicationDevelopment，JAD)的一部分。

聯合應用開發

JAD是以小組形式定義和建立系統的，它是由企業主管部門經理、會議主持人、用戶、協調人員、IT 人員、秘書等共同組成的專題討論組。由這個專題討論組來定義并詳細說明系統的需求和可選的技術方案。JAD的過程大致如下:

確定JAD項目，主要指確定系統的范圍和規范。
在JAD 專題預備會上，會議主持人向參與者介紹項目和JAD專題討論內容
準備JAD專題討論材料。
進行JAD專題討論會，其目的是要達成對需求的一致意見，并對各種可選的技術方案加以過論從由研究出幾有可供選擇的方案

JRP會議

聯合需求計劃(Joint Requirement Planning，JRP)是一種相對來說成本較高的需求獲取方法，但也是一種十分有效的方法。

它通過聯合各個關鍵用戶代表、系統分析師、開發團隊代表，通過有組織的會議來討論需求。通常該會議的參與人數為6~18人，召開時間為1~5h。

在會議之前，應該將與討論主題相關的材料提前分發給所有將要參加會議的人。在會議開始之后，按照以下步驟進行:

應該花一些時間讓所有的與會者互相認識，以使交流在更加輕松的氣氛下進行。會議開始時，針對所列舉的問題進行逐項專題討論。
對現有系統和類似系統的不足進行開放性交流。鼓勵與會者在短時間內說出盡量多的想法，在這一過程中不對這些想法發表任何評論。
大家在此基礎上對新的解決方案進行一番設想，在這個過程中，需要把這些想法、問題、不足記錄下來，形成一個要點清單。
針對這個要點清單進行整理，明確優先級，并進行評審

主要原則

JRP的主要意圖是收集需求，而不是對需求進行分析和驗證。

實施IP時應把握以下主要原則:

在JRP實施之前，應制定詳細的議程，并嚴格遵照議程進行。
按照既定的時間安排進行。
盡量完整地記錄會議期間的內容。
在討論期間盡量避免使用專業術語。
充分運用解決沖突的技能。
會議期間應設置充分的間歇時間。
鼓勵團隊取得一致意見。
保證參加 JRP的所有人員能夠遵守事先約定的規則。

JRP將會起到群策群力的效果，對于一些最有歧義的問題、需求最不清晰的領域都是十分有用的一種方法。

這種方法最大的難度是會議的組織和相關人員的能力，要做到言之有物，氛開放，否則，將難以達到預想的效果。

11.2.6 需求記錄技術

在開發過程中，有時候進行需求獲取的人員和進行需求分析的人員不是同一個人（部門），因此，需要統一需求記錄工具，以便所有人的獲取結果是統一口徑的。

任務卡片

各個項目的內容及解釋如圖11-1：

任務卡片還有一個增強版，如圖11-2，增加問題點描述和解決方案提示

場景說明

有時候，很難總結出子任務和任務變體，因為需要對任務執行過程進行抽象，這時候可以用場景說明來對用戶的描述進行整理。

場景說明就是用戶對其工作場景和過程的詳細描述。

用戶故事

描述對用戶有價值的功能，包含書面描述（用于計劃和備忘），交談（細化故事）和測試用例（驗證故事實現）。在任何項目中，需要用戶團隊根據故事的重要性來安排開發工作，回答所有開發問題，編寫所有的故事。在編寫故事之前應該建立用戶角色模型，必須包含對項目成功至關重要的角色，盡量保證所有用戶對系統完全滿意。
用戶故事具有6個基本屬性:獨立性、可協商性、對用戶有價值、可預測性、短小精悍和可測試性。

獨立性。
- 盡可能避免故事之間存在依賴關系，因為依賴關系會產生優先級和規劃問題
可協商性。
- 故事是可協商的，不是必須實現的書面合同或者需求。
對用戶有價值。
- 確保每個故事對用戶有價值的最好方式是讓用戶編寫故事。
可預測性。
- 系統分析師應該能夠預測(至少大致猜測)故事的規模，以及實現所需要的工作量。
短小精悍。
- 故事規模對實現有影響，哪種故事規模最合適，取決于開發團隊的規模和能力，以及技術實現等方面。
可測試性。
- 所編寫的故事必須是可測試的。

Volere白卡

一種類似于任務卡片的需求記錄工具

用戶故事和白卡定位的是最小的需求項，因此在實際應用中會導致量比較大，一般在敏捷方法中使用。

11.3 需求分析

將雜亂的用戶需求整理成好的需求（具有二義性，完整性，一致性，可測試性，確定性，可跟蹤性，正確性，必要性等特性）

11.3.1 需求分析的任務

把用戶對開發軟件提出的要求進行分析整理，確認后形成描述完整，清晰與規范的文檔。

11.3.2 需求分析的方法

分析的方法有很多比如

結構化分析(Structured Analysis，SA)方法
面向對象的分析(Object-Oriented Analysis，OOA)方法
面向問題域的分析(Problem Domain Oriented Analysis，PDOA)方法。

PDOA

與 SA 方法和 OOA方法相比，PDOA方法更多地強調描述，而較少強調建模。它的描述大致分為以下兩個部分:

關注問題域。用一個文檔對含有的問題域進行相關的描述，并列出需要在該域中求解的問題列表，也就是需求列表。只有這個文檔是在分析時產生的。
關注解系統(即系統實現)的待求行為。用一個文檔對解系統的待求行為進行描述該文檔將在需求定義階段完成。

在 PDOA方法中，對整個過程有著清晰的定義:

收集基本的信息并開發問題框架，以建立問題域的類型。
在問題框架類型的指導下，進一步收集詳細信息，并給出一個問題域相關特性的描述。
基于以上兩點，收集并用文檔說明新系統的需求。

從上面的描述中可以看出，問題框架是PDOA的核心元素，是將問題域分為一系列相互關聯的子域，而一個子域可以是那些可能算是精選出來的問題域的一部分。

也可以把問題框架看作是開發上下文范圍關系圖，但不同的是，上下文范圍關系圖的建模對象是針對解系統，而問題框架則是針對問題域。

也就是說，問題框架的目標就是大量地獲取更多有關問題域的信息。

方法的對比

SA 方法關注于功能的分層和分解，這非常符合人們自上而下、逐步分解問題直到可解決的思考方式。

SA方法本身隱含著幾個基本假設，即問題域是可定義的、問題域是有限的、通過有限的步驟總可以將復雜問題分解到可解決的程度。SA方法應用的是科學方法中的因果律、歸納法和邏輯法，通過對現實世界中的問題域進行不斷的“測量”和“分解”，直到得到問題域的邏輯模型。

OOA 方法則遵循完全不同的思維方式，它基于抽象、信息隱藏、功能獨立和模塊化這些基本理念對系統進行分析。OOA方法首先對問題域的事物的“外在表象”進行觀測，然后在邏輯世界中模擬出一個對應的邏輯對象,“斷定”該對象和現實事物是一致的。隨后，觀測到的對象被記錄入對象集合，觀測到的行為和表象被記錄入對象關系模型和對象行為模型。OOA方法建立的對象彼此之間通過接口來相互溝通，每傳遞一個消息即觸發一個事件，并引起內部方法的執行。只有觀測對象內部的時候，才能看到具體的屬性和方法。否則，只能看到對象對外部開放的接口。

SA方法假定系統分析師理解問題域的全部，并且有能力正確地識別和分解問題。

而OOA方法既不假定系統分析師理解問題域的全部，也不假定其能夠建立正確的抽象對象，它只承諾一種可以持續“觀測并理解”的方法，以及“觀測后建立”的對象和現實世界的外在表象是一致的。

11.4 結構化分析方法

基本思想：自頂向下，逐層分解，把大問題分解成一個個小問題

SA方法分析模型的核心是數據字典，圍繞這個核心，有三個層次的模型，分別是數據模型、功能模型和行為模型(也稱為狀態模型)。

在實際工作中，一般使用E-R圖表示數據模型，用DFD表示功能模型，用狀態轉換圖(State Transform Diagram，STD)表示行為模型。

這三個模型有著密切的關系，它們的建立不具有嚴格的時序性，而是一個迭代的過程。

11.4.1 數據流圖

DFD是SA方法中的重要工具。可以被認為是一個系統模型。

DFD的主要作用

DFD是理解和表達用戶需求的工具，是需求分析的手段。由于DFD簡明易懂，不需要任何計算機專業知識就可以理解它，因此，系統分析師可以通過DFD與用戶進行交流。
DFD概括地描述了系統的內部邏輯過程，是需求分析結果的表達工具，也是系統設計的重要參考資料，是系統設計的起點。
DFD作為一個存檔的文字材料，是進一步修改和充實開發計劃的依據。

DFD的基本符號

數據流
- 有名字的箭頭
加工
- 對數據流的變換，一般用圓圈
數據存儲
- 一般用直線段表示
外部實體（數據源以及數據終點）
- 系統之外的生產者或消費者，不能由計算機處理的部分

DFD的層次

SA方法的思路是依賴于DFD進行自頂向下的分析。

頂層圖：

系統最高層結構的DFD。將整個待開發的系統表示為一個加工，將所有的外部實體和進出系統的數據流放在一張圖中。

逐層分解

加工的編號，將以1,2,3為序列展開。對0層圖上的加工進行再分解，稱之為1層圖，其編號規則是：1. 1, 1.2, 1.3.......

如何畫DFD

DFD的繪制是一個自頂向下、由外到里的過程，通常按照以下幾個步驟進行:

畫系統的輸入和輸出:
1. 在圖的邊緣標出系統的輸入數據流和輸出數據流。這一步其實是決定研究的內容和系統的范圍。
畫 DFD的內部:
1. 將系統的輸入、輸出用一系列的處理連接起來，可以從輸入數據流畫向輸出數據流，也可以從中間畫出去。
為每一個數據流命名:
1. 命名的好壞與DFD的可理解性密切相關，應避免使用空洞的名字。
為加工命名:
1. 使用動賓短語為每個加工命名。

每畫好一張 DFD，就需要進行檢查和修改，檢查和修改的原則如下:

DFD中的所有圖形符號只限于前述4種基本圖形元素，圖上每個元素都必須有名字。
每個加工至少有一個輸入數據流和一個輸出數據流，而且要保持數據守恒。也就是，一個加工的所有輸出數據流中的數據必須能從該加工的輸入流中直接獲得，或者通過該加工能產生的數據。一個加工的輸出數據流不應與輸入數據流同名，即使它們的組成完全相同。
在 DFD中，須按層給加工編號。編號表明了該加工處在哪一層，以及上下層的父圖與子圖的對應關系。
規定任何一個 DFD 子圖必須與它上一層的一個加工對應，兩者的輸入數據流和輸出數據流必須一致。
- 這就是父圖與子圖的平衡。也就是說，父圖中的某加工的輸入/輸出數據流必須與它的所有子圖的輸入/輸出數據流在數量上和名字上相同。值得注意的是，如果父圖中的一個輸入/輸出數據流對應于子圖中的幾個輸入/輸出數據流，而子圖中組成這些數據流的數據項的全體正好是父圖中的這一個數據流，那么它們仍然算是平衡的。
在整套DFD中，每個數據存儲必須既有讀的數據流，又有寫的數據流。但是在某張子圖中，可能只有讀沒有寫，或者只有寫沒有讀。
可以在 DFD 中加入物質流，幫助用戶理解DFD，但不可夾帶控制流。