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