需求的類型
軟件需求包括三個不同的層次──業務需求、用戶需求和功能需求。 除此之外，每個系統還有各種非功能需求。
業務需求（BusinessRequirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麽要開發壹個系統，即組織希望達到的目標。使用前景和範圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。 用戶需求（UserRequirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什麽。
功能需求（Functional Requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什麽。
非功能需求（Non-functional Requirement） 定義了軟件產品為滿足用戶業務需求而必須具有的除功能需求以外的特性。包括系統的完整性（聯機幫助、 數據管理、用戶管理、軟件發布管理、在線升級等）、性能、可靠性、可維護性、可擴充性、對技術和業務的適應性等。
需求分析的任務
1 解決的問題
1) 齊全、準確地找出目標系統全部的功能、性能、限制； 2) 找出全部的輸入流、輸出流； 3) 找出所有的加工；
4) 產生完整的分層的DFD、數據字典、加工的描述； 5) 補充的意見。
2 綜合要求
確定對系統的綜合要求，系統功能要求，系統性能要求，運行要求，將來可能提出的要求。
3 任務
圖1為需求分析任務圖，需求分析階段要完成的具體明確的最終任務就是形成壹份經開發方和用戶認可或達成***識的軟件需求分析文檔（需求規格說明書、修改後的項目開發計劃、初步的用戶手冊、確認測試計劃、數據要求說明書）。這個文檔能清晰準確地說明系統將要開發什麽，能夠規定出詳細的技術需求，包括所有面向用戶、面向機器和其它軟件系統的接口。可以說需求文檔在開發過程中壹直起指導作用。
為了更好地完成軟件開發第壹階段的需求分析任務，提高質量，需求管理是必不可少的。
需求管理的目的是在客戶與開發方之間建立對需求的***同理解，維護需求與其他工作成果的壹致性，並控制需求的變更，主要體現在跟蹤和控制需求變更管理。需求管理是開發工作有效進行的保證，是壹種很高層次的系統行為，涉及整個開發過程和產品本身。
需求分析的方法
需求分析方法由對軟件問題的信息域和功能域的系統分析過程及其表示方法組成，大多數的需求分析方法是由信息驅動的。信息域具有三種屬性： 信息流、信息內容和信息結構。
常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向數據結構的Jackson方法（JSD），面向數據結構的結構化數據系統開發方法（DSSD），面向對象的分析方法（OOA）等。選擇那種方法要根據哪些資源在什麽時間對開發人員有效，不能盲目套用。這裏著重闡述面向數據流的結構化分析方法（SA）。
面向數據流的結構化分析方法
面向數據流的結構化分析方法（Structured Analysis，簡稱SA），是面向數據流進行需求分析的方法，是需求分析使用最多的方法之壹。 SA也是壹種建模活動，該方法使用簡單易讀符號，根據軟件內部數據傳遞、變換的關系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。適用於數據處理類型軟件的需求分析，這壹方法除了簡單，容易掌握之外，還能和設計階段的結構化設計（SD）銜接，從而取得良好的設計結果。
自頂向下逐層分解的分析策略
SA方法的基本手段：“分解”和“抽象”。這是系統開發技術中控制復雜性的兩種手段。它先將系統“抽象”成壹個模型，此模型是有輸入和輸出並有系統名稱的盒子，然後打開這個盒子，對它進行逐層分解，直到能被理解，可以實現為止。因此分析的策略是自頂向下，逐層加細，由抽象到具體的過程。如圖2。
結構化分析方法使用工具
SA方法利用圖形等半形式化的描述方式表達需求，簡明易懂，用它們形成需求規格說明書中的主要部分。描述工具是
1) 數據流圖：描述系統由哪幾部分組成，各部分之間有什麽聯系等等。 2) 數據字典：定義了數據流圖中每壹個圖形元素。
3) 描述加工邏輯的結構化語言、判定表、判定樹：詳細描述數據流圖中不能被再分解的每壹個加工。
由於分析中的主要依據是數據傳遞及數據變換所形成的數據流，所以結構化分析壹般采用的方法是使用數據流圖的分析方法，最終結果是產生需求規格說明書，該文檔包括壹套數據流圖，對數據流圖中的成分進行定義的壹本數據字典及對加工邏輯的描述。
結構化分析步驟
用結構化分析方法進行系統需求分析的具體步驟是： 1) 了解當前系統的工作流程，獲得當前系統的物理模型。通過對當前系統的詳細調查，了解當前系統的工作過程，同時收集資料、文件、數據、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用壹個模型來反映自己對當前系統的理解，如畫系統流程圖。
2) 抽象出當前系統的邏輯模型。物理模型反映了系統“怎麽做”的具體實現，去掉物理模型中非本質的因素，抽取出本質的因素，構造出當前系統的邏輯模型，反映了當前系統“做什麽”的功能。
3) 建立目標系統的邏輯模型。分析、比較目標系統與當前系統邏輯上的差別，明確目標系統到底要“做什麽”，從而從當前系統的邏輯模型導出目標系統的邏輯模型。
4) 作進壹步補充和優化。為了對目標系統做完整的描述，還需要對得到的邏輯模型做壹些補充。
說明目標系統的人機界面。
說明至今尚未詳細考慮的細節（包括出錯處理、系統的啟動與結束、系統的輸入/輸出和系統性能方面的需求等）。
其他（系統特有的其他必須滿足的性能和限制，也需要用適當的形式做出書面記錄。 分析階段結束時，系統分析員必須和用戶再次認真地審查系統文件，爭取在系統開始設計之前，盡可能地發現其中存在的壹些錯誤並及時糾正，直至用戶確認這個模型表達了他們的要求後，系統文件（軟件需求規格說明書等）才作為用戶和軟件開發人員之間的“合同”而最後得到確定。
結構化分析方法的優缺點
1) 優點： 結構化分析方法是軟件需求分析中公認的、有成效的、技術成熟的、使用廣泛的壹種方法，它較適合於開發數據處理類型軟件的需求分析，該方法利用圖形等半形式化工具表達需求，簡明易讀，也易於使用，為後壹階段的設計、測試、評價提供了有利條件。 2) 缺點：① 傳統的SA方法主要用於數據處理方面的問題，主要工具DFD體現了系統“做什麽”的功能，但它僅是壹個靜態模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統。② 上世紀60年代末出現的數據庫技術，使許多大型數據處理系統中的數據都組織成數據庫的形式，SA方法使用DFD在分析與描述“數據要求”方面是有局限的，DFD應與數據庫技術中的實體聯系圖(ER圖)結合起來(如同IDEF0功能模型與IDEF1信息模型相結合壹樣)。ER圖能增加對數據存儲的細節以及數據與數據之間，數據與處理過程之間關系的理解，還解決了在DD中所包含的數據內容表示問題，這樣才能較完整的描述用戶對系統的需求。③ 對於壹些頻繁的人機交互的軟件系統，如飛機訂票、銀行管理等系統，用戶最關系的是如何使用它，輸入命令、操作方式、系統響應方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統的需求，SA方法往往對這壹部分用自然語言作補充。④ 描述軟件需求的精確性有待提高。 5 需求的變更
在開發項目過程中，用戶隨時會提出壹些新的需求，要求開發方解決，這些需求的提出，有時在開發階段中有時在開發階段後。這種在需求分析的兩個相鄰子階段中，或者在叠代周期的需求分析中，後壹段或周期的需求分析結果與前壹次不壹致，我們把這種不壹致稱為需求變更。產生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發方與用戶的溝通不夠。在需求分析階段，開發方與用戶沒有很好的交流，開發方就根據用戶提供的大概信息，自己推導出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠，導致用戶提出更改需求。2) 項目的實施周期過長。隨著時間的推移，用戶對整個系統的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術更新過快。由於技術的快速更新， 企業可能引進壹些新的設備， 而這些設備可能就會與我們的目標系統有直接的關系， 由於這壹變化可能發生在解決用戶原先問題之前或者之中，那麽開發方不得不加入這壹新的需求。[3]
為了盡可能地避免發生需求變更，以及保證需求分析的高穩定性，可以采用以下方法：1) 分工明確，系統分析員和程序員各有不同的職責。系統分析員處在用戶和程序員之間，溝通用戶和開發人員的認識和見解。系統分析員壹方面要協助用戶對所開發的軟件提出需求，另壹方面還要和程序員充分交換意見，探討其合理性和實現的可能性。如圖3所示，系統分析員在需求分析階段起著重要的作用。
2) 開發方與用戶進行協作和交流。在用戶提出需求變更時系統分析員應該認真聽取用戶的要求並加以整理和分析。分析需求變更的原因並提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發帶來的不良後果。3) 合同約束。由於需求變更可能會對整個項目產生影響，所以，開發方和用戶在簽定項目合同時，可以對需求變更增加壹些相關的合同條款。4) 建立需求文檔並進行版本控制。需求分析的最終成果是壹份客戶和開發方對所開發的產品達成***識的系統文檔。有了這份文檔， 即使開發方人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次的需求變更都用壹個新的版本來標識。5) 需求評審和設立需求基線。為了讓開發方詳細了解用戶的需求，讓不同人員從不同的角度對需求進行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進行最後確認的機會，可以有效減少需求變更的發生。需求在通過正式評審和批準之後，應該確定需求基線，進壹步的需求變更將在此基線的基礎上，依照項目定義的變更過程進行。設置需求基線可以將變更引起的麻煩減至最小。
軟件架構（software
architecture）是壹系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。 軟件架構是壹個系統的草圖。軟件架構描述的對象是直接構成系
統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向
對象領域中，組件之間的連接通常用接口_(計算機科學)來實現。
軟件體系結構是構建計算機軟件實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎壹樣，壹個軟件架構師或者系統架構師陳述軟件構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟件構架是壹個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的壹方面，它集中於某些具體的特征。
在“軟件構架簡介”中，David Garlan 和 Mary Shaw
認為軟件構架是有關如下問題的設計層次：“在計算的算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結
構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。
但構架不僅是結構；IEEE Working Group
on Architecture 把其定義為“系統在其環境中的最高層概念”。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式。它並不僅註
重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時註重對外部的考慮。
在Rational Unified Process 中，軟件系統的構架（在某壹給定點）是指系統重要構件的組織或結構，這些重要構件通過接口與不斷減小的構件與接口所組成的構件進行交互。
從和目的、主題、材料和結構的聯系上來說，軟件架構可以和建築物的架構相比擬。壹個軟件架構師需要有廣泛的軟件理論知識和相應的經驗來事實和管
理軟件產品的高級設計。軟件架構師定義和設計軟件的模塊化，模塊之間的交互，用戶界面風格，對外接口方法，創新的設計特性，以及高層事物的對象操作、邏輯
和流程。
壹般而言，軟件系統的架構（Architecture）有兩個要素：
它是壹個軟件系統從整體到部分的最高層次的劃分。
壹個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-flow）。
所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和
聯結器完成某壹項需求。
建造壹個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
建造壹個系統之前會有很多的重要決定需要事先作出，而壹旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。
對於較大的通常應用應該使用框架，可能節省不少時間.。能使妳很輕松的開發出壹款軟件來。