軟體工程/規劃/需求簡介

需求分析是系統工程和軟體開發流程的第一個階段。

需求分析 在系統工程和軟體工程中，包括確定新產品或更改產品的需求或條件所需的任務，同時考慮到各種利益相關者（如受益者或使用者）之間可能相互衝突的需求。

需求分析對開發專案的成功至關重要。 需求必須有文件記錄、可操作、可衡量、可測試、與已識別的業務需求或機會相關，並且定義到足以進行系統設計的細節級別。需求可以是架構性的、結構性的、行為的、功能性的和非功能性的。

概述

從概念上講，需求分析包括三種類型的活動

• 需求收集：與客戶和使用者溝通以確定他們的需求的任務。這有時也稱為需求收集。
• 需求分析：確定所述需求是否不清楚、不完整、模稜兩可或矛盾，然後解決這些問題。
• 記錄需求：需求可以以各種形式記錄，例如自然語言文件、用例、使用者故事或流程規範。

需求分析可能是一個漫長而艱鉅的過程，在此過程中會涉及許多微妙的心理技巧。新系統會改變人們之間環境和關係，因此必須識別所有利益相關者，考慮到他們的所有需求，並確保他們瞭解新系統的含義。分析師可以使用多種技術從客戶那裡獲取需求。從歷史上看，這包括進行訪談或進行焦點小組（在這個語境中更恰當地稱為需求研討會）以及建立需求清單。更現代的技術包括原型設計和用例。在必要時，分析師將使用這些方法的組合來確定利益相關者的確切需求，以便生產出滿足業務需求的系統。

需求工程

系統需求分析也稱為需求工程。 有時它被鬆散地稱為需求收集、需求捕獲或需求規範。術語需求分析也可以專門用於分析本身，而不是需求的收集或記錄，例如。需求工程可以分為離散的時間步驟

• 需求收集，
• 需求分析和協商，
• 需求規範，
• 系統建模，
• 需求驗證，
• 需求管理。

Laplante (2007) 認為需求工程是“系統工程和軟體工程的一個分支，它關注確定硬體和軟體系統的目標、功能和約束”。 在某些生命週期模型中，需求工程過程從可行性研究活動開始，該活動會導致可行性報告。如果可行性研究表明應開發該產品，則可以開始需求分析。如果需求分析先於可行性研究，這可能會促進跳出框框的思考，那麼在最終確定需求之前，應確定可行性。

需求分析主題

利益相關者識別

請參閱利益相關者分析，瞭解業務用途。利益相關者 (SH) 是對系統有合法利益的人或組織（如公司、標準機構等法律實體）。他們可能會直接或間接地受到系統的影響。1990 年代的主要新重點是關注利益相關者的識別。人們越來越認識到，利益相關者不僅限於僱用分析師的組織。其他利益相關者將包括

• 任何作業系統的人員（正常操作員和維護操作員）
• 任何從系統中受益的人員（功能性、政治性、財務性和社會性受益者）
• 任何參與購買或採購系統的人員。在大眾市場產品組織中，產品管理、營銷和有時銷售部門充當替代消費者（大眾市場客戶）來指導產品開發
• 監管系統各個方面的組織（財務監管機構、安全監管機構和其他監管機構）
• 反對系統的人或組織（負面利益相關者；另請參見誤用案例）
• 負責與正在設計的系統進行介面的系統組織
• 與分析師為其設計系統的組織進行水平整合的組織

利益相關者訪談

利益相關者訪談是需求分析中常用的技術。儘管它們通常本質上是特異性的，並且專注於利益相關者的觀點和感知需求，但通常沒有更大的企業或系統背景，但這種視角缺陷通常具有獲得更深入瞭解利益相關者獨特業務流程、與決策相關的業務規則和感知需求的優勢。因此，該技術可以作為一種手段來獲取通常不會在聯合需求開發會議中獲得的集中知識，在這些會議中，利益相關者的注意力被迫承擔更多跨職能的背景。此外，訪談的面對面性質提供了一個更輕鬆的環境，可以詳細探討思路。

