系統建置中階通用工程業製造業
系統使用者故事與驗收條件提示詞
把功能需求轉為可驗收的使用者故事與 Given-When-Then。
適用對象:PM、QA · 最後更新 2026-07-17
適用情境
把功能需求轉為可驗收的使用者故事與 Given-When-Then。
適用產業或公司規模
- 通用
- 工程業
- 製造業
使用前需要準備的資料
- 功能需求清單。
- 主要角色。
可替換欄位說明
| 變數 | 說明 |
|---|---|
| [公司名稱] | 貴公司正式名稱 |
| [系統名稱] | 本次系統 |
| [功能主題] | 例如:報價審核、專案回報 |
完整提示詞
Prompt
你是資深敏捷 PM。請把功能需求轉為使用者故事。 【背景】 - 公司:[公司名稱] - 系統:[系統名稱] - 功能主題:[功能主題] 【輸出】 1. 10–15 條使用者故事(As-a / I want / So that)。 2. 每條故事 3–5 條驗收條件(Given-When-Then)。 3. 標示優先度(Must / Should / Could / Won't)。 4. 標示相依關係。 5. 建議測試資料類型。 【判斷標準】故事需以「使用者能得到什麼結果」描述,不描述介面細節。 【不確定資訊處理】 若下列變數尚未填寫或資訊不足,請直接列出缺漏欄位並詢問使用者,不要自行假設或編造資料。 【禁止事項】 - 禁止捏造統計數字、法規條號、認證名稱或客戶案例。 - 遇到專業判斷不足時,請明確標註「需由人員確認」而非自行推論。 【最後自我檢查】 產出結束後,請在最後條列自我檢查:(1) 是否有虛構的數字、法規、標準或客戶名稱;(2) 是否忽略任何未填寫的重要變數;(3) 是否明確標示假設條件。
使用步驟
- 填入變數。
- 與 QA 共同 review 驗收條件。
- 納入 backlog。
實際填寫範例
「作為業務主管,我希望可以查看本月 Pipeline,以便追蹤達成率。」
常見錯誤
- 用「畫面上加一個按鈕」寫故事。
注意事項
- 驗收條件必須可測,避免『使用者滿意』這類主觀敘述。
相關提示詞
最後更新 2026-07-17
需要依照公司流程與產業需求進一步客製化嗎?
宏鼎集成提供企業 AI 導入、流程盤點及系統整合顧問服務,可協助您把提示詞落實為可穩定運作的內部流程。