【正文】 f. 缺省或失敗時的響應(yīng)。 編寫需求的人應(yīng)當(dāng)避免把設(shè)計或項目需求寫入 SRS之中，應(yīng)當(dāng)對說 明需求設(shè)計約束與規(guī)劃設(shè)計兩者有清晰的區(qū)別。表 1給出該大綱目錄，表 2至表 5給出大綱中第 3章的具體需求內(nèi)容。 a. 如果這個產(chǎn)品是獨立的 ，而且全部內(nèi)容自含，應(yīng)在此說明； b. 如果 SRS 定義的產(chǎn)品是一個較大的系統(tǒng)或項目中的一個組成部分，那么本條應(yīng)包括如下內(nèi)容： （ 1）要概述這個較大的系統(tǒng)或項目的每一個組成部分的功能，并說明其接口； （ 2）指出該軟件產(chǎn)品主要的外部接口。 這一條的內(nèi)容不能用來陳述具體需求或強加若干特殊的設(shè)計約束，本條應(yīng)對在 SRS的具體需求一章之中的某些具體需求或設(shè)計約束的描述提供理由。 b. 輸入 這部分應(yīng)包括： （ 1）詳細描述該功能的所有輸入數(shù)據(jù)，如： 輸入源、數(shù)量、度量單位、時間設(shè)定、有效輸入范圍（包括精度和公差）； （ 2）操作員控制細節(jié)的需求。這個領(lǐng)域的具體需求必須包括： a. 利用可靠的密碼技術(shù)； b. 掌握特定的記錄或歷史數(shù)據(jù)集； c. 給不同的模塊分配不同的功能； d. 限定一個程序中某些區(qū)域的通信； e. 計算臨界值的檢查和。 操作 這里說明用戶要求的常規(guī)的和特殊的操作。以便使 SRS易于使用。 a. 大綱 1（表 2）中首先說明全部功能需求，然后說明四種類型的接口要求，最后是其他需求； b. 大綱 2（表 3）中，把對應(yīng)每個特定功能的四種接口需求和該功能需求放在一起描述，然后說明其他需求； c. 大綱 3（表 4）中，與功能需求有關(guān)的全部內(nèi)容放在一起首先說明，然后是其他需求的描述。 通信接口 這里指定各種通信接口，例如，局部網(wǎng)絡(luò)的協(xié)議等等。 硬件的限制 本項包括在各種硬件約束下運行的軟件要求，例如，應(yīng)該包括： a. 硬件配置的特點（接口數(shù)，指令系統(tǒng)等）； b. 內(nèi)存 儲器和輔助存儲器的容量。 具體需求的內(nèi)容 功能需求 本條描述軟件產(chǎn)品的輸入怎樣變換成輸出。 許多人在軟件生存周期的操作和維護階段與系統(tǒng)相關(guān)。每一個文件、文獻要有標(biāo)題，索引號或文件號，發(fā)布或發(fā)表日期以及出版單位； c. 詳細說明可以得到該參考文件的來源。 項目要求表達客戶和開發(fā)者之間對于軟件生產(chǎn)方面合同性事宜的理解（因此不應(yīng)當(dāng)包括在 SRS中）例如： a. 成本； b. 交貨進度； c. 報表處理； d. 軟件開發(fā)方法； e. 質(zhì)量保證； f. 確認和驗證 的標(biāo)準(zhǔn)； g. 驗收過程。 a. 必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受； b. 期望是指這些需求將提高軟件產(chǎn)品的功能，但是如果缺省的話也是可接受的； c. 任選是給開發(fā)者一個機會，可以提供某些超出 SRS規(guī)定的目標(biāo)。對一些特殊的應(yīng)用還有一些特別有用的模型。數(shù)學(xué)模型對某些特殊應(yīng)用領(lǐng)域是特別有用的。關(guān)注輸入、輸出的系統(tǒng)主要是在當(dāng)前的輸入上操作，要求生成與輸入相匹配的輸出（類似于數(shù)據(jù)轉(zhuǎn)換例行程序或一個數(shù)學(xué)函數(shù)包）； c. 還有一些系統(tǒng)（如過程控制系統(tǒng)）要求記憶它們的狀態(tài)。比如，計算機的字處理器就是非常有用的生產(chǎn)輔助工具。局部的改變（修正） 可以借助于好的代碼注釋來實現(xiàn)。 （ 1）冗余本身不是錯誤，但是容易發(fā)生錯誤。 SRS 的環(huán)境 必須認識到 SRS在整個軟件開發(fā)規(guī)范（見 GB 8566）所規(guī)定的有關(guān)階段都起作用。因此 SRS是軟件產(chǎn)品繼續(xù)提高的基礎(chǔ)。本指南不提倡把軟件需求說明（ Software Requirements Specifications，以下簡稱 SRS）劃分成等級，避免把它定義成更小的需求子集。有了 SRS就便于移值軟件產(chǎn)品，以適應(yīng)新的用戶或新的機種。用戶和客戶通常不是同一些人。 可修改性 如果一個 SRS的結(jié)構(gòu)和風(fēng)格在需求有必要改變時是易于實現(xiàn)的、完 整性的、一致的，那么這個 SRS就是可以修改的。當(dāng)編碼和設(shè)計文件作修改時，重要的是要查清這些修改所影響的全部需求。盡管自然語言是豐富多彩的， 但不易精確，用形式化的方法較好。 途徑 根據(jù)被描述的軟件的性質(zhì)，至少有三種不同的途徑： a. 有些軟件產(chǎn)品（如報表系統(tǒng)）要求著重說明輸出。 至少可以提出三種可供使用的通用模型：數(shù)學(xué)型、功能型、計時型。尤其是實時系統(tǒng)或考慮人為因素的系統(tǒng)。 穩(wěn)定性 注釋需求的一種方法是使用穩(wěn)定性量綱。有兩種選擇： a. 不顧本指南的警告，在 SRS 中描述了設(shè)計。這些信息可以由 SRS的附錄提供。但要牢記，這樣的圖不是產(chǎn)品設(shè)計時所需求的，而只是一種有效的解釋性的工具。這是 SRS中篇幅最大和最重要的部分。 設(shè)計約束 設(shè)計約束受其他標(biāo)準(zhǔn)、硬件限制等方面的影響。 軟件接口 在這里應(yīng)指定需使用的其他軟件產(chǎn)品（例如，數(shù)據(jù)管理系統(tǒng)，操作系統(tǒng)，或者數(shù)學(xué)軟件包） ，以及同其他應(yīng)用系統(tǒng)之間的接口。例如：考慮一個大的交互記帳系統(tǒng)，在里層可以分為操作軟件（它支持近乎實時的事務(wù)處理）、支撐軟件（聯(lián)機功能、磁盤備份、裝入磁帶等等）以及診斷軟件（診斷硬件、通信等），外一層是應(yīng)收款帳以及應(yīng)付款帳等等； SRS的可讀性，而不是進行概要設(shè)計。附錄中可能包括： a. 輸入輸出格式樣本，成本分析研究的描述或用戶調(diào)查結(jié)果； b. 有助于理解 SRS的背景信息； c. 軟件所解決問題的描述； d. 用戶歷史、背景、經(jīng)歷和操作特點； e. 交叉訪問表。 注：這里的內(nèi)容有時是用戶接口的一部分。 可轉(zhuǎn)移 /轉(zhuǎn)換性 這里規(guī)定把軟件從一種環(huán)境移植到另一種環(huán)境所要求的用戶程序，用戶接口兼容方面的約束等等。 c. 加工 定義輸入數(shù)據(jù)、中間參數(shù)，以獲得預(yù)期輸出結(jié)果的全部操作。這些包括： a. 管理方針； b. 硬件的限制； c. 與其他應(yīng)用間的接口； d. 并行操作； e. 審查功能； f. 控制功能； g. 所需的高級語言； h. 通信協(xié)議； i. 應(yīng)用的臨界點； j. 安全和保密方面的考慮。 在本條的描述中，用一個方框圖來表達一個較大的系統(tǒng)或項目的主要組成部分、相互聯(lián)系和外部接口是非常有幫助的。 目的（ SRS的 ） 在這一條包括下列內(nèi)容： a. 描述實際 SRS的目的； b. 說明 SRS所預(yù)期的讀者。 SRS應(yīng)把注意力集中在要完成的服務(wù)目標(biāo)上。 一個模型用于解釋文件所寫的需求是有效的，但是對于實際軟件的實現(xiàn)可能并不是最適宜的?？捎脠D 1所示的有限狀態(tài)機形式的功能模型來描述。例如，假設(shè)一個系統(tǒng)中當(dāng)接收“ 0”時用“ 1”來回答。 此外，可以使用若干種形式化方法，以便允許自動處理 SRS內(nèi)容，只要作某些限制就可以做到； 用一些表格或圖示法來顯示需求。這是因為： a. 客戶通常對軟件設(shè)計和開發(fā)過程了解較少，而不能寫出可用的 SRS； b. 開發(fā)者通常對于客戶的問題和意圖了解較少，從而不可能寫出一個令人滿意的系統(tǒng)需求。 b. 向前追蹤（即是向由 SRS派生的所有文件追蹤）。 完整性 如果一個 SRS能滿足下列要求，則該