1.是否一定要用UML來表達需求？
需求如何表達，用什么方式表達，同樣是招無定式。P 117
其實無論是否使用UML圖，其目的無非是想表達以下內(nèi)容：
（1）系統(tǒng)所涉及業(yè)務(wù)的靜態(tài)概念及它們之間的關(guān)系（結(jié)構(gòu)建模）
（2）系統(tǒng)所涉及業(yè)務(wù)的動態(tài)內(nèi)容，一般就是各種業(yè)務(wù)流程（行為建模）
（3）我們希望這個系統(tǒng)能為用戶做什么事情。
以上三個目的都是可以找到相應(yīng)的UML來輔助實現(xiàn)，但沒有規(guī)定非用不可，只要達到目的，任何合適的方法都是可以采用的。
2.先獲取需求還是先分析業(yè)務(wù)？
準(zhǔn)確全面的需求獲取依賴于精準(zhǔn)的業(yè)務(wù)理解，應(yīng)該從業(yè)務(wù)分析開始，在此基礎(chǔ)上整理出需求用例，如果你能深刻理解業(yè)務(wù)，理解客戶的需要，你就可以提出有價值的需求解決方案。p118
本書介紹了類圖、活動圖、狀態(tài)機圖、順序圖，其實都是講述如何利用UML來分析業(yè)務(wù)的問題，我們可以利用類圖進行業(yè)務(wù)結(jié)構(gòu)建模，利用活動圖、狀態(tài)機圖、順序圖來進行業(yè)務(wù)行為建模。利用用例圖從用戶視角來介紹系統(tǒng)能為用戶做什么事情。
用例圖,可以更清晰地展示用戶需求與用戶所需服務(wù),讓產(chǎn)品團隊更好地站在用戶角度去思考問題,并建立場景化思維
在業(yè)務(wù)架構(gòu)·應(yīng)用架構(gòu)·數(shù)據(jù)架構(gòu)一書中說“分支流程和業(yè)務(wù)場景有完美的對應(yīng)關(guān)系。識別分支流程，就是場景化思維”，業(yè)務(wù)分析后確定對應(yīng)的IT需求，就可以開始做用例圖了，用例圖就是對系統(tǒng)功能的描述。
比如主流程是登錄，分支流程是忘記密碼、修改密碼，衍生出來的功能是發(fā)送驗證碼。
用例圖（Use Case Diagram）是由參與者（Actor）、用例（Use Case）以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的視圖，是被稱為參與者的外部用戶所能觀察到的系統(tǒng)功能的模型圖。
用例圖有兩個來源：需要分析和業(yè)務(wù)分析。
我們需要利用這些UML圖來理解、發(fā)掘、整理客戶的業(yè)務(wù)，然后根據(jù)客戶的目標(biāo)、期望整理出系統(tǒng)的需求，這個時候我們就需要使用用例圖。能否精準(zhǔn)地把握客戶的需求，其實70%靠我們對業(yè)務(wù)的準(zhǔn)確深入全面理解，30%靠需求的整理。
本書建議需求分析應(yīng)該從業(yè)務(wù)理解開始，在把握客戶需要的基礎(chǔ)上逐步整理出需求規(guī)格。當(dāng)然這個過程也不是絕對的，我們也可以從客戶直接提出的需求規(guī)格中發(fā)掘其背后的需要，再回過頭來完善需求規(guī)格。
