因為工作中寫最多的就是后臺產品的需求用例，所以先整理了這份文檔模板，在往后的文章中會陸續(xù)總結PRD中其他部分的模板。

1. 文檔模板背景介紹

• 需求用例：我團隊把一個需求（可理解為功能矩陣中的一行）的詳細描述、頁面、交互、數(shù)據項、基本流程這些能盡可能多描述地需求細節(jié)的內容稱為一個需求用例。
• 閱讀者：需求開發(fā)者、需求測試人
• 工具：Confluence（+JIRA）

我團隊寫文檔都是使用Confluence（一款在線文檔協(xié)作軟件，企業(yè)Wiki），結合同系列的JIRA進行項目管理，好用到飛起。

需求用例都是盡我所能寫得詳細，并且結合程序員們的反饋，不斷迭代。所以我的模板是最適合我團隊和業(yè)務的，并不是普世的，我提倡每個人都輸出自己的文檔模板。

這一版模板完成后大大提升了我的寫作效率，一個簡單的增刪改查需求，使用模板約30分鐘能完成。

希望這個模板能拋磚引玉，為你的模板提供一點思路。

2. 需求用例屬性

這一模塊代表了需求用例的基本屬性，尤其是文檔的狀態(tài)，在線協(xié)作時能提示開發(fā)和測試這個文檔進行到哪一步了，流程需要團隊內部達成一致。

可使用表格規(guī)范需求用例屬性，方便查閱。

暫時為空的項，填寫“暫無”。

3. 文檔正文

后臺產品的需求用例，我把正文分成關聯(lián)、描述、VI&UI、數(shù)據項和流程等幾個部分。實際應用后發(fā)現(xiàn)這是比較合理的方式，能最大程度上讓開發(fā)者根據不同時期的不同需要去理解需求。

例如在評審會時，大家只需要看用例描述和VI部分就能對需求有大致了解；計劃會時主要講解描述、VI&UI和流程部分；開發(fā)者實際開發(fā)時會著重看VI&UI和數(shù)據項部分。

我寫需求文檔有幾大準則，是需要時刻銘記和實踐的：

• 字不如表，表不如圖；
• 使用最少的字去描述，多利用各種符號；
• 排版要舒適，不能反人類；
• 盡量無歧義、準確、全面。

3.1 關聯(lián)用例

