需求分析
那些沒有經驗的問題解決者們，幾乎無一例外，都是去匆忙地尋找解決辦法，而不是先給要解決的問題下定義。
什麼是軟件需求？什麼是需求捕獲、需求分析和系統分析？需求描述了系統必須滿足的情況或提供的能力，它就可以是直接來自客戶需要，也可以來自合同、標準、規範或其他有正規約束力的文檔。需求的捕獲是獲取知識的過程，知識從無到有、從少到多。需求分析是挖掘和整理知識的過程，它在已掌握知識的基礎上進行。如果說需求分析致力於搞清楚軟件系統要“做什麼”的話，那麼系統分析已經開始涉及“怎麼做”的問題了。系統分析是針對系統所要面臨的問題，蒐集相關的資料，以瞭解產生問題的原因所在，進而提出解決問題的方法與可行的邏輯方案，以滿足系統的需求，實現預定的目標。需求捕獲、需求分析並不是先後進行的兩個階段工作，相反，它們往往是相互伴隨、交叉進行的。人們對軟件工程中“分析”這個術語的含義有着不同的理解——有時把它作爲需求分析（Requirement Analysis）的簡稱，有時是指系統分析（System Analysis），有時則作爲需求分析和系統分析的總稱。但迄今爲止人們所提出的各種分析方法中，真正屬於需求分析的內容所佔的分量並不太大；更多的內容是給出一種系統建模的方法，告訴分析員如何建立一個能夠滿足用戶需求的系統模型。分析員大量的工作是對系統的應用領域進行調查和研究並抽象地表示這個系統。確切地講，這些工作應該叫做系統分析，而不是需求分析，它既是對“做什麼”問題的進一步明確，也在相當程度上涉及到“怎麼做”的問題。大多數的分析方法（如OOA）應該屬於“系統分析”的範疇。需求分析的工作成果是《軟件需求規格說明書》（Software Requirements Specification，SRS），它精確地闡述了一個軟件系統必須提供的功能、必須達到的質量屬性指標以及它必須遵守的約束。對於不同的系統分析方法，其工作成果差異很大。通過結構化分析方法得到的最重要的工作成果是數據流圖；而面向對象的分析方法得到的工作成果主要是分析類圖、魯棒圖、序列圖等——其中分析類圖描述設計的靜態方面，而魯棒圖和序列圖描述設計的動態方面。
需求分析活動要進一步完善和細化軟件需求。需求分析和領域建模是相互支持的關係。要進行領域建模，很大程度上依賴於需求討論會等內容。領域模型作爲領域建模的成果，規定了重要的領域詞彙表，並且這些詞彙的定義是嚴格的、大家共同認可的，所以可以成爲團隊交流的基礎，自然也應當作爲需求分析活動和《軟件需求規格說明書》應當遵循的標準詞彙。需求分析活動應該提供功能需求、質量屬性需求以及約束性需求等不同需求的明確定義。
功能需求強調行爲，而約束不是行爲。約束是設計或項目的某些限制條件，這些限制條件也屬於需求，但通常被稱爲“約束”來強調其限制性，例如：必須使用Oracle；必須在Linux上運行。
推薦的軟件質量屬性分類方式：
運行期質量屬性：
性能、安全性、易用性、持續可用性、可伸縮性、互操作性、可靠性、魯棒性（健壯性或容錯性）。
開發期質量屬性：
易理解性、可擴展性、可重用性、可測試性、可維護性、可移植性。
我們可以將運行期質量屬性和功能性一起視爲“軟件的外部質量”，而將開發期質量屬性視爲“軟件的內部質量”。無疑，軟件的內部質量制約着軟件的外部質量。
功能需求影響架構，而架構必須適應功能需求。但功能需求並不能決定架構。倒是質量屬性需求對軟件架構影響更大。反過來，大部分質量屬性需求能否被滿足，也很大程度上依靠軟件架構的設計。約束性需求最特殊，它可能產生的影響有3種：
1、 作爲架構設計時必須遵守的限制條件；
2、 導致軟件系統必須提供某些功能需求；
3、 導致軟件系統必須滿足某些約束性需求。
需求的變更蘊含着風險，因爲不存在不需要成本的需求變更。當然，需求變更也蘊含着機遇。對軟件架構設計而言，這個機遇可能意味着設計出穩定的架構，最終這個架構能夠支持業務功能在一定範圍內“隨需應變”。一般而言，功能需求最易變，而質量需求最穩定。功能需求最容易變化，一是功能需求集中存在少量長期穩定的功能。二是雖然功能的行爲步驟常常變化，但功能點本身趨於穩定。當採用用例技術進行需求捕獲和需求分析時，用例圖往往是相對穩定的（它描述了功能體現），而用例規約則可能頻繁變化（它以交互序列的形式描述功能執行的步驟）。質量屬性需求相對來說最爲穩定。
在需求分析過程中需求不斷地和客戶進行交流，這時客戶非常希望能夠看到給他帶來實感的界面草圖甚至可執行的系統原型。而開發方最擔心的問題是客戶需求的不斷變化，所以他們也希望能夠儘早掌握客戶的真正需求，並希望需求成果得到客戶的確認。在需求分析期間就開始界面設計，並將界面草圖等設計成果用於和客戶的交流當中，這樣可以增加實感、方便交流，並幫助客戶“發現”他真正想要的功能。當然，界面設計的成果並不應該放入《需求文檔》，因爲它們是設計而不是需求。非功能需求的滿足程度對軟件的成功非常關鍵，因此《軟件需求規格說明書》必須系統地描述非功能需求的具體要求。非功能需求大致分爲質量屬性和約束兩大類。
用例技術及應用
我們掌握的知識本身和我們的實踐能力並不成正比。因爲如果不能根據經驗使“頭腦中的知識”和“實踐”真正“匹配”起來，知識就無法轉化成真正的實踐能力。
用例圖描述軟件系統爲用戶或外部系統提供的服務。用例圖最重要的元素是參與者（Actor）和用例（Use Case）。用例的名稱應該從參與者的角度進行描述，並以動詞開頭。用例圖通過確定與本系統的交互的角色或外部系統、描述系統必須提供的功能的方式，清晰地界定了系統的功能範圍（Scope）。用例圖不僅是可視化的，而且是結構良好的、有利於從宏觀上反映系統功能的大局觀。所謂用例描簡述，就是通過簡短的文字對用例的功能進行描述：一般而言，用例簡述應包含成功場景的簡單描述。用例簡述是一項非常輕便的技術，很多敏捷方法都通過類似用例簡述的技術捕獲和交流需求。用例規約是對用例的詳細描述，一般包括簡要說明、主事件流、備選事件流、前置條件、後置條件（後者條件應覆蓋所有可能的用例結束後的狀態。即，後者條件不僅僅是用例成功結束後的狀態，還應該包含用例因發生錯誤而結束後的狀態。）和優先級等。用例規約的主要目的是界定軟件系統的行爲需求（需求可以劃分爲業務需求（組織要達到的目標）、用戶需求（用戶使用系統來做什麼）和行爲需求（開發人員需要實現什麼）三個層次，所謂行爲需求是指系統軟件爲了提供用戶所需要的功能而必須執行哪些行爲）。用例簡述和用例規約都是對用例進行說明的技術，但用例規約要比用例簡述複雜10倍以上。
在面向對象的理論系統中，協作被定義爲“多個對象爲了完成某種目標而進行的交互”。而用例實現的是協作的具體運用：即爲了實現用例定義的功能，我們必須考慮需要哪些類，這些類又如何交互來完成最終的功能。用例實現是從功能需求向設計方案過渡的紐帶。通過分析一組關鍵用例的用例實現，可以獲得未來系統的思想化和職責模型，它的重點是識別組成軟件系統的高級職責塊、規劃它們之間的關係：這個職責模型是規劃架構機制、滿足高質量屬性要求的武器。
用例圖從總體上反映了用戶需求，而用例簡述和用例規約分別是行爲需求的簡化描述和詳細描述。至於用例實現，已經屬於設計的範疇了。
用例方法是以客戶爲中心的。用例方法比傳統的SRS更易於被用戶所理解，是開發人員於用戶之間進行溝通的有效手段之一。用例圖可以從大局上反映系統的功能結構，並且用例圖在很大程度上不會受到需求變更的衝擊——因爲它不涉及需求細節。傳統需求方法採用功能分解方式，非常容易混淆需求和設計的界限，而用例方法有利於解決這個問題。
一個軟件系統，它應當提供哪些功能往往是和業務目標相一致的，而一個企業的業務目標還是相當穩定的。對軟件開發影響巨大的需求變更其實更多地發生在行爲需求層面——用例規約的主事件流和備選事件流正式反映行爲需求。
需求捕獲是知識採集的過程，致力於收集用戶對未來軟件系統的期望和具體要求。有如下的一些技術和手段：“需求採集卡”、“用戶故事卡”、“用例圖+用例簡述”。
需求分析的目的是以比較規範的形式，明確定義軟件系統的要求，顯然用例規約正是一項規範、明確的技術——它通過特定格式的文本來記錄參與者和系統之間的各種情況下的交互場景，以此來明確對軟件系統的行爲需求。需求分析還必須去僞存真、查漏補缺。用例規約技術能幫助需求分析員以用戶爲中心進行思考，定義不同場景下的軟件系統應有的行爲需求。
架構設計不應等到所有用例被細化到用例規約程度纔開始。對架構設計起關鍵作用的功能需求只佔功能需求的一小部分，這部分用例應該已經被細化到用例規約的程度，它們和其他非功能需求一起決定架構設計方案。必須聰明地應付需求變更。需求變更對用例圖和用例簡述的影響比較小，而對用例規約的影響很大。因此我們應該“推後用例細化、激發需求變更”。不是對軟件架構起關鍵作用的用例，可以推遲到要實現該用例所定義的功能之前才進行細化，過早地爲這些用例制定用例規約會增加“需求變更管理”的開銷，使需求變更的影響增大。必須通過不斷增加功能、發佈小版本、提供給用戶試用、接受用戶反饋等一系列的活動。在項目前期不將所有用例細化，而是將大部分用例保持在“用例圖+簡短描述”的水平——這樣做並不影響開發出原型來啓發和確認用戶需求，並可能儘早激發需求變更的發生——直到變更的機率較小的時候甚至到了程序小組要實現該用例的時候，再深入到小組的系統分析員對用例進行細化。（但筆者認爲，這樣做的只時候使用敏捷開發的時候，使用瀑布模型時是顯然不適合的。另外，這樣做也同樣有將問題推遲發生的風險，我們應該儘早的發現問題，和讓問題方式。需求變更的方式，往往是在細節的交流過程中，或用戶看到原型之後出現的。筆者認同識別出關鍵需求就進行架構設計的觀點，但此時應該同時開始其他需求的細化工作）
