在需求抽象時，相對于系統功能，你過多的注意用戶的業務，將導致在需求的全局觀和引進不是真正必需的需求上顯得不足。在需求抽象上，應用用例方法會發揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。
如果你知道已缺少一些信息，使用TBD（to be determined）標準標志可以突出這些缺陷，當你在構建產品的相關部分時，就可以從一個給定的需求集中解決所有的缺陷。
一致性：一致性需求就是不要于其他的軟件需求或高級別的系統（商業）需求發生沖突。需求中的不一致必須在開發開始前得到解決。只有經過調研才能確定哪些是正確的。修改需求時一定要謹慎，如果只審定修改的部分，沒有審定于修改相關的部分，就可能導致不一致性。
可修改性：當每個需求的要求修改了或維護其歷史更改時，你必須能夠審定SRS。也就是說每個需求必須相對于其他需求有其單獨的標示和分開的說明，便于清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關的需求分組，建立目錄表，索引，以及前后參考（照）。
可追蹤：你應能將一個軟件與其原始材料相對應，如高級系統需求，用例，用戶的提議等。也能夠將軟件需求與設計元素，源代碼，用于構造實現和驗證需求的測試相對應�？勺粉櫟男枨髴摼哂歇毩耸�，細密和結構化的編寫，不應過大，不應是敘述性的文字和公告式的列表。
需求質量的評審
這些有關需求質量的特性的描述在理論上都是非常好的，但一個好的需求到底是個什么樣子的呢？為了體現得更切合實際，我們做個小練習。下面有幾個從實際的工程選出的需求，依據上面的質量標準，評估每個需求，看看有什么問題，然后用更好的方式重寫。我將對每個例子都提出自己的分析和改進的建議。也歡迎你提出不同的見解。我所占優的只是我知道每個需求的出處。因為你我都不是真正的客戶，我們只能猜測每個需求的意圖。
例1．“產品應在不少于每60秒的正常周期內提供狀態信息”
這個需求是不完整的：狀態信息是什么，如何顯示給用戶。這個需求有幾處含糊。我們在談論產品的哪部分？狀態信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態信息也可以？也許它的意圖是消息間隔不應超過60秒，那么1毫秒是不是太短？“每”這個詞導致了不確定性。問題的后果，就是需求的不可證實。
彌補缺陷，重寫需求的一種方法：
1、狀態信息
1．1后臺任務管理器因該以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態信息
1．2如果后臺進程處理正常，那么應該顯示任務已完成的百分數/比
1．3任務完成時，應顯示相關的信息
1．4后臺任務出錯應該顯示錯誤信息
為了分別測試和追蹤，我將其分成了多個需求。如果將幾個需求串接在一節中，在構造和軟件測試時就很容易漏掉一個。
例2．“產品應瞬間在顯示和隱藏不可打印字符間切換”
計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性表現在沒有聲明觸發狀態切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個的文檔，或其他的？這也是個模糊的問題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問題的后果，就是需求的不可證實。
象這樣編寫需求也許更好一些：“用戶能夠在一個由特定觸發條件激活處于編輯的文檔中在顯示和隱藏所有HTML標記間切換”�，F在就很清楚，不可打印字符是HTML標記。由于沒有定義觸發條件，需求對設計沒有約束力。只有設計人員選定了觸發條件后，你才能編寫測試驗證觸發的正確操作。
例3．“HTML分析器可以產生HTML標記錯誤報告，幫助HTML入門者快速解決錯誤”。單詞“快速”使其模糊，沒 有加進錯誤報告的定義也是其部完整。我不知道，你怎么驗證這個需求。找一個自稱為HTML的入門者，看看能不能根據錯誤報告快速解決錯誤？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
