引語
第一,你必須弄清問題,第二,找出已知數與未知數之間的聯系.......
-----波利亞,<<怎樣解題>>
那些沒有經驗的問題解決者們,幾乎無一例外,都是去匆忙的尋找解決辦法,而不是先給要解決的問題下定義.
------傑拉爾德.溫伯格,<<你的燈亮着嗎>>
業内對架構的讨論仍沿用了傳統思想;如果知道了系統需求,就可以為此系統建構架構,這種觀點是缺乏遠見的......
------Len Bass,<<軟體構架實踐>>
一、什麼是軟體需求
簡單的說，軟體需求就是"這個軟體到底要為使用者做什麼".
IEEE的軟體工程标準術語需求定義為：
1.使用者所需求的解決某個問題或達到某個目标所需具備的條件或能力。
2.系統或系統元件為符合合同、标準、規範或其他正式文檔而必須滿足的條件或必須具備的能力。
3.上述第一項或第二項中定義的條件和能力的文檔表述。
RUP這樣定義需求的：
需求描述了系統必須滿足的情況或提供的能力，它就可以是直接來自客戶需要，也可以來自合同、标準、規範或其他正規限制力的文檔。
二、軟體需求要做哪些事情呢？
需求捕獲 vs. 需求分析 vs. 系統分析
需求捕獲：是擷取知識的過程，知識從無到有、從少到多。需求采集者必須了解使用者所從事的工作，并且了解使用者和客戶希望軟體系統在哪些方面幫助他們。
成果：一摞“需求采集卡”，其中記錄了需求類型、需求描述、需求背景、需求提出者和需求記錄者等對進一步需求分析非常有用的資訊。
需求分析：是挖掘和整理知識的過程， 它在已掌握知識的基礎上進行。畢竟，初步捕獲到的需求資訊往往處于不同層次，也有一些主觀甚至不正确的資訊。而經過必要的需求分析工作之後，需求會更加系統、更加有條理。更加全面。
成果：《軟體需求規格說明書》(Software Requirements Specification,SRS)，精确地闡述了一個軟體系統必須提供的功能、必須達到的品質屬性以及它必須遵守的限制。SRS應盡可能完整地描述各種條件下的系統行為。
系統分析：針對系統所要面臨的問題，搜集相關的資料，以了解産生問題的原因所在，進而提出解決問題的方法與可行的邏輯方案，以滿足系統的需求，實作預定的目标。
成果：通過結構化分析得到的最重要的工作成果是資料流圖；而面向對象的系統分析方法得到的工作成果主要是分析類圖、魯棒圖、序列圖等--其中分析類圖描述設計的表态方面，而魯棒圖和序列圖描述設計的動态方面。
需求捕獲、需求分析是互相伴随、交叉進行的；需求工作伊始，無疑更多的是進行需求捕獲工作，相伴進行的需求分析工作占的比例偏少，但随着掌握的需求資訊越來越多，我們需要開展的需求的分析和整理工作也越來越多了。
用做什麼和怎麼做來區分分析與設計。需求分析緻力于搞清楚軟體系統要做什麼，而系統分析更關注怎麼做的問題。大多數分析方法（如OOA）應該屬于系統分析的範疇。
需求分析在軟體過程中所處的位置?
概念化階段明确了軟體項目的意義、可行性及概況等。在《願景與範圍文檔》所劃定的大前提的指導下，需求分析活動要進一步完善和細化軟體需求。
需求分析和領域模組化是互相支援的關系。不難了解，要進行領域模組化，很大程度上依賴于需求讨論會等活動。同時，領域模型作為領域模組化的成果，規定了重要的領域詞彙表，并且這麼詞彙的定義是嚴格的、大家共同認可的，是以可以成為團隊交流的基礎，自然也應當作為需求分析活動和《軟體需求規格說明書》應當遵循的标準詞彙。
對于後期的架構設計活動而言，需求分析活動應該提供功能需求、品質屬性以及限制性需求等不同需求的明确定義。軟體架構師将就此開展用例分析、品質屬性分析、細化架構設計等活動。
三、架構師必須掌握的需求知識?
架構師是需求分類、需求折衷和需求變更的研究方面的專家。
需求分類 ：
運作期品質屬性：
性能 (Performance)
安全性 (Security)
易用性 (Usability)
持續可用性 (Availability)
可伸縮性 (Ssclability)
互操作性 (Interoperability)
可靠性 (Reliability)
魯棒性 (Robustness)
開發期品質屬性：
易了解性 (Understand)
可擴充性 (Extensibility)
可重用性 (Reusability)
可測試性 (Testability)
可維護性 (Maintainability)
可移植性 (Portability)
性能 (Performance)。性能是指軟體系統及時提供相應服務的能力。具體而言，性能包括速度、吞吐量和持續高速性三方面的要求：
吞吐量通過機關時間處理的交易數來度量；
速度往往通過平均響應時間來度量；
而持續高速性是指保持調整處理速度的能力。
持續高速性和實時系統有關，實時系統有“硬實時”和“軟實時”之分，其中硬實時系統對每次系統響應時間都有嚴格要求，如果不能滿足要求，後果将是緻命的，是以把性能籠統地說成“進行典型操作所需的時間”顯然忽視了實時的系統性能的内涵。
效率（Efficiency）和性能的關系：它們反映了同一問題的“表”、“裡”兩面，性能為“表”，效率為“裡”，所謂效率，是指軟體系統對CPU處理能力和存儲能力這兩大類計算機資源的使用效率。
安全性（Security）。指軟體系統同時兼顧向合法使用者提供服務，以及阻止非授權使用者的能力。高安全性意味着“同時兼顧”，這是因為有些攻擊的目的是使軟體系統拒絕向合法使用者提供服務，而不是非法通路。
易用性（Usability）。不少文獻也稱為可用性，但為了避免和持續可用性（Availability）混淆，本文采用非常流行的“易用性”的叫法。指軟體系統易于使用的程度。
持續可用性（Availability）。不少文獻也稱為可用性，為避免和易用性（Usability）混淆，本文采用“持續可用性”的叫法。持續可用性指系統長時間無故障運作的能力。
可伸縮性（Scalability）。指當使用者資料量增加時，軟體系統維持高服務品質的能力。例如當業務量較小時，軟體系統運作在一台伺服器上，當業務量增大時，可以通過增加伺服器或者增加單台伺服器上所運作軟體系統的個數來提高性能，而無需對軟體系統本身進行程式設計級的修改。
互操作性（Interoperability）。指本軟體系統與其他系統交換資料和互相調用服務的難易程度。
可靠性（Reliability）。軟體系統在一定的時間内無故障運作的能力。
魯棒性（Robustness）。也稱健壯性、容錯性。魯棒性是指軟體系統在以下情況下仍能夠正常運作的能力；使用者進行了非法操作，相連的軟硬體系統發生了故障，以及其他非正常情況。
開發期品質屬性則随着軟體系統規模的日益增長，顯得越來越重要了，下面做一下說明。
易了解性（Understandability）。尤指設計被開發人員了解的難易程度。
可擴充性（Extensibility）。為适應新需求或需求的變化為軟體增加功能的能力。我們在實際工作中，經常将可擴充性稱為靈活性。
可重用性（Reusability）。重用軟體系統或其一部分的能力的難易程度。
可測試性（Testability）。對軟體測試以證明其滿足需求規約的難易程度。在實際工作中主要指進行單元測試、插樁測試等的難易程度。
可維護性（Maintainability）。為了達到下列三種目的之一，而定位修改點并實施修改的難易程度：修改Bug、增加功能、提高品質屬性。
可移植性（Portability）。将軟體系統從一個運作環境轉移到另一個不同的運作環境的難易程度。
務實地，我們可以将運作期品質屬性和功能性一起視為“軟體的外部品質”，而将開發期品質屬性視為“軟體的内部品質”。無疑，軟體的内部品質制約着軟體的外部品質；在軟體開發管理本身已經十分複雜的今天，想使内部品質很差的軟體具有良好的外部品質幾乎是不可能的。同時，随着商業環境變化的加劇，很多企業軟體出現了“建成即廢棄”的尴尬情況，于是，軟體系統的内部品質越來越受到重視，通過強化軟體系統的可擴充性、可重用性、易了解性等開發期品質屬性，可以使軟體更多被被改變、被重用的空間。
各類需求對架構設計的不同影響
功能需求影響架構，而架構必須适應功能需求。但功能需求并不能決定架構，這是顯而易見的。因為如果僅為了滿足功能需求而進行架構設計，那麼設計結果幾乎是毫無限制的，基本于接口程式設計還是統統寫死到實作都能實作功能需求，分不分層，以及如何分層似乎也無不同。
倒是品質屬性對軟體架構影響更大。例如，為了獲得高可移植性，架構設計中必須考慮對硬體和平台相關特性進行封閉和隔離。再例如，精心規劃職責模型是獲得高性能的根本，這就是為什麼“将性能放在首位的軟體系統”有時其架構與衆不同的原因。
反過來，大部分品質屬性需求能否被滿足，也很大程度上依靠軟體架構的設計。
限制性需求最為特殊，它可能産生的影響有三種：
1.作為架構設計時必須遵守的限制條件。
2.導緻軟體系統必須提供某些功能需求。
3.導緻軟體系統必須滿足某些限制性需求。
各類需求的“易變更性”不同