文檔模板分享:后臺產品需求用例
因為工作中寫最多的就是后臺產品的需求用例,所以先整理了這份文檔模板,在往后的文章中會陸續(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)描述:
列表頁面:
- 各查詢項為空,展示占位文本;
- 后臺分頁;
- 默認每頁顯示10項結果;
- 列表中可查看所有該登錄賬戶有權限查看的數(shù)據;
- 默認按更新時間排序。
新增頁面:
- 各輸入項為空,展示占位文本;
- 默認選擇….
修改頁面:本條數(shù)據上次成功保存內容。
數(shù)據頁面:
- 展示當前實時數(shù)據;
- 默認展示最近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é)議
一套下來,時間已經過去大半了吧?
感謝作者,已三連,能出一篇測試文檔中具體會包含哪些框架和元素嗎?
兩篇文章都挺不錯的,怎么不更新了呢,跳槽了?
你是技術轉做產品的嗎?
不是哦~之前是念的工科
有些內容還是不錯的,平時都有積累。值得學習。
一起進步~
寫后臺用例文檔時更多應該注意的是什么?
“3.3.1 P00 頁面名稱
設置頁面編號和名稱,插入視覺圖,使用數(shù)字標注,標明交互、初始狀態(tài)數(shù)據項等內容?!?br /> 此處描述沒有圖示很難理解,因為僅靠文字,腦補畫面不容易將全部描述項呈現(xiàn)出來,怕會有缺失。
不介意的話,舉個圖例把,謝謝
上方的圖就是示例,因為是模板里的所以不夠直觀~下篇文章注意,感謝閱讀~
用例和需求文檔有什么區(qū)別嗎
我理解用例是需求文檔的一部分,可能會把一個簡單的增刪改查功能的需求文檔拿出來作為一個用例。
希望對你有啟發(fā),大家看完多吐槽哦~
請問有文檔文件嗎
文檔模板內容其實和文章里一樣,工作實際寫的文檔可能不方便分享哦~
可以看一些實際的文檔案例嗎?后臺能找的參考實在是太少了呢