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/
