7、 是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9 、用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10 、用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11、用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
八、 注意需求評審會的過程和結束 標準
通常，需求評審會都不是件容易的事情,業務審查人員分散在各個地域和時間上的不一致性是困難產生的所在。在很多情況下,我們可以使用 分布式需求評審軟件從網絡上對需求文檔進行預先評審,而在評審會中則要注意不要使評審會演變成了“業務會”或“技術研討會”。
同時,需求評審會的結果是對需求規格書完成了評審過程,那我們又如何判斷審查的結束標準呢?請看如下幾條建議:
1 、審查期間評審員們提出的所有問題都已經解決。
2、 相關文檔中的所有更改都已經正確完成。
3、 修訂過的文檔進行了拼寫檢查。
4 、所有標識為TBD(待確定)的問題已經全部解決, 或者已經對每個TBD的問題的解決過程、計劃解決的目標日期和責任解決人等編制了文檔。
5 、需求文檔正式進入了配置庫。
本文闡述了需求評審和確認的一些”注意”事項，一旦完成需求評審將表示進入了需求設計階段，欲知需求設計如何實現，且聽下文為您分解。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
