本文內容來自於對《軟件工程導論》（第6版，張海潘 牟永敏 編著），僅爲個人學習記錄。如涉及版權問題請版權方聯繫我。
需求分析是軟件定義時期的最後一個階段。
需求分析的基本任務：準確地回答“系統必須做什麼”這個問題。
需求分析的任務還不是確定系統怎樣完成它的工作，而僅僅是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求 。
在需求分析階段結束之前，系統分析員應該寫出軟件需求規格說明書，以書面形式準確地描述軟件需求。
儘管目前有許多不同的用語需求分析的結構化分析方法，但是，所有這些分析方法都遵守下述準則：
（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）有效性
必須證明需求是正確有效的，確實能解決用戶面對的問題。
本文內容來自於對《軟件工程導論》（第6版，張海潘 牟永敏 編著），僅爲個人學習記錄。如涉及版權問題請版權方聯繫我。