產品設計體會（二一） UC寫作

uc（user case，用例）是需求人員寫給開發人員看的一種最基本的文件，最近在和微軟合作做專案，發現雙方的文件規範差異很大，造成了溝通成本的提高，所以感覺到在乙個長期合作的團隊中，文件與規範的統一真的是非常必要的（我強調的是「統一」，並沒有強調要一定要用「某種格式」）。

查了一下資料，早期的需求人員是通過對應用場景（scenario）的分析來細化需求，本世紀初，一些牛人們才將這種方法正式歸納為用例法。之後在**製作中，業界又對其發展，擴充套件出了「任務分解」等需求細化方法。下面簡單的說一下乙個用例要描述哪些事情。

首先需要有個總體的用例圖來對系統給出高階視覺化的表示，uml中給出了幾個關鍵點：方框代表系統邊界，每個角色（小人圖形）通過線條和與之互動的用例（橢圓）相連。

然後需要描述每個用例，基本元素有（括號中舉例說明）：

用例的唯一標識（uc_ordermeal）；

用例名稱（點菜）；

行為者（小明）；

用例的簡述（小明週末晚上去a餐館，點乙個菜，之後等燒好了吃掉）；

前置條件（是週末，……）；

後置條件（服務員接受訂單，去廚房，……）；

流程，分主幹和分支，描述共前置條件到後置條件的過程中，系統與使用者之間有何種互動步驟，這裡多見的是時序圖或者流程圖（小明自己選or 讓服務員推薦，if 服務員推薦，小明接受or 不接受……確定點某個菜……）；

其他內容，比如限制條件、業務規則的描述（小明不吃辣，小明口袋裡只有100塊）；介面描述（小明的例子中好像沒有，對於網頁，我們對介面的描述經常佔uc的很大篇幅，甚至配上demo）；額外的一些針對專案特定的需求。

uc一般只能描述絕大部分的功能需求，無法描述諸如效能、培訓需要、時間限制等非功能需求，所以把uc拼在一起，再加上非功能的需求描述以及專案其他的概要資訊，才構成教科書裡的「需求說明書」。