軟件需求規(guī)格說明書

1、軟件需求規(guī)格說明書模版文件變化記錄單版本編號*變化狀態(tài)簡要說明變更人變更日期批準人批準日期*變化狀態(tài)：A增加，M修改，D刪除文件批準單職務簽字日期1. 引言提出對軟件需求規(guī)格說明書的縱覽，幫助讀者理解文檔如何編寫并且如何閱讀和解釋。1.1 編寫目的 對產(chǎn)品（也可能是項目，但是我們統(tǒng)稱為產(chǎn)品）進行定義，在該文檔中詳盡說明這個產(chǎn)品的軟件需求，包括修正 或發(fā)行版本號。如果這個軟件需求規(guī)格說明書只與整個系統(tǒng)的一部分有關，那么只定義文檔中說明的部分或子系統(tǒng)。1.2 文檔約定描述編寫文檔時所采用的標準或排版約定，包括正文風格、提示區(qū)或重要符號。例如，說明高層需求的優(yōu)先級是 否可以被其所有細化的需求所繼承，

2、或者每個需求陳述是否都有優(yōu)先級。1.3 預期的讀者和閱讀建議 列舉軟件需求規(guī)格說明書所針對的不同讀者，例如開發(fā)人員、項目經(jīng)理、營銷人員、用戶、測試人員等。描述文 檔中剩余部分的內(nèi)容及其組織結構。提出最適合每一類型讀者閱讀文檔的建議。1.4 產(chǎn)品的范圍 提供對指定的軟件及其目的的簡短描述，包括利益和目標。把軟件與企業(yè)目標或業(yè)務策略相聯(lián)系?？梢詤⒖柬椖?范圍文檔，而不是將其內(nèi)容復制到這里。1.5 參考資料 列舉編寫軟件需求規(guī)格說明書時所參考的資料或其它來源?？赡馨ㄓ脩艚缑骘L格指導、合同、標準、系統(tǒng)需求 規(guī)格說明書、用戶需求、相關產(chǎn)品的軟件需求規(guī)格說明書。這里應該給出詳細的信息，包括標題名稱、作者

3、、版本號、 日期、出版單位或資料來源，以方便讀者查閱這些文獻。2. 綜合描述這一部分概述了正在定義的產(chǎn)品以及它所運行的環(huán)境、使用產(chǎn)品的用戶和已知的限制、假設和依賴。2.1 產(chǎn)品的前景 描述軟件需求規(guī)格說明書中所定義的產(chǎn)品的背景和起源。說明該產(chǎn)品是否是產(chǎn)品系列中的下一個成員，是否是成 熟產(chǎn)品所改進的下一代產(chǎn)品、是否是現(xiàn)有應用程序的替代品，或者是否是一個全新的產(chǎn)品。如果軟件需求規(guī)格說明書定義了大系統(tǒng)的一個組成部分，那么就要說明這部分軟件是怎樣與整個系統(tǒng)相關聯(lián)的， 并且要定義出兩者之間的接口。建議使用系統(tǒng)結構圖或者實體關系圖表示。2.2 產(chǎn)品的功能概述產(chǎn)品所具有的主要功能，詳細內(nèi)容在第 4 節(jié)描述，

4、所以這里只需要概括總結，例如用列表的方法給出。很好 地組織產(chǎn)品的功能，使每個讀者都易于理解。用圖形表示主要的需求分組以及它們之間的聯(lián)系。建議使用數(shù)據(jù)流程圖（ DFD ）的頂層圖或功能層次圖來實現(xiàn)圖形化。2.3 用戶類和特征確定可能使用該產(chǎn)品的不同用戶類并描述它們相關的特征。有一些需求可能只與特定的用戶類相關。將該產(chǎn)品的 重要用戶類與那些不太重要的用戶類區(qū)分開。2.4 運行環(huán)境描述軟件的運行環(huán)境，包括硬件平臺、操作系統(tǒng)和版本，還有其它的軟件組件或者與其共存的應用程序。2.5 設計和實現(xiàn)上的限制 確定影響開發(fā)人員自由選擇的問題，并說明這些問題為什么成為一種限制。可能的限制包括： 必須使用或者避免的

