【正文】 　　9）確定質量屬性：確定質量屬性和其它非功能需求在功能需求之外再考慮一下非功能的質量特點，這會使你的產品達到并超過客戶的期望。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。許多組織一開始都采用IEEE標準8301998(IEEE 1998)描述的需求規(guī)格說明書模板。說明了該產品是否是產品系列中的下一成員，是否是成熟產品所改進的下一代產品、是否是現(xiàn)有應用程序的替代品，或者是否是一個新型的、自含型產品。關聯(lián)圖表示了高層抽象的外部接?；蛘吣氵€可以包括對特定優(yōu)先級部分的評價，例如利益、損失、費用和風險，其相對優(yōu)先等級可以從1（低）到9 （高）。 安全性需求　　詳盡陳述與系統(tǒng)安全性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產品所創(chuàng)建或使用的數(shù)據(jù)的保護?！　?）指明需求來源：指明需求的來源為了讓所有項目風險承擔者明白需求規(guī)格說明書中為何提供這些功能需求，要都能追溯每項需求的來源，這可能是一種使用實例或其它客戶要求，也可能是某項更高層系統(tǒng)需求、業(yè)務規(guī)范、政府法規(guī)、標準或別的外部來源。數(shù)據(jù)字典的維護獨立于軟件需求規(guī)格說明，并且在產品的開發(fā)和維護的任何階段，各個風險承擔者都可以訪問數(shù)據(jù)字典。對話圖描繪了系統(tǒng)中的對話元素和它們之間的導航連接，但它沒有揭示具體的屏幕設計。經評審批準，這些文檔就定義了開發(fā)工作的需求基線。每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。過多的需求變更是一個報警信號，意味著問題并未真正弄清楚，項目范圍并未很好地確定下來或是政策變化較大。 　　4．跟蹤所有受需求變更影響的工作產品當進行某項需求變更時，參照需求跟蹤能力矩陣找到相關的其它需求、設計模板、源代碼和測試用例，這些相關部分可能也需要修改。而輔助需求如質量屬性、性能需求及對用戶不可見的功能則在需求規(guī)格說明書中予以說明?！　υ拡D：在許多應用程序中，用戶界面可以看作是一個有限狀態(tài)機。這樣的需求跟蹤能力矩陣同時也把功能需求和高層的需求及其它相關需求聯(lián)系起來了。 　 附錄A ：詞匯表　　定義所有必要的術語，以便讀者可以正確地解釋軟件需求規(guī)格說明，包括詞頭和縮寫?？赡苄枰槍γ總€功能需求或特性分別陳述其性能需求，而不是把它們都集中在一起陳述。 通信接口　　描述與產品所使用的通信功能相關的需求，包括電子郵件、We b 瀏覽器、網(wǎng)絡通信標準或協(xié)議及電子表格等等?！　〈送猓_定項目對外部因素存在的依賴。 參考文獻　　　列舉了編寫軟件需求規(guī)格說明時所參考的資料或其它資源。除了設計和實現(xiàn)上的限制，軟件需求規(guī)格說明不應該包括設計、構造、測試或工程管理的細節(jié)。 　　4）確定需求優(yōu)先級：確定需求的優(yōu)先級別應用分析方法來確定使用實例、產品特性或單項需求實現(xiàn)的優(yōu)先級別?！　?）分析用戶工作流程：分析用戶工作流程觀察用戶執(zhí)行業(yè)務任務的過程。在編寫使用實例的文檔時可采用標準模版，在使用實例基礎上可得到功能需求。不僅要包括組織直接控制的范圍內的事務，還要包括外部因素。項目視圖陳述將考慮權衡有不同需求客戶的看法。對重要的步驟要給予一定指導，這將有助于分析人員的工作，而且也使收集需求活動的安排和進度計劃更容易進行?！　?2）編寫項目視圖和范圍文檔：項目視圖和范圍文檔應該包括高層的產品業(yè)務目標，所有的使用實例和功能需求都必須遵從能達到的業(yè)務需求。它可能有點理想化，但必須以現(xiàn)有的或所期待的客戶市場、企業(yè)框架、組織的戰(zhàn)略方向和資源局限性為基礎。如果可能，可建立測量的標準用于評價是否達到業(yè)務目標.　　 3）用戶群分類：產品的用戶在很多方面存在著差異，例如：用戶使用產品的頻度、他們的應用領域和計算機系統(tǒng)知識、他們所使用的產品特性、他們所進行的業(yè)務過程、他們在地理上的布局以及他們的訪問優(yōu)先級。 　　一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。畫一張簡單的示意圖（最好用數(shù)據(jù)流圖）來描繪出用戶什么時候獲得什么數(shù)據(jù)，并怎樣使用這些數(shù)據(jù)。以優(yōu)先級為基礎確定產品版本將包括哪些特性或哪類需求?！　?）采用軟件需求規(guī)格說明模版: 采用需求規(guī)格說明書模板在你的組織中要為編寫軟件需求文檔定義一種標準模板。這可能包括用戶界面風格指導、合同、標準、系統(tǒng)需求規(guī)格說明、使用實例文檔，或相關產品的軟件需求規(guī)格說明。例如，如果你打算把其它項目開發(fā)的組件集成到系統(tǒng)中，那么你就要依賴那個項目按時提供正確的操作組件。定義了相關的消息格式。 安全設施需求　　詳盡陳述與產品使用過程中可能發(fā)生的損失、破壞或危害相關的需求。你可能希望為整個公司創(chuàng)建一張跨越多項項目的詞匯表，并且只包括特定于單一項目的軟件需求規(guī)格說明中的術語。在開發(fā)過程中建立這個矩陣，而不要等到最后才去補建。在任何情況下僅有一個對話元素（例如一個菜單，工作區(qū)，行提示符或對話框）對用戶輸入是可用的。 　　4）確定合格的標準：確定合格的標準讓用戶描述什么樣的產品才算滿足他們的要求和適合他們使用的。這樣能減少因疏忽而不得不變更產品的機會，這種變更在變更需求的情況下是必須進行的。　　9．使用需求管理工具商業(yè)化的需求管理工具能幫助你在數(shù)據(jù)庫中存儲不同類型的需求，為每項需求確定屬性，可跟蹤其狀態(tài)，并在需求與其它軟件開發(fā)工作產品間建立跟蹤能力聯(lián)系鏈。之后的需求變更就遵循變更控制過程即可。二、需求管理　　需求開發(fā)的結果應該有項目視圖和范圍文檔