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