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