1、合格的軟件需求規格說明書軟件需求規格說明作為產品需求的最終成果必須具有綜合性：必須包括所有 的需求。開發者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未 寫入軟件需求規格說明那么它將不能作為協議的一部分并且不能在產品中出現。構造并編寫軟件需求規格說明，并使用戶和其它讀者能理解它牢記以下可讀 性的建議：-對節、小節和單個需求的號碼編排必須一致。-在右邊部分留下文本注釋區。-允許不加限制地使用空格。-正確使用各種可視化強調標志（例如，黑體、下劃線、斜體和其它不同字體）。 創建目錄表和索引表有助于讀者尋找所需的信息。-對所有圖和表指定號碼和標識號，并且可按號碼進行查閱。使用字處理程序中交叉

2、引用的功能來查閱文檔中其它項或位置，而不是通過頁 碼或節號。1.5優秀需求具有的特性怎樣才能把好的需求規格說明和有問題的需求規格說明區別開來？下面討 論單個需求陳述說明的幾個特點（Davis 1993； IEEE 1998）。讓風險承擔者從 不同角度對S R S需求說明進行認真評審，能很好地確定哪些需求確實是需要的。 只要你在編寫、評審需求時把這些特點記在心中，就會寫出更好的（盡管并不十 分完美）需求文檔，同時也會開發出更好的產品。1.5.1需求說明的特征完整性每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實 現這些功能所需的所有必要信息。正確性每一項需求都必須準確地陳述其要

3、開發的功能。做出正確判斷的參考是需求 的來源，如用戶或高層的系統需求規格說明。若軟件需求與對應的系統需求相抵 觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用 戶的積極參與的原因。沒有用戶參與的需求評審將導致此類說法：“那些毫無意 義，這些才很可能是他們所要想的。”其實這完全是評審者憑空猜測。可行性每一項需求都必須是在已知系統和環境的權能和限制范圍內可以實施的。為 避免不可行的需求，最好在獲取(e l i c i t a t i o n)需求(收集需求) 過程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一 起工作，由他負責檢查技術可行性。必要性每一項需求

4、都應把客戶真正所需要的和最終系統所需遵從的標準記錄下來。“必要性”也可以理解為每項需求都是用來授權你編寫文檔的“根源”。要使每 項需求都能回溯至某項客戶的輸入，如使用實例或別的來源。劃分優先級給每項需求、特性或使用實例分配一個實施優先級以指明它在特定產品中所 占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開發或節省預 算或調度中就喪失控制無二義性對所有需求說明的讀者都只能有一個明確統一的解釋，由于自然語言極易導 致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。避免二義 性的有效方法包括對需求文檔的正規審查，編寫測試用例，開發原型以及設計特 定的方案腳本。可驗證性檢查一

5、下每項需求是否能通過設計測試用例或其它的驗證方法，如用演示、 檢測等來確定產品是否確實按需求實現了。如果需求不可驗證，則確定其實施是 否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的 需求也是不可驗證的。1.5.2需求規格說明的特點完整性不能遺漏任何必要的需求信息。遺漏需求將很難查出。注重用戶的任務而不 是系統的功能將有助于你避免不完整性。如果知道缺少某項信息，用TBD ( “待 確定”）作為標準標識來標明這項缺漏。在開始開發之前，必須解決需求中所有 的T B D項。一致性一致性是指與其它軟件需求或高層（系統，業務）需求不相矛盾。在開發前 必須解決所有需求間的不一致部分。只有進行一番調查研究，才能知道某一項需 求是否確實正確。可修改性在必要時或為維護每一需求變更歷史記錄時，應該修訂S R S。這就要求每 項需求要獨立標出，并與別的需求區別開來，從而無二義性。每項需求只應在S RS中出現一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互 參照列表方法將使軟件需求規格說明更容易修改。可跟蹤性應能在每項軟件需求與它的根源和設計元素、