需求分析 - 不同類型的需求

數月前曾經寫過一篇章，標題是「需求、目標和口號」，是個人很喜歡的一篇，內容簡要分辨項目中真正可以落實的「需求」，只有幾句說話的「目標」以及空喊的「口號」之間的分別。最近剛完成了一個網上課程，更加明確地介紹了不同類型的需求，很能幫助量化「需求」是否到位，本篇將抽取一些內容作分享。

課程中介紹，我們在項目中做需求收集及分析時，可以將需求分為九個類別，列出如下：

1. Business Requirement - 又可以稱為Business Need Requirement，主要用來勾劃出需要完成的項目 (WHAT)，項目的重要性 (WHY)，以及項目可如何處理業務的需要 (HOW)
2. User / Stakeholder Requirement - 主要用作延伸Business Requirement，重點勾劃項目相關持份者的需求，例如是從法規、運營、風險、財務等角度出發的需求
3. Functional Requirement - 是描述系統功能的需求文件，包括系統各功能的定義及其表現，亦描述系統與用戶之間的互動，常見的做法是透過Functional Requirement 仔細描述開發功能，協助定義項目範圍
4. Non-Functional Requirement - 通常用於描述系統運作的環境
5. Interface Requirement - 描述系統與系統之間互動的文件
6. Business Rules - 是描述具體業務邏輯的文件，也包含公式、運算、算法等，例如產品銷售的客群，有哪些客戶可以使用產品，或需要通過哪些客戶風險評估等
7. Data Requirements - 描述數據如何被儲存及用於操作的文件
8. Assumptions / Constraints - 描述系統運作背後的一些假設及限制的文件
9. Meta Information - 通用的資訊紀錄

一般情況下，以上的各項需求會由不同的部門或角色執行落實，例如Business Requirement 由Business Owner 提出，User/Stakeholder Requirement 由End-User 提出並由Business Analyst 收集分析整合，又例如Functional Requirement 通常由System Analyst 編寫等，視乎機構內的部門分工而訂。而項目團隊在機構的項目框架上，通常會進一步細化分工或按情況調整，例如有些項目團隊沒有Business Analyst 的角色時，就需要由用戶部門與IT合作落實相關需求。

為什麼項目有時會出現所謂需求太high-level，以致聽起來似乎只說了目標甚至乎像是口號，難以落實？很大程度是原於需求內容只提供了以上的某些部份，而最常見的情況是只提供了Business Requirement的一項，只說了項目的目標，但未有深化其它各項例如是User Requirement、Business Rules及Data Requirement等，以致項目在需求環節缺少了重要的元素，難於進行評估亦難於落實。

要留意一點是，項目出現需求不齊絕對不是小問題。就項目計劃方面，這種情況會造成項目難以估算開發範圍，評估的開發量很容易因為遺漏需求，而導致項目後期不斷出現Change Request，以致最終延誤項目，嚴重情況甚至可導致要重啟項目。當然更壞的情況其實是項目持續進行而根本看不見盡頭，影響團隊士氣，長期佔用項目資源亦限制了機構的其它發展計劃，為機構帶來不少損失。

明白了以上這一點，在項目初期定義需求的時候，就更需要嚴格執行需求的評審，並盡可能在項目初段時間找齊項目的持份者，如果項目一直延期的話，也應該盡快評估項目當前需求缺少的部分，盡快補足以減少對項目的後續影響。

也有人會問，是否要在所有需求都集齊才開始進入下一步開發階段，筆者個人認為是不需要，亦是不可能的。坦白說，在今時今日的科技發展，最傳統waterfall 的方法實在很難生存，也難以為時刻出現的新機遇作調整，固此，每一個機構和團隊也有必要適度引入Agile ，以便項目在出現雛型後啟動一些部件的開發，並引發其它範圍的考慮和深化。至於具體有多大程度應使用Agile，則有相當大的討論空間，日後會再整理一下思維再寫。