聯合需求開發 (JRD) 會議

需求通常具有跨職能的影響，這些影響是單個利益相關者不知道的，並且在利益相關者訪談期間經常被遺漏或定義不完整。這些跨職能的影響可以透過在受控環境中進行 JRD 會議來引出，由訓練有素的協調員主持，利益相關者參與討論以引出需求，分析其細節並發現跨職能的影響。應有專門的記錄員和業務分析師在場記錄討論。利用訓練有素的協調員的技能來指導討論，使業務分析師能夠專注於需求定義過程。

JRD 會議類似於聯合應用設計會議。前者，會議收集指導設計的要求，而後者收集滿足收集到的需求的特定設計功能。

合同式需求清單

記錄需求的一種傳統方法是合同式需求清單。在複雜的系統中，此類需求清單可能長達數百頁。

一個合適的比喻是一個非常長的購物清單。這些清單在現代分析中非常不受歡迎；因為它們在實現其目標方面非常失敗；但它們至今仍被視為。

優勢

• 提供需求清單。
• 為專案發起人（人）和開發人員提供一份合同。
• 對於大型系統，可以提供高級別的描述。

劣勢

• 此類清單可能長達數百頁。實際上不可能通讀此類文件並對系統有連貫的理解。
• 此類需求清單抽象了所有需求，因此幾乎沒有上下文。

• 這種抽象使得無法瞭解需求如何擬合或協同工作。
• 這種抽象使得難以正確地優先考慮需求；雖然清單確實可以輕鬆地優先考慮每個單獨的專案，但從上下文中刪除一個專案可能會使整個用例或業務需求變得毫無用處。
• 這種抽象增加了誤解需求的可能性；隨著更多人閱讀它們，對設想系統的（不同）解釋的數量會增加。
• 這種抽象意味著很難確定是否擁有大多數需求。這些文件必然會籠統地描述；但正如人們常說的，細節決定成敗。

• 這些清單在利益相關者和開發人員之間創造了一種虛假的相互理解。
• 這些合同風格的清單讓利益相關者產生一種錯誤的安全感，認為開發人員必須實現某些東西。但是，由於這些清單的性質，它們不可避免地會錯過在流程後期發現的關鍵需求。開發人員可以使用這些發現的需求來重新協商對他們有利的條款和條件。
• 這些需求清單對系統設計沒有任何幫助，因為它們不適合應用。

需求清單的替代方案

作為大型預定義需求清單的替代方案，敏捷軟體開發使用使用者故事以日常語言來定義需求。

可衡量的目標

最佳實踐將編制的需求清單僅僅視為線索，並反覆詢問“為什麼？”直到發現實際的業務目的。利益相關者和開發人員然後可以設計測試來衡量到目前為止每個目標的實現程度。此類目標的變化速度比一長串具體但未衡量的需求慢得多。一旦建立了一小組關鍵的可衡量目標，就可以進行快速原型設計和短迭代開發階段，從而在專案完成一半之前就交付實際的利益相關者價值。

原型

在 1980 年代中期，原型被認為是解決需求分析問題的最佳解決方案。原型是應用程式的模型。模型允許使用者視覺化尚未構建的應用程式。原型幫助使用者瞭解系統的外觀，並使使用者更容易做出設計決策，而無需等待系統構建。隨著原型的引入，使用者和開發人員之間通訊的重大改進經常被看到。對應用程式的早期觀點導致後期更改較少，因此大大降低了總體成本。

然而，在接下來的十年中，雖然證明是一種有用的技術，但原型並沒有解決需求問題。

