軟件需求說明作為產品需求的最終成果必須具有綜合性：必須包括所有的需求。開發者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未寫入軟件需求規格說明那么它將不能作為協議的一部分并且不能在產品中出現。
1. 完整性
每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。
2. 正確性
每一項需求都必須準確地陳述其要開發的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統需求規格說明。若軟件需求與對應的系統需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參與的需求評審將導致此類說法：“那些毫無意義，這些才很可能是他們所要想的�！逼鋵嵾@完全是評審者憑空猜測。
3. 可行性
每一項需求都必須是在已知系統和環境的權能和限制范圍內可以實施的。為避免不可行的需求，最好在獲�。� e l i c i t a t i o n）需求(收集需求)過程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一起工作，由他負責檢查技術可行性。
4. 必要性
每一項需求都應把客戶真正所需要的和最終系統所需遵從的標準記錄下來�！氨匾浴币部梢岳斫鉃槊宽椥枨蠖际怯脕硎跈嗄憔帉懳臋n的“根源”。要使每項需求都能回溯至某項客戶的輸入，如使用實例或別的來源。
5. 劃分優先級
給每項需求、特性或使用實例分配一個實施優先級以指明它在特定產品中所占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開發或節省預算或調度中就喪失控制
6. 無二義性
對所有需求說明的讀者都只能有一個明確統一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。避免二義性的有效方法包括對需求文檔的正規審查，編寫測試用例，開發原型以及設計特定的方案腳本。
7. 可驗證性
檢查一下每項需求是否能通過設計測試用例或其它的驗證方法，如用演示、檢測等來確定產品是否確實按需求實現了。如果需求不可驗證，則確定其實施是否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗證的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
