訂製軟件需求書與範圍控制
將使用者、業務規則、資料、介面及驗收寫成可比較範圍，先分清必須、可選同未確認事項。
作者：WeTech 技術團隊 · 內容更新： (香港時間（GMT+8）)
訂製軟件需求書要描述使用者點完成工作，而唔只係功能名稱。每項需要列輸入、規則、輸出、權限、例外及驗收情境；報價按已確認版本比較，未決事項同變更程序要同樣清楚。
適合哪些情況？
適合準備詢價、重做內部系統，或多個部門對功能理解唔一致嘅企業。
需求書最少內容
| 欄目 | 要寫清楚 | 驗收連結 |
|---|---|---|
| 角色及流程 | 誰做、先後及批准人 | 按角色完成工作 |
| 資料與規則 | 欄位、計算及例外 | 正常、邊界及錯誤輸入 |
| 整合及搬遷 | 來源、接口與責任 | 對帳、權限及失敗處理 |
| 交付及變更 | 文件、帳戶、排除項 | 版本簽收及增項程序 |
由一個完整工作寫起
例如報價唔只係「新增報價單」，仲有計價、折扣權限、批准、版本、匯出及取消。用一個由頭到尾情境列清楚角色同預期結果，再分成可驗收工作。畫面草圖可以幫理解，但唔可以代替規則。
將必須同可選分開
先確認第一期必須完成嘅流程、法定或合約限制同外部依賴。可選功能另列價格及影響；未確認欄位、API 或資料品質要記為假設，不能等上線前先發現無法交付。
需求版本要接到測試
每項需求加穩定識別碼、負責人及測試情境，修改時記錄原因同受影響範圍。讓報價、開發、UAT 同交接用同一版本；變更先確認成本、時間及測試影響，再進入工作清單。
假設情境
假設企業訂製報價工具，第一期只包括一種貨幣同一級折扣批准，多幣種另列選項。測試以已確認計價樣本核對，而唔係只睇畫面是否完成。呢個係假設例子。
常見問題
有畫面圖就足夠？
仲要補規則、權限、資料、例外同驗收條件。
所有需求要一次定死？
可分期，但每期要有清楚基準及變更安排。
需求書由邊個確認？
業務負責人確認規則，技術及資料負責人確認依賴，再共同簽收。
品牌與公開案例範圍
WeTech Consulting（亦稱 WeTech／WeTech AI HK）提供香港 AI 與 IT 顧問服務。WeProperty HK 與 WeCredit HK 為自行開發產品，公開案例只支持所列可觀察功能。WeProperty 展示樓盤、屋苑與成交參考入口；WeCredit 展示提交、審核及公開資料遮蔽，唔構成 TU 信貸評級或最終事實裁定。
參考來源
官方文件用於核對技術、風險及量度概念；本文清單、估算方法與合成例子為 WeTech 規劃建議，並非官方定價或客戶成效。工具方案及條款以供應商當時版本為準。來源查閱： (GMT+8)
相關閱讀
一起梳理你的業務需求
提供現有流程、使用系統與目標，我們會先了解範圍，再討論交付、驗收與報價。
預約免費初步諮詢了解服務