軟件需求設計評審的八項要點需注意

2008/9/16 8:34:05 | 4685次閱讀 | 來源：網友轉載【已有0條評論】發(fā)表評論

ard所言：“用例和測試用例以兩種方式協同作, 如果系統(tǒng)用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統(tǒng)用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
　　七、注意對需求包含的用例文檔進行評審
　　用例是參與者對系統(tǒng)和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發(fā)方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
　　1 用例的目標或價值度量是否明確?
　　這一點是考察用例的編寫是從用戶角度還是從系統(tǒng)角度出發(fā)的。必須保證用例從用戶角度出發(fā),用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統(tǒng)做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的溝通還沒能達成“契約”。
　　2 用例是否是獨立的分散任務?
　　3 是否明確說明可用用例會給哪些參與者帶來用處?
　　不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統(tǒng)和用例的主要價值態(tài)度及其約束條件。
　　4 編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節(jié)?
　　用例不應該有任何的設計細節(jié),更不能出現UI設計。我們要確保參與者是以黑盒子看系統(tǒng)的,這樣化繁為簡的思路,正是系統(tǒng)分析分層次目的所在。
　　5 所有預期的分支過程是否都編寫了文檔說明?
　　參與者的動作和系統(tǒng)的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
　　6 所有預估的異常過程是否都編寫了文檔說明?
　　參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
　　7 是否存在一些普通的動作序列可以分解成獨立的用例?
　　用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
　　8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
　　用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統(tǒng)要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業(yè)務或任務流程。
　　9 用例中的每個參與者和步驟是否都與所執(zhí)行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
　　10 用例中定義的每個可選路徑是否都可行和可驗證?
　　用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統(tǒng)執(zhí)行通過的。
　　11用例的前置條件和后置條件是否合理?
　　分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區(qū)分了用例和用例之間的界限。
　　分析師經常會發(fā)現在檢查一個包含九個步驟的用例時,發(fā)現執(zhí)行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
　　八、注意需求評審會的過程和結束標準
　　通常，需求評審會都不是件容易的事情,業(yè)務審查人員分散在各個地域和時間上的不一致性是困難產生的所在。在很多情況下,我們可以使用分布式需求評審軟件從網絡上對需求文檔進行預先評審,而在評審會中則要注意不要使評審會演變成了“業(yè)務會”或“技術研討會”。
　　同時,需求評審會的結果是對需求規(guī)格書完成了評審過程,那我們又如何判斷審查的結束標準呢?請看如下幾條建議:
　　1 審查期間評審員們提出的所有問題都已經解決。
　　2 相關文檔中的所有更改都已經正確完成。
　　3 修訂過的文檔進行了拼寫檢查。
4 所有標識為TBD(待確定)的問題已經全部解決, 或者已經對每個TBD的問題的解決過程、計劃解決的目標日期和責任解決人等編制了文檔。
　　5 需求文檔正式進入了配置庫。
　　本文闡述了需求評審和確認的一些”注意”事項，一旦完成需求評審將表示進入了需求設計階段，欲知需求設計如何實現，且聽下文為您分解。