軟件工程之需求分析(二)

2． 需求分析

　　1）繪制關聯圖：繪制系統關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質流。

　　2）創建開發原型：創建用戶接口原型當開發人員或用戶不能確定需求時，開發一個用戶接口原型，這樣使得許多概念和可能發生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。

　　3）分析可行性：分析需求可行性在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。

　　4）確定需求優先級：確定需求的優先級別應用分析方法來確定使用實例、產品特性或單項需求實現的優先級別。以優先級為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。

　　5）為需求建立模型：為需求建立模型需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。

　　6）編寫數據字典：創建數據字典數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確?？蛻襞c開發小組是使用一致的定義和術語。分析和設計工具通常包括數據字典組件。

　　7）應用質量功能調配：使用質量功能調配質量功能調配是一種高級系統技術，它將產品特性、屬性與對客戶的重要性聯系起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。它將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現了會給客戶帶去驚喜，但若未實現也不會受到責備。 

3． 編寫規格說明書

　　項目視圖和范圍文檔包含了業務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬性和外部接口需求。軟件需求規格說明闡述一個軟件系統必須提供的功能和性能以及它所要考慮的限制條件,它不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟件需求規格說明不應該包括設計、構造、測試或工程管理的細節。

　　1）采用軟件需求規格說明模版: 采用需求規格說明書模板在你的組織中要為編寫軟件需求文檔定義一種標準模板。該模板為記錄功能需求和各種其它與需求相關的重要信息提供了統一的結構。注意，其目的并非是創建一種全新的模板，而是采用一種已有的且可滿足項目需要并適合項目特點的模板。許多組織一開始都采用IEEE標準830-1998(IEEE 1998)描述的需求規格說明書模板。要相信模板是很有用的，但有時要根據項目特點進行適當的改動。

  1 2 3 4 5 6 A引言 目的 文檔約定 預期的讀者和閱讀建議 產品的范圍 參考文獻   B綜合描述 產品的前景 產品的功能 用戶類和特征 運行環境 設計和實現上的限制 假設和依賴附錄 C外部接口需求附錄 用戶界面附錄 硬件接口 軟件接口 通信接口     D系統特性 說明和優先級 激勵/響應序列 功能需求       E 其它非功能需求 性能需求 安全設施需求 安全性需求 軟件質量屬性 業務規則 用戶文檔 F其它需求             G附件 詞匯表 分析模型 待確定問題的列表      　　　　　　　　　　　　　　　　　表2 需求規格說明模板
　　a. 引言

　　　引言提出了對軟件需求規格說明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。

　　a . 1 目的

　　　對產品進行定義，在該文檔中詳盡說明了這個產品的軟件需求，包括修正或發行版本號。如果這個軟件需求規格說明只與整個系統的一部分有關系，那么就只定義文檔中說明的部分或子系統。

　　a.2 文檔約定

　　　描述編寫文檔時所采用的標準或排版約定，包括正文風格、提示區或重要符號。

　　a.3 預期的讀者和閱讀建議

　　　列舉了軟件需求規格說明所針對的不同讀者，例如開發人員、項目經理、營銷人員、用戶、測試人員或文檔的編寫人員。描述了文檔中剩余部分的內容及其組織結構。提出了最適合于每一類型讀者閱讀文檔的建議。

　　a.4 產品的范圍

　　　提供了對指定的軟件及其目的的簡短描述，包括利益和目標。把軟件與企業目標或業務策略相聯系?？梢詤⒖柬椖恳晥D和范圍文檔而不是將其內容復制到這里。

　　a.5 參考文獻

　　　列舉了編寫軟件需求規格說明時所參考的資料或其它資源。這可能包括用戶界面風格指導、合同、標準、系統需求規格說明、使用實例文檔，或相關產品的軟件需求規格說明。

　　b. 綜合描述

　　　這一部分概述了正在定義的產品以及它所運行的環境、使用產品的用戶和已知的限制、假設和依賴。

　　b.1 產品的前景

　　　描述了軟件需求規格說明中所定義的產品的背景和起源。說明了該產品是否是產品系列中的下一成員，是否是成熟產品所改進的下一代產品、是否是現有應用程序的替代品，或者是否是一個新型的、自含型產品。

　　b.2 產品的功能

　　　概述了產品所具有的主要功能。其詳細內容將在d 中描述，所以在此只需要概略地總結。很好地組織產品的功能，使每個讀者都易于理解。

　　b.3 用戶類和特征

　　　確定你覺得可能使用該產品的不同用戶類并描述它們相關的特征。有一些需求可能只與特定的用戶類相關。

　　b.4 運行環境

