軟件設(shè)計是怎樣煉成的（2）——優(yōu)秀設(shè)計從分析需求開始

摘要：

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

大綱：

1.什么是優(yōu)秀的設(shè)計？
2.優(yōu)秀的設(shè)計能節(jié)省項目工作量
3.優(yōu)秀設(shè)計從分析需求開始
4.軟件系統(tǒng)不是木桶型的
5.軟件設(shè)計的“大道理”
6.規(guī)劃系統(tǒng)骨架——架構(gòu)設(shè)計
7.打造系統(tǒng)的底蘊(yùn)——數(shù)據(jù)庫設(shè)計
8.細(xì)節(jié)決定成敗——詳細(xì)設(shè)計
9.用戶感覺好才是真的好——用戶體驗設(shè)計
10.持續(xù)提升設(shè)計水平

本文章是系列文章之一，如果你還沒有看過之前的文章，建議先看完前面的文章再看本篇，這樣效果更好。

3.優(yōu)秀設(shè)計從分析需求開始

設(shè)計應(yīng)該針對需求來做，這個大道理似乎人人都懂，但實際操作時往往就不是這樣。所以我們 也不說大道理，直接通過一個“很簡單”的案例來體驗一下優(yōu)秀設(shè)計應(yīng)該如何從分析需求開始。

3.1 案例挑戰(zhàn)：考勤系統(tǒng)的軟件設(shè)計

某公司要做一個內(nèi)部用的考勤系統(tǒng)，希望達(dá)成以下目標(biāo)：

1）規(guī)范員工的上下班、請假、外出工作等行為。
2）方便計算員工的薪金。
3）方便管理各種帶薪假期。

你如何考慮本系統(tǒng)的設(shè)計呢？

你可能會說：我靠，才三句話的需求，怎樣做設(shè)計呢？

說得太好了！我們做軟件設(shè)計的，第一步并不是直接去設(shè)計，而是分析需求！

3.2 如何分析需求？

當(dāng)你接受一個項目的設(shè)計任務(wù)時，可能會遇到比較尷尬的情況，那就是需求有問題！

具體的情況可能有：

a）需求很簡單，幾句話或者是一頁紙的需求。
b）需求很詳細(xì)，可能有幾十頁甚至上百頁，這些需求是招標(biāo)書中提供的，或者是客戶直接提供的。不要以為有這么多需求是好事，這些需求通常是前后有點矛盾、邏輯有點混亂，甚至是不知所云滴！

c）你們有專門的部門或者專職完成了需求工作，提供了一份需求文檔。你也不要以為這是好事，因為很可能會出現(xiàn)這樣的情況：需求文檔的提供者認(rèn)為自己寫的需求文檔很牛逼，水平很高；但負(fù)責(zé)實現(xiàn)的開發(fā)部門認(rèn)為該文檔質(zhì)量太差，比方說：不考慮實現(xiàn)的可能性和難度，沒有考慮到客戶的真正需求等等。有時候甚至出現(xiàn)開發(fā)部門忽略掉需求部門，直接找客戶重新調(diào)研，重新編寫需求文檔的情況。

上述三種情況一句話總結(jié)就是：需求的質(zhì)量有問題！

我們需要重新分析一次需求，先從業(yè)務(wù)角度審視一次，然后再從軟件設(shè)計的視角審視一次。通常我們需要按順序思考以下問題：

1）什么人會使用這個系統(tǒng)？
2）不同的人將會使用這個系統(tǒng)的什么功能？

3）還有哪些不確定或不具體的需求點？
4）哪些需求對技術(shù)提出了怎樣的要求？
5）系統(tǒng)的大致架構(gòu)應(yīng)該如何考慮？

下面開始我們看幾個圖，按順序逐一思考一下上述的幾個問題。本小節(jié)回答問題1、2，后面的小節(jié)回答其他問題。

1）什么人會使用這個系統(tǒng)？

不少技術(shù)人員分析需求時往往是技術(shù)的視角，當(dāng)你問他系統(tǒng)有什么用戶時，你可能得到的結(jié)果有兩種：

a）沒有什么用戶啊，所有人都是用戶，因為系統(tǒng)只需要配置一下權(quán)限，誰都可以用。
b）系統(tǒng)有兩種用戶，就是：用戶和管理員。

我們從業(yè)務(wù)的角度來審視一下考勤系統(tǒng)的可能用戶，請看下圖：

圖2.1 系統(tǒng)可能用戶分析

此圖列出了如下可能用戶：

employee：員工
finance：財務(wù)
receptionist：前臺
manager：經(jīng)理
senior manager：高級經(jīng)理
administrator：管理員

而上述用戶還有這樣的關(guān)系：finanace（財務(wù)）、receptionist（前臺）、manager（經(jīng)理）繼承employee（員工）；senior manager（高級經(jīng)理）繼承manager（經(jīng)理）。

用戶之間的繼承關(guān)系，是什么意思呢？

我們都知道代碼中B類（子類）繼承A類（父類)，子類就具備了父類的特點。用戶之間的繼承關(guān)系是相同的意思，我們繼續(xù)看看下圖你就可以理解了。

下圖將會回答這個問題：

2）不同的人將會使用這個系統(tǒng)的什么功能？

