在寫需求用例的之前，一定要對所涉及的業(yè)務(wù)流程有一個比較完整認知，最好先和客戶進行一次交流。
現(xiàn)在就可以寫需求用例了。主要分為一下幾個步驟：
1）描述涉及的角色（Roles）
   在系統(tǒng)中會與系統(tǒng)驚醒交互的角色都有哪些

image.png

2）設(shè)計基本用例圖(UML-Usecase)
該圖應(yīng)涵蓋承接項目中的完整的業(yè)務(wù)用例，粒度要適中，每個用例能說明業(yè)務(wù)中一個主要步驟就好。不要過細，也不要過粗?。ㄟ@個尺度的把握比較難，主要是看用例是否能表述清楚一個業(yè)務(wù)中的問題）
對于基本用例圖，主要是為了建立一個全局的視圖，角色和用例之間的關(guān)系。對于中等規(guī)模的項目，我建議要分出不用的業(yè)務(wù)模塊，并且把業(yè)務(wù)模塊用不同的“包”來表示，這樣可以大大降低用例圖的視覺復(fù)雜性。
3）書寫用例描述
對不同業(yè)務(wù)模塊中的用例分別書寫具體的用例描述

image.png

1.   管理員登陸系統(tǒng)
   

2.   進入主題管理功能區(qū)
   

3.   選擇要修改的主題
   

4.   修改主題名稱和描述并可以重新指定主題的父級主題
   

5.   確認并完成修改主題
   

   4）為復(fù)雜用例設(shè)計交互圖/活動圖（UML- Activity）
   主要是根據(jù)用例描述中的“路徑”信息來設(shè)計活動圖，所以只要為比較復(fù)雜的用例設(shè)計就可以了。這樣可以更直觀的理解用例描述中的路徑流程。
   5）為主要業(yè)務(wù)對象設(shè)計狀態(tài)圖（UML- Statechart）
   主要是用來說明業(yè)務(wù)對象的有哪些狀態(tài)，并且在什么情況下有狀態(tài)的遷移。