4 、是否每個需求都在項目的范圍內?
劃分項目范圍和區分系統邊界同樣是需求說明書的一個任務，不要對需求書作出超范圍的論述和延伸，要知道需求書不是分析師賣弄概念、展示時尚的場所，它是 軟件工程的一個重要環節。
5、 是否每個需求都沒有內容和語法上的錯誤?
按照傳統的需求列表方式，需求像菜單一樣被一條條列出來，構成需求項的主要欄位包括：需求ID、 需求描述、優先級、來源和狀態等。 通常需求首先要經過“拼寫檢查”，保證沒有拼寫上的問題，然后通過逐行瀏覽修改那些在內容或行文上出現問題的需求。
6 、在現有的 資源內, 是否能實現所有的需求?
需求規格說明要考慮可行性的問題。事實上，分析師的關注層面是價值驅動和成本驅動方面。分析師應該明白不是所有的需求都要去實現，一些看上去很明顯與涉及用戶有沖突的、費力不討好的需求應該果斷地舍棄。國內有專家提出，搞需求也要講“和諧”即是此中道理。
舉例而言，企業中的用戶可分為三種類型：決策層用戶、管理層用戶、操作層用戶。每種用戶所代表的價值取向是不同的，決策和管理層希望系統處理業務是業務安全優先的，而 操作系統用戶則是更多地考慮方便性的。國內某電子貿易公司，從自身業務安全考慮，規定了系統不允許“借貨”,意即代理商的產品直接發到客戶根本不經過本貿易公司的物流部門。如果操作層用戶提出了這樣的“借貨”需求,倒是可以方便他的日常處理,但卻違背了公司的根本利益。很顯然，這樣的需求肯定是有所不為的。
7、 每一條特定的錯誤信息，是否都是唯一的和具有含義的?
不要忽視錯誤信息的定義, 它必須具有唯一性。如果過于籠統地定義錯誤信息則和沒有定義的效果是一樣的。
二、 注意對需求規格說明的實踐性進行評審
所謂實踐性是指需求本身是否來源于目前企業的相關業務規則和文件制度,而非源于分析師們經驗主義的臆測。實踐性是判斷需求規格說明是不是理論聯系實踐、密切和用戶聯系的一個關鍵性指標。如果需求規格說明和用戶實踐脫離,即使看上去寫得再天花亂墜,也會使需求說明如同無根之樹、無源之水,會大大減低用戶對需求報告本身的信任度。
有經驗的 系統分析師通常會迷信自己的經驗,把從前的經驗嫁接到目前的企業需求分析中。也許由于行業性質相同,但如果不經過當前的實踐調研則給出需求，仍然會無法體現出企業自身的特征。因而不能為企業帶來真正的價值,也會造成與用戶需求的鴻溝。
筆者也曾經“輕實踐重抽象”，我認為系統分析師的工作特點是站在具體案例上的深度抽象，前提是必須獲得本企業的一手具體業務背景、流程和規則。
我們在分析比如“任務跟蹤”之類的系統時，由于系統的抽象模型是已知的(通過大量同類軟件的分析得知)，但還是需要分析師把抽象模型演繹到企業當前業務現狀。這樣的需求分析才會有“實話實說”之效,才能引發評審者的共鳴。否則，在需求評審中評審者是很難讀懂你的意圖，自然不會立即通過你的需求報告，導致需要重新返工撰寫需求報告。
這使我想到毛主席當年倡導“理論聯系實際”的深刻內涵。任何時刻,我們都要記住一個原則，即密切聯系用戶。誠然，需求分析需要方法也要理論支持,但最關鍵點仍然在于它本身是一種實踐,需求分析實踐直接來源于和用戶的直接 溝通和互動。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