• 管理者一旦看到原型，可能很難理解最終設計不會在一段時間內完成。
• 設計師經常感到被迫在實際系統中使用拼湊的原型程式碼，因為他們害怕“浪費時間”重新開始。
• 原型主要幫助做出設計決策和使用者介面設計。但是，它們無法告訴你最初的需求是什麼。
• 設計師和終端使用者可能過於關注使用者介面設計，而對生產服務於業務流程的系統關注不足。
• 原型適用於使用者介面、屏幕布局和螢幕流程，但對於可能涉及複雜資料庫更新和/或計算的批處理或非同步流程，則不太有用。

原型可以是平面圖（通常稱為線框）或使用合成功能的工作應用程式。線框是在各種圖形設計文件中製作的，並且通常從設計中刪除所有顏色（即使用灰度調色盤），在最終軟體預計會應用圖形設計的情況下。這有助於避免對應用程式的最終視覺外觀和感覺產生混淆。

用例

用例是一種用於記錄新系統或軟體更改的潛在需求的技術。每個用例都提供一個或多個場景，這些場景傳達了系統應該如何與終端使用者或其他系統互動以實現特定業務目標。用例通常避免使用技術術語，而是偏向於使用終端使用者或領域專家的語言。用例通常由需求工程師和利益相關者共同撰寫。

用例是用於描述軟體或系統行為的看似簡單的工具。用例包含對所有使用者可以與軟體或系統互動的方式的文字描述。用例不描述系統的任何內部工作原理，也不解釋該系統將如何實現。它們只是展示了使用者執行任務所遵循的步驟。所有使用者與系統互動的方式都可以用這種方式描述。

軟體需求規格說明

軟體需求規格說明 (SRS) 是對要開發系統的行為的完整描述。它包括一組用例，這些用例描述了使用者將與軟體進行的所有互動。用例也稱為功能需求。除了用例之外，SRS 還包含非功能性 (或補充) 需求。非功能性需求是規定設計或實現約束 (例如效能需求、質量標準或設計約束) 的需求。

IEEE 830-1998 描述了軟體需求規格說明的推薦方法。該標準描述了軟體需求規格說明的可能結構、理想內容和質量。

⇔== 需求型別 == 需求以多種方式進行分類。以下是與技術管理相關的常見需求分類：

客戶需求

事實和假設的陳述，這些事實和假設根據任務目標、環境、約束以及效力和適用性衡量標準 (MOE/MOS) 來定義對系統的期望。客戶是執行系統工程八個主要功能的人，特別強調操作員作為關鍵客戶。操作需求將定義基本需求，至少會回答以下清單中提出的問題：

• 操作分配或部署：系統將在哪裡使用？
• 任務概況或場景：系統將如何完成其任務目標？
• 效能和相關引數：完成任務的關鍵系統引數是什麼？
• 使用環境：各種系統元件將如何使用？
• 效力要求：系統在執行任務時必須有多有效或高效？
• 操作生命週期：系統將被使用者使用多長時間？
• 環境：系統將在哪些環境中有效地執行？

架構需求

架構需求透過識別系統所需的系統架構來解釋必須做什麼。

結構需求

結構需求透過識別系統所需的結構來解釋必須做什麼。

行為需求

行為需求透過識別系統所需的行為來解釋必須做什麼。

功能需求

功能需求透過識別必須完成的必要任務、動作或活動來解釋必須做什麼。功能需求分析將用作功能分析的頂層功能。

非功能需求

非功能性需求是指定可用於判斷系統操作的標準而不是特定行為的需求。

效能需求

必須執行任務或功能的程度；通常以數量、質量、覆蓋範圍、及時性或準備情況來衡量。在需求分析過程中，將根據系統生命週期因素在所有確定的功能中互動地開發效能 (執行得有多好) 需求；並以其估計的確定性程度、對系統成功的關鍵程度及其與其他需求的關係來表徵。

設計需求

技術資料包和技術手冊中表達的產品“製造到”、“編碼到”和“購買到”要求，以及流程的“如何執行”要求。

派生需求

從更高層需求中隱含或轉換來的需求。例如，對長距離或高速的需求可能會導致對低重量的設計需求。

分配需求

