【正文】 能的界線是處理范圍設定和客戶期望的一個途徑。達到這一目的的一個途徑是考慮軟件項目的五個方面：性能、質(zhì)量、計劃、成 本和人員。根據(jù)這些差異，你可以把這些不同的用戶分成小組。詳細描述出它們的個性特點及任務狀況，將有助于產(chǎn)品設計。他們必須一直參與項目的開發(fā)而且有權作出決策。與產(chǎn)品代表的區(qū)別在于，核心隊伍成員通常沒有決定權。因此，一個使用實例是相關的用法說明的集合，并且一個說明是使用實例的例子。 使用實例的描述 并不向開發(fā)者提供他們所要開發(fā)的功能的細節(jié)。比起使用以功能為中心的方法，使用實例方法可以使用戶更清楚地認識到新系統(tǒng)允許他們做什么。 7）召開應用程序開發(fā)聯(lián)系會議：召開應用程序開發(fā)聯(lián)系會議應用程序開發(fā)聯(lián)系會議是范圍廣的、簡便的專題討論會，也是分析人員與客戶代表之間一種很好的合作辦法，并能由此擬出需求文檔的底稿。編制業(yè)務過程流程文檔將有助于明確產(chǎn)品的使用實例和功能需求。聽取那些描述合理特性的意見：快捷、簡易、直覺性、用戶友好、健壯性、可靠性、安全性和高效性。 2． 需求分析 1）繪制關聯(lián)圖：繪制系統(tǒng)關聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。注意要找出需求文檔與原型之間所有的沖突之處。當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。 6）編寫數(shù)據(jù)字典：創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng) 一的數(shù)據(jù)定義。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。軟件需求規(guī)格說明闡述一個軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件 ,它不僅是系統(tǒng)測試和用戶文檔的基礎，也是所有子系列項目規(guī)劃、設計和編碼的基礎。該模板為記錄功能需求和各種其它與需求相關的重要信息提供了統(tǒng)一的結(jié)構(gòu)。 1 2 3 4 5 6 A 引言 目的 文檔約定 預期的讀者和閱讀建議 產(chǎn)品的范圍 參考文獻 B 綜合描述 產(chǎn)品的前景 產(chǎn)品的功能 用戶類和特征 運行環(huán)境 設計和實現(xiàn)上的限制 假設和依賴附錄 C 外部接口需求附錄 用戶界面附錄 硬件接口 軟件接口 通信接口 D 系統(tǒng)特性 說明和優(yōu)先級 激勵 /響應序列 功能需求 E 其它非功能需求 性能需求 安全設施需求 安全性需求 軟件質(zhì)量屬性 業(yè)務規(guī)則 用戶文檔 F 其它需求 G 附件 詞匯表 分析模型 待確定問題的列表 表 2 需求規(guī)格說明模板 a. 引言 引言提出了對軟件需求 規(guī)格說明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。 預期的讀者和閱讀建議 列舉了軟件需求規(guī)格說明所針對的不同讀者，例如開發(fā)人員、項目經(jīng)理、營銷人員、用戶、測試人員或文檔的 編寫人員。把軟件與企業(yè)目標或業(yè)務策略相聯(lián)系。 b. 綜合描述 這一部分概述了正在定義的 產(chǎn)品以及它所運行的環(huán)境、使用產(chǎn)品的用戶和已知的限制、假設和依賴。其詳細內(nèi)容將在 d 中描述，所以在此只需要概略地總結(jié)。 運行環(huán)境 描述了軟件的運行環(huán)境，包括硬件平臺、操作系統(tǒng)和版本，還有其它的軟件組件或與其共存的應用程序。你可能認為產(chǎn)品將符合一個特殊的用戶界面設計約 定，但是另一個 S R S 讀者卻可能不這樣認為。如果這些依賴已經(jīng)記錄到其它文檔 (例如項目計劃 )中了，那么在此就可以參考其它文檔。如果產(chǎn)品的不同部 分有不同的外部接口，那么應把這些外部接口的詳細需求并入到這一部分的實例中。 硬件接口 描述系統(tǒng)中軟件和硬件每一接口的特征。描述所需要的服務以及內(nèi)部組件通信的性質(zhì)。規(guī)定通信安全或加密問題、數(shù)據(jù)傳輸速率和同步通信機制。這些序列將與使用實例相關的對話元素相對應。就像本章 開頭所描述的那樣，你必須唯一地標識每個需求。你還可以在這里定義容量需求，例如存儲器和磁盤空間的需求或者存儲在數(shù)據(jù)庫中表的最大行數(shù)。定義必須采取的安全保護或動作，還有那些預防的潛在的危險動作。明確產(chǎn)品必須滿足的安全性或保密性策略。 業(yè)務規(guī)則 列舉出有關產(chǎn)品的所有操作規(guī)則，例如什么人在特定環(huán)境下可以進行何種操作。 f. 其它需求 定義在軟件需求規(guī)格說明的其它部分未出現(xiàn)的需求，例如國際化需求或法律上的需求。 附錄 B ：分析模型 這個可選部分包括或涉及到相關的分析 模型的位置，例如數(shù)據(jù)流程圖、類圖、狀態(tài)轉(zhuǎn)換圖或?qū)嶓w 關系圖。為每項需求注上標號制定一種慣例來為需求規(guī)格說明書中的每項需求提供一個獨立的可識別的標號或記號。層次化編碼 。某些業(yè)務規(guī)范將引 出相應的功能需求；當然這些需求也應能追溯相應業(yè)務規(guī)范。 這里我們還要介紹需求規(guī)格說明書中設計階段，用到的圖形模型 數(shù)據(jù)字典、數(shù)據(jù)流圖、數(shù)據(jù)流圖、狀態(tài)轉(zhuǎn)換圖、對話圖和類圖。 數(shù)據(jù)流圖：是結(jié)構(gòu)化系統(tǒng)分析的基本工具。分析實體聯(lián)系圖有助于對業(yè)務或系統(tǒng)數(shù)據(jù)組成的理解和交互，并暗示產(chǎn)品將有必要包含一個數(shù)據(jù)庫。這樣的系統(tǒng)是有限狀態(tài)機的例子。在激活的輸入?yún)^(qū)中，用戶根據(jù)他所采取的活動，可以導航到有限個其它對話元素。類圖是用圖形方式敘述面向?qū)ο蠓治鏊_定的類以及它們之間的關系 4. 需求驗證 1）審查需求文檔：對需求文檔進行正式審查是保證軟件質(zhì)量的很有效的方法?？蛻敉ㄟ^使用測試用例以確認是否達到了期望的要求。優(yōu)秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能。 二、需求管理 需求開發(fā)的結(jié)果應該有項目視圖和范圍文檔、使用實例文檔、軟件需求規(guī)格說明 及相關分析模型。 1．確定需求變更 控制過程，確定一個選擇、分析和決策需求變更的過程。明確與變更相關的任務并評估完成這些任務需要的工作量。進行影響分析的能力依賴于跟蹤能力數(shù)據(jù)的質(zhì)量和完整性。之后的需求變更就遵循變更控制過程即可。版本控制工具能自動完成這些任務。為了盡量減少困惑、沖突、誤傳，應僅允許指定的人來更新需求。 8．衡量需求穩(wěn)定性記錄基準需求的數(shù)量和每周或每月的變更（添加、修改、刪除）