摘要：要開發(fā)出用戶滿意的軟件并不是件容易的事，軟件架構(gòu)師必須全面把握各種各樣的需求、權(quán)衡需求之間有可能的矛盾之處，分門別類地將不同需求一一滿足。本文從理解需求種類的復(fù)雜性談起，通過具體案例的分析，展示了如何通過RUP的4+1視圖方法，針對不同需求進(jìn)行架構(gòu)設(shè)計，從而確保重要的需求一一被滿足。
呼喚架構(gòu)設(shè)計的多重視圖方法
靈感一閃，就想出了把大象放進(jìn)冰箱的辦法，這自然好。但希望每個架構(gòu)設(shè)計策略都依靠靈感是不現(xiàn)實的——我們需要系統(tǒng)方法的指導(dǎo)。
需要架構(gòu)設(shè)計的多重視圖方法，從根本上來說是因為需求種類的復(fù)雜性所致。以工程領(lǐng)域的例子開道吧。比如設(shè)計一座跨江大橋：我們會考慮“連接南北的公路交通”這個“功能需求”，從而初步設(shè)計出理想化的橋墩支撐的公路橋方案；然后還要考慮造橋要面臨的“約束條件”，這個約束條件可能是“不能影響萬噸輪從橋下通過”，于是細(xì)化設(shè)計方案，規(guī)定橋墩的高度和橋墩之間的間距；另外還要顧及“大橋的使用期質(zhì)量屬性”，比如為了“能在湍急的江流中保持穩(wěn)固”，可以把大橋橋墩深深地建在巖石層之上，和大地渾然一體；其實，“建造期間的質(zhì)量屬性”也很值得考慮，比如在大橋的設(shè)計過程中考慮“施工方便性”的一些措施。
和工程領(lǐng)域的功能需求、約束條件、使用期質(zhì)量屬性、建造期間的質(zhì)量屬性等類似，軟件系統(tǒng)的需求種類也相當(dāng)復(fù)雜，具體分類如圖1所示。
軟件需求
功能需求
非功能需求
約束
質(zhì)量屬性
運(yùn)行期質(zhì)量屬性
開發(fā)期質(zhì)量屬性
超市系統(tǒng)案例：理解需求種類的復(fù)雜性
例子是最好的老師。為了更好地理解軟件需求種類的復(fù)雜性，我們來分析一個實際的例子。在表1中，我們列舉了一個典型的超市系統(tǒng)的需求子集，從這個例子中可以清晰地看到需求可以分為兩大類：功能需求和非功能需求。
|
非功能需求 |
功能需求 |
|
約束 |
運(yùn)行期質(zhì)量屬性 |
開發(fā)期質(zhì)量屬性 |
|
項目預(yù)算有限
用戶的平均電腦操作水平偏低
要求能在Linux上運(yùn)行
開發(fā)人員分散在不同地點(diǎn)
…… |
高性能
易用性
…… |
易理解性
模塊間松散耦合
…… |
提高收銀效率
任意商品項可單獨(dú)取消
通過收銀終端的按鍵組合，可以使收銀過程從“逐項錄入狀態(tài)”進(jìn)入“選擇取消狀態(tài)”
…… |
表1 超市系統(tǒng)案例：理解需求種類的復(fù)雜性
簡單而言，功能需求就是“軟件有什么用，軟件需要做什么”。同時，注意把握功能需求的層次性是軟件需求的最佳實踐。以該超市系統(tǒng)為例：
超市老板希望通過軟件來“提高收銀效率”。
那么，你可能需要為收銀員提供一系列功能來促成這個目的，比如供收銀員使用的“任意商品項可單獨(dú)取消”功能有利于提供收銀效率（筆者曾在超市有過被迫整單取消然后一車商品重新掃描收費(fèi)的痛苦經(jīng)歷）。
而具體到這個超市系統(tǒng)，系統(tǒng)分析員可能會決定要提供的具體功能為：通過收銀終端的按鍵組合，可以使收銀過程從“逐項錄入狀態(tài)”進(jìn)入“選擇取消狀態(tài)”，從而取消某項商品。
從上面的例子中我們還驚訝地發(fā)現(xiàn)，非功能需求——人們最經(jīng)常忽視的一大類需求——包括的內(nèi)容非常寬、并且極其重要。非功能需求又可以分為如下三類：
約束。要開發(fā)出用戶滿意的軟件并不是件容易的事，而全面理解要設(shè)計的軟件系統(tǒng)所面臨的約束可以使你向成功邁進(jìn)一步。約束性需求既包括企業(yè)級的商業(yè)考慮（例如“項目預(yù)算有限”），也包括最終用戶級的實際情況（例如“用戶的平均電腦操作水平偏低”）；既可能包括具體技術(shù)的明確要求（例如“要求能在Linux上運(yùn)行”），又可能需要考慮開發(fā)團(tuán)隊的
項目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
