如何寫需求文檔--基礎(chǔ)篇

時間：2023-05-23 23:36:01 | 來源：網(wǎng)站運(yùn)營

時間：2023-05-23 23:36:01 來源：網(wǎng)站運(yùn)營

如何寫需求文檔--基礎(chǔ)篇：文章來源：https://www.dankal.cn

書寫需求文檔是產(chǎn)品經(jīng)理的必修課，可以說需求文檔貫穿了我們的工作，從接手項(xiàng)目到原型設(shè)計、項(xiàng)目開發(fā)、測試驗(yàn)收都必不可少。

一、為什么需要寫需求文檔

第一，對于開發(fā)，需求文檔就是產(chǎn)品經(jīng)理和開發(fā)溝通的工具，一份清晰的需求文檔不僅能和開發(fā)說明“項(xiàng)目要干什么”，“要實(shí)現(xiàn)什么功能”，而且也能交代清楚“交互和跳轉(zhuǎn)的邏輯是什么”、“每種情況下的處理邏輯是什么”，可以減少開發(fā)期間溝通成本，提成開發(fā)完整度。大多數(shù)情況下我們都會在測試階段拖延很長時間，并不可避免地補(bǔ)充了億點(diǎn)細(xì)節(jié)。因?yàn)榇蠖鄶?shù)開發(fā)經(jīng)常只會以你提供需求文檔為準(zhǔn)，需求文檔以外的不在他們的工作范圍，如果你的文檔描述的越細(xì)，后期測試階段可以花更少的時間來彌補(bǔ)開發(fā)漏掉的需要處理的細(xì)節(jié)。

第二，對于測試，需求文檔是他們工作推進(jìn)的標(biāo)準(zhǔn)。一個項(xiàng)目能不能順利驗(yàn)收其實(shí)測試也起到很多作用。而一份完整的需求文檔可以保證讓測試可以按照項(xiàng)目按照你所設(shè)想的方向收尾，減少后期產(chǎn)品驗(yàn)收的工作量。

第三，對于產(chǎn)品經(jīng)理，首先，驗(yàn)收開發(fā)交付的產(chǎn)品時，要以需求文檔為準(zhǔn)。其次，我們每個可能手頭上都不止一項(xiàng)目，沒有人有過目不忘的記憶。一份詳細(xì)的需求文檔可以方便后期迭代時回溯歷史需求，或者項(xiàng)目交接便利后來者的工作，也方便我們對于自己的工作進(jìn)行復(fù)盤。

二、如何寫需求文檔

1、 搭建框架

在寫需求文檔前，需要先搭建框架，其實(shí)我們在拿到業(yè)務(wù)部的需求時，已經(jīng)有一個項(xiàng)目的大概框架了。這個時候我們則需要把每個模塊盡可能細(xì)化到功能點(diǎn)，其實(shí)就是先寫目錄。結(jié)合每個功能的操作，把涉及到多個頁面或多個系統(tǒng)的狀態(tài)變化整理出來；同時也可以檢查下大框架下的內(nèi)容是不是有遺漏，有沒有遺漏描述某一項(xiàng)功能邏輯。

在這一步我們基本就可以把一級菜單、二級菜單以及功能描述的大點(diǎn)梳理出來。一般我的思路：一級菜單是大的功能模塊（比如小程序首頁、后臺用戶管理）->二級菜單具體功能點(diǎn)/列表（比如小程序首頁輪播圖、后臺用戶管理用戶列表）->功能描述再從面到點(diǎn)細(xì)化（比如先說明用戶列表展示字段、有哪些操作，在具體描述每個操作的說明）。

2、功能描述

通常完成了目錄框架，自己對整個需求就很清晰了。接下來就是挨個補(bǔ)齊具體的需求的功能描述。那么功能描述要怎么寫呢，我們經(jīng)常會很糾結(jié)，需求到底要寫到多細(xì)，常常以為寫的很詳細(xì)了，結(jié)果研發(fā)還是有很多疑問。除了功能的規(guī)則外，還需體現(xiàn)以下幾點(diǎn)

1. 輸入框

輸入框主要用途是輸入內(nèi)容，需要注意：

（1）基本說明

• 字段類型：文本/數(shù)字/時間等
• 長度限制：11位；超過xx位省略處理
• 是否必填：是/否
• 校驗(yàn)規(guī)則：為空校驗(yàn)、有效性校驗(yàn)

（2）交互說明

• 調(diào)取鍵盤類型、選擇器的類型等

（3）特殊情況

• 默認(rèn)回顯用戶手機(jī)號或者其他的功能要求

2. 按鈕

這里的按鈕是指可以點(diǎn)擊的單個對象：按鈕、鏈接文字、圖標(biāo)等。需要注意：

• 交互說明：詳細(xì)列舉各狀態(tài)（未登錄時、非會員用戶等）下，點(diǎn)擊按鈕的交互，以及對應(yīng)的結(jié)果（成功、失敗、跳轉(zhuǎn)頁面等）。
• 操作提醒：列舉各種操作結(jié)果對應(yīng)的toast提示語
• 通知：操作完成后如果觸發(fā)短信通知、或者推送消息

3. 文本展示

頁面文本展示信息。由于用戶身份、狀態(tài)的改變或者按鈕交互，會導(dǎo)致文本改變，有的甚至是樣式的改變。需要需注意：

• 長度規(guī)則：字?jǐn)?shù)限制、x行顯示多余省略等
• 狀態(tài)說明：在不同條件下可以呈現(xiàn)不同的狀態(tài)
• 排序規(guī)則：按照創(chuàng)建時間降序、優(yōu)先級排序等

4. 整體回顧

在完成需求文檔后，找個時間靜下來從頭閱讀一遍。這一步可以差缺補(bǔ)漏，補(bǔ)充一下細(xì)節(jié)、排查下邏輯是否嚴(yán)謹(jǐn)。

5. 其它補(bǔ)充

1. 及時將開發(fā)過程中與開發(fā)討論的細(xì)節(jié)、需求的調(diào)整、補(bǔ)充記錄下。

人無完人，我們沒辦法可以將每個需求點(diǎn)都考慮的非常細(xì)，開發(fā)過程總會遇到遺漏的細(xì)節(jié)或者需要調(diào)整方案的地方。討論過后記得及時更新需求文檔，方便同步項(xiàng)目其他成員，也方便后期回溯。

2. 將常用交互規(guī)則以及項(xiàng)目特定的名次定義寫在全局說明里。

比如列表一頁展示多少條數(shù)據(jù)、時間的格式、一些特殊名次的解釋（比如土地工項(xiàng)目中關(guān)于月度銷售額的解釋）等寫在全局的說明，方便查閱和管理。

3、整理屬于自己的模板庫。

隨著項(xiàng)目的積累，其實(shí)有很多功能是重疊的?？梢赃m時整理一些通用的“套路”出來復(fù)用即規(guī)范了自己的文檔，也減少重復(fù)工作量。