業務分析師的需求收集

卓越的使用者體驗在於讓終端使用者能夠實現他們的目標，無論是網站、軟體系統還是產品。為了滿足他們的需求，我們需要了解他們的工作和工作環境。軟體開發生命週期的第一個基本階段是需求收集。它提供了清晰、簡潔且經過一致同意的客戶需求集，軟體應該滿足這些需求。業務分析師和主題專家負責需求收集過程。

業務客戶往往期望軟體團隊能夠洞察他們的想法，並根據未說出口或未知的需求交付解決方案。因此，所有需求都需要正式記錄在一個龐大的文件中。

需求收集流程

徵求和收集業務需求是每個專案的重要第一步。為了彌合業務需求和技術需求之間的差距，業務分析師必須充分理解給定環境中的業務需求，將這些需求與業務目標相協調，並適當地向利益相關者和開發團隊傳達這些需求。為此，他們需要確保需求使用雙方都能理解的語言編寫。

此階段旨在定義每個專案都應理解和定義的業務目標，以便可以根據專案為業務帶來的價值來確定所有工作的優先順序。

以下是此階段將進行的活動。

在此階段，提取適當的資訊以準備編寫需求文件。有很多不同的業務分析技術可以用來收集需求及其優先順序，包括研討會、輔助訪談、觀察或原型（可在單獨的文章中討論）。

此處將識別利益相關者類別，即想要構建產品的客戶、將為此付費的客戶、終端使用者以及將受到影響的其他利益相關者。然後，將利益相關者類別對映到業務目標。確定所需輸入以及每個已識別利益相關者類別的參與程度和影響力。必須確定利益相關者代表和決策者。

在此階段，將驗證和確認規則是否不清楚、不完整、含糊不清或自相矛盾。必須確定需求的類別（功能性或非功能性）並確定其優先順序。

收集、編寫和釋出利益相關者的需求。建立命名約定和定義。將需求追溯到來源。記錄事實和假設。

與利益相關者一起驗證需求的生命週期，從其起源，到其開發和規範，再到其後續部署和使用。它確保由於遺漏的需求而在已開發的系統中沒有任何範圍“漏洞”。此活動還確保所有需求在內部彼此一致。

這是利益相關者對需求的安全接受。此步驟是使用者實際的“簽字確認”，併為配置工作啟動奠定了基礎。

**需求**是對擬議系統必須做什麼或充分做什麼才能解決客戶問題的預期陳述。在利益相關者提出需求後，業務分析師的角色是進一步定義、分析、驗證和確定需求陳述的優先順序。

作為整體的需求集代表利益相關者之間達成的協議。需求的集合是需求文件。為了有效地實施和衡量需求，它們必須具體、明確且清晰。

**業務需求——**企業需求、目標和目標的高階陳述。它們確認專案的範圍並識別利益相關者。它們通常描述系統或解決方案應該做什麼。業務需求應始終從客戶的角度編寫。儘管它們是高階的廣泛需求，但應詳細說明組織的需求“是什麼”以及為什麼應該滿足這些需求。

**利益相關者需求——**這些陳述描述了利益相關者為實施解決方案而需要的東西或遇到的問題，無論這些問題與組織或運營問題有關。利益相關者需求充當業務需求與其他類別解決方案需求之間的聯結器。它將使用者置於關注的中心，並使用流程圖、用例圖、用例場景和其他流程模型進行描述。

**解決方案需求——**它們描述了利益相關者希望如何實施業務和利益相關者需求的解決方案。它們通常細分為子類別

**功能需求——**功能需求描述了開發人員必須構建到產品中的產品的範圍、功能、行為以及與其他系統的連線。它們精確地描述了軟體必須執行的任務。它們還定義了系統必須符合的業務規則。

業務分析師將透過開發用例（如下所述）來捕獲和驗證功能需求。

**非功能需求——**非功能需求定義了系統的質量特性、約束或標準，系統必須具備或符合這些標準。它們將描述系統的外觀和感覺。它們決定系統的視覺屬性、可用性和效能要求——大小、速度等。它們還包括產品的預期執行環境、可維護性、可移植性、可靠性、安全性等。
**過渡需求——**臨時功能，用於過渡到新系統。它們本質上總是臨時的，因為只有在定義了現有解決方案和新解決方案之後才能開發它們。

用例描述了計算機軟體系統的行為和功能需求。它們為所有人提供了一種簡單的格式，以便快速掌握系統的功能。現有系統——在使用現有系統時，可以使用它來快速激發想法。

它們描述了使用者為了完成給定任務而執行的一系列典型操作。用例模型由以下部分組成——一組用例——可選描述或圖表，指示它們之間的關係。

使用用例圖，用例之間的關係是顯而易見的。在下圖中，參與者表示為簡筆畫，每個用例表示為橢圓形。箭頭顯示參與者與用例之間以及各種用例之間的關係。

需求收集是一個相當冗長且詳細的過程。毋庸置疑，系統越大，流程就越複雜。需求管理流程將有助於控制成本、避免需求蔓延並確保端到端的可追溯性。其優勢在於，此流程將幫助您在預設計階段收集大部分需求，定義和確定其優先順序，避免重複並設定標準以衡量已實施的程度。

塞繆爾·薩姆

更新於：2020年7月14日

4K+ 次瀏覽

透過完成課程獲得認證