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