需求分析

在 IT 中，需求分析是系統開發過程的一部分（除其他事項外，還包括需求管理）和業務分析的一部分。 目的是確定、構造和檢查客戶對要開發的系統的要求。 需求分析的結果通常記錄在規范中，或者在敏捷軟件開發的情況下，這會導致產品積壓。

xxx的組織為需求分析命名了以下組件：

根據IEEE，需求工程可以分為：

• 需求啟發，
• 需求分析，
• 需求規范和
• 需求驗證

這些活動重疊，并且經常重復進行多次。

卡內基梅隆大學軟件工程研究所 (SEI) 在其能力成熟度模型中區分了集成

• 需求的演變和
• 需求管理。

在羅伯遜開發的 Volere 程序模型中存在

• 需求規范，
• 利益相關者分析，
• 需求分析，
• 分析優先級和
• 記錄基本要求。

國際商業分析學會 (IIBA) 在商業分析知識體系 (BABOK) 中列出了關于此主題的三個章節：

• 需求獲取：確定利益相關者的需求，
• 需求管理 溝通：管理和溝通需求，識別可重復使用的需求，組裝需求，準備批準需求，管理需求變更，
• 需求分析：確定需求的優先級和結構，以文本形式記錄需求，用圖形/模型記錄需求，檢查內容質量，檢查是否符合目標。

國際需求工程委員會 (IREB) 在需求工程認證專家 (CPRE) 認證的教科書中列出了關于此主題的四個章節：

• 發現：需求發現使用多種技術從利益相關者和其他來源提取、細化和優化需求。
• 文檔：文檔中充分描述了要求。
• 審查和協調：必須在早期階段審查和協調記錄的要求，以確保它們滿足所有要求的質量標準。
• 管理：需求管理與所有其他活動一起進行，包括構建需求、為不同角色做好準備以及一致地更改和實施需求所需的所有措施。

在所有上述模型中，以下步驟以一種或另一種形式存在。 需求收集（英文啟發）； 通過分析，建立共識； 要求以文本或模型的形式記錄， 之后，通常會檢查整個事情是否仍然一致（驗證）。 圍繞這些步驟存在過程的管理和管理。

記錄后，需求必須結構化和分類。 這確保了需求變得更加清晰。 這反過來又增加了對需求之間關系的理解。 這里的標準是：

必須檢查依賴需求以確定一個需求是否是另一個需求的先決條件，它們是否相互依賴或者它們是否可以獨立實現。相關需求在邏輯上和專業上屬于一起的不應單獨實現。角色相關的每個用戶組都有自己對需求的看法，應該支持，看用戶角色。

其他結構化選項是功能性和非功能性需求，以及專業動機（專業和技術）和技術動機（僅技術）的需求。 以這種方式構建的需求必須在客戶和開發人員之間達成一致。 如有必要，這種協調可以成為一個迭代過程，從而導致需求的細化。

在構建之后，有時與此同時，根據質量特性對需求進行質量保證：

正確的要求必須相互一致。看可行性。必要的，客戶沒有要求的不是要求。優先考慮的，必須明確哪些要求是最重要的。 確定優先級的目的是先提供經常需要或對客戶特別重要的功能，然后再提供不太經常需要的功能。 它是通過量化功能分支來實現的。可用的，有用的，即使是部分實施，也應該已經創建了一個生產系統。

測試結果構成規范的基礎，評估有時會相互競爭。 只實現高優先級的任務并不會自動產生一個高效的系統。 評價時，不僅要考慮單個功能本身，還要考慮它在整個系統中的作用。