【正文】 說，它的行為如同一個有限狀態(tài)機。 困難 多數(shù)軟件 產(chǎn)品可能接收無限的序列作為輸入，于是，為了通過輸入輸出序列完整地說明產(chǎn)品的特性，就要求 SRS包括一個無限長的輸入和所需的輸出充列。 典型例子 一種選擇是用典型例子來說明要求的特性。顯然，要列出全部輸入和輸出序列是不可能的。下面是一組四種對話的典型的例子，用它描述系統(tǒng)特性。 模型 另一種表達需求的方法是模型的方式，這是表達復雜需求的精確和有效方法。 應注意區(qū)別各種模型的應用場合，參考 。數(shù)學模型對某些特殊應用領域是特別有用的。 用數(shù)學模型能夠?qū)?： （ 01） *。 功能模型 功能模型是提供從略語以輸出映象的模型。 對前面用數(shù)學模型描述的例子。圖中進入的箭頭表示啟動狀態(tài)。在各線記號 x/y的含義是： x代表接受的輸入，而 y是產(chǎn)生的輸出。這種模型 對于表達軟件特性的形式和細節(jié)特別有用。 計時模型可以把下列限制加到圖 1的模型中去： a. 激活因素 0將在進入 S1狀態(tài) 30S之內(nèi)出現(xiàn)； b. 響應 1將在進入 S2狀態(tài) 2S之內(nèi)出現(xiàn)。對一些特殊的應用還有一些特別有用的模型。要注意的是，對 SRS使用形式需求語言，通常含有使用特殊模型的意思。這個定義應該規(guī)定： a. 模型中的參數(shù)所要求的范圍； b. 使用時的限定值； c. 結果的精確度； d. 負載的能力； e. 要求的執(zhí)行時間； f. 缺省或失敗時的響應。每當一個 SRS使用一個模型時： a. 它意味著此模型提供一個十分有效和精確的方法說明需求； b. 并不意味著軟件產(chǎn)品的實現(xiàn)必須基于這個模型。 軟件需求的注釋 有關軟件產(chǎn)品的所有需求，并不是同等重要的。而另一些可能并不那么重要。 有這種方法注釋需求，可以： a. 幫助客戶對每一個需求給予更周密的考慮，通?？梢栽谛枨笾谐吻咫[藏的假設； b. 幫助開發(fā)者做出正確的設計決定，并對軟件產(chǎn)品不同部分作出相應的努力。當一個需求在軟件預期的生存期間內(nèi)描述不改變的話，可以認為該需求是穩(wěn)定 的，否則可以認為是易變的。 a. 必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受； b. 期望是指這些需求將提高軟件產(chǎn)品的功能，但是如果缺省的話也是可接受的； c. 任選是給開發(fā)者一個機會，可以提供某些超出 SRS規(guī)定的目標。 在表達需求時遇到的共同弊病 SRS的基本點是它必須說明由軟件獲得的結果，而不是獲得這些結果 的手段。 編寫需求的人應當避免把設計或項目需求寫入 SRS之中，應當對說 明需求設計約束與規(guī)劃設計兩者有清晰的區(qū)別。 SRS 必須描述在干什么數(shù)據(jù)上、為誰完成什么功能、在什么地方、產(chǎn)生什么結果。通常不指定如下的設計項目： a. 把軟件劃分成若干模塊； b. 給每一個模塊分配功能； c. 描述模塊間的信息流程或者控制流程； d. 選擇數(shù)據(jù)結構。安全和保密方面的周密考慮可能增加一些直接反映設計約束的需求。 通常應考慮到，若要為軟件選擇高層次的設計，就可能需要大量的資源（可能占整個產(chǎn)品開發(fā)成本的 10%20%以上）。這意味著，或者將一個潛在不適當?shù)脑O計作為一個需求進行描述（因為，若要得到好的設計，所花費的時間是不夠的），或者在需求 階段花費了過多的時間（因為在 SRS完成之前整個設計分析都要完成）； b. 采用本指南中 ，用模型設計描述需求，這種模型設計只用于輔助描述需求，而不使之成為實際的設計。 項目要求表達客戶和開發(fā)者之間對于軟件生產(chǎn)方面合同性事宜的理解（因此不應當包括在 SRS中）例如： a. 成本； b. 交貨進度； c. 報表處理； d. 軟件開發(fā)方法； e. 質(zhì)量保證； f. 確認和驗證 的標準； g. 驗收過程。在 SRS中提供的只是關于軟件產(chǎn)品本身的需求。表 1給出該大綱目錄，表 2至表 5給出大綱中第 3章的具體需求內(nèi)容。 目錄 1 前言 目的 范圍 定義、縮寫詞、略語 參考資料 2 項目概述 產(chǎn)品描述 產(chǎn)品功能 用戶特點 一般約束 假設和依據(jù) 3 具體需求 （參閱本指南 條中具體需求的組織形式） 附錄 索引 前言（ SRS第 1章） 本章提供整個 SRS綜述。 范圍（ SRS的 ） a. 用一個名字標識被生產(chǎn)的軟件產(chǎn)品。應當： （ 1）盡可能精確地描述所有相關的利閃、目的、以及最終目標。 定義、縮寫詞、略語（ SRS的 ） 本條中必須提供全部需求的術語、縮寫詞及略語的定義，以便對 SRS進行適當?shù)慕忉?。也可以參考其他的文件。每一個文件、文獻要有標題，索引號或文件號，發(fā)布或發(fā)表日期以及出版單位； c. 詳細說明可以得到該參考文件的來源。 項目概述（ SRS第 2章） 本章應描述影響產(chǎn)品和其需求的一般因素，本章不說明具體的需求，而僅使需求更易于理解。 a. 如果這個產(chǎn)品是獨立的 ，而且全部內(nèi)容自含，應在此說明； b. 如果 SRS 定義的產(chǎn)品是一個較大的系統(tǒng)或項目中的一個組成部分，那么本條應包括如下內(nèi)容： （ 1）要概述這個較大的系統(tǒng)或項目的每一個組成部分的功能，并說明其接口； （ 2）指出該軟件產(chǎn)品主要的外部接口。這里僅僅是一個綜述性描述。 本條既不用來強迫進行設計方案 的描述，也不是描述在解決問題時的設計約束。 產(chǎn)品功能（ SRS的 ） 本條是為將要完成的軟件功能提供一個摘要。 有時，如果存在較高層次的規(guī)格說明時，則功能摘要可直接從中取得，這個較高層次的規(guī)格說明為軟件產(chǎn)品分配了特殊的功能，為了清晰起見，請注意： a. 編制功能的一種方法是制作功能表，以便客戶或者第一次 讀這個文件的人都可以理解； b. 用方框圖來表達不同的功能和它們的關系也是有幫助的。 這一條不用作陳述具體需求，只是對后來 SRS中具體需求一章中為什么要描述的某些需求提供理由。 許多人在軟件生存周期的操作和維護階段與系統(tǒng)相關。這些人的某些特點，象教育水平、經(jīng)驗、技術、專長等，都是施加于 系統(tǒng)操作環(huán)境的重要約束。 這一條的內(nèi)容不能用來陳述具體需求或強加若干特殊的設計約束，本條應對在 SRS的具體需求一章之中的某些具體需求或設計約束的描述提供理由。而這些項將限定開發(fā)者在設計系統(tǒng)時的任選項。 本條不陳述具體需求或具體設計約束：而對 SRS 的具體需求一章中為 什么要確定某些具體需求和設計約束提供理由。這些因素不是軟件的設計約束，但是它們的改變可能影響到 SRS中的需求。 具體需求（ SRS的第 3章） 本章應包括軟件開發(fā)者在建立設計時需要的全部細節(jié)。 a. 根據(jù)本指南第 4章所規(guī)定的準則（如可驗證性、無歧義性等），對每一個需求細節(jié)作具體描述； b. 在 SRS的前言、項目概述、附錄部分的有關討論中，要提供對任何一個具體需求交叉引用的背景； c. 具體需求分類的方法如下： （ 1）功能需求； （ 2）性能需求； （ 3）設計約束； （ 4）屬性； （ 5）外