【正文】 、精度、頻率等等； c. 強加于實現(xiàn)的設計限制 —— 在效果、實現(xiàn)的語言、數據庫完整性、資源限制、操作環(huán)境等等方面所要求的標準； d. 屬性 —— 可移植性、正確性、可維護性及安全性等方面的考慮因素； e. 外部接口 —— 與人、硬件、其他軟件和其他硬件的相互關系。 注意事項 在注釋需求之前，必須徹底理解這種注釋的實質性含義。 必要性等級 注釋的另一種方法是把需求分成必須保證級、期望級和任選級。 穩(wěn)定性 注釋需求的一種方法是使用穩(wěn)定性量綱。 SRS中每一個需求必須進行注釋，以便區(qū)別其重要的程度。某些需求可能是基本的，例如是對于生命攸關的應用。 一個模型用于解釋文件所寫的需求是有效的，但是對于實際軟件的實現(xiàn)可能并不是最適宜的。 必須注意，在需求的定義域內要保持一個模型定義。 警告 無論使用哪一類型的模型，都要： 在 SRS中 或在 SRS涉及到的一個文件中對它嚴格定義。例如，編譯程序的說明可以使用屬性文法，工資單系統(tǒng)可以使用表格。 其他模型 隊了上面提及的模型外。尤其是實時系統(tǒng)或考慮人為因素的系統(tǒng)。 計時模型 計時模型是一種增加了時間限制的模型。雙線的方框表示接收狀態(tài)。可用圖 1所示的有限狀態(tài)機形式的功能模型來描述。象有限狀態(tài)機或 Petri網，這些功能模型可以有助于標識和定義軟件的各種特點，或者可以表示系統(tǒng)所要進行的操作。 這里，“ *”號表示括號內的字符串可以重復一次或多次。例如，導航、線性規(guī)劃、計量經濟、信號處理和氣象分析等。 數學模型 數學模型是使用數學關系描述軟件特性的模型。 至少可以提出三種可供使用的通用模型：數學型、功能型、計時型。 0101 010101010101 01 010101 這 些對話僅提供了要求的輸入和輸出之間的關系，但是不能完全描述系統(tǒng)的特性。然而，用典型的序列可以十分清楚地理解系統(tǒng)的特性。例如，假設一個系統(tǒng)中當接收“ 0”時用“ 1”來回答。然而，用這樣的途徑不可能完整地描述軟件所要求的一切特性。在此種情況下，既要關注輸入/輸出對，又要關注這些輸入 /輸出對的次序?？梢愿鶕敬屋斎牒蜕弦淮屋斎脒M行應答。用戶的輸入通常是致力于提供控制信息和啟動數據文卷的處理； b. 有些軟件產品需要著重說明輸入、輸出特性。 途徑 根據被描述的軟件的性質，至少有三種不同的途徑： a. 有些軟件產品（如報表系統(tǒng)）要求著重說明輸出。 表達軟件需求的方法 軟件需求可以用若干種方法來表達： a. 通過輸入、輸出說明； b. 使用代表性的例子； c. 用規(guī)范化的模型。 自動檢查 SRS具有在 。 此外，可以使用若干種形式化方法，以便允許自動處理 SRS內容，只要作某些限制就可以做到； 用一些表格或圖示法來顯示需求。比如： a. 可以驗證實體或活動，無論在 SRS中什么地方都是同一名字。故生產工具是必要的。一個 SRS通常有若干作者。 生產工具 軟件產品生產中有多種生產工具。盡管自然語言是豐富多彩的， 但不易精確，用形式化的方法較好。批準了的需求改變，用如下的方法編入 SRS之中： a. 提供各種改變后的正確的、完全的審查記錄； b. 允許對 SRS當前的和被替代部分的審查。 在 SRS的改進中，應注意如下事項： 盡管可以預見校正版本的開發(fā)以后不可避免，而對需求還必須盡可能完全、清楚 地描述。這是因為： a. 客戶通常對軟件設計和開發(fā)過程了解較少，而不能寫出可用的 SRS； b. 開發(fā)者通常對于客戶的問題和意圖了解較少，從而不可能寫出一個令人滿意的系統(tǒng)需求。 SRS 的編制者 軟件開發(fā)的過程是由開發(fā)者和客戶雙方同意開發(fā)什么樣的軟件協(xié)議開始的。例如： 它們的危急性（如故障可能危及完全或導致大量財政方面和社會方面的損失）； 它們僅與暫時的需要相關（如支持一種可立即恢復原狀的顯示）； 它們的來源（如某功能是由已存在的軟件產品的全部拷貝復制而成）。對于較大范圍的改變。 a. 維護常常是由與原來開發(fā)無聯(lián)系的人來進行的。當編碼和設計文件作修改時，重要的是要查清這些修改所影響的全部需求。在這種情況下，要指出軟件所支持的確切的法律或行政文件。 當 SRS中的一個需求表達另一個需求的一種指派或者是派生的，向前、向后的追蹤都要提供。 b. 向前追蹤（即是向由 SRS派生的所有文件追蹤）。建議采用如下兩種類型的追蹤： a. 向后追蹤（即向已開發(fā)過的前一階段追蹤）。 （ 2）不管冗余是否必須， SRS 一定要包含一個詳細的交叉引用表，以便 SRS 具備可修改性。冗余可增加 SRS的可讀性，但是在一個冗余文件被更新時容易出現(xiàn)問題。即同一需求不能在 SRS中出現(xiàn)多次。 可修改性 如果一個 SRS的結構和風格在需求有必要改變時是易于實現(xiàn)的、完 整性的、一致的，那么這個 SRS就是可以修改的。 可驗證性 當且僅當 SRS中描述的每一個需求都是可以驗證的，該 SRS才是可以驗證的；當且僅當在某一性能價格比可取的有限處理過程，人或機器能通過該過程檢查軟件產品能否滿足需求時，才稱這個需求是可以驗證的。 關于使用“待定”一詞的規(guī)定 任何一個使用“待定”的 SRS都是不完全的。 完整性 如果一個 SRS能滿足下列要求，則該 SRS就是完整的： a. 包括全部有意義的要求，無論是關系到功能的、性能的、設計約束的，還是關系到屬性或外部接口方面的需求； b. 對所有可能出現(xiàn)的輸入數據的響應予以定義 ，要對合法和非合法的輸入值的響應做出規(guī)定； c. 要符合 SRS要求。 需求通常是用自然語言編寫的，使用自然語言的 SRS起草者必須特別注意消除其需求的歧義性。 SRS 的特點 無歧義性 當且僅當它對每一個需求只有一種解釋時， SRS者是無歧義 的。正因為如此， SRS的起草者必須特別注意不要超出這種作用的范圍。 對 SRS的描述有兩項基本要求： a. 必須描述一定的功能、性能； b. 必須用確定的方法敘述這些功能、性能。用戶和客戶通常不是同一些人。在本指南中，客戶和開發(fā)者可能是同一個組織的成員。 分割（ partitioning） 把一個整體分成若干部分。文件中的客戶和開發(fā)者也可能是同一個組織的成員。其中包括產品的技術、組織、成本和進度計劃要求等內容。 2 引用標準 GB 8566 計算機軟件開發(fā)規(guī)范 GB 8567 計算機軟件產品開發(fā)文件編制指南 GB/T 11457 軟件工程術語 3 定義 GB/T 11457 所列術語和下列定義適用于本指南。雖然 SRS也可能要改變，但是原來的 SRS還是軟件產品改進的可靠基礎。由于 SRS所討論的是軟件產品，而不是開發(fā)這個產品的設計。有了 SRS就便于移值軟件產品，以適應新的用戶或新的機種。作為開發(fā)合同的一部分， SRS還可以提供一個可以度量和遵循的基準（然而，反之則不成立，即任一有關軟件的合同都不能作為 SRS。 SRS對軟件的清晰描述，有助于估計所必須的資源，并用作編制進度的依據； d. 為確認和驗證