第三，用例主要以事件流的形式定義需求，但這不是唯壹的方式，用例是高度形式化的。
除了主事件流之外，參與者還描述了誰將使用這個用例。先決條件描述了執行用例必須滿足的條件或狀態。後置條件描述用戶在成功執行後應該處於什麽狀態。特殊需求將以特有的方式描述與用例相關的其他功能性或非功能性需求，通常非功能性需求占大多數。與XP、FDD和其他敏捷方法相比，用例更正式，定義要求更嚴格，當然會花費更多時間。
4.用例在同壹時間只能有壹個主要參與者。
1.學生準備申請助學金，系統提示學生輸入學習成績和家庭條件等信息。
2.學生提交上述信息以獲得批準。
3.學生資助審批人審查學生資助申請，決定是否批準，系統提示審批意見。
4、授予審批人員輸入原因並確認。
那麽參與者之間的協作在哪裏描述呢？我們真的需要它。事實上，這是業務用例實現的責任。
5.用例不是需求的唯壹定義形式，它們需要與其他需求定義形式壹起定義完整的需求。
用例比其他需求方法有優勢，但僅使用用例無法有效地定義完整的需求。用例主要定義功能和行為需求，系統還有很多非功能需求需要定義，比如可用性、性能、可支持性等等。以用例的形式定義這些需求是不可行的，定義它們的最佳形式應該是特性。
此外，壹些功能需求可能沒有被用例定義，例如系統提供的服務接口。然而，對於中間件產品中大量不與參與者交互的需求來說，使用用例定義尤其不合適。它的需求是以更恰當地使用特性的方式定義的。
上述用例是什麽，其特征是什麽？在實踐中，總有人分不清用例與業務用例。業務用例是用例思想的延續，但是它改變了使用情況。用例是從用戶的角度定義“軟件系統”的需求。業務用例不研究“軟件系統”的需求，而是關心“業務組織”向外界提供什麽服務。如果住房公積金中心是商業機構，您可能是商業參與者（如果您打算進行住房公積金貸款）。那麽辦理住房公積金貸款就是壹個業務用例。這次商務會議將描述什麽？它將描述類似於以下內容（由於其復雜性，僅用於說明）:
1.職工準備相關材料，到住房公積金中心申請繳納。業務用例開始了。
2.員工向中心提交貸款準備的相關材料，中心工作人員對材料進行初審。
3.如果批準，員工準備辦理抵押合同，中心工作人員委托擔保公司與員工簽訂抵押合同。
4.擔保完成後，員工與中心簽訂貸款合同，中心工作人員要求員工辦理銀行卡並提供卡號。
5.借款合同簽訂後，中心工作人員要求借款合同必須進行公證，由工作人員和中心共同進行公證。
6.員工完成公證後，中心將發放貸款。業務用例結束。
可以看出，這裏的業務用例描述了業務參與者（員工）如何使用業務組織（中心）提供的服務的過程。因此，業務用例實際上是壹個業務流程。它從業務組織外部的業務參與者的角度定義了業務組織提供的服務。當然，業務用例還包括壹些內部流程，這些流程可能不是由業務參與者發起的，例如采購流程。所以業務用例只是使用了用例的思想和形式，研究的主題是完全不同的。用例研究軟件系統並在用例的幫助下定義軟件系統需求。業務用例研究目標組織，並在業務用例的幫助下定義目標組織應該具有的業務流程以及這些流程應該是什麽樣子。