肥蝦的專案"瞎"日誌-明確簡要的需求書(Requirements Document)

需求書肥蝦沒有寫過幾次(因為我大多在vendor side)，但是看過很多次了。正是所謂「沒看過豬走路，至少也吃過豬肉。」因為此次是內部研發的專案，肥蝦必須自己擬定需求書，以為後續專案執行的依據。而且既然是內部使用，就必須要明確、可驗證、可追蹤。

一般需求書會分為十一個段落，但可依實際的狀況與需要刪減。以下簡要說明了肥蝦心目中一般標準的需求書範本：
(一)前言(Business need or opportunity)：描述公司現在所處情境的分析、公司策略與採行此專案的原因。

(二)目的(Business and project objects)：執行專案後所欲達成的目標。

(三)現有環境架構(existed environment)：描述現有的實體環境，與既有的週遭軟、硬體設備。

(四)功能面的需求(Functional requirements)：商業流程所需要的操作面與管理面的作業要求。

(五)非功能面的需求(Non-functional requirements)：作業的效能、資訊安全、備份、備援與回復作業要求等項目。

(六)品質要求(Quality requirements)：可分為程序跟產品兩大部份。在程序上，如：對人員、技術的要求。在產品上，如：文件、設計、程式碼、測試的要求。基本上會針對容錯度、可用性、可靠性、完整性、可擴充性、可驗證性、安全性…等，提出一個明確的標準。如針對系統回應的時間，MTBF(mean time between failure)，MTTR(mean time to repair)等設定一個區間。

(七)驗收/評鑑標準(Acceptance Criteria)：此部份可列出一個功能面定性的checklist或定量的metrics。

(八)指導原則(Guiding principles)：如公司內控規章、程式開發/編碼準則、網路作業安全規範等，內外部的相關法規與依據。

(九)影響分析(Impacts to other organizational areas and other entities inside or outside the organization)：對既有公司內部作業單位、業務單位、研發單位、管理單位、內控與會計單位；外部的股東、既有客戶等的衝擊與影響。

(十)支援與訓練需求(Support and training requirements)：後續上系統的作業支援、維護的要求，以及系統轉移所必要的教育訓練需求。

(十一)需求的假設與限制(Requirement assumptions and constraints)：假設的部份主要來自未來商業發展應用的需求，以及市場競爭立基點；限制則為來自合約上時程與金額的限制。

根據以上的肥蝦的認知，肥蝦花了一天終於寫好了近二十頁的需求書，準備提交給John協理。


文章定位：