七.需求文件
需求研發(fā)的最終成果是：客戶和研發(fā)小組對將要研發(fā)的產(chǎn)品達成一致協(xié)議。協(xié)議綜合了業(yè)務需求、用戶需求和軟件功能需求。就像我們早先所看到的，項目視圖和范圍文件包含了業(yè)務需求，而使用實例文件則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文件，還要編寫產(chǎn)品的非功能需求文件，包括質(zhì)量屬性和外部接口需求。只有以結(jié)構化和可讀性方式編寫這些文件，并由項目的風險承擔者評審通過后，各方面人員才能確信他們所贊同的需求是可靠的。
你能使用以下三種方法編寫軟件需求規(guī)格說明：
用好的結(jié)構化和自然語言編寫文本型文件。
建立圖像化模型，這些模型能描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和他們之間的變化、數(shù)據(jù)關系、邏輯流或?qū)ο箢惡退麄兊年P系。
編寫形式化規(guī)格說明，這能通過使用數(shù)學上精確的形式化邏輯語言來定義需求。
由于形式化規(guī)格說明具有非常強的嚴密性和精確度，因此，所使用的形式化語言只有極少數(shù)軟件研發(fā)人員才熟悉，更不用說客戶了。雖然結(jié)構化的自然語言具有許多缺點，但在大多數(shù)軟件工程中，他仍是編寫需求文件最現(xiàn)實的方法。包含了功能和非功能需求的基于文本的軟件需求規(guī)格說明已為大多數(shù)項目所接受。圖像化分析模型通過提供另一種需求視圖，增強了軟件需求規(guī)格說明。
軟件需求規(guī)格說明不僅是系統(tǒng)測試和用戶文件的基礎，也是所有子系列項目規(guī)劃、設計和編碼的基礎。他應該盡可能完整地描述系統(tǒng)預期的外部行為和用戶可視化行為。除了設計和實現(xiàn)上的限制，軟件需求規(guī)格說明不應該包括設計、構造、測試或工程管理的細節(jié)。許多讀者使用軟件需求規(guī)格說明來達到不同的目的：
客戶和營銷部門依賴他來了解他們所能提供的產(chǎn)品。
項目經(jīng)理根據(jù)包含在軟件需求規(guī)格說明中描述的產(chǎn)品來制定規(guī)劃并預測進度安排、工作量和資源。
軟件研發(fā)小組依賴他來理解他們將要研發(fā)的產(chǎn)品。
測試小組使用軟件需求規(guī)格說明中對產(chǎn)品行為的描述制定測試計劃、測試用例和測試過程。
軟件維護和支持人員根據(jù)需求規(guī)格說明了解產(chǎn)品的某部分是做什么的。
產(chǎn)品發(fā)布組在需求規(guī)格說明和用戶界面設計的基礎上編寫客戶文件，如用戶手冊和幫助屏幕等。
培訓人員根據(jù)需求規(guī)格說明和用戶文件編寫培訓材料。
軟件需求規(guī)格說明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。研發(fā)者和客戶不能作所有假設。如果所有所期望的功能或非功能需求未寫入軟件需求規(guī)格說明，那么他將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。
我見過有一個項目忽然接到測試人員發(fā)出的錯誤災難的報告。結(jié)果是他們測試的是老版本的軟件需求規(guī)格說明，而他們覺得錯誤的地方正是產(chǎn)品所獨有的特性。他們的測試工作是徒勞的，因為他們一直在老版本的軟件需求規(guī)格說明中尋找錯誤的系統(tǒng)行為。
在編寫軟件需求規(guī)格說明，希望讀者牢記以下的建議：
對節(jié)、小節(jié)和單個需求的號碼編排必須一致。
在右邊部分留下文本注釋區(qū)。
允許不加限制地使用空格。
正確使用各種可視化強調(diào)標志(例如，黑體、下劃線、斜體和其他不同字體)。
創(chuàng)建目錄表和索引表有助于讀者尋找所需的信息。
對所有圖和表指定號碼和標識號，并且可按號碼進行查閱。
使用字處理程式中交叉引用的功能來查閱文件中其他項或位置，而不是通過頁碼或節(jié)號。
為了滿足軟件需求規(guī)格說明的可跟蹤性和可修改性的質(zhì)量標準，必須唯一確定每個軟件需求。這能使你在變更請求、修改歷史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。由于要達到這一目的，用單一的項目列表是不夠的，因此，我將描述幾個不同的需求