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