良好的需求規劃

---

---

那麼，什麼構成了良好的需求？良好的需求應該是有價值且可操作的；它應該定義需求，並提供通往解決方案的途徑。團隊中的每個人都應該理解它的含義。需求的複雜性各不相同。

• 一份良好的需求文件可以作為包含高階需求分解成子需求的組的一部分。

• 它們還可以包含非常詳細的規範，其中包括一組功能需求，描述最終產品的行為或元件。

• 良好的需求需要簡潔明瞭，並應回答“我們需要什麼？”而不是“我們如何滿足需求？”

• 良好的需求確保所有利益相關者都理解他們計劃中的部分；如果部分內容不明確或被誤解，最終產品可能會出現缺陷或失敗。

在需求演進過程中，透過持續不斷地從團隊那裡獲得反饋，可以幫助避免需求的失敗或誤解。與每個人的持續協作和認同是成功的關鍵。

需求收集和分析

需求是指利益相關者為解決問題或實現組織目標而需要的一個條件或能力；系統必須滿足或擁有的條件或能力。

在軟體工程中，需求分析涵蓋了確定新產品或更改產品的需求或條件的任務，同時考慮各種利益相關者之間可能存在的衝突需求，分析、記錄、驗證和管理軟體或系統的需求。

需求應：

• 已記錄
• 可操作的
• 可衡量的
• 可測試的
• 可追溯的

需求應與已識別的業務需求或機會相關，並定義到足以進行系統設計的詳細程度。

商業分析師透過觀察現有系統、研究現有流程、與客戶和終端使用者討論來收集資訊。分析師在沒有工作系統的情況下也應該具備想象力和創造力。分析收集到的需求以找到缺失環節就是需求分析。

需求獲取方法

為了獲取目標，向業務專家、開發經理和專案發起人提出以下問題：

• 這個專案將幫助公司實現哪些業務目標？

• 我們為什麼現在做這個專案？

• 如果我們以後再做會怎麼樣？

• 如果我們根本不做會怎麼樣？

• 誰將從這個專案中受益？

• 那些將從中受益的人認為這是目前可能做出的最重要的改進嗎？

• 我們是否應該做其他專案？

可能的目標包括降低成本、改進客戶服務、簡化工作流程、替換過時的技術、試用新技術等等。此外，請確保您完全理解擬議的專案將如何幫助實現既定的目標。

不同型別的需求

商業分析師最感興趣的需求型別如下：

業務需求

業務需求是企業必須執行的關鍵活動，以便在保持與解決方案無關的情況下滿足組織目標。業務需求文件 (BRD) 詳細說明了專案的業務解決方案，包括客戶需求和期望的文件。

使用者需求

使用者需求應指定使用者期望/想要從軟體專案構建的軟體中獲得的特定需求。使用者需求應可驗證、清晰簡潔、完整、一致、可追溯、可行。

使用者需求文件 (URD) 或使用者需求規格說明書通常用於軟體工程中，它指定使用者期望軟體能夠做什麼。

系統需求

系統需求處理定義軟體資源需求和先決條件，這些需求和先決條件需要安裝在計算機上才能提供應用程式的最佳功能。

功能需求

功能需求捕獲並指定所開發系統的特定預期行為。它們定義諸如系統計算、資料操作和處理、使用者介面以及與應用程式的互動等內容，以及其他顯示如何滿足使用者需求的特定功能。為每個需求分配一個唯一的 ID 號。

非功能需求

非功能需求是指定可以用來判斷系統操作的標準，而不是特定行為的標準。系統架構說明了實現非功能需求的計劃。

非功能需求說明系統應該是什麼樣子，或者可以將其描述為“系統應該……”。非功能需求被稱為系統的質量。

過渡需求

過渡需求描述解決方案必須滿足的能力，以便促進企業從當前狀態向預期未來狀態過渡，但在過渡完成後將不再需要這些能力。

