PRD（產品需求文件｜Product Requirement Document）範本

版本：1.0
參照標準：ISO/IEC/IEEE 29148:2018、ISO 9241-210:2019、IIBA BABOK v3
適用對象：產品經理、UI/UX 設計師、業務分析師、開發團隊
文件性質：產品需求定義與功能規劃文件

📋 使用說明

PRD 是將商業目標轉譯為具體功能需求的關鍵文件，定義「產品要做什麼」。它是 UI/UX 設計師與工程團隊開發的主要依據，橋接業務需求（BRD）與技術實作（SDD/TSD）之間的落差。

何時使用本範本

新產品或新功能的需求定義階段
產品重大改版前的需求整理
跨部門協作時的需求溝通基準文件

填寫原則

以使用者為中心：所有功能描述應從使用者角度出發
量化可驗證：驗收條件必須可量化、可測試
優先序明確：使用 MoSCoW 或數字排序標明優先級
迭代更新：隨需求演進持續更新文件版本

📄 範本正文

[產品/功能名稱] 產品需求文件（PRD）

1. 文件資訊

項目	內容
文件編號	PRD-[專案代碼]-[序號]
版本	v0.1
建立日期	YYYY-MM-DD
最後更新	YYYY-MM-DD
撰寫者	[產品經理姓名]
審核者	[審核者姓名 / 角色]
核准者	[核准者姓名 / 角色]
狀態	草稿 / 審查中 / 已核准 / 已凍結

版本歷程

版本	日期	修改人	修改內容摘要
v0.1	YYYY-MM-DD	[姓名]	初版建立

審核紀錄

審核者	角色	審核日期	結果	備註
			通過 / 有條件通過 / 退回

2. 產品概述

2.1 產品願景

簡述本產品/功能的願景，說明為何需要此產品，以及期望達成的長期目標。

願景聲明：
為了 [目標使用者]，他們需要 [解決的問題/需求]，本產品 [產品名稱] 是一個 [產品類型]，能夠 [關鍵價值主張]。不同於 [現有替代方案]，本產品 [獨特優勢]。

2.2 商業目標

目標編號	商業目標	量化指標（KPI）	目標值	衡量方式
BG-001	例：提升線上轉換率	轉換率	≥ 5%	Google Analytics
BG-002	例：降低客服成本	客服案件量	減少 30%	客服系統報表

2.3 專案範圍

包含（In Scope）：

功能項目 1
功能項目 2

排除（Out of Scope）：

不在本次開發範圍的項目 1
不在本次開發範圍的項目 2

2.4 成功標準

指標	目標值	衡量方式	評估時間
使用者採用率	≥ 60%	系統使用統計	上線後 3 個月
使用者滿意度	≥ 4.0/5.0	NPS 調查	上線後 1 個月
系統錯誤率	< 0.1%	監控報表	持續監控

3. 使用者輪廓（User Persona）

3.1 目標使用者分類

Persona 1：[使用者名稱/角色]

項目	描述
角色名稱	例：企業用戶 - 財務主管
年齡範圍	35-50 歲
技術熟練度	中等
使用頻率	每日
主要目標	快速查看財務報表、審核請款
痛點	現行系統操作繁瑣、報表不即時
使用情境	辦公室桌機、偶爾使用平板

Persona 2：[使用者名稱/角色]

項目	描述
角色名稱	例：一般員工
年齡範圍	25-40 歲
技術熟練度	初階至中等
使用頻率	每週 2-3 次
主要目標	提交請款單、查詢進度
痛點	表單填寫步驟過多
使用情境	手機為主、桌機為輔

3.2 使用者旅程地圖（User Journey Map）

階段：    認知 → 註冊 → 首次使用 → 日常使用 → 進階功能
觸點：    廣告   官網    引導教學    主功能     設定/報表
情緒：    😐    😊     😐→😊     😊        😊
痛點：    無     驗證慢   學習曲線    載入速度    功能不直覺
機會：    SEO    簡化    教學引導    效能優化    UX 改善

4. 核心功能清單（Feature List）

4.1 功能總覽

功能編號	功能名稱	優先序	相關 User Story	對應 Persona	狀態
F-001	使用者註冊與登入	Must Have	US-001, US-002	Persona 1, 2	待開發
F-002	儀表板首頁	Must Have	US-003	Persona 1	待開發
F-003	報表匯出	Should Have	US-010	Persona 1	待開發
F-004	行動裝置推播通知	Could Have	US-015	Persona 2	待開發

