業務分析 - 需求管理

收集軟體需求是整個軟體開發專案的基石。徵求和收集業務需求是每個專案的重要第一步。為了彌合業務需求和技術需求之間的差距，業務分析師必須充分了解給定上下文中的業務需求，將這些需求與業務目標保持一致，並妥善地將這些需求傳達給利益相關者和開發團隊。

關鍵利益相關者希望有人能夠用通俗易懂的英語解釋客戶/使用者需求。這是否會幫助他們從高層次理解價值？這將是主要關注的領域，因為他們將嘗試將文件與需求進行對映，以及 BA 如何以最佳方式進行溝通。

專案失敗的原因

專案失敗有很多原因，但一些常見領域包括以下內容 -

• 市場和戰略失敗
• 組織和計劃失敗
• 質量失敗
• 領導力和治理失敗
• 技能、知識和能力失敗
• 參與度、團隊合作和溝通失敗

問題的核心在於，專案越來越複雜，變化不斷發生，溝通也充滿挑戰。

為什麼成功的團隊進行需求管理

需求管理是關於讓您的團隊保持**同步**並提供專案內部正在發生的事情的**可見性**。

對於整個團隊瞭解正在構建什麼以及為什麼構建至關重要，這是專案成功的關鍵 - 這就是我們如何定義需求管理。“為什麼”很重要，因為它為關於需求的目標、反饋和決策提供了上下文。

這提高了未來成功和潛在問題的可預測性，使您的團隊能夠快速糾正任何問題，並按時並在預算範圍內成功完成您的專案。作為起點，讓所有相關人員對需求是什麼以及如何管理需求有一個基本的瞭解非常有價值。

讓我們從基礎開始

需求是利益相關方為了解決問題或實現目標而需要滿足的條件或能力。系統或系統元件必須滿足或具備的條件或能力，以滿足合同、標準、規範或其他正式強加的文件。

需求可以用文字、草圖、詳細的模型或模型來表達，無論哪種資訊最能傳達給工程師要構建什麼以及傳達給 QA 經理要測試什麼。根據您的開發流程，您可能使用不同的術語來捕獲需求。

高階需求有時簡稱為**需求**或**目標**。在軟體開發實踐中，需求可能被稱為“用例”、“特性”或“功能需求”。更具體地說，在敏捷開發方法中，需求通常被捕獲為**史詩**和**故事**。

無論您的團隊稱它們為什麼或使用什麼流程；需求對於所有產品的開發都至關重要。如果沒有明確定義需求，您可能會產生不完整或有缺陷的產品。在整個過程中，可能會有很多人參與定義需求。

利益相關者可能會請求一個功能，該功能描述產品將如何透過解決問題來提供價值。設計師可能會根據最終產品從可用性或使用者介面角度應該如何外觀或執行來定義需求。

業務分析師可能會建立一個符合特定技術或組織約束的系統需求。對於當今正在構建的複雜產品和軟體應用程式，通常需要數百或數千個需求才能充分定義專案的範圍或版本的範圍。因此，團隊必須能夠訪問、協作、更新和測試每個需求直至完成，因為需求在開發過程中會隨著時間的推移而自然地發生變化和發展。

現在我們已經從高層次定義了需求管理的價值，讓我們更深入地瞭解每個團隊成員和利益相關者都可以從中受益的四個基本要素 -

• 規劃良好的需求：“我們到底在構建什麼？”
• 協作和認同：“快點批准規範吧！”
• 可追溯性和變更管理：“等等，開發人員知道更改了嗎？”
• 質量保證：“你好，有人測試過這個東西嗎？”

每個人都知道我們在構建什麼以及為什麼構建嗎？這就是需求管理的價值所在。

利益相關者的協作和認同

每個人都在迴圈中嗎？我們是否獲得了對需求的批准以繼續前進？這些問題在開發週期中出現。如果每個人都能就需求達成一致意見，那將是件好事，但對於擁有許多利益相關者的大型專案來說，這種情況通常不會發生。試圖讓每個人都達成一致可能會導致決策被延遲，或者更糟糕的是，根本無法做出決策。就每個決定達成共識並不總是容易的。

在實踐中，您並不一定需要“共識”，您需要獲得團隊的“認同”以及控制者的批准，以便您可以推進專案。在達成共識時，您試圖讓每個人都妥協並就決策達成一致。在獲得認同時，您試圖讓人們支援最佳解決方案，做出明智的決策並做必要的事情來繼續前進。

您不需要每個人都同意該決定是最好的。您需要每個人都支援該決定。團隊協作可以幫助獲得對決策的支援以及規劃良好的需求。

協作團隊努力確保每個人都在專案中發揮作用並提供反饋。協作團隊不斷分享想法，通常具有更好的溝通能力，並且傾向於支援做出的決定，因為他們對專案目標有共同的承諾感和理解。

當開發人員、測試人員或其他利益相關者感到“脫離迴圈”時，就會出現溝通問題，人們會感到沮喪，專案也會被延遲。一旦每個人都認同了工作範圍，就必須使需求清晰且有據可查。跟蹤所有需求是事情變得棘手的地方。

想象一下，有一個長達一英里的待辦事項清單，其中涉及與多個人協作才能完成。您將如何整理所有這些專案？您將如何跟蹤對一項專案的更改將如何影響專案的其餘部分？這就是可追溯性和變更管理增加價值的地方。