它們與其他需求型別不同，因為它們本質上總是臨時的，並且因為只有在定義了現有解決方案和新解決方案後才能開發它們。它們通常涵蓋來自現有系統的資料轉換、必須解決的技能差距以及為達到預期未來狀態而進行的其他相關更改。它們是透過解決方案評估和驗證來開發和定義的。

可追溯性和變更管理

需求可追溯性是一種組織、記錄和跟蹤所有需求的方法，從最初的想法產生到測試階段。

需求可追溯性矩陣 (RTM) 提供了一種方法來跟蹤功能需求及其在整個開發過程中的實現。每個需求都包含在矩陣中，以及其關聯的章節號。

隨著專案的進展，RIM 會更新以反映每個需求的狀態。當產品準備好進行系統測試時，矩陣列出每個需求、哪個產品元件解決了該需求以及哪個測試驗證了它是否已正確實現。

在 RTM 中包含以下每一列：

• 需求描述
• FRD 中的需求參考
• 驗證方法
• 測試計劃中的需求參考

示例 - 連線點以識別專案內各項之間的關係。它是常見下游流的聯結器。

創意 需求 設計 測試 業務目標

您應該能夠將每個需求追溯到其原始業務目標。

透過追溯需求，您可以識別變化產生的連鎖反應，檢視需求是否已完成以及是否正在正確測試。可追溯性和變更管理為管理者提供了安心感和必要的可見性，以便預測問題並確保持續的質量。

質量保證

第一次就正確交付需求意味著更高的質量、更快的開發週期以及更高的客戶滿意度。需求管理不僅有助於做到正確，還有助於您的團隊在整個開發過程中節省資金和避免許多麻煩。

簡潔明瞭的需求可以幫助您儘早發現和解決問題，而不是在以後解決問題時成本高得多。此外，在開發過程後期編碼後糾正缺陷的成本可能高達100 倍，而早期在需求時糾正的成本則要低得多。

透過將需求管理整合到您的質量保證流程中，您可以幫助您的團隊提高效率並消除返工。此外，返工是大多數成本問題發生的地方。

換句話說，開發團隊正在將大部分預算浪費在第一次沒有正確執行的工作上。例如，開發人員根據舊的規範文件編寫功能程式碼，之後才瞭解到該功能的需求已更改。透過有效的需求管理最佳實踐，可以避免此類問題。

總而言之，需求管理聽起來可能是一門複雜的學科，但當您將其簡化為一個簡單的概念時——它是關於幫助團隊回答“每個人都理解我們正在構建什麼以及為什麼？”這個問題。從商業分析師、產品經理和專案領導到開發人員、質量保證經理和測試人員，以及相關的利益相關者和客戶——專案的失敗根源往往是對專案範圍的誤解。

當每個人都在協作，並且對整個專案生命週期中與需求相關的討論、決策和更改具有完整的背景和可見性時，成功就會持續發生，並且您可以保持持續的質量。此外，該流程更加流暢，參與其中的每個人都會減少摩擦和挫敗感。

注意 - 研究表明，專案團隊可以透過有效地管理需求來消除 50-80% 的專案缺陷。根據卡內基梅隆軟體工程研究所的說法，“60-80% 的軟體開發成本用於返工。”

獲取需求籤字

需求籤字確認正式確認專案干係人對已記錄需求的內容和表達方式的準確性和完整性達成一致。正式確認降低了在實施期間或之後，干係人引入新的（以前未遇到過的）需求的風險。

獲得需求籤字確認通常涉及對已記錄的需求進行面對面的最終審查，審查物件為每個專案干係人。在每次審查結束時，都會要求干係人正式批准已審查的需求文件。此批准可以物理方式或電子方式記錄。

獲得需求籤字確認通常是需求溝通中的最終任務。業務分析師需要正式需求審查的輸出結果，包括對審查過程中提出的任何意見或異議的處理。