3.1 需求工件集
用例模型主要用于描述系統的功能性需求,對于其他的非功能性需要用其他文檔來記錄。RUP中定義了如下的需求工件集合。
在實際應用中,除了這些工件之外,我們還可以根據實際需求靈活選用其他形式的文檔來補充說明需求。并不是所有的系統需求都適保合用用例模型來描述的,如編譯器,我們很難用用例方法來表述它所處理的語言的方法規則,在這種情況下,采用傳統的BNF范式來表述更加合適一些。在電信軟件行業中,很多電信標準都是采用SDL語言來描述的,我們也不必用UML來改寫這些標準(UML對SDL存在著這樣的兼容性),只需將SDL形式的電信標準作為需求工件之一,在其他工件中對其加以引用就可以了?傊,萬萬不可拘泥于用例建模的形式,應靈活運用各種方式的長處。
3.2 補充規約
補充規約記錄那些在用例模型中不易表述的系統需求,主要包括以下內容。
功能性需求主要在用例模型中刻畫,但是也有部分需求不適合在用例中表述。有些功能性需求是全局性的,適用于所有的用例,如出錯處理、I18N支持等,我們不需要在所有的用例中描述這些功能性需求,只需要在補充規約中統一描述就可以了。 可用性
記錄所有可用性相關的需求,如系統的使用者所需要的培訓時間、是否應附合一些常見的可用性標準如Windows界面風格等。 可靠性
定義系統可靠性相關的各種指標,包括:
可用性:指出可用時間百分比(xx.xx%),系統處于使用、維護、降級模式等操作的小時數; 平均故障間隔時間(MTBF):通常表示為小時數,但也可表示為天數、月數或年數; 平均修復時間(MTTR):系統在發生故障后可以暫停運行的時間; 精確度:指出系統輸出要求具備的精密度(分辨率)和精確度(按照某一已知的標準); 最高錯誤或缺陷率:通常表示為bugs/KLOC(每千行代碼的錯誤數目)或bugs/function-point(每個功能點的錯誤數目)。性能
記錄系統性能相關的各種指標,包括:
對事務的響應時間(平均、最長); 吞吐量(例如每秒處理的事務數); 容量(例如系統可以容納的客戶或事務數); 降級模式(當系統以某種形式降級時可接受的運行模式); 資源利用情況:內存、磁盤、通信等?芍С中
定義所有與系統的可支持性或可維護性相關的需求,其中包括編碼標準、命名約定、類庫、如何來對系統進行維護操作和相應的維護實用工具等。 設計約束
設計約束代表已經批準并必須遵循的設計決定,其中包括軟件開發流程、開發工具、系統構架、編程語言、第三方構件類庫、運行平臺和數據庫系統等等。
3.3 詞匯表
詞匯表主要用于定義項目特定的術語,它有助于開發人員對項目中所用的術語有統一的理解和使用,它也是后續階段中進行對象抽象的基礎。
4. 調整用例模型
在一般的用例圖中,我們只表述參與者和用例之間的關系,即它們之間的通訊關聯。除此之外,我們還可以描述參與者與參與者之間的泛化(generalization)、用例和用例之間的包含(include)、擴展(extend)和泛化(generalization)關系。我們利用這些關系來調整已有的用例模型,把一些公共的信息抽取出來重用,使得用例模型更易于維護。但是在應用中要小心選用這些關系,一般來說這些關系都會增加用例和關系的個數,從而增加用例模型的復雜度。而且一般都是在用例模型完成之后才對用例模型進行調整,所以在用例建模的初期不必要急于抽象用例之間的關系。
文章來源于領測軟件測試網 http://www.kjueaiud.com/