　　　描述了軟件的運行環境，包括硬件平臺、操作系統和版本，還有其它的軟件組件或與其共存的應用程序。

　　b.5 設計和實現上的限制

　　　確定影響開發人員自由選擇的問題，并說明這些問題為什么成為一種限制。

　　b.6 假設和依賴

　　　列舉出在對軟件需求規格說明中影響需求陳述的假設因素（與已知因素相對立）。這可能包括你打算要用的商業組件或有關開發或運行環境的問題。你可能認為產品將符合一個特殊的用戶界面設計約定，但是另一個S R S 讀者卻可能不這樣認為。如果這些假設不正確、不一致或被更改，就會使項目受到影響。

　　此外，確定項目對外部因素存在的依賴。例如，如果你打算把其它項目開發的組件集成到系統中，那么你就要依賴那個項目按時提供正確的操作組件。如果這些依賴已經記錄到其它文檔(例如項目計劃)中了，那么在此就可以參考其它文檔。

　　c. 外部接口需求

　　　利用本節來確定可以保證新產品與外部組件正確連接的需求。關聯圖表示了高層抽象的外部接。需要把對接口數據和控制組件的詳細描述寫入數據字典中。如果產品的不同部分有不同的外部接口，那么應把這些外部接口的詳細需求并入到這一部分的實例中。

　　c.1 用戶界面

　　　陳述所需要的用戶界面的軟件組件。描述每個用戶界面的邏輯特征。而對于用戶界面的細節，例如特定對話框的布局，應該寫入一個獨立的用戶界面規格說明中，而不能寫入軟件需求規格說明中。

　　c.2 硬件接口

　　　描述系統中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之間交流的數據和控制信息的性質以及所使用的通信協議。

　　c.3 軟件接口

　　　描述該產品與其它外部組件（由名字和版本識別）的連接，包括數據庫、操作系統、工具、庫和集成的商業組件。明確并描述在軟件組件之間交換數據或消息的目的。描述所需要的服務以及內部組件通信的性質。確定將在組件之間共享的數據。

　　c.4 通信接口

　　　描述與產品所使用的通信功能相關的需求，包括電子郵件、We b 瀏覽器、網絡通信標準或協議及電子表格等等。定義了相關的消息格式。規定通信安全或加密問題、數據傳輸速率和同步通信機制。

　　d. 系統特性

　　d.1 說明和優先級

　　　提出了對該系統特性的簡短說明并指出該特性的優先級是高、中，還是低?；蛘吣氵€可以包括對特定優先級部分的評價，例如利益、損失、費用和風險，其相對優先等級可以從1（低）到9 （高）。

　　d.2 激勵/響應序列

　　　列出輸入激勵（用戶動作、來自外部設備的信號或其它觸發器）和定義這一特性行為的系統響應序列。這些序列將與使用實例相關的對話元素相對應。

　　d.3 功能需求

　　　詳列出與該特性相關的詳細功能需求。這些是必須提交給用戶的軟件功能，使用戶可以使用所提供的特性執行服務或者使用所指定的使用實例執行任務。描述產品如何響應可預知的出錯條件或者非法輸入或動作。就像本章開頭所描述的那樣，你必須唯一地標識每個需求。

　　e. 其它非功能需求

　　　這部分列舉出了所有非功能需求，如產品的易用程度如何，執行速度如何，可靠性如何，當發生異常情況時，系統如何處理，而不是外部接口需求和限制。

　　e.1 性能需求

　　　闡述了不同的應用領域對產品性能的需求，并解釋它們的原理以幫助開發人員作出合理的設計選擇。確定相互合作的用戶數或者所支持的操作、響應時間以及與實時系統的時間關系。你還可以在這里定義容量需求，例如存儲器和磁盤空間的需求或者存儲在數據庫中表的最大行數。盡可能詳細地確定性能需求?？赡苄枰槍γ總€功能需求或特性分別陳述其性能需求，而不是把它們都集中在一起陳述。

　　e.2 安全設施需求

　　　詳盡陳述與產品使用過程中可能發生的損失、破壞或危害相關的需求。定義必須采取的安全保護或動作，還有那些預防的潛在的危險動作。明確產品必須遵從的安全標準、策略或規則。

　　e.3 安全性需求

　　　詳盡陳述與系統安全性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產品所創建或使用的數據的保護。定義用戶身份確認或授權需求。明確產品必須滿足的安全性或保密性策略。

　　e.4 軟件質量屬性

　　　詳盡陳述與客戶或開發人員至關重要的其它產品質量特性。這些特性必須是確定、定量的并在可能時是可驗證的。至少應指明不同屬性的相對側重點，例如易用程度優于易學程度，或者可移植性優于有效性。

　　e.5 業務規則

