三、 注意對需求規格說明的完整性進行評審
我們經常由下面的問題清單來評審需求說明書是否”完整” 。
1、編寫的所有需求，其詳細程度是否一致和合適?
2、需求是否能為設計提供足夠的基礎?
3、所有對其他需求的內部引用是否正確?
4、是否包含了每個需求的實現優先級?
5、是否定義了功能說明的內在算法?
6、是否包含了所有已知的客戶需求或系統需求?
7、是否遺漏了必要的信息?如果有遺漏的話,把他們標記為待確定的問題(TBD) ?
8、是否對所有預期的錯誤條件所產生的系統行為都編制了文檔?
需求說明的完整性主要體現在需求說明的詳細程度上，我們怎樣判斷該需求的描述是否詳細呢?我認為需求需要精化，而不是僅僅提出精化功能、對象要考慮涉眾參與者、做些什么、需要什么數據信息、受什么業務規則和條件限制、系統會有什么響應，等等。
讓我們看一個功能需求例子,“FR1: 銷售出貨要考慮到信用額度”。
乍看顯得過于簡單和含糊,我們把它修改成”FR1: 1 銷售出貨的前提是該客戶擁有超過出貨價值的信用額度, 否則,系統提示‘該客戶信用額度不足,不予出貨!’ 2 正式出貨后系統將扣減其信用額度” 。
很顯然,修改后的需求把出貨和信用額度的來由去向和系統的具體反應都說明清楚了。
當然傳統的需求描述也能夠與用例中的參與者和系統響應等內容映射的。
四、 注意對需求方案的可行性和成本預算進行評審
需求方案的可行性和成本預算也是需求評審中的兩個重要方面。
需求方案的可行性和成本預算評審的目的，是從需求的多項方案中選擇最優化的或者是性價比最高的方案。一般而言,需求說明書可以給出同一個問題的幾種方案，并給出各自的優缺點和成本差異,經過比較由決策者作出最終選擇。
當我們理解了需求說明,我們下一步需要對其分析是否有可行性。
如果可行性高,則還要考慮它需要哪些 資源和預算。我們需要確定技術是否確實滿足業務需求,同時, 也要考慮整個產品成本,包括開發人員、服務器、許可和升級費用,還需要考慮初始硬件、軟件和支持、基礎結構和 培訓的費用。
五、 注意對需求的質量屬性進行評審
我們需要評審需求規格說明是否合理地確定了所有的性能目標，是否合理地確定了安全性方面要考慮到的問題。
系統性能需求之所以在概念階段即被要求,是因為現實的教訓。君不見很多功能已經完善的系統因為性能上不達標,而被用戶束之高閣——用戶通常難以忍受運行或響應速度過慢的系統。
系統的安全性也是一個很重要的指標,尤其是作為企業級的系統,它的安全考量完全繼承于組織對安全的基本訴求 。除了功能權限、字段級別權限外,數據間的授權關系也是必須考慮的,這本身也是一種業務規則。在”商機管理系統”需求分析中,“業務員A不能夠查看業務員B下達的訂單或相關信息”。所以,諸如此類的安全性需求在需求規格說明中是否被完整的描述，也是需求評審過程的一個硬性指標�？偟恼f來,安全性包含了身份驗證、訪問控制、加密和審核 等考慮事項。
六、 注意對需求的可實施性進行評審
是否對每個需求都設置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術，它可以在項目早期階段發現需求的歧義和錯誤。
正如Ross Collard所言：“用例和測試用例以兩種方式協同作, 如果系統用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
七、 注意對需求包含的用例文檔進行評審
用例是參與者對系統和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1、用例的目標或價值度量是否明確?
這一點是考察用例的編寫是從用戶角度還是從系統角度出發的。必須保證用例從用戶角度出發,用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的 溝通還沒能達成“契約”。
2、用例是否是獨立的分散任務?
3、是否明確說明可用用例會給哪些參與者帶來用處?
不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統和用例的主要價值態度及其約束條件。
4、編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
用例不應該有任何的設計細節,更不能出現UI設計。 我們要確保參與者是以黑盒子看系統的,這樣化繁為簡的思路,正是系統分析分層次目的所在。
5、所有預期的分支過程是否都編寫了文檔說明?
參與者的動作和系統的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
6、所有預估的異常過程是否都編寫了文檔說明?
參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
7、是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8、每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9、用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10、用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11、用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
八、 注意需求評審會的過程和結束 標準
通常，需求評審會都不是件容易的事情,業務審查人員分散在各個地域和時間上的不一致性是困難產生的所在。在很多情況下,我們可以使用 分布式需求評審軟件從網絡上對需求文檔進行預先評審,而在評審會中則要注意不要使評審會演變成了“業務會”或“技術研討會”。
同時,需求評審會的結果是對需求規格書完成了評審過程,那我們又如何判斷審查的結束標準呢?請看如下幾條建議:
1、審查期間評審員們提出的所有問題都已經解決。
2、相關文檔中的所有更改都已經正確完成。
3、修訂過的文檔進行了拼寫檢查。
4、所有標識為TBD(待確定)的問題已經全部解決, 或者已經對每個TBD的問題的解決過程、計劃解決的目標日期和責任解決人等編制了文檔。
5、需求文檔正式進入了配置庫。
本文闡述了需求評審和確認的一些”注意”事項，一旦完成需求評審將表示進入了需求設計階段，欲知需求設計如何實現，且聽下文為您分解。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
