軟件設計是怎樣煉成的（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）系統的大體架構應該如何考慮？

下面開始咱們看幾個圖，按順序逐一思考一下上述的幾個問題。本小節回答問題一、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）這些人（角色）分別須要用系統的什麼功能？

需求分析實際上是一個負責的高難度的話題，回答上述兩個問題僅僅是需求分析的第一步而已，咱們還須要深刻分析業務，包括業務流程、業務數據結構等等。若是以前的需求工做不到位，就須要咱們立馬開展軟件設計工做，其實將會埋下不少地雷，後患無窮。關於需求分析的更多分享，請留意個人其餘文章。

 

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

軟件知識原創基地創辦人