圖2.2 系統(tǒng)的需求分析

圖2.1和圖2.2都是UML的用例圖，兩個圖加在一起比較完整系統(tǒng)地表達(dá)了以下問題：

a）什么角色會用本系統(tǒng)？
b）這些角色通過本系統(tǒng)分別能干什么事情？
c）角色之間有可能會有繼承關(guān)系，請留意父類能干的事情，子類也能干，例如：employee可以打卡，manager也可以打卡，盡管圖2.2中manager沒有直接與”打卡“相連，但圖2.1中已經(jīng)說明了manager繼承employee。

UML是需求分析的有力工具，我的工作中很喜歡用UML。但你的工作中、你的需求文檔中可能會沒有UML圖，不管你們是否用UML圖，分析需求時都需要從業(yè)務(wù)的角度思考這些問題：

a）什么人（角色）會用這個系統(tǒng)？
b）這些人（角色）分別需要用系統(tǒng)的什么功能？

需求分析其實是一個負(fù)責(zé)的高難度的話題，回答上述兩個問題僅僅是需求分析的第一步而已，我們還需要深入分析業(yè)務(wù)，包括業(yè)務(wù)流程、業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)等等。如果之前的需求工作不到位，就需要我們立馬開展軟件設(shè)計工作，其實將會埋下很多地雷，后患無窮。關(guān)于需求分析的更多分享，請留意我的其他文章，或者買一本我的書籍《火球——UML大戰(zhàn)需求分析》看看（廣告一下，哈哈）。

3.3 找出設(shè)計關(guān)注點

本小節(jié)我們回答這兩個問題：

3）還有哪些不確定或不具體的需求點？
4）哪些需求對技術(shù)提出了怎樣的要求？

軟件設(shè)計師需要有敏銳的需求及設(shè)計觸覺，看著圖2.1和圖2.2 嗅出一些問題，你能嗅出一些問題嗎？

請看下圖：

圖2.3 系統(tǒng)的設(shè)計點分析

圖2.3主要從設(shè)計的視角對需求再進(jìn)行一次審視，以下是一些建議：

a）你需要更加深入思考需求，考慮到各種不同的業(yè)務(wù)場景和特殊情況，例如：領(lǐng)導(dǎo)不在公司時如何審批請假？
b）你需要思考需求的細(xì)節(jié)，例如：報表的具體形式？
c）你需要思考各種技術(shù)方案，例如：打卡數(shù)據(jù)的同步方案，財務(wù)軟件是否要對接等等？
d）你要做出平衡，用合適的方案和盡量少的工作量來滿足需求。

3.4 針對需求做初步的架構(gòu)設(shè)計

本小節(jié)將會回答這個問題：

5）系統(tǒng)的大致架構(gòu)應(yīng)該如何考慮？

接下來你要做初步的架構(gòu)設(shè)計了，架構(gòu)設(shè)計是難度很高的事情，需要你全面考慮需求，考慮工期限制預(yù)算限制，考慮項目組人員的水平，而做出的一種平衡。請看下圖：

圖2.4 系統(tǒng)架構(gòu)的考慮

圖2.4是UML的部署圖，這個圖比較粗糙，而且為了降低大家閱讀難度，我僅僅是用了部署圖的最基本最少的語法來表達(dá)。

圖2.4中的每一個立體的矩形，表示的就是物理上或者是邏輯上的一臺設(shè)備，設(shè)備之間 有物理連接的話就用線條連接，每臺設(shè)備中”{ }“括起來的文字是對該設(shè)備的進(jìn)一步說明。

圖可能是表達(dá)設(shè)計的最好方式，建議大家用UML，表達(dá)系統(tǒng)架構(gòu)時，用UML的部署圖、組件圖和包圖是比較合適的。我們設(shè)計的系統(tǒng)多數(shù)是分布式系統(tǒng)，不是單機(jī)系統(tǒng)，用部署圖來表達(dá)分布式系統(tǒng)的架構(gòu)設(shè)計可能是比較合適的。

圖2.4針對圖2.3中提出的問題進(jìn)行了初步的回應(yīng)，圖2.4 就是一個初步的架構(gòu)設(shè)計，當(dāng)然后續(xù)我們還需要繼續(xù)細(xì)化這個設(shè)計。

3.5 小結(jié)：如何需求驅(qū)動設(shè)計？

本篇的例子告訴我們：

1）優(yōu)秀的設(shè)計是需要從分析需求開始的。
2）需求的質(zhì)量可能有問題，那么我們需要從業(yè)務(wù)的角度重新審視一次。
3）從設(shè)計的角度審視需求，我們會提出很多需求細(xì)化及設(shè)計方案的問題。
4）架構(gòu)設(shè)計是全面考慮各種需求、項目的工期限制預(yù)算限制，還有項目組人員水平后綜合做出來的一種平衡。

本文是系列文章的第2篇，要做軟件設(shè)計師一點都不簡單啊，請留意后續(xù)文章！

作者：張傳波

創(chuàng)新工場創(chuàng)業(yè)課堂（敏捷課程）講師

軟件研發(fā)管理資深顧問

CMMI首席專家

《火球——UML大戰(zhàn)需求分析》作者

www.umlonline.org創(chuàng)辦人