5、特定技術、工具、編程語言、數(shù)據(jù)庫； 經(jīng)費、進度、資源等方面的限制；所要求的開發(fā)規(guī)范或標準； 企業(yè)策略、政府法規(guī)或工業(yè)標準； 硬件限制，例如定時需求或存儲器限制； 數(shù)據(jù)轉換格式標準。其它。2.6 假設和依賴 列舉出在對軟件需求規(guī)格說明書影響需求陳述的假設因素。可能包括打算要用的商業(yè)組件或有關開發(fā)或運行環(huán)境 的問題。你可能認為產(chǎn)品將符合一個特殊的用戶界面設計約定，但是另外一個分析員卻不這么認為。如果這些假設不 正確、不一致或者被更改，都會使項目受到影響。此外，確定項目對外部因素存在的依賴。例如，如果你打算把其它項目開發(fā)的組件集成到系統(tǒng)中，那么你就要依 賴哪個項目能否按時提供正確的組件。如果這些依賴

6、已經(jīng)記錄到其它文檔（如項目計劃）中了，那么在此就可以參考 其它文檔。2.7 關鍵點說明本軟件需求規(guī)格說明書中的關鍵點（例如：關鍵功能、關鍵算法和所涉及的關鍵技術等）。3. 外部接口需求 確定可以保證新產(chǎn)品與外部組件正確連接的需求。關聯(lián)圖表示了高層抽象的外部接口。需要把對接口數(shù)據(jù)和控制 組件的詳細描述寫入數(shù)據(jù)字典中。如果產(chǎn)品的不同部分有不同的外部接口，那么應該把這些外部接口的詳細要求并入 到這一部分的實例中。3.1 用戶界面 陳述所需要的用戶界面的軟件組件。描述每個用戶界面的邏輯特征。以下是可能要包括的一些特征： 將要采用的圖形用戶界面標準或產(chǎn)品系列的風格；屏幕布局或解決方案的限制； 將出現(xiàn)在每

7、個屏幕的標準按鈕、功能或導航鏈接； 快捷鍵；錯誤信息顯示標準。對于用戶界面的細節(jié)，例如特定對話框的布局，建議寫入一個獨立的用戶界面規(guī)格說明中，不要寫入軟件需求規(guī) 格說明書中。3.2 硬件接口描述系統(tǒng)中軟件和硬件每個接口的特征?？赡馨ㄖС值挠布愋?、軟硬件之間交流的數(shù)據(jù)和控制信息的性質以 及所使用的通信協(xié)議。3.3 軟件接口描述產(chǎn)品與其它外部組件（由名字和版本識別）的連接，包括數(shù)據(jù)庫、操作系統(tǒng)、工具、庫和集成的商業(yè)組件。 明確并描述在軟件組件之間交換數(shù)據(jù)或信息的目的，描述所需要的服務以及內(nèi)部組件通信的性質，確定將在組件之間 共享的數(shù)據(jù)。如果必須用一種特殊的方法來實現(xiàn)數(shù)據(jù)共享機制，那么就必須把它

8、定義為一種實現(xiàn)上的限制。3.4 通信接口描述與產(chǎn)品所使用的通信功能相關的需求，包括電子郵件、WEB瀏覽器、網(wǎng)絡通信標準或協(xié)議及電子表格等，定義相關的信息格式、規(guī)定通信安全或加密問題、數(shù)據(jù)傳輸速率和同步通信機制。4. 功能需求4.1功能分類將功能性需求先粗分再細分，下表中的Feature A, Fu nction A.1等符號應當被替換成有含義的名稱。也可以用功能結構圖表示功能類別功能Feature AFunction A.1Function A.2Feature BFunction B.1Function B.24.2 系統(tǒng)特性Feature A4.2.1說明和優(yōu)先級提出對該系統(tǒng)特性的簡短說明

