2.3.3 用例場景
用例在實際執行的時候會有很多的不同情況發生，稱之為用例場景；也可以說場景是用例的實例，我們在描述用例的時候要覆蓋所有的用例場景，否則就有可能導致需求的遺漏。在用例規約中，場景的描述可以由基本流和備選流的組合來表示。場景既可以幫助我們防止需求的遺漏，同時也可以對后續的開發工作起到很大的幫助：開發人員必須實現所有的場景、測試人員可以根據用例場景來設計測試用例。
2.3.4 特殊需求
特殊需求通常是非功能性需求，它為一個用例所專有，但不適合在用例的事件流文本中進行說明。特殊需求的例子包括法律或法規方面的需求、應用程序標準和所構建系統的質量屬性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些設計約束，如操作系統及環境、兼容性需求等，也可以在此節中記錄。
需要注意的是，這里記錄的是專屬于該用例的特殊需求；對于一些全局的非功能性需求和設計約束，它們并不是該用例所專有的，應把它們記錄在《補充規約》中。
2.3.5 前置和后置條件
前置條件是執行用例之前必須存在的系統狀態，后置條件是用例一執行完畢后系統可能處于的一組狀態。
2.4 檢查用例模型
用例模型完成之后，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查：
現有的用例模型是否完整地描述了系統功能，這也是我們判斷用例建模工作是否結束的標志。如果發現還有系統功能沒有被記錄在現有的用例模型中，那么我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現有的用例之中。 模型是否易于理解
用例模型最大的優點就在于它應該易于被不同的涉眾所理解，因而用例建模最主要的指導原則就是它的可理解性。用例的粒度、個數以及模型元素之間的關系復雜程度都應該由該指導原則決定。 是否存在不一致性
系統的用例模型是由多個系統分析員協同完成的，模型本身也是由多個工件所組成的，所以我們要特別注意不同工件之前是否存在前后矛盾或沖突的地方，避免在模型內部產生不一致性。不一致性會直接影響到需求定義的準確性。 避免二義性語義
好的需求定義應該是無二義性的，即不同的人對于同一需求的理解應該是一致的。在用例規約的描述中，應該避免定義含義模糊的需求，即無二義性。
3. 系統需求
RUP中根據FURPS+模型將系統需求分為以下幾類：
除了第一項功能性需求之外的其他需求都歸之為非功能性需求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