透過將高層需求劃分或分配成多個低層需求而建立的需求。例如：一個 100 磅重的物品由兩個子系統組成，可能會導致兩個低層物品的重量需求分別為 70 磅和 30 磅。

著名的需求分類模型包括惠普公司開發的 FURPS 和 FURPS+。

需求分析問題

利益相關者問題

史蒂夫·麥康奈爾在他的著作《快速開發》中詳細介紹了使用者如何妨礙需求收集的幾種方法

• 使用者不瞭解他們想要什麼，或者使用者對他們的需求沒有明確的認識
• 使用者不會承諾一組書面需求
• 使用者在成本和時間表確定後堅持提出新的需求
• 與使用者的溝通緩慢
• 使用者通常不參與評審，或者無法參與評審
• 使用者在技術方面不夠成熟
• 使用者不瞭解開發流程
• 使用者不瞭解當前的技術

這可能會導致即使系統或產品開發已經開始，使用者需求仍然不斷變化。

工程師/開發人員問題

工程師和開發人員在需求分析過程中可能遇到的問題是

• 技術人員和終端使用者可能使用不同的詞彙。因此，他們可能錯誤地認為自己完全達成一致，直到最終產品交付。
• 工程師和開發人員可能會嘗試使需求適合現有系統或模型，而不是開發一個專門滿足客戶需求的系統。
• 分析通常由工程師或程式設計師進行，而不是由具有溝通技巧和領域知識的人員來正確理解客戶需求。

嘗試的解決方案

解決溝通問題的一種嘗試方法是聘用商業或系統分析方面的專家。

20 世紀 90 年代引入的技術，如原型、統一建模語言 (UML)、用例和敏捷軟體開發，也旨在解決以前方法遇到的問題。

此外，一類新的應用程式模擬或應用程式定義工具已經進入市場。這些工具旨在彌合業務使用者和 IT 組織之間的溝通差距，同時允許應用程式在生產任何程式碼之前進行“試銷”。這些工具中最好的工具提供

• 電子白板，用於繪製應用程式流程並測試替代方案
• 捕獲業務邏輯和資料需求的能力
• 生成高保真原型，這些原型密切模擬最終應用程式
• 互動性
• 新增上下文需求和其他註釋的能力
• 遠端和分散式使用者執行和與模擬進行互動的能力

進一步閱讀

• Laplante，Phil（2009）。 軟體和系統需求工程 （第 1 版）。 華盛頓州雷德蒙德：CRC 出版社。 ISBN 1-42006-467-3.
• 麥康奈爾，史蒂夫（1996）。 快速開發：馴服瘋狂的軟體時間表 （第 1 版）。 華盛頓州雷德蒙德：微軟出版社。 ISBN 1-55615-900-5.
• Wiegers, Karl E. (2003). 軟體需求 (第二版). 雷德蒙德，華盛頓州：微軟出版社。 ISBN 0-7356-1879-8.
• Andrew Stellman 和 Jennifer Greene (2005). 應用軟體專案管理. 劍橋，馬薩諸塞州：O'Reilly Media。 ISBN 0-596-00948-8.
• Brian Berenbach，Daniel Paulish，Juergen Katzmeier，Arnold Rudorfer (2009)。 軟體和系統需求工程：實踐. 紐約：McGraw-Hill 專業出版社。 ISBN 0-07-1605479.{{cite book}}: CS1 maint: 多個姓名：作者列表 (link)
• Walter Sobkiw (2008). 透過創造性系統工程實現可持續發展. 新澤西州：CassBeth。 ISBN 0615216307.

• Walter Sobkiw (2011). 系統實踐作為常識. 新澤西州：CassBeth。 ISBN 978-0983253082.

外部連結

• 使用 UML 的軟體需求分析 文章由 Dhiraj Shetty 撰寫。
• 需求工程流程“好東西”
• 需求工程：路線圖 (PDF) 文章由 Bashar Nuseibeh 和 Steve Easterbrook 在 2000 年撰寫。