《軟體架構設計》學習筆記&摘錄（四）

需求分析

       那些沒有經驗的問題解決者們，幾乎無一例外，都是去匆忙地尋找解決辦法，而不是先給要解決的問題下定義。

 

       什麼是軟體需求？什麼是需求捕獲、需求分析和系統分析？需求描述了系統必須滿足的情況或提供的能力，它就可以是直接來自客戶需要，也可以來自合約、標準、規範或其他有正規約束力的文檔。需求的捕獲是擷取知識的過程，知識從無到有、從少到多。需求分析是挖掘和整理知識的過程，它在已掌握知識的基礎上進行。如果說需求分析致力於搞清楚軟體系統要“做什麼”的話，那麼系統分析已經開始涉及“怎麼做”的問題了。系統分析是針對系統所要面臨的問題，搜集相關的資料，以瞭解產生問題的原因所在，進而提出解決問題的方法與可行的邏輯方案，以滿足系統的需求，實現預定的目標。需求捕獲、需求分析並不是先後進行的兩個階段工作，相反，它們往往是相互伴隨、交叉進行的。人們對軟體工程中“分析”這個術語的含義有著不同的理解——有時把它作為需求分析（Requirement
Analysis）的簡稱，有時是指系統分析（System Analysis），有時則作為需求分析和系統分析的總稱。但迄今為止人們所提出的各種分析方法中，真正屬於需求分析的內容所佔的分量並不太大；更多的內容是給出一種系統建模的方法，告訴分析員如何建立一個能夠滿足使用者需求的系統模型。分析員大量的工作是對系統的應用領域進行調查和研究並抽象地表示這個系統。確切地講，這些工作應該叫做系統分析，而不是需求分析，它既是對“做什麼”問題的進一步明確，也在相當程度上涉及到“怎麼做”的問題。大多數的分析方法（如OOA）應該屬於“系統分析”的範疇。需求分析的工作成果是《軟體需求規格說明書》（Software
Requirements Specification，SRS），它精確地闡述了一個軟體系統必須提供的功能、必須達到的品質屬性指標以及它必須遵守的約束。對於不同的系統分析方法，其工作成果差異很大。通過結構化分析方法得到的最重要的工作成果是資料流圖；而物件導向的分析方法得到的工作成果主要是分析類圖、魯棒圖、順序圖表等——其中分析類圖描述設計的靜態方面，而魯棒圖和順序圖表描述設計的動態方面。

       需求分析活動要進一步完善和細化軟體需求。需求分析和領域建模是相互支援的關係。要進行領域建模，很大程度上依賴於需求討論會等內容。領域模型作為領域建模的成果，規定了重要的領域詞彙表，並且這些詞彙的定義是嚴格的、大家共同認可的，所以可以成為團隊交流的基礎，自然也應當作為需求分析活動和《軟體需求規格說明書》應當遵循的標準詞彙。需求分析活動應該提供功能需求、品質屬性需求以及約束性需求等不同需求的明確定義。

       功能需求強調行為，而約束不是行為。約束是設計或項目的某些限制條件，這些限制條件也屬於需求，但通常被稱為“約束”來強調其限制性，例如：必須使用Oracle；必須在Linux上運行。

       推薦的軟體品質屬性分類方式：

       運行期品質屬性：

       效能、安全性、易用性、持續可用性、延展性、互通性、可靠性、魯棒性（健壯性或容錯性）。

       開發期品質屬性：

       易理解性、可擴充性、可重用性、可測試性、可維護性、可移植性。

       我們可以將運行期品質屬性和功能性一起視為“軟體的外部品質”，而將開發期品質屬性視為“軟體的內部品質”。無疑，軟體的內部品質制約著軟體的外部品質。

       功能需求影響架構，而架構必須適應功能需求。但功能需求並不能決定架構。倒是品質屬性需求對軟體架構影響更大。反過來，大部分品質屬性需求能否被滿足，也很大程度上依靠軟體架構的設計。約束性需求最特殊，它可能產生的影響有3種：

1、          作為架構設計時必須遵守的限制條件；

2、          導致軟體系統必須提供某些功能需求；

3、          導致軟體系統必須滿足某些約束性需求。

 

需求的變更蘊含著風險，因為不存在不需要成本的需求變更。當然，需求變更也蘊含著機遇。對軟體架構設計而言，這個機遇可能意味著設計出穩定的架構，最終這個架構能夠支援業務功能在一定範圍內“隨需應變”。一般而言，功能需求最易變，而品質需求最穩定。功能需求最容易變化，一是功能需求集中存在少量長期穩定的功能。二是雖然功能的行為步驟常常變化，但功能點本身趨於穩定。當採用用例技術進行需求捕獲和需求分析時，使用案例圖往往是相對穩定的（它描述了功能體現），而用例規約則可能頻繁變化（它以互動序列的形式描述功能執行的步驟）。品質屬性需求相對來說最為穩定。

       在需求分析過程中需求不斷地和客戶進行交流，這時客戶非常希望能夠看到給他帶來實感的介面草圖甚至可執行檔系統原型。而開發方最擔心的問題是客戶需求的不斷變化，所以他們也希望能夠儘早掌握客戶的真正需求，並希望需求成果得到客戶的確認。在需求分析期間就開始介面設計，並將介面草圖等設計成果用於和客戶的交流當中，這樣可以增加實感、方便交流，並協助客戶“發現”他真正想要的功能。當然，介面設計的成果並不應該放入《需求文檔》，因為它們是設計而不是需求。非功能需求的滿足程度對軟體的成功非常關鍵，因此《軟體需求規格說明書》必須系統地描述非功能需求的具體要求。非功能需求大致分為品質屬性和約束兩大類。

 