9、并指出該特性的優(yōu)先級是高、中還是低。4.2.2功能需求詳細列出與該特性相關的功能需求。這些是必須提交給用戶的軟件功能，使用戶可以使用所提供的特性執(zhí)行服務 或者使用所指定的用例執(zhí)行任務。描述產(chǎn)品如何響應可預知的出錯條件或非法輸入或動作。4.2.2.1功能 function A.1(1) 說明本功能的簡要說明(2) 角色本功能的執(zhí)行人員(3 )前置條件該功能啟動的前提條件(4) 輸入描述本功能的輸入信息(包括需要訪問的存儲信息)。(5) 過程對本功能將做什么進行詳細的描述。(6) 輸岀描述本功能的輸出信息(包括需要訪問的存儲信息)。(7 )后置條件該功能結束的退出條件(8 )業(yè)務規(guī)則列舉出與該功能

10、相關的操作規(guī)則。例如什么人在特定環(huán)境下可以進行何種操作。4.2.2.2 fun ctio n A.1 圖書借閱(1) 說明借閱人通過此功能向系統(tǒng)查詢并提交借書請求(2) 角色借閱人(3 )前置條件借閱人借閱證件在有效期內(nèi)借閱人沒有逾期未歸還的圖書(4)輸入借閱證(5)過程主過程描述1用戶用借閱證提供的帳號登錄系統(tǒng)，系統(tǒng)顯示我的圖書館界面2. 用戶選擇查詢圖書，系統(tǒng)顯示查詢界面3. 用戶按書名、作者、出版社查詢，系統(tǒng)顯示查詢結果4. 用戶可單選或多選書本，并確認借閱。系統(tǒng)顯示確認借閱圖書清單。5. 用戶選擇確認借閱，系統(tǒng)顯示借閱疋單及費用6用戶選擇提交定單，系統(tǒng)顯示提交結果和定單號7.系統(tǒng)執(zhí)行后

11、置條件分支過程描述系統(tǒng)執(zhí)行4； 系統(tǒng)顯示借書籃現(xiàn)有內(nèi)容 系統(tǒng)執(zhí)行2;系統(tǒng)執(zhí)行44.2.1用戶選擇放棄，系統(tǒng)執(zhí)行2; 系統(tǒng)保存并執(zhí)行1；系統(tǒng)執(zhí)行1；異常過程描述“歸還圖書”功能 系統(tǒng)顯示余額和所需金額“交納借閱費”功能系統(tǒng)執(zhí)行1(6)輸岀費用記錄借閱定單(7 )后置條件創(chuàng)建借書定單更新借閱人借閱記錄(8 )業(yè)務規(guī)則每次每人至少選擇一本，至多選擇三本4.3 系統(tǒng)特性Feature B5. 非功能需求5.1 性能需求95%闡述不同的應用領域對產(chǎn)品性能的需求，并解釋它們的原理以幫助開發(fā)人員做出合理的設計選擇。確定相互合作 的用戶數(shù)或者所支持的操作、響應時間以及與實時系統(tǒng)的時間關系；還要定義容量需求，例

12、如存儲器和磁盤空間的需 求或者存儲在數(shù)據(jù)庫中表的最大行數(shù)。也可能需要針對每個功能需求或特性分別陳述其性能需求，而不是把它們集中 在一起陳述。例如：“在運行 WINDOWS 10的3.5GHZ雙核芯片的計算機上，當系統(tǒng)至少有 50%的空閑資源時, 的目錄數(shù)據(jù)庫查詢必須在兩秒內(nèi)完成”。5.2 安全性需求陳述與系統(tǒng)安全性、完整性或私人問題相關的需求，這些問題將會影響到產(chǎn)品的使用和產(chǎn)品所創(chuàng)建或使用的數(shù)據(jù) 的保護。明確產(chǎn)品必須滿足的安全性或保密性策略。一個軟件系統(tǒng)的安全需求的范例如下：“每個用戶在第一次登錄 之后，必須更改他的最初登錄密碼。最初的登錄密碼不能重用?！?.3軟件質量屬性詳盡陳述與客戶或開發(fā)

13、人員至關重要的質量特性。這些特性必須是確定、定量的并可驗證的。至少應指明不同屬 性的相對側重點，例如易用程度優(yōu)于易學程度，或者可移植性優(yōu)于有效性。5.4 其它需求定義至今未出現(xiàn)的需求。例如國際化需求、法律上的需求、有關操作、管理、維護、安裝、配置、啟動、關閉、 修復、容錯、登錄、監(jiān)控等等方面的需求。說明本產(chǎn)品在可使用性、可維護性、可移植性、可靠性和安全性等方面的 要求。6. 數(shù)據(jù)字典6.1實體關系圖6.2實體定義指出數(shù)據(jù)項名、定義、項結構組成、項范圍、項類型。實體名稱Be_圖書實體描述每本圖書都經(jīng)有上架，預定，借出，返回待查和下架幾個狀態(tài)，詳細請參看圖書狀態(tài)圖屬性名稱類型精度說明（屬性的業(yè)務含

