1. 怎樣的需求文檔才是算良好的
軟體需求規格說明作為產品需求的最終成果必須具有綜合性：必須包括所有的需求。開發者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未寫入軟體需求規格說明那麼它將不能作為協議的一部分並且不能在產品中出現。構造並編寫軟體需求規格說明，並使用戶和其它讀者能理解它牢記以下可讀性的建議：● 對節、小節和單個需求的號碼編排必須一致。● 在右邊部分留下文本注釋區。● 允許不加限制地使用空格。● 正確使用各種可視化強調標志(例如，黑體、下劃線、斜體和其它不同字體)。● 創建目錄表和索引表有助於讀者尋找所需的信息。● 對所有圖和表指定號碼和標識號，並且可按號碼進行查閱。● 使用字處理程序中交叉引用的功能來查閱文檔中其它項或位置，而不是通過頁碼或節號。優秀需求具有的特性怎樣才能把好的需求規格說明和有問題的需求規格說明區別開來?下面討論單個需求陳述說明的幾個特點( Davis 1993;IEEE 1998)。讓風險承擔者從不同角度對S R S需求說明進行認真評審，能很好地確定哪些需求確實是需要的。只要你在編寫、評審需求時把這些特點記在心中，就會寫出更好的(盡管並不十分完美)需求文檔，同時也會開發出更好的產品。1、需求說明的特徵1)完整性每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。2)正確性每一項需求都必須准確地陳述其要開發的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統需求規格說明。若軟體需求與對應的系統需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參與的需求評審將導致此類說法：「那些毫無意義，這些才很可能是他們所要想的。」其實這完全是評審者憑空猜測。3)可行性每一項需求都必須是在已知系統和環境的權能和限制范圍內可以實施的。為避免不可行的需求，最好在獲取( e l i c i t a t i o n)需求(收集需求)過程中始終有一位軟體工程小組的組員與需求分析人員或考慮市場的人員在一起工作，由他負責檢查技術可行性。4)必要性每一項需求都應把客戶真正所需要的和最終系統所需遵從的標准記錄下來。「必要性」也可以理解為每項需求都是用來授權你編寫文檔的「根源」。要使每項需求都能回溯至某項客戶的輸入，如使用實例或別的來源。