【文章內(nèi)容簡介】 內(nèi)出現(xiàn)。 其他模型 隊了上面提及的模型外。對一些特殊的應用還有一些特別有用的模型。例如，編譯程序的說明可以使用屬性文法，工資單系統(tǒng)可以使用表格。要注意的是，對 SRS使用形式需求語言，通常含有使用特殊模型的意思。 警告 無論使用哪一類型的模型，都要： 在 SRS中 或在 SRS涉及到的一個文件中對它嚴格定義。這個定義應該規(guī)定： a. 模型中的參數(shù)所要求的范圍； b. 使用時的限定值； c. 結(jié)果的精確度； d. 負載的能力； e. 要求的執(zhí)行時間； f. 缺省或失敗時的響應。 必須注意，在需求的定義域內(nèi)要保持一個模型定義。每當一個 SRS使用一個模型時： a. 它意味著此模型提供一個十分有效和精確的方法說明需求； b. 并不意味著軟件產(chǎn)品的實現(xiàn)必須基于這個模型。 一個模型用于解釋文件所寫的需求是有效的，但是對于實際軟件的實現(xiàn)可能并不是最適宜的。 軟件需求的注釋 有關(guān)軟件產(chǎn)品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是對于生命攸關(guān)的應用。而另一些可能并不那么重要。 SRS中每一個需求必須進行注釋，以便區(qū)別其重要的程度。 有這種方法注釋需求，可以： a. 幫助客戶對每一個需求給予更周密的考慮，通?？梢栽谛枨笾谐吻咫[藏的假設； b. 幫助開發(fā)者做出正確的設計決定，并對軟件產(chǎn)品不同部分作出相應的努力。 穩(wěn)定性 注釋需求的一種方法是使用穩(wěn)定性量綱。當一個需求在軟件預期的生存期間內(nèi)描述不改變的話，可以認為該需求是穩(wěn)定 的，否則可以認為是易變的。 必要性等級 注釋的另一種方法是把需求分成必須保證級、期望級和任選級。 a. 必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受； b. 期望是指這些需求將提高軟件產(chǎn)品的功能，但是如果缺省的話也是可接受的； c. 任選是給開發(fā)者一個機會，可以提供某些超出 SRS規(guī)定的目標。 注意事項 在注釋需求之前，必須徹底理解這種注釋的實質(zhì)性含義。 在表達需求時遇到的共同弊病 SRS的基本點是它必須說明由軟件獲得的結(jié)果，而不是獲得這些結(jié)果 的手段。 編寫需求的人必須描述的基本問題是： a. 功能 —— 所設計的軟件要做什么； b. 性能 —— 是指軟件功能在執(zhí)行過程中的速度、可使用性、響應時間、各種軟件功能的恢復時間、吞吐能力、精度、頻率等等； c. 強加于實現(xiàn)的設計限制 —— 在效果、實現(xiàn)的語言、數(shù)據(jù)庫完整性、資源限制、操作環(huán)境等等方面所要求的標準； d. 屬性 —— 可移植性、正確性、可維護性及安全性等方面的考慮因素； e. 外部接口 —— 與人、硬件、其他軟件和其他硬件的相互關(guān)系。 編寫需求的人應當避免把設計或項目需求寫入 SRS之中，應當對說 明需求設計約束與規(guī)劃設計兩者有清晰的區(qū)別。 在 SRS中嵌入了設計 在 SRS中嵌入設計說明，會過多地約束軟件設計，并且人為地把具有潛在危險的需求放入 SRS中。 SRS 必須描述在干什么數(shù)據(jù)上、為誰完成什么功能、在什么地方、產(chǎn)生什么結(jié)果。 SRS應把注意力集中在要完成的服務目標上。通常不指定如下的設計項目： a. 把軟件劃分成若干模塊； b. 給每一個模塊分配功能； c. 描述模塊間的信息流程或者控制流程； d. 選擇數(shù)據(jù)結(jié)構(gòu)。 把設計完全同 SRS隔離開來 始終是不現(xiàn)實的。安全和保密方面的周密考慮可能增加一些直接反映設計約束的需求。例如： a. 在一些分散的模塊中保持某些功能； b. 允許在程序的某些區(qū)域之間進行有限的通訊； c. 計算臨界值的檢查和。 通常應考慮到，若要為軟件選擇高層次的設計，就可能需要大量的資源（可能占整個產(chǎn)品開發(fā)成本的 10%20%以上）。有兩種選擇： a. 不顧本指南的警告，在 SRS 中描述了設計。這意味著，或者將一個潛在不適當?shù)脑O計作為一個需求進行描述（因為，若要得到好的設計，所花費的時間是不夠的），或者在需求 階段花費了過多的時間（因為在 SRS完成之前整個設計分析都要完成）； b. 采用本指南中 ，用模型設計描述需求，這種模型設計只用于輔助描述需求，而不使之成為實際的設計。 在 SRS中嵌入了一些項目要求 SRS應當是描寫一個軟件產(chǎn)品，而不是描述生產(chǎn)軟件產(chǎn)品的過程。 項目要求表達客戶和開發(fā)者之間對于軟件生產(chǎn)方面合同性事宜的理解（因此不應當包括在 SRS中）例如： a. 成本； b. 交貨進度； c. 報表處理； d. 軟件開發(fā)方法； e. 質(zhì)量保證； f. 確認和驗證 的標準； g. 驗收過程。 項目需求在另外的文件中描述。在 SRS中提供的只是關(guān)于軟件產(chǎn)品本身的需求。 6 SRS 大綱 本章著重討論 SRS的每一個基本部分，可以作為一個 SRS的大綱。表 1給出該大綱目錄，表 2至表 5給出大綱中第 3章的具體需求內(nèi)容。各開發(fā)者和客戶應當根據(jù)所描述的實際情況，按本指南有關(guān)規(guī)定編寫自己的 SRS。 目錄 1 前言 目的 范圍 定義、縮寫詞、略語 參考資料 2 項目概述 產(chǎn)品描述 產(chǎn)品功能 用戶特點 一般約束 假設和依據(jù) 3 具體需求 （參閱本指南 條中具體需求的組織形式） 附錄 索引 前言（ SRS第 1章） 本章提供整個 SRS綜述。 目的（ SRS的 ） 在這一條包括下列內(nèi)容： a. 描述實際 SRS的目的； b. 說明 SRS所預期的讀者。 范圍（ SRS的 ） a. 用一個名字標識被生產(chǎn)的軟件產(chǎn)品。比如：數(shù)據(jù)庫系統(tǒng)，報表生成程序等等； b. 說明軟件產(chǎn)品將干什么，如果需要的話，還要說明軟件產(chǎn)品不干什么； c. 描述所說明的軟件的應用。應當： （ 1）盡可能精確地描述所有相關(guān)的利閃、目的、以及最終目標。 （ 2）如果有一個較高層次的說明存在，則應該使其和高層次說明中的類似的陳述相一致（例如，系統(tǒng)的需求規(guī)格說明）。 定義、縮寫詞、略語（ SRS的 ） 本條中必須提供全部需求的術(shù)語、縮寫詞及略語的定義，以便對 SRS進行適當?shù)慕忉?。這些信息可以由 SRS的附錄提供。也可以參考其他的文件。 參考資料（ SRS的 ） 本條應包括： a. 在 SRS中各處參照的文件的全部清單，如經(jīng) 核準的計劃任務書，上級機關(guān)批文、合同等； b. 列出其他參考資料，如屬本項目的其他已發(fā)表的文件和主要文獻等。每一個文件、文獻要有標題，索引號或文件號，發(fā)布或發(fā)表日期以及出版單位； c. 詳細說明可以得到該參考文件的來源。這個信息可以通過引用附錄或其他文件提供。 項目概述（ SRS第 2章） 本章應描述影響產(chǎn)品和其需求的一般因素，本章不說明具體的需求，而僅使需求更易于理解。 產(chǎn)品描述（ SRS的 ） 這一條是把一個產(chǎn)品用其他有關(guān)的產(chǎn)品或項目來描述。 a. 如果這個產(chǎn)品是獨立的 ，而且全部內(nèi)容自含，應在此說明； b. 如果 SRS 定義的產(chǎn)品是