14、義及業(yè)務規(guī)則）圖書編號字符12圖書類別編號（3位）+圖書購入年份（4位）+流水號位圖書分類字符3圖書的分類名稱字符100書本的封面名稱作者字符20書籍的作者出版社字符100書籍標明的出版社出版日期日期書籍標明的出版日期版本信息字符100書籍標明的出版社簡介字符1000書籍的內(nèi)容簡介，上架時錄入狀態(tài)字符1書籍的狀態(tài)，請參看圖書狀態(tài)圖7. 業(yè)務規(guī)則與業(yè)務算法7.1 業(yè)務規(guī)則列舉出有關產(chǎn)品的所有操作規(guī)則。例如什么人在特定環(huán)境下可以進行何種操作。這些規(guī)則不是功能需求，但它們 可以暗示某些功能需求執(zhí)行這些規(guī)則。業(yè)務規(guī)則的范例如下：“只有持有管理員密碼的用戶才能執(zhí)行 100元以上的退款操作”。借出規(guī)則說明

15、：讀者已借書數(shù)未超過最大借書數(shù)、該書有庫存，而且該讀者擁有借閱該書的權限，則執(zhí)行該操 作。罰款規(guī)則說明：1. 超期罰款：超期天數(shù)*超期罰款率。2. 丟失罰款：圖書價格*丟失賠率7.2算法說明用于實施系統(tǒng)計算功能的公式和算法的描述，類似于業(yè)務規(guī)則。如某神州行套餐的計費標準說明。a. 每個主要算法的概況；b. 用于每個主要算法的詳細公式。附錄 A ：分析模型（也可以納入 4 功能需求章節(jié)中描述）包括或涉及到相關的分析模型的位置，例如數(shù)據(jù)流圖、類圖、狀態(tài)轉換圖等。頂層數(shù)據(jù)流圖：第 1 層數(shù)據(jù)流圖：第 2 層數(shù)據(jù)流圖：附錄 B ：待確定問題的列表編輯一張在軟件需求規(guī)格說明書中待確定問題的列表，其中每一

16、表項都是編上號的，以便跟蹤調查。附錄C:編寫文檔的原則編寫文檔時，要求具有本規(guī)范規(guī)定的所有條目如果某條目無內(nèi)容，則填寫 “無”，并在可能的情況下說明理由。必 要時，可增加適當?shù)臈l目。編寫優(yōu)秀的需求文檔沒有現(xiàn)成固定的方法，最好是根據(jù)經(jīng)驗進行。許多需求文檔可以通過使用有效的技術編寫風 格和使用用戶術語而不是技術術語的方式得以改進。你在編寫需求文檔時，應牢記以下幾點建議:? 保持語句和段落的簡短；? 采用主動語態(tài)的表達方式；? 語法正確，句子完整；? 使用的術語與詞匯表中所定義的術語一致；? 避免模糊的、主觀的術語如用戶友好、容易、簡單、迅速、有效、許多、最新技術、優(yōu)越的、可接受的、健 壯的等等；? 避免使用比較性的詞匯如提高、最大化、最小化、最佳化等。定量說明所需要提高的程度或者說清一些參數(shù) 可以接受的最大值和最小值。含糊的語句表達將引起需求的不可驗證。? 由于需求的編寫是層次化的，因此，可以把頂層不明確的需求向低層詳細分解，直到消除不明確性為止。編 寫詳細的需求文檔，所帶來的益處是如果需求得到滿足，那么客戶的目的也就達到了，但是不要讓過于詳細 的需求影響了設計。如果你能用不同的方法來滿足需求，并且這種方法是可接受的，那么需求的詳細程度也 就足夠了。然而，如果評審需求規(guī)格說明書的設計人員對客戶的意圖還不甚了解，那么就需要增