使用插入超鏈接快捷鍵” [ ”，關聯(lián)該需求用例的關聯(lián)用例。

3.1.1 前置用例

該需求的前置需求，可進行適當文字描述。

3.1.2 前版用例

若用例為優(yōu)化或升級，則需鏈接該需求的前一版本的用例，可進行適當文字描述。

3.1.3 相關用例

用例對其他用例有影響時，需關聯(lián)，如后臺需求用例會和前端需求用例聯(lián)系，可進行適當文字描述。

3.1.4 前臺用例

該需求用例功能所需要支持的前臺功能。如一個廣告Banner的增刪改查功能，對應前臺的Banner用例。

3.2 用例詳細描述

3.2.1 需求目的

實現(xiàn)需求的目的，和需求設計的目的，1…2…3…逐條列出

3.2.2 需求場景

實際場景，可用作圖表示，配合文字描述。

3.2.3 需求流程圖

需求中的業(yè)務流程圖、狀態(tài)流轉、操作流程等流程圖，少量文字描述。

3.2.4 需求規(guī)則

需求中若涉及規(guī)則，則需描述清楚，可配合實例，注意考慮極限情況。

3.3 VI&UI設計

這部分建議使用“左圖右字”的排版，便于閱讀。（Confluence中有“節(jié)”的設置，排版非常好用）

3.3.1 P00 頁面名稱

設置頁面編號和名稱，插入視覺圖，使用數(shù)字標注，標明交互、初始狀態(tài)數(shù)據項等內容。

每條交互都需要有編號。

使用標號和“→”描述交互過程，注意標清錯誤提示語；可使用動圖等形式表現(xiàn)稍稍復雜的交互。

圖片較長時，交互內容盡量標注在圖中對應位置旁邊。

3.3.2 交互

UC000.1：“P00 頁面名稱” 初始狀態(tài)（常見舉例）

描述該頁面初始進入時的樣子。不同業(yè)務頁面的初始狀態(tài)不同，但很多情況下可以復用。以下就是我經常使用的初始狀態(tài)描述：

列表頁面：

1. 各查詢項為空，展示占位文本；
2. 后臺分頁；
3. 默認每頁顯示10項結果；
4. 列表中可查看所有該登錄賬戶有權限查看的數(shù)據；
5. 默認按更新時間排序。

新增頁面：

1. 各輸入項為空，展示占位文本；
2. 默認選擇….

修改頁面：本條數(shù)據上次成功保存內容。

數(shù)據頁面：

1. 展示當前實時數(shù)據；
2. 默認展示最近7天數(shù)據趨勢圖。

UC000.2：…

UC000.3：…

3.4 數(shù)據項

使用列表標明涉及頁面中的數(shù)據項

3.4.1 輸入項

需要用戶輸入的數(shù)據項，例如篩選、新建時的輸入項

• 每個輸入項需要考慮：
• 字段名稱（簡潔、易于理解，注意與概念相似字段進行區(qū)分）
• 是否必填（填寫與否有何影響？）
• 使用組件（從規(guī)定的組件庫中選取，適當描述組件性質）
• 占位文本（Input字段，輸入框中的占位文字，提示用戶可輸入的內容）
• 數(shù)據來源（可選選項的來源）
• 權限限制（用戶權限對本字段有無影響？）
• 字段單位
• 字段類型（整數(shù)、小數(shù)、字母、符號等）
• 字段長度（≤？漢字）
• 字段范圍（數(shù)值范圍，可否為0？最大為？小數(shù)是否自動補齊？）
• 數(shù)據格式
• 搜索特點（模糊搜索）
• 可選選項（1- …；2-…）
• 解釋說明（是否需要文字提示用戶字段含義或用法）
• 極限情況（初始狀態(tài)、極限狀態(tài)）
• 可否重復（能否與其他條目的同一字段重復）
• 可否修改（修改后對本條數(shù)據、或其他系統(tǒng)的數(shù)據的影響、對客戶端的影響；什么時候可以修改）
• 是否聯(lián)動（與其他數(shù)據、與其他系統(tǒng)、與客戶端）
• 是否排序（排序規(guī)則）
• 展示預覽（為空時；輸入時；輸入完；查看時；列表中；客戶端；極限時）
• 只讀字段（不同情況下怎么展示只讀）
• 錯誤提示（為空或不滿足約束條件時的提示語，提示方式）
• 備注說明

約束條件需要結合業(yè)務，在每次的文檔寫作中不斷積累和總結。

3.4.2 展示/列表項

用戶在列表中查看或展示給用戶，不能進行操作的數(shù)據項

每個展示項需要考慮：

• 字段名稱
• 字段來源（新建、其他系統(tǒng)）
• 初始狀態(tài)（列表、預覽、數(shù)據報表…）
• 分頁類型（前臺or后臺，默認一頁幾條數(shù)據）
• 無數(shù)據時（如何展示？）
• 展示樣式（多種情況：為空時、多個值、很長時）
• 排序規(guī)則
• 備注說明

3.5 用例流程（基本流、備選流、異常流）

主要寫清流程描述，因為“3.2.3 需求流程圖”中已有流程圖，這一部分可以省略。

同樣，每個流程都需要編號，寫清前置、描述和預期結果。尤其是異常流，需要和開發(fā)、測試多進行討論和溝通。

3.5.1 基本流

【UC000-A】

• 前置條件：
• 流程描述：
• 預期結果：

3.5.2 備選流

【UC000-B】

• 前置條件：
• 流程描述：
• 預期結果：

3.5.3 異常流

【UC000-C】網絡異常

Massage（1s）錯誤提示：網絡異常，請稍后重試。

【UC000-D】輸入時不滿足約束（輸入后即能直接判斷）

控件下方錯誤提示，提示語詳見 4.數(shù)據項 中的 “約束條件” 一列。

【UC000-E】保存失敗

Massage（1s）錯誤提示：保存失敗，請稍后重試。繼續(xù)留在本頁。

..

3.6 名詞說明

用例中關于一些業(yè)務名詞的定義與說明。

3.7 測試方案

使用超鏈接關聯(lián)測試文檔，方便查看。

3.8 文檔版本

這里我使用的是Confluence的一個文檔版本插件，可以查看文檔不同版本之間的差異，但是和文檔狀態(tài)沒能關聯(lián)起來看，所以用的不多，但是對于查看文檔修改和修改內容還是很好用的。

本文由 @ZoeSunPM 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自unsplash，基于CC0協(xié)議