　　　列舉出有關產品的所有操作規則，例如什么人在特定環境下可以進行何種操作。這些本身不是功能需求，但它們可以暗示某些功能需求執行這些規則。

　　e.6 用戶文檔

　　　列舉出將與軟件一同發行的用戶文檔部分，例如，用戶手冊、在線幫助和教程。明確所有已知的用戶文檔的交付格式或標準。

　　f. 其它需求

　　　定義在軟件需求規格說明的其它部分未出現的需求，例如國際化需求或法律上的需求。你還可以增加有關操作、管理和維護部分來完善產品安裝、配置、啟動和關閉、修復和容錯，以及登錄和監控操作等方面的需求。

　　附錄A ：詞匯表

　　定義所有必要的術語，以便讀者可以正確地解釋軟件需求規格說明，包括詞頭和縮寫。你可能希望為整個公司創建一張跨越多項項目的詞匯表，并且只包括特定于單一項目的軟件需求規格說明中的術語。

　　附錄B ：分析模型

　　這個可選部分包括或涉及到相關的分析模型的位置，例如數據流程圖、類圖、狀態轉換圖或實體-關系圖。

　　附錄C ：待確定問題的列表

　　編輯一張在軟件需求規格說明中待確定問題的列表，其中每一表項都是編上號的，以便于跟蹤調查。

　　2）指明需求來源：指明需求的來源為了讓所有項目風險承擔者明白需求規格說明書中為何提供這些功能需求，要都能追溯每項需求的來源，這可能是一種使用實例或其它客戶要求，也可能是某項更高層系統需求、業務規范、政府法規、標準或別的外部來源。

　　3）為每項需求注上標號：為了滿足軟件需求規格說明的可跟蹤性和可修改性的質量標準，必須唯一確定每個軟件需求。為每項需求注上標號制定一種慣例來為需求規格說明書中的每項需求提供一個獨立的可識別的標號或記號。這種慣例應當很健全，允許增加、刪除和修改。作了標號的需求使得需求能被跟蹤，記錄需求變更并為需求狀態和變更活動建立度量。需求標識方法有序列號;層次化編碼;使用"待確定"（to be determined, TBD ）符號等。

　　4）記錄業務規范：是指關于產品的操作原則，比如誰能在什么情況下采取什么動作。將這些編寫成需求規格說明書中的一個獨立部分，或一獨立的業務規范文檔。某些業務規范將引出相應的功能需求；當然這些需求也應能追溯相應業務規范。

　　5）創建需求跟蹤能力矩陣：建立一個矩陣把每項需求與實現、測試它的設計和代碼部分聯系起來。這樣的需求跟蹤能力矩陣同時也把功能需求和高層的需求及其它相關需求聯系起來了。在開發過程中建立這個矩陣，而不要等到最后才去補建。

　　這里我們還要介紹需求規格說明書中設計階段，用到的圖形模型--數據字典、數據流圖、數據流圖、狀態轉換圖、對話圖和類圖。

　　數據字典：一個定義應用程序中使用的所有數據元素和結構的含義、類型、數據大小、格式、度量單位、精度以及允許取值范圍的共享倉庫。數據字典的維護獨立于軟件需求規格說明，并且在產品的開發和維護的任何階段，各個風險承擔者都可以訪問數據字典。它定義了原數據元素、組成結構體的復雜數據元素、重復的數據項、一個數據項的枚舉值以及可選的數據項。

　　數據流圖：是結構化系統分析的基本工具。一個數據流圖確定了系統的轉化過程、系統所操縱的數據或物質的收集（存儲），還有過程、存儲、外部世界之間的數據流或物質流。數據流模型把層次分解方法運用到系統分析上，這種方法很適用于事務處理系統和其它功能密集型應用程序。

　　數據流圖：描繪了系統的數據關系。分析實體聯系圖有助于對業務或系統數據組成的理解和交互，并暗示產品將有必要包含一個數據庫。相反，當你在系統設計階段建立實體聯系圖時，通常要定義系統數據庫的物理結構。

　　狀態轉換圖：實時系統和過程控制應用程序可以在任何給定的時間內以有限的狀態存在。當滿足所定義的標準時，狀態就會發生改變，例如在特定條件下，接收到一個特定的輸入激勵。這樣的系統是有限狀態機的例子。大多數軟件系統需要一些狀態建?；蚍治?，就像大多數系統涉及到轉換過程、數據實體和業務對象。

　　對話圖：在許多應用程序中，用戶界面可以看作是一個有限狀態機。在任何情況下僅有一個對話元素（例如一個菜單，工作區，行提示符或對話框）對用戶輸入是可用的。在激活的輸入區中，用戶根據他所采取的活動，可以導航到有限個其它對話元素。因此，許多用戶界面可以用狀態轉換圖中的一種稱為對話圖來建模。對話圖描繪了系統中的對話元素和它們之間的導航連接，但它沒有揭示具體的屏幕設計。

