需求分析是軟體定義時期的最後乙個階段。
需求分析的基本任務：
準確地回答「系統必須做什麼」這個問題。
需求分析的任務還不是確定系統怎樣完成它的工作，而僅僅是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求 。
在需求分析階段結束之前，系統分析員應該寫出軟體需求規格說明書，以書面形式準確地描述軟體需求。
儘管目前有許多不同的用語需求分析的結構化分析方法，但是，所有這些分析方法都遵守下述準則：
（1）必須理解並描述問題的資訊域，根據這條準則應該建立資料模型。
（2）必須定義軟體應完成的功能，這條準則要求建立功能模型。
（3）必須描述作為外部事件結果的軟體行為，這條準則要求建立行為模型。
（4）必須對描述資訊、功能和行為的模型進行分解，用層次的方式展示細節。
3.1需求分析的任務
3.1.1確定對系統的綜合要求
雖然功能需求是對軟體系統的一項基本需求，但卻並不是唯一的需求。通常對軟體系統有下述幾方面的綜合要求：
1.功能需求
這方面的需求制定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能。
2.效能需求
效能需求制定系統必須滿足的定時約束或容量約束。
3.可靠性和可用性需求
可靠性需求定量地制定系統的可靠性。
可用性與可靠性密切相關，它量化了使用者可以使用系統的程度。
4.出錯處理需求
這類需求說明系統對環境錯誤應該怎樣響應。
5.介面需求
介面需求描述應用系統與它的環境通訊的格式。常見的介面需求有：使用者介面需求；硬體介面需求；軟體介面需求；通訊介面需求。
6.約束
設計約束或實現約束描述在設計或實現應用系統時應遵守的限制條件。常見的約束有：精度；工具和語言約束；設計約束；應該使用的標準；應該使用的硬體平台。
7.逆向需求
逆向需求說明軟體系統不應該做什麼。
8.將來可能提出的需求
應該明確地列出那些雖然不屬於當前系統開發範疇，但是根據分析將來很可能會提出來的需求。這樣做的目的是，在設計過程中對系統將來可能的擴充和修改項做準備，以便一旦確實需要時能比較容易地進行這種擴充和修改。
3.1.2分析系統的資料要求
分析系統的資料要求通常採用建立資料模型的方法。
3.1.3匯出系統的邏輯模型
綜合上述兩項分析的結果可以匯出系統的詳細的邏輯模型，通常用資料流圖、實體聯絡圖（er圖）、狀態轉換圖、資料字典和主要的處理演算法描述這個邏輯模型。
3.1.4修正系統開發計畫
根據在分析過程中獲得的對系統的更深入更具體的了解，可以比較準確地估計系統的成本和進度，修正以前制定的開發計畫。
3.2與使用者溝通獲取需求的方法
3.2.1訪談
訪談是最早開始使用的獲取使用者需求的技術，也是迄今為止仍然廣泛使用的需求分析技術。
訪談有兩種基本形式，分別是正式的和非正式的訪談。正式訪談時，系統分析員將提出一些事先準備好的具體問題。在非正式訪談中，分析員將提出一些使用者可以自由回答的開放性問題，以鼓勵被訪問人員說出自己的想法。
情景分析技術
情景分析技術的用處主要體現在下述兩個方面：
（1）他能在某種程度上演示目標系統的行為，從而便於使用者理解，而且還可能進一步揭示出一些分析員目前還不知道的需求。
（2）由於情景分析較易為使用者所理解，使用這種技術能保證使用者在需求分析過程中始終扮演乙個積極主動的角色。需求分析的目標是獲知使用者的真實需求，而這一資訊的唯一**是使用者，因此，讓使用者起積極主動的作用對需求分析工作獲得成功是至關重要的。
3.2.3簡易的應用規格說明技術
這種方法提倡使用者與開發者密切合作，共同標識問題，提出解決方案要素，商討不同方案並指定基本需求。
使用簡易的應用規格說明技術分析需求的典型過程如下：
①進行初步的訪談，通過使用者對基本問題的回答，初步確定待解決的問題的範圍和解決方案。
②開發者和使用者分別寫出「產品需求」。
3.3分析建模與規格說明
3.3.1分析建模
為了更好地理解複雜事物，人們常常採用建立事物模型的方法。所謂模型，就是為了理解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。
需求分析過程中應該建立3種模型，它們分別是資料模型、功能模型、行為模型。
3.3.2軟體需求規格說明
通過需求分析出了建立分析模型之外，還應該寫出軟體需求規格說明書，它是需求分析階段得出的最主要的文件。
通常用自然語言完整、準確、具體地描述系統的資料要求、功能需求、效能需求。可靠性和可用性要求、出錯處理需求、介面需求、約束、逆向需求以及將來可能提出的需求。
3.4實體-聯絡圖
為了把用弧度資料要求清楚、準確地描述出來，系統分析員通常建立乙個概念性的資料模型（也稱為資訊模型）。概念性資料模型是一種面向問題的資料模型，是按照使用者的觀點對資料建立的模型。它描述了從使用者角度看到的資料，它反映了使用者的現實環境，而且與在軟體系統中的實現方法無關。
資料模型中包含3種相互關聯的資訊：資料物件、資料物件的屬性及資料物件彼此間相互連線的關係。
3.4.1資料物件
資料物件是對軟體必須理解的附和資訊的抽象。所謂復合資訊是指具有一系列不同性質或屬性的事物，僅有單個值的事物（例如寬度）不是資料物件。
資料物件可以是外部實體。總之，可以由一組屬性來定義id實體都可以被認為是資料物件。
資料物件彼此間是有關聯的。
資料物件之封裝了資料而沒有對施加於資料上的操作的引用，這是對資料物件與物件導向范型中的「類」或「物件」的顯著區別。
3.4.2屬性
屬性定義了資料物件的性質。
應該根據對所要解決的問題的理解，來確定特定資料物件的一組合適的屬性。
3.4.3聯絡
客觀世界中的事物彼此間往往是有聯絡的。
資料物件彼此之間相互連線的方式稱為聯絡，也稱為關係。聯絡可分為以下3中型別：
（1）一對一聯絡（1：1）
（2）一對多聯絡（1：n）
（3）多對多聯絡（m：n）
聯絡也可能有屬性。
3.4.4實體-聯絡圖的符號
通常，使用實體-聯絡圖（entity-relationship diagram）來建立資料模型。可以把實體-聯絡圖簡稱為er圖，相應地可把用er圖描繪的資料模型稱為er模型。
er圖中包含了實體（即資料物件）、關係和屬性3中基本成分，通常用矩形框代表實體，用連線相關實體的菱形框標識關係，用橢圓型或圓角矩形標識實體（或關係）的屬性，並用直線把實體（或關係）與其屬性連線起來。
3.5資料規範化
軟體系統經常使用各種長期儲存的資訊，這些資訊通常以一定方式組織並儲存在資料庫或檔案中，為減少資料冗餘，避免出現插入異常或刪除異常，簡化修改資料的過程，通常需要把資料結構規範化。
通常用「正規化（normal forms）」定義消除資料冗餘的程度。第一正規化（1nf）資料冗餘程度最大，第五正規化（5nf）資料冗餘程度最小。但是，第一，正規化級別越高，儲存同樣資料就需要分解成更多張表，因此，「儲存自身」的過程也就越複雜。第二，隨著正規化級別的提高，資料的儲存結構與機遇問題域的結構間的匹配程度也隨之下降，因此，在需求變化時資料的穩定性較差。第三，正規化級別提高則需要訪問的表增多，因此效能（速度）將下降。從實用角度看來，在大多數場合選用第三正規化都比較恰當。
通常按照屬性間的依賴情況區分正規化化的程度。下面給出第
一、第二和第三正規化的定義：
（1）第一正規化 每個屬性值都必須是原子值，即僅僅是乙個簡單值而不含內部結構。
（2）第二正規化 滿足第一正規化條件，而且每個非關鍵字屬性都由整個關鍵字決定（而不是由關鍵字的一部分來決定）
（3）第三正規化 符合第二正規化的條件，每個非關鍵字屬性都僅由關鍵字決定，而且乙個非關鍵字屬性不能僅僅是對另乙個非關鍵字屬性的進一步描述（即乙個非關鍵字屬性值不依賴於另乙個非關鍵字屬性值）。
3.6狀態轉換圖
狀態轉換圖（簡稱為狀態圖）通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行為。
3.6.1狀態
狀態是任何可以被觀察到的系統行為模式，乙個狀態代表系統的一種行為模式。
在狀態圖中定義的狀態主要有：初態（即初始狀態）、狀態（即最終狀態）和中間狀態。在一張狀態圖中只能有乙個初態，而終態則可以有0至多個。
狀態圖既可以表示系統迴圈執行過程，也可以表示系統單程生命期。
3.6.2事件
事件是在某個特定時刻發生的事情，它是對引起系統做動作或（和）從乙個狀態轉換到另乙個狀態的外界事件的抽象。簡而言之，事件就是引起系統做動作或（和）轉換狀態的控制資訊。
3.6.3符號
在狀態圖中，初態用實心圓表示，終態用一對同心圓（內圓為實心圓）表示。
中間狀態用圓角矩形表示，可以用兩條水平橫線把它劃分成上、中、下3個部分。上部分為狀態的名稱，這部分是必須的；中間部分為狀態變數的名字和值，這部分是可選的；下面部分是活動表，這部分也是可選的。
3.8驗證軟體需求
軟體需求的驗證從以下4個方面：
（1）一致性
所有需求必須是一直的，任何一條需求不能和其他需求互相矛盾。
（2）完整性
需求必須是完整的，規格說明書應該包含使用者需求的每乙個功能或效能。
（3）現實性
指定的需求應該是用現有的硬體技術和軟體技術基本上可以實現的。
（4）有效性
必須證明需求是正確有效的，確實能解決使用者面對的問題。
《軟體工程》第三章
軟體專案特徵 軟體產品的不可見性 專案的高度不確定性 軟體過程的多變化性 軟體人員的高流動性。有效的軟體管理集中於 人員 產品 過程 專案。軟體專案的生命週期 專案啟動 專案規劃 專案實施 專案收尾 在大多數軟體專案中，民主式 主程式設計師式 技術管理式是三種典型的開發組織方式。微軟公司採取靈活高效...
工程導論第三章
工程與技術的關係 工程依賴技術的發展，技術是實現工程的手段。其二，技術比工程更依賴科學的發展。由此可見，兩者的關係十分密切，但是相較於工程，技術對於科學發展的依賴性更強。工程技術的傳統學科很多,大家最熟悉的因該是土木工程，但其實還有很多這樣的工程學科，我們舉一些例子 建築工程 機械工程 電氣工程 化...
工程導論第三章
第三章 需求分析 分析方法都應該遵守以下準則 1 必須理解並且描述問題的資訊域，根據這條準則建立資料模型。2 必須定義軟體應該完成的功能，這條準則要求建議功能模型。3 必須描述作為外部事件結果的軟體行為，這條準則要求建立行為模型。4 必須對描述資訊，功能和行為的模型進行分解，用層次的方式細節。需求分...