需求管理是一套系統化方法,用於尋找、詳細記錄、組織及追蹤系統的變更需求。
我們對需求的定義如下:
系統必須符合的條件或能力。
需求管理是達成下列目標的一套系統化方法,這是我們對需求管理的正式定義:
-
擷取、組織及詳細記錄系統的需求
-
針對變更系統需求的議題,在客戶和專案團隊之間建立並維持共識
需求有效管理的關鍵包括維護一份清楚的需求說明書和每一種需求類型的適當屬性,以及對於其他需求和其他專案工作成果的可追蹤性。
收集需求看似一件簡單的作業。但在實際的專案中,您會遭遇困難,因為:
-
需求總是難以捉摸,且可能有多個來源。
-
需求始終不易訴諸文字來明確表達。
-
需求種類繁多,且詳細程度不一。
-
需求數量一旦失控即難以掌握。
-
需求之間彼此相關,也涉及軟體工程流程的其他工作成果。
-
需求有獨特的內容和或內容值。例如,重要性不一,滿足的難易度也不同。
-
利害關係人眾多,意謂著必須由跨領域的人群來共同管理需求。
-
需求變更。
因此,您在組織內需要開發什麼技能來協助您解決這些難題?我們發現有必要精通下列各項技能:
問題分析的目的在於瞭解問題、關係人最初需求及提出高階的解決方案。必須實際推論和分析來發現「問題真相」。在問題分析期間,將在真正問題為何及誰為關係人的議題上達成共識。此外,您也會以商業角度來定義解決方案的界限,以及解決方案的商業性限制。您也應該已分析專案的商業案例,清楚瞭解在建置的系統中所做的投資預期將有何報酬。
另請參閱活動:分析問題.
需求的來源眾多;例如客戶、夥伴、使用者及領域專家。您必須知道如何準確判斷真正的來源、取得這些來源,也必須知道如何從中萃取資訊。提供這項資訊主要來源的人稱為專案的關係人。如果您開發的資訊系統是為了在公司內部使用,您可以在開發團隊中納入具有使用者經驗和商業領域專業的人。您通常以商業模型層次來開始討論,而非系統層次。如果您開發的產品會上市銷售,您可以運用大量行銷人員,以確實瞭解該市場的客戶需求。
在運用訪談、腦力激盪、技術原型建立、問卷調查及競爭力分析等技術時,即可能展開導出活動。導出結果是一份要求或需求清單,圖文並貌,且設定相對的優先順序。
另請參閱活動:瞭解關係人需求.
定義系統表示在瞭解關係人的需求之後,將結果轉換並組織成有意義的說明,以描述您要建置的系統。在系統定義早期,主要是決定需求由什麼構成、文件格式、語言正式性、需求具體性(數量多寡和詳細程度)、要求優先順序和預估投入成本(通常由不同的人在分開的演練中,得出兩種差別極大的評價)、技術和管理風險,以及初始範圍。此活動可能包含初期原型和設計模型,與最重要的關係人需求有直接關係。系統定義的成果是一份以自然語言和圖形表達的系統說明。
另請參閱活動:定義系統.
為了執行專案,您必須根據所有關係人的輸入,小心訂定各需求的優先性,並管理需求的範圍。太多專案都免不了有開發人員在做一些所謂的「隱藏程式」 (開發人員覺得有趣和有挑戰性的功能),而不是儘早努力緩和專案風險或穩定應用程式的架構。
為了確保儘早解決或緩和專案的風險,您應該採漸進方式開發系統,在為了緩和已知專案風險的每一次擴增活動中,小心選擇需求。您必須與專案的關係人一起議定範圍(每一次反覆活動)。這通常要有專業技術來妥善管理對於專案不同階段的期望成果。您也必須控制需求的來源、專案工作成果的外表,以及開發流程本身。
另請參閱活動:活動:管理系統的範圍.
系統的詳細定義必須能夠讓關係人瞭解、同意並簽署。不僅必須涵蓋功能性,也要納入任何法律或規章需求的達成性、可用性、可靠性、效能、支援性及維護性。很難建置不代表一定需要複雜的定義,就是一項常犯的錯誤。這會導致難以解釋專案和系統的用途。人們或許深受感動,但因為根本不瞭解,當然提不出好的意見。對於系統的描述文件,您應該仔細瞭解文件的讀者。通常可能需要針對不同的讀者來準備不同類型的說明。
在溝通討論系統的用途和定義系統的詳細資料時,我們知道使用案例方法是一種非常有效的方式(通常再配合簡單的視覺化原型)。使用案例可將需求納入情境中;以說故事的手法來敘述系統的用途。
系統詳細定義的另一項要素是描述如何測試系統。關於執行什麼測試的測試計劃和定義,告訴我們將驗證哪些系統功能。
另請參閱活動:修正系統定義.
無論您如何小心定義需求,世事總無常。導致變更需求難以管理的原因,不僅因為變更需求表示必須付出或多或少的時間來實作特定的新功能,也因為需求的變更可能連帶影響其他需求。您必須為需求提供一種變化靈活的結構,且在需求和開發生命週期的其他工作成果之間,利用追蹤鏈結來表示相依關係。管理變更包括建立基準線、決定必須追蹤的相依關係、建立相關項目之間的追蹤性及變更控制等活動。
另請參閱活動:管理變更需求.
如需本主題的詳細資訊,請參閱:
概念:需求
概念:需求的類型
概念:追蹤性
白皮書:透過使用案例來實施需求管理
|