摘要：
設計應該針對需求來做，這個大道理似乎人人都懂，但實際操作時往往就不是這樣。所以我們也不說大道理，直接通過一個“很簡單”的案例來體驗一下優秀設計應該如何從分析需求開始，體驗架構設計是如何全面考慮各種需求、項目的工期限制預算限制，還有項目組人員水平後做出來的。
大綱：
1.什麼是優秀的設計？
2.優秀的設計能節省項目工作量
3.優秀設計從分析需求開始
4.軟件系統不是木桶型的
5.軟件設計的“大道理”
6.規劃系統骨架——架構設計
7.打造系統的底蘊——數據庫設計
8.細節決定成敗——詳細設計
9.用戶感覺好纔是真的好——用戶體驗設計
10.持續提升設計水平
本文章是系列文章之一，如果你還沒有看過之前的文章，建議先看完前面的文章再看本篇，這樣效果更好。
3.優秀設計從分析需求開始
設計應該針對需求來做，這個大道理似乎人人都懂，但實際操作時往往就不是這樣。所以我們 也不說大道理，直接通過一個“很簡單”的案例來體驗一下優秀設計應該如何從分析需求開始。
3.1 案例挑戰：考勤系統的軟件設計
某公司要做一個內部用的考勤系統，希望達成以下目標：
1）規範員工的上下班、請假、外出工作等行爲。
2）方便計算員工的薪金。
3）方便管理各種帶薪假期。
你如何考慮本系統的設計呢？
你可能會說：我靠，才三句話的需求，怎樣做設計呢？
說得太好了！我們做軟件設計的，第一步並不是直接去設計，而是分析需求！
3.2 如何分析需求？
當你接受一個項目的設計任務時，可能會遇到比較尷尬的情況，那就是需求有問題！
具體的情況可能有：
a）需求很簡單，幾句話或者是一頁紙的需求。
b）需求很詳細，可能有幾十頁甚至上百頁，這些需求是招標書中提供的，或者是客戶直接提供的。不要以爲有這麼多需求是好事，這些需求通常是前後有點矛盾、邏輯有點混亂，甚至是不知所云滴！
c）你們有專門的部門或者專職完成了需求工作，提供了一份需求文檔。你也不要以爲這是好事，因爲很可能會出現這樣的情況：需求文檔的提供者認爲自己寫的需求文檔很牛逼，水平很高；但負責實現的開發部門認爲該文檔質量太差，比方說：不考慮實現的可能性和難度，沒有考慮到客戶的真正需求等等。有時候甚至出現開發部門忽略掉需求部門，直接找客戶重新調研，重新編寫需求文檔的情況。
上述三種情況一句話總結就是：需求的質量有問題！
我們需要重新分析一次需求，先從業務角度審視一次，然後再從軟件設計的視角審視一次。通常我們需要按順序思考以下問題：
1）什麼人會使用這個系統？
2）不同的人將會使用這個系統的什麼功能？
3）還有哪些不確定或不具體的需求點？
4）哪些需求對技術提出了怎樣的要求？
5）系統的大致架構應該如何考慮？
下面開始我們看幾個圖，按順序逐一思考一下上述的幾個問題。本小節回答問題1、2，後面的小節回答其他問題。
1）什麼人會使用這個系統？
不少技術人員分析需求時往往是技術的視角，當你問他系統有什麼用戶時，你可能得到的結果有兩種：
a）沒有什麼用戶啊，所有人都是用戶，因爲系統只需要配置一下權限，誰都可以用。
b）系統有兩種用戶，就是：用戶和管理員。
我們從業務的角度來審視一下考勤系統的可能用戶，請看下圖：
圖2.1 系統可能用戶分析
此圖列出瞭如下可能用戶：
employee：員工
finance：財務
receptionist：前臺
manager：經理
senior manager：高級經理
administrator：管理員
而上述用戶還有這樣的關係：finanace（財務）、receptionist（前臺）、manager（經理）繼承employee（員工）；senior manager（高級經理）繼承manager（經理）。
用戶之間的繼承關係，是什麼意思呢？
我們都知道代碼中B類（子類）繼承A類（父類)，子類就具備了父類的特點。用戶之間的繼承關係是相同的意思，我們繼續看看下圖你就可以理解了。
下圖將會回答這個問題：
2）不同的人將會使用這個系統的什麼功能？
圖2.2 系統的需求分析
圖2.1和圖2.2都是UML的用例圖，兩個圖加在一起比較完整系統地表達了以下問題：
a）什麼角色會用本系統？
b）這些角色通過本系統分別能幹什麼事情？
c）角色之間有可能會有繼承關係，請留意父類能幹的事情，子類也能幹，例如：employee可以打卡，manager也可以打卡，儘管圖2.2中manager沒有直接與”打卡“相連，但圖2.1中已經說明了manager繼承employee。
UML是需求分析的有力工具，我的工作中很喜歡用UML。但你的工作中、你的需求文檔中可能會沒有UML圖，不管你們是否用UML圖，分析需求時都需要從業務的角度思考這些問題：
a）什麼人（角色）會用這個系統？
b）這些人（角色）分別需要用系統的什麼功能？
需求分析其實是一個負責的高難度的話題，回答上述兩個問題僅僅是需求分析的第一步而已，我們還需要深入分析業務，包括業務流程、業務數據結構等等。如果之前的需求工作不到位，就需要我們立馬開展軟件設計工作，其實將會埋下很多地雷，後患無窮。關於需求分析的更多分享，請留意我的其他文章，或者買一本我的書籍《火球——UML大戰需求分析》看看（廣告一下，哈哈）。
3.3 找出設計關注點
本小節我們回答這兩個問題：
3）還有哪些不確定或不具體的需求點？
4）哪些需求對技術提出了怎樣的要求？
軟件設計師需要有敏銳的需求及設計觸覺，看着圖2.1和圖2.2 嗅出一些問題，你能嗅出一些問題嗎？
請看下圖：
圖2.3 系統的設計點分析
圖2.3主要從設計的視角對需求再進行一次審視，以下是一些建議：
a）你需要更加深入思考需求，考慮到各種不同的業務場景和特殊情況，例如：領導不在公司時如何審批請假？
b）你需要思考需求的細節，例如：報表的具體形式？
c）你需要思考各種技術方案，例如：打卡數據的同步方案，財務軟件是否要對接等等？
d）你要做出平衡，用合適的方案和儘量少的工作量來滿足需求。
3.4 針對需求做初步的架構設計
本小節將會回答這個問題：
5）系統的大致架構應該如何考慮？
接下來你要做初步的架構設計了，架構設計是難度很高的事情，需要你全面考慮需求，考慮工期限制預算限制，考慮項目組人員的水平，而做出的一種平衡。請看下圖：
圖2.4 系統架構的考慮
圖2.4是UML的部署圖，這個圖比較粗糙，而且爲了降低大家閱讀難度，我僅僅是用了部署圖的最基本最少的語法來表達。
圖2.4中的每一個立體的矩形，表示的就是物理上或者是邏輯上的一臺設備，設備之間 有物理連接的話就用線條連接，每臺設備中”{ }“括起來的文字是對該設備的進一步說明。
圖可能是表達設計的最好方式，建議大家用UML，表達系統架構時，用UML的部署圖、組件圖和包圖是比較合適的。我們設計的系統多數是分佈式系統，不是單機系統，用部署圖來表達分佈式系統的架構設計可能是比較合適的。
圖2.4針對圖2.3中提出的問題進行了初步的迴應，圖2.4 就是一個初步的架構設計，當然後續我們還需要繼續細化這個設計。
3.5 小結：如何需求驅動設計？
本篇的例子告訴我們：
1）優秀的設計是需要從分析需求開始的。
2）需求的質量可能有問題，那麼我們需要從業務的角度重新審視一次。
3）從設計的角度審視需求，我們會提出很多需求細化及設計方案的問題。
4）架構設計是全面考慮各種需求、項目的工期限制預算限制，還有項目組人員水平後綜合做出來的一種平衡。
本文是系列文章的第2篇，要做軟件設計師一點都不簡單啊，請留意後續文章！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟件研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者