　　類圖：面向對象的軟件開發優于結構化分析和設計，并且它運用于許多項目的設計中，從而產生了面向對象分析、設計和編程的域。類圖是用圖形方式敘述面向對象分析所確定的類以及它們之間的關系 

4. 需求驗證

　　1）審查需求文檔：對需求文檔進行正式審查是保證軟件質量的很有效的方法。組織一個由不同代表（如分析人員，客戶，設計人員，測試人員）組成的小組，對需求規格說明書及相關模型進行仔細的檢查。另外在需求開發期間所做的非正式評審也是有所裨益的。

　　2）依據需求編寫測試用例：根據用戶需求所要求的產品特性寫出黑盒功能測試用例?？蛻敉ㄟ^使用測試用例以確認是否達到了期望的要求。還要從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結果與測試用例相一致。同時，要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。

　　3）編寫用戶手冊：在需求開發早期即可起草一份用戶手冊，用它作為需求規格說明的參考并輔助需求分析。優秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能。而輔助需求如質量屬性、性能需求及對用戶不可見的功能則在需求規格說明書中予以說明。

　　4）確定合格的標準：確定合格的標準讓用戶描述什么樣的產品才算滿足他們的要求和適合他們使用的。將合格的測試建立在使用情景描述或使用實例的基礎之上。 

二、需求管理

　　需求開發的結果應該有項目視圖和范圍文檔、使用實例文檔、軟件需求規格說明及相關分析模型。經評審批準，這些文檔就定義了開發工作的需求基線。這個基線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定。需求約定是需求開發和需求管理之間的橋梁，需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動。

　　 1．確定需求變更控制過程，確定一個選擇、分析和決策需求變更的過程。所有的需求變更都需遵循此過程，商業化的問題跟蹤工具都能支持變更控制過程。

　　2．建立變更控制委員會，組織一個由項目風險承擔者組成的小組作為變更控制委員會，由他們來確定進行哪些需求變更，此變更是否在項目范圍內，估價它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設置實現的優先順序，制定目標版本。

　　3．進行需求變更影響分析，應評估每項選擇的需求變更，以確定它對項目計劃安排和其它需求的影響。明確與變更相關的任務并評估完成這些任務需要的工作量。通過這些分析將有助于變更控制委員會作出更好的決策。影響分析可以提供對建議的變更的準確理解，幫助做出信息量充分的變更批準決策。通過對變更內容的檢驗，確定對現有的系統做出是修改或拋棄的決定，或者創建新系統以及評估每個任務的工作量。進行影響分析的能力依賴于跟蹤能力數據的質量和完整性。

　　4．跟蹤所有受需求變更影響的工作產品當進行某項需求變更時，參照需求跟蹤能力矩陣找到相關的其它需求、設計模板、源代碼和測試用例，這些相關部分可能也需要修改。這樣能減少因疏忽而不得不變更產品的機會，這種變更在變更需求的情況下是必須進行的。

　　5．建立需求基準版本和需求控制版本文檔確定一個需求基準，這是一致性需求在特定時刻的快照。之后的需求變更就遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。最好的辦法是使用合適的配置管理工具在版本控制下為需求文檔定位。

　　6．維護需求變更的歷史記錄記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負責更新和更新的新版本號等。版本控制工具能自動完成這些任務。版本控制是管理需求的一個必要方面。需求文檔的每一個版本必須被統一確定。組內每個成員必須能夠得到需求的當前版本，必須清楚地將變更寫成文檔，并及時通知到項目開發所涉及的人員。為了盡量減少困惑、沖突、誤傳，應僅允許指定的人來更新需求。這些策略適用于所有關鍵項目文檔。

　　7．跟蹤每項需求的狀態建立一個數據庫，其中每一條記錄保存一項功能需求。保存每項功能需求的重要屬性，它包括狀態（如已推薦的，已通過的，已實施的，或已驗證的），這樣在任何時候都能得到每個狀態類的需求數量。

　　8．衡量需求穩定性記錄基準需求的數量和每周或每月的變更（添加、修改、刪除）數量。過多的需求變更"是一個報警信號"，意味著問題并未真正弄清楚，項目范圍并未很好地確定下來或是政策變化較大。

　　9．使用需求管理工具商業化的需求管理工具能幫助你在數據庫中存儲不同類型的需求，為每項需求確定屬性，可跟蹤其狀態，并在需求與其它軟件開發工作產品間建立跟蹤能力聯系鏈。 

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