1 UML版型
UML版型（stereotype），也被稱爲類型、構造型。是對UML元素基礎定義的擴展，在同一個元素的基礎定義上賦予特別的含義，是的這個元素適用於特定的場合。例如用例有“業務用例”、“業務用例實現”等版型，類有“接口”、“邊界類”、“實體類”、“控制類”等版型。除了UML已經定義的版型，爲了在某種場合下讓元素表達某種特定的含義，版型也是可以自己定義的。如包元素有“子系統”、“組織結構”、“模塊”等默認版型，在具體項目中，也可以自己另外定義“文檔”、“開發小組”等版型，以表達業務含義。
2 參與者（Actor）
官方定義：actor是在系統之外與系統交互的某人或某事物。
參與者的特徵：
- 位於系統邊界之外：參與者是主動向系統發出動作的，系統是爲參與者服務的
- 可以非人：另一個計算機系統、定時器、傳感器等都可以是參與者
3 如何發現參與者
通過詢問如下問題幫助發現參與者：
- 誰負責提供、使用或刪除信息
- 誰將使用此功能
- 誰對某個特定功能感興趣
- 在組織中的什麼地方使用系統
- 誰負責支持和維護系統
- 系統有哪些外部資源
- 其他還有哪些系統將需要與該系統進行交互
4 業務主角（Bussiness Actor）
參與者的一個版型，遵循參與者的所有定義。它用於定義業務的參與者，在需求階段使用。業務主角是與業務系統有着交互的人和事物，用來確定業務範圍。業務主角是客戶實際業務裏的參與者，沒有計算機系統，沒有抽象的計算機角色。可以通過回答如下問題對發現的業務主角進行正確性檢查：
- 業務主角的名稱是否是客戶的業務術語
- 業務主角的職責是否在客戶的崗位手冊裏有對應的定義
- 業務主角的業務用例是否都是客戶的業務術語
- 客戶是否對業務主角都能順利理解
5 業務工人（Business Worker）
系統業務的參與者，但位於系統的邊界內，且一般都是被動參與業務的，比如訂票系統的人工座席，只有在機票購買者發起購票流程時纔會開始工作。區分參與者與業務工人的方法：
- 他是主動向系統發出動作的嗎
- 他有完整的業務目標嗎
- 系統是爲他服務的嗎
如果三個問題的答案都是否定的，則他一定是業務工人，而非參與者。
6 涉衆
涉衆（stakeholder）也被稱爲干係人，是與要建設的系統有利益關係的一切人和事。
7 參與者與用戶
用戶（user）是系統的使用者，是參與者的代表，如祕書代表局長使用系統，則局長是系統的參與者，但並不是系統的最終用戶。
8 角色
角色（role）是參與者的職責，是一個抽象的概念，一個角色代表了系統中的一類職責。