優先序分類（MoSCoW）
Must Have：必備功能，缺少則產品無法上線
Should Have：重要功能，應盡量納入
Could Have：有則更好，資源允許時納入
Won’t Have（this time）：本期不做，未來考慮

4.2 功能詳細描述

F-001：使用者註冊與登入

功能描述：
系統提供使用者自行註冊帳號及登入功能，支援帳號密碼與第三方社群登入（Google、Microsoft）。

User Story：

作為 [一位新使用者]
我想要 [透過 Email 快速完成註冊]
以便 [開始使用系統功能]

驗收條件（Acceptance Criteria）：

Scenario: 使用者以 Email 註冊
  Given 使用者在註冊頁面
  When 使用者輸入有效的 Email 和密碼
  And 使用者點擊「註冊」按鈕
  Then 系統發送驗證信至使用者 Email
  And 使用者收到「註冊成功，請驗證 Email」的提示
  And 系統建立狀態為「待驗證」的帳號

Scenario: 使用者嘗試使用已存在的 Email 註冊
  Given 使用者在註冊頁面
  When 使用者輸入已存在的 Email
  And 使用者點擊「註冊」按鈕
  Then 系統顯示「此 Email 已被使用」的錯誤訊息

業務規則：

規則編號	規則描述
BR-001	密碼長度至少 8 碼，需包含大小寫字母、數字及特殊字元
BR-002	Email 驗證連結有效期為 24 小時
BR-003	連續登入失敗 5 次，帳號鎖定 30 分鐘

資料需求：

欄位名稱	資料型別	必填	驗證規則
Email	String(254)	✅	RFC 5322 格式
密碼	String(128)	✅	最少 8 碼，複雜度規則
顯示名稱	String(50)	✅	2-50 字元
手機號碼	String(15)	❌	E.164 格式

5. 流程圖（Process Flow）

5.1 主要業務流程

使用流程圖描述核心業務流程，建議使用 Mermaid、Visio 或 draw.io 繪製。

[範例：訂單處理流程]

使用者下單 → 系統驗證庫存 → 庫存足夠？
  ├─ 是 → 建立訂單 → 發送確認通知 → 等待付款
  │                                      ├─ 付款成功 → 出貨處理 → 完成
  │                                      └─ 付款逾時 → 取消訂單
  └─ 否 → 顯示缺貨通知 → 加入候補清單

5.2 使用者操作流程（User Flow）

描述使用者完成特定任務的步驟順序與頁面流轉。

首頁 → 登入頁 → 驗證 → 儀表板
                  ↓ 失敗
               錯誤提示 → 重試 / 忘記密碼

6. 介面原型（Wireframe）

6.1 頁面清單

頁面編號	頁面名稱	路徑	對應功能	Wireframe 連結
P-001	首頁	/	F-002	[連結]
P-002	登入頁	/login	F-001	[連結]
P-003	註冊頁	/register	F-001	[連結]
P-004	儀表板	/dashboard	F-002	[連結]

6.2 Wireframe 規格

設計工具：Figma / Adobe XD / Sketch
設計規範：
遵循 WCAG 2.2 AA 無障礙標準
支援 RWD（Responsive Web Design）
斷點設定：手機（< 768px）、平板（768-1024px）、桌機（> 1024px）

頁面互動說明

頁面	元件	互動行為	說明
登入頁	Email 輸入框	onBlur	即時格式驗證
登入頁	密碼輸入框	onClick 眼睛圖示	切換明碼/密碼顯示
登入頁	登入按鈕	onClick	呼叫登入 API、顯示 Loading

7. 非功能性需求（Non-Functional Requirements）

7.1 效能需求

指標	目標值	衡量方式
頁面載入時間	< 3 秒（首次）、< 1 秒（後續）	Lighthouse / WebPageTest
API 回應時間	95th percentile < 500ms	APM 監控
同時在線使用者	≥ 5,000	壓力測試

7.2 安全需求

需求	說明	參照標準
資料傳輸加密	TLS 1.3	OWASP ASVS
敏感資料儲存	AES-256 加密	ISO 27001
身分驗證	OAuth 2.0 / OIDC	RFC 6749
存取控制	RBAC	NIST SP 800-162

7.3 可用性需求

指標	目標值
系統可用率	≥ 99.9%
RTO（復原時間目標）	≤ 30 分鐘
RPO（復原點目標）	≤ 5 分鐘

