軟件設計是怎樣煉成的（2）——優秀設計從分析需求開始

摘要：

設計應該針對需求來做，這個大道理似乎人人都懂，但實際操作時往往就不是這樣。所以我們也不說大道理，直接通過一個“很簡單”的案例來體驗一下優秀設計應該如何從分析需求開始，體驗架構設計是如何全面考慮各種需求、項目的工期限制預算限制，還有項目組人員水平后做出來的。

大綱：

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大戰需求分析》作者

www.umlonline.org創辦人