用例技術及應用

       我們掌握的知識本身和我們的實踐能力並不成正比。因為如果不能根據經驗使“頭腦中的知識”和“實踐”真正“匹配”起來，知識就無法轉化成真正的實踐能力。

       使用案例圖描述軟體系統為使用者或外部系統提供的服務。使用案例圖最重要的元素是參與者（Actor）和用例（Use Case）。用例的名稱應該從參與者的角度進行描述，並以動詞開頭。使用案例圖通過確定與本系統的互動的角色或外部系統、描述系統必須提供的功能的方式，清晰地界定了系統的功能範圍（Scope）。使用案例圖不僅是可視化的，而且是結構良好的、有利於從宏觀上反映系統功能的大局觀。所謂用例描簡述，就是通過簡短的文字對用例的功能進行描述：一般而言，用例簡述應包含成功情境的簡單描述。用例簡述是一項非常輕便的技術，很多敏捷方法都通過類似用例簡述的技術捕獲和交流需求。用例規約是對用例的詳細描述，一般包括簡要說明、主事件流、備選事件流、前置條件、後置條件（後者條件應覆蓋所有可能的用例結束後的狀態。即，後者條件不僅僅是用例成功結束後的狀態，還應該包含用例因發生錯誤而結束後的狀態。）和優先順序等。用例規約的主要目的是界定軟體系統的行為需求（需求可以劃分為業務需求（組織要達到的目標）、使用者需求（使用者使用系統來做什麼）和行為需求（開發人員需要實現什麼）三個層次，所謂行為需求是指系統軟體為了提供使用者所需要的功能而必須執行哪些行為）。用例簡述和用例規約都是對用例進行說明的技術，但用例規約要比用例簡述複雜10倍以上。

       在物件導向的理論系統中，協作被定義為“多個對象為了完成某種目標而進行的互動”。而用例實現的是協作的具體運用：即為了實現用例定義的功能，我們必須考慮需要哪些類，這些類又如何互動來完成最終的功能。用例實現是從功能需求向設計方案過渡的紐帶。通過分析一組關鍵用例的用例實現，可以獲得未來系統的思想化和職責模型，它的重點是識別組成軟體系統的進階職責塊、規劃它們之間的關係：這個職責模型是規劃架構機制、滿足高品質屬性要求的武器。

       使用案例圖從總體上反映了使用者需求，而用例簡述和用例規約分別是行為需求的簡化描述和詳細描述。至於用例實現，已經屬於設計的範疇了。

       用例方法是以客戶為中心的。用例方法比傳統的SRS更易於被使用者所理解，是開發人員於使用者之間進行溝通的有效手段之一。使用案例圖可以從大局上反映系統的功能結構，並且使用案例圖在很大程度上不會受到需求變更的衝擊——因為它不涉及需求細節。傳統需求方法採用功能分解方式，非常容易混淆需求和設計的界限，而用例方法有利於解決這個問題。

       一個軟體系統，它應當提供哪些功能往往是和營運目標相一致的，而一個企業的營運目標還是相當穩定的。對軟體開發影響巨大的需求變更其實更多地發生在行為需求層面——用例規約的主事件流和備選事件流正式反映行為需求。

       需求捕獲是知識採集的過程，致力於收集使用者對未來軟體系統的期望和具體要求。有如下的一些技術和手段：“需求採集卡”、“使用者故事卡”、“使用案例圖+用例簡述”。

       需求分析的目的是以比較規範的形式，明確定義軟體系統的要求，顯然用例規約正是一項規範、明確的技術——它通過特定格式的文本來記錄參與者和系統之間的各種情況下的互動情境，以此來明確對軟體系統的行為需求。需求分析還必須去偽存真、查漏補缺。用例規約技術能協助需求分析員以使用者為中心進行思考，定義不同情境下的軟體系統應有的行為需求。

       架構設計不應等到所有用例被細化到用例規約程度才開始。對架構設計起關鍵作用的功能需求只佔功能需求的一小部分，這部分用例應該已經被細化到用例規約的程度，它們和其他非功能需求一起決定架構設計方案。必須聰明地應付需求變更。需求變更對使用案例圖和用例簡述的影響比較小，而對用例規約的影響很大。因此我們應該“推後用例細化、激發需求變更”。不是對軟體架構起關鍵作用的用例，可以延遲到要實現該用例所定義的功能之前才進行細化，過早地為這些用例制定用例規約會增加“需求變更管理”的開銷，使需求變更的影響增大。必須通過不斷增加功能、發布小版本、提供給使用者試用、接受使用者反饋等一系列的活動。在項目前期不將所有用例細化，而是將大部分用例保持在“使用案例圖+簡短描述”的水平——這樣做並不影響開發出原型來啟發和確認使用者需求，並可能儘早激發需求變更的發生——直到變更的幾率較小的時候甚至到了程式小組要實現該用例的時候，再深入到小組的系統分析員對用例進行細化。（但筆者認為，這樣做的只時候使用敏捷開發的時候，使用瀑布模型時是顯然不適合的。另外，這樣做也同樣有將問題延遲發生的風險，我們應該儘早的發現問題，和讓問題方式。需求變更的方式，往往是在細節的交流過程中，或使用者看到原型之後出現的。筆者認同識別出關鍵需求就進行架構設計的觀點，但此時應該同時開始其他需求的細化工作）