討論客製化軟件時，第一份需求不需要很長，但應能說明工作怎樣發生、誰會使用，以及甚麼結果才算完成。這比單純列出功能名稱，更容易讓雙方對項目有相同理解。
以下清單可用來準備初步討論。實際範圍、費用及時間，需要根據資料、系統接駁和交付安排評估。
1. 先描述目前的工作和需要改善的問題
選一個具體情境，由收到工作開始，記錄每個步驟、負責人、使用的表格或系統，以及完成後的交付。指出重複輸入、等候、找不到資料或容易出錯的位置。
例如「需要一個後台」只描述了介面；「同事收到查詢後，需要檢查資料、分派負責人及追蹤回覆」則提供了可以討論的流程。
- 誰提出需求，誰每天使用，誰作最後確認？
- 目前每一步怎樣完成？
- 哪個問題最需要先解決？
- 第一版有哪些事情可以暫時不做？
2. 整理資料、權限和系統接駁
列出需要讀取及更新的資料，並準備已移除敏感內容的範例。若有現有系統，先確認資料由誰管理、可否匯出，以及是否有正式接駁方法。
權限不應只分成「有登入」和「沒有登入」。不同角色可能只需要查看自己的工作、修改特定欄位，或審批某些操作。先畫出角色與權限，有助避免開發後才發現流程不合用。
| 範圍 | 要準備的資料 |
|---|---|
| 使用者 | 角色、日常工作和審批責任 |
| 資料 | 欄位、樣本、來源和更新負責人 |
| 接駁 | 現有系統、匯出格式及可用介面 |
| 權限 | 誰可以查看、修改、審批及匯出 |
3. 用可以演示的情境定義完成
把功能要求改寫成一段可以重做的使用情境。例如：同事建立查詢，主管分派負責人，負責人更新狀態後，主管可以按日期查看待處理清單。
每個情境也應包含例外：必填資料不足、重複紀錄、沒有權限、接駁系統暫時不可用。驗收不只檢查畫面是否存在，也要確認實際工作能否完成。
- 指定輸入、操作步驟和預期結果
- 確認哪些角色可以完成操作
- 記錄錯誤或例外時應出現的回應
- 用同一批情境比較演示、測試和正式交付
4. 提早談交付、維護和退出安排
除了開發功能，也應清楚列出測試、資料搬遷、培訓、帳戶管理、維護和支援的安排。這些工作可能影響團隊能否真正接手使用系統。
討論原始碼、網域、託管帳戶及資料匯出的交接方式，以及新增需求如何評估。各項安排應以雙方實際確認的交付文件為準，避免依賴口頭假設。
- 誰管理正式系統及第三方帳戶？
- 會交付哪些文件、培訓及操作說明？
- 出現問題時，應向誰提出及怎樣跟進？
- 日後轉換供應商或系統時，資料如何帶走？
5. 先排好第一版的優先次序
把需求分成「第一版必須有」「可以下一階段處理」和「仍需要確認」。第一版應盡量圍繞一條可完成的核心流程，而不是同時加入所有想到的功能。
比較方案時，使用相同的需求、情境和交付清單。報價如有差異，先了解是否包含不同的接駁、資料處理、測試或維護工作，再作取捨。