7.4 相容性需求

平台	支援版本
Chrome	最新兩個主要版本
Firefox	最新兩個主要版本
Safari	最新兩個主要版本
Edge	最新兩個主要版本
iOS Safari	iOS 15+
Android Chrome	Android 12+

8. 依賴與限制

8.1 技術依賴

依賴項目	說明	負責團隊	預計就緒日
身分驗證服務（SSO）	整合企業 SSO 系統	資安團隊	YYYY-MM-DD
通知推播服務	FCM / APNS	平台團隊	YYYY-MM-DD

8.2 業務限制

限制條件	說明
法規合規	需符合個資法/GDPR 要求
預算限制	本期開發預算 XXX 萬元
時程限制	需於 YYYY-MM-DD 前上線

9. 里程碑與時程

里程碑	預計日期	交付物	負責人
需求確認	YYYY-MM-DD	PRD 定版	產品經理
設計完成	YYYY-MM-DD	Wireframe + SDD	設計師 + 架構師
開發完成	YYYY-MM-DD	可測試版本	開發團隊
UAT 驗收	YYYY-MM-DD	測試報告	QA + 業務
正式上線	YYYY-MM-DD	Release Note	DevOps

10. 風險與緩解措施

風險編號	風險描述	發生機率	影響程度	緩解措施	負責人
R-001	需求頻繁異動	高	高	設定需求凍結日、異動審核	PM
R-002	第三方 API 不穩定	中	中	建立 Fallback 機制	架構師
R-003	上線時程壓縮	中	高	優先交付 Must Have 功能	PM

11. 術語定義

術語	全稱	定義
PRD	Product Requirement Document	產品需求文件
MoSCoW	Must/Should/Could/Won’t	需求優先序分類法
Wireframe	—	低保真介面原型
Persona	—	使用者人物誌
UAT	User Acceptance Testing	使用者驗收測試

12. 附件與參考

Wireframe 設計稿（Figma 連結）
競品分析報告
使用者研究報告
相關 BRD 文件

範例：電子商務平台 PRD 摘要

以下為精簡範例，展示如何填寫各章節重點。

產品概述

產品名稱：ShopEase 線上商城
願景：為中小型零售商提供一站式電子商務解決方案
商業目標：上線半年內達成月交易額 500 萬元

核心功能（Must Have）

功能	描述
商品目錄	支援分類瀏覽、關鍵字搜尋、篩選排序
購物車	加入/移除商品、數量調整、優惠券套用
結帳付款	信用卡、行動支付、超商取貨付款
訂單管理	訂單查詢、狀態追蹤、退換貨申請

非功能性需求

首頁載入 < 2 秒
支援 10,000 同時在線
系統可用率 ≥ 99.95%

📌 填寫提醒
PRD 應由產品經理主導撰寫，技術團隊協同審查
每個功能需有明確的驗收條件（Acceptance Criteria）
定期與利害關係人同步更新進度
版本異動需記錄於版本歷程表中

PRD（產品需求文件｜Product Requirement Document）範本#

📋 使用說明#

何時使用本範本#

填寫原則#

📄 範本正文#

[產品/功能名稱] 產品需求文件（PRD）#

1. 文件資訊#

版本歷程#

審核紀錄#

2. 產品概述#

2.1 產品願景#

2.2 商業目標#

2.3 專案範圍#

2.4 成功標準#

3. 使用者輪廓（User Persona）#

3.1 目標使用者分類#

Persona 1：[使用者名稱/角色]#

Persona 2：[使用者名稱/角色]#

3.2 使用者旅程地圖（User Journey Map）#

4. 核心功能清單（Feature List）#

4.1 功能總覽#

4.2 功能詳細描述#

F-001：使用者註冊與登入#

5. 流程圖（Process Flow）#

5.1 主要業務流程#

5.2 使用者操作流程（User Flow）#

6. 介面原型（Wireframe）#

6.1 頁面清單#

6.2 Wireframe 規格#

頁面互動說明#

7. 非功能性需求（Non-Functional Requirements）#

7.1 效能需求#

7.2 安全需求#

7.3 可用性需求#

7.4 相容性需求#

8. 依賴與限制#

8.1 技術依賴#

8.2 業務限制#

9. 里程碑與時程#

10. 風險與緩解措施#

11. 術語定義#

12. 附件與參考#

範例：電子商務平台 PRD 摘要#

產品概述#

核心功能（Must Have）#

非功能性需求#