2023年如何寫一篇挑不出毛病的需求文檔

如何寫一篇挑不出毛病的需求文檔？class="size-fullwp-image-5780129aligncenter"src="/wp-files/2023/03/MsvN1C2BzTIlhsPZyZFB.jpg"alt=""width="900"height="420"/>

前言

需求文檔是產(chǎn)品經(jīng)理的基本功，也是產(chǎn)品力量的體現(xiàn)，產(chǎn)品力量行不行看文檔就能看出來。

我從實際工作+日?？偨Y(jié)，整理了一些自己寫PRD的方法，共享給各位，盼望能對各位有用~

一、原則與前提

在文章開頭前，我們簡潔看下在什么時候用、誰去用，來明確需求文檔的書寫原則：

產(chǎn)品需求評審的時候看；研發(fā)技術(shù)方案設(shè)計、敲代碼的時候看；UI進(jìn)行界面設(shè)計的時候看；測試寫測試用例、執(zhí)行用例的時候看。PRD文檔的目的就是讓每個項目成員知道需求為什么做、要做什么、怎么做。

所以可以得到PRD的書寫原則有：

有理有據(jù)：從項目成員知道為什么做；全面、清楚、精確?????：讓大家知道做什么、怎么做；易讀性：讓大家便利快捷的理解文檔內(nèi)容。明確了原則，還有2個前提：「需求類型、需求大小」

需求類型有：功能需求、接口需求、性能需求、策略需求、埋點需求、統(tǒng)計需求等等。需求大小：可以是從0-1的大項目，包含上邊的全部需求類型，還有就是日常迭代版本的小需求。我們接下來文章內(nèi)容都是基于以上原則與前提，接下來正文開頭~

二、需求文檔用啥寫

我們以終為始，先看需求文檔的呈現(xiàn)方式。目前主要有以下2類：

1.Axure一體化需求文檔

使用Axure將全部需求文檔，最終通過Axure打包供應(yīng)出去。好處是便利查看，看原型的基礎(chǔ)上又能看文檔說明。但有一種不是很“嚴(yán)厲?”的感覺。

2.Word版

通過Word進(jìn)行需求描述，并統(tǒng)一供應(yīng)。簡單留存，也比較正規(guī)，在閱讀上以文字為主。

詳細(xì)選擇那種方式，可以先看公司要求。

像我之前有公司要求，必需用word，就算是有大量原型的，也只能把頁面原型畫好，然后再復(fù)制到word里，在word寫需求內(nèi)容。

假如沒有要求，詳細(xì)采納的方式可以看不同的需求類型：

假如只涉及到畫原型的，可以使用Axure。

假如只有偏后端需求的，規(guī)律相關(guān)的需求，比如說是接口需求、算法需求，并不涉及到前端需求的，我們可以直接使用word寫。

假如是做的大項目，同時有功能需求，又有接口需求、算法需求的，我建議都放在一起，比如說都用Axure寫需求。

我之前做新項目的時候，同時供應(yīng)了功能需求的axure文檔+word版的接口需求，后來用例評審的時候，測試說不知道word版接口需求，之后我就統(tǒng)一寫在axure里了。

三、需求文檔包含哪些內(nèi)容

需求有大有小，同樣的需求文檔也有大有小，小到直接一句話描述，大到上百個原型頁面，好幾萬個字。

一句話的需求我們在這就不說了，我們說下正常的需求文檔。

不論是使用Axure還是word，也不論需求大小是什么，PRD文檔中一般需要包含以下內(nèi)容：

1.文檔修改記錄

需求文檔在需求評審、研發(fā)、測試過程中肯定會改的。

比如說加個限制，補充個遺漏的規(guī)律等等，不過我們肯定要記錄下修改內(nèi)容，并準(zhǔn)時更新需求文檔、準(zhǔn)時同步項目成員。

一般通過表格展現(xiàn)出以下內(nèi)容：

修改內(nèi)容：說清晰修改的哪個模塊，哪個頁面、哪個功能點。當(dāng)然也可以分成修改模塊、修改頁面多個列。修改緣由：就是為啥要修改，比如說規(guī)律缺失需要補充等等。修改人：誰改的。修改日期：修改時間。

在使用Axure時，我們可以在文檔修改記錄中加上文本鏈接跳轉(zhuǎn)，項目成員點擊文字可直接進(jìn)入到對應(yīng)頁面查看。

對于word，也是同樣的，加個文檔修改記錄。

對于文檔修改記錄，不僅在PRD文檔中可以用到，在寫其它文檔時都可以加上，比如操作手冊。

2.項目背景or需求背景

背景同樣也是有大有小，對于新項目，則需要介紹下整個項目的大背景。對于每個需求，我們同樣也可以簡潔說下需求背景。

參考格式如下：

當(dāng)前的現(xiàn)狀是什么，有哪些問題/痛點，這些問題導(dǎo)致了什么結(jié)果，為了解決這個問題，我們需要實行什么動作，達(dá)到什么目的，能夠獵取哪些收益，產(chǎn)生什么價值。

3.名詞解釋

假如有專業(yè)名詞，肯定要寫上。

在不同行業(yè)、不同公司、不同團(tuán)隊中都有特地的名詞，項目成員是不明白一些名詞的，這個時候肯定要說明。

比如說抗菌藥物DDD值，肯定的專業(yè)名詞，不說一般沒人知道。

另外在說名詞解釋的時候，盡量加上示例說明便利大家快速理解。

4.流程圖

當(dāng)涉及跨角色、跨系統(tǒng)、跨模塊、多推斷規(guī)律時，我們肯定要畫出來，讓各方更快地了解產(chǎn)品流程。

流程圖同樣有大有?。?/p>

包括整體產(chǎn)品業(yè)務(wù)流程圖、單個模塊的流程圖、單個功能的流程圖。

1）整體流程圖

為了將這個產(chǎn)品的功能業(yè)務(wù)串起來，可以不用畫的太具體，畫出大的概覽圖，從大而全的角度將這個項目表達(dá)出來。

一般是在0-1的新項目中畫，日常迭代的需求中不需要。

2）單個模塊功能的流程圖

當(dāng)一個功能模塊功能許多時，為了將模塊內(nèi)的功能串起來，說清晰單獨模塊的流程，這個就要畫的細(xì)致一點。

當(dāng)涉及到新的模塊時肯定要畫。

3）單個功能的流程圖

對于簡單的單個功能，涉及到的處理規(guī)律比較多時，我們也需要畫出單獨的流程圖進(jìn)行說明。

流程圖的類型有許多種，像業(yè)務(wù)流程圖、頁面流程圖、泳道圖、uml里的時序圖、用例圖等等。

我們可以基于不同流程圖的特性去選擇不同的類型，比如有多角色時，我們可以使用泳道圖。

對于UML，像用例圖、序列圖，在畫的時候有肯定的門檻，同樣的肯定會有團(tuán)隊成員看不懂。我是從來沒畫過，所以大家可以自行選擇學(xué)習(xí)與繪制。

對于頁面流程圖，是表達(dá)出頁面之間的跳轉(zhuǎn)規(guī)律，像移動端的頁面，我們可以直接平鋪出每個頁面，展現(xiàn)出頁面間的跳轉(zhuǎn)規(guī)律。

對于PC端產(chǎn)品，頁面尺寸較大，我們可以通過頁面名稱展現(xiàn)出頁面流程。

流程圖的能夠達(dá)到業(yè)務(wù)清晰，表明重點，項目成員能夠快速理解的目的就行。

5.需求說明

對需求的具體說明，這一點確定是必需的，我們下邊單獨說。

以上內(nèi)容是我認(rèn)為在寫需求文檔時，需要包含的內(nèi)容，下邊的內(nèi)容我們則可以自行選擇~

1）產(chǎn)品架構(gòu)圖

在0-1產(chǎn)品搭建的時候進(jìn)行展現(xiàn)，將整個產(chǎn)品抽象化，通過數(shù)據(jù)層、服務(wù)層、應(yīng)用層、呈現(xiàn)層等抽象層面表現(xiàn)出產(chǎn)品的整體架構(gòu)。

來自Processon

產(chǎn)品架構(gòu)圖是特別大的層面，當(dāng)你沒有獨立負(fù)責(zé)一條業(yè)務(wù)線的時候，很難有這種大的架構(gòu)概念。

當(dāng)你需要規(guī)劃一條產(chǎn)品線的時候，可以畫出來產(chǎn)品架構(gòu)圖，讓之后的產(chǎn)品方向再這個大的框架下去走。

我也是在最近這2年，獨立負(fù)責(zé)產(chǎn)品線的時候才開頭繪制的，主要是和領(lǐng)導(dǎo)們匯報使用的。

詳細(xì)怎么畫，大家可以在平臺上搜一下，有許多。

2）功能架構(gòu)圖or信息架構(gòu)圖

對于功能架構(gòu)圖，就是寫清晰產(chǎn)品功能的層級架構(gòu)，簡潔說就是一級菜單、二級菜單是什么，每個菜單里有哪些功能，展現(xiàn)出功能的層級關(guān)系。

我一次都沒有畫過。

對于功能架構(gòu)的展現(xiàn)，我一般在畫原型的時候規(guī)劃出來，然后直接畫原型。

當(dāng)然也可以通過思維導(dǎo)圖的方式畫出來，但是吧，畫出來也沒人看。

還有一個信息架構(gòu)圖，這個我也沒畫過。

我有很長的一段時候都沒整明白功能架構(gòu)圖與信息架構(gòu)圖有啥區(qū)分~

現(xiàn)在我的理解是：

功能架構(gòu)圖是展現(xiàn)出功能層級關(guān)系，體現(xiàn)出菜單-功能的層級規(guī)律。信息架構(gòu)圖是展現(xiàn)出每個功能頁面內(nèi)的展現(xiàn)字段內(nèi)容，主要用于研發(fā)設(shè)計表結(jié)構(gòu)與表字段。對于功能架構(gòu)圖和信息架構(gòu)圖，一般是在產(chǎn)品0-1的時候畫，而且涉及到的內(nèi)容比較多，多的內(nèi)容肯定沒人去看。

究竟要不要畫是一方面，大家肯定要知道功能結(jié)構(gòu)圖和信息架構(gòu)圖是個什么東西，詳細(xì)畫不畫大家自行選擇。

四、畫原型寫文檔

需求類型里有一個功能需求，這個就是每個產(chǎn)品避開不了的，所以我們單獨說下畫原型+寫文檔~

1.首先依據(jù)要做的需求范圍進(jìn)行分類

當(dāng)有多個需求類型時，按類型進(jìn)行分類，使用Axure時可以通過建立文件夾。

使用word則可以加個一級標(biāo)題。

目的是將需求有層級的依次展現(xiàn)出來。

然后在不同的文件夾下，在進(jìn)行分級。

比如「功能需求說明」文件夾下有多個功能模塊，則根據(jù)模塊/菜單名稱建立子文件夾，然后再在每個模塊下建立對應(yīng)頁面；

當(dāng)同一個頁面內(nèi)有多個tab頁/子頁面時：

對于PC端，我一般是分頁面說明；APP的頁面尺寸小，我們可以在一個Axure頁面內(nèi)統(tǒng)一說明。

然后再對每個頁面單獨畫原型，寫文檔。

2.需求文檔的表現(xiàn)方式

當(dāng)采納Axure寫需求文檔的時候，常見的布局是：左圖右文。

左邊展現(xiàn)原型圖，右邊展現(xiàn)需求說明。

對于word版，常為：原型頁面展現(xiàn)，單獨寫文檔說明。

3.提取公共規(guī)律，放入全局說明

在畫原型、寫文檔的時候，肯定會有相同的功能規(guī)律、相同的需求規(guī)律。

例如說后臺系統(tǒng)，會有一堆的列表，列表就涉及到分頁數(shù)量、默認(rèn)排序等。

我們可以直接統(tǒng)一使用全局說明。

將相同的功能規(guī)律、需求內(nèi)容當(dāng)在一個單獨的全局說明里，在全局說明里進(jìn)行單獨說明。

當(dāng)在某個頁面中需要說明的功能點已經(jīng)在「全局說明」里存在時，可以加個說明：請見全局說明。

同時對文字添加文字跳轉(zhuǎn)鏈接，閱讀者點擊可直接跳轉(zhuǎn)到對應(yīng)的全局說明頁面。

3.功能點序號標(biāo)注

先畫出原型圖，在原型中標(biāo)注「序號」，然后在右側(cè)根據(jù)相同的序號進(jìn)行功能需求描述。

標(biāo)注挨次：一般根據(jù)從左到右，從上到下的挨次。標(biāo)注哪些點：需要進(jìn)行功能說明的功能點，但是并不意味著每一個點都要進(jìn)行標(biāo)注。我一般根據(jù)從大到小，根據(jù)模塊化的方式。

以下方的表單頁面為例：

當(dāng)原型畫出后，在頁面上標(biāo)個序號[1]，對頁面進(jìn)行下簡介，一般說明頁面是什么，使用角色是誰。

然后連續(xù)標(biāo)注「返回」，對「返回」進(jìn)行說明。

由于點擊返回時，沒有添加其它推斷規(guī)律（如是否二次確認(rèn)），所以直接描述交互規(guī)律即可。

然后接著對下方的「患者信息」進(jìn)行標(biāo)注。

我們可以看到「患者信息」里有許多字段，我不建議對每個字段進(jìn)行說明。

我們直接對「患者信息」整個模塊進(jìn)行標(biāo)注，然后對每個字段進(jìn)行說明。

由于只是表單輸入，我們需要說明是否必填、采納什么組件、是能輸入文字、還是數(shù)字輸入框，數(shù)字范圍限制、數(shù)字小數(shù)點限制（如最多2位小數(shù)）、輸入小數(shù)點超過如何處理（是直接限制輸入，還是能四舍五入）、字符長度限制、當(dāng)字符輸入超長如何處理。

假如是采納選擇框，選擇框里的值是寫死的，還是從哪里取值。

……

這就是對需求的描述，我們需要盡可能的寫全，就是盡可能的把考慮到的限制加上，你寫的越全，在評審的時候，才會少挨懟。之后的需求變更才會少。

（現(xiàn)在看其實上邊的需求描述還是不全，比如漏了小數(shù)點位數(shù)說明，文本輸入框內(nèi)能不能輸入表情emoji符號等等）

當(dāng)頁面內(nèi)消失彈窗時，我們需要對彈窗里的內(nèi)容進(jìn)行說明，單獨對彈窗里功能點進(jìn)行標(biāo)注，然后再下方連續(xù)對需求進(jìn)行說明。

對于彈窗里的內(nèi)容，我一般從「1」開頭重新編號。不把序號挨次和其他頁面夾雜在一起。當(dāng)調(diào)整一個功能點后，需要重新編號，增加了多余的工作量。

4.需求具體書寫

對需求的具體描述，是最核心的內(nèi)容，我們可以根據(jù)下方的格式來寫：

標(biāo)題：功能點名稱。角色權(quán)限：如當(dāng)前登錄用戶角色為管理員時，則顯示此按鈕。規(guī)章規(guī)律：主要有校驗規(guī)律、前置條件、觸發(fā)時機等，當(dāng)涉及到的校驗規(guī)律太多時，可以采納分行分段、添加序號、使用表格等方式，將每個規(guī)律有條理的全部說明清晰。比如：確定按鈕。

當(dāng)角色為「管理員」時，展現(xiàn)出確認(rèn)按鈕；

當(dāng)XX未填寫時，按鈕顯示為禁用狀態(tài)，點擊時消失toast提示：請?zhí)顚慩XX。當(dāng)XXX、XXX全部填寫后，按鈕置為可點擊狀態(tài)，點擊后跳轉(zhuǎn)至XXX頁面。極值說明：如輸入框輸入字符的長度，數(shù)字輸入的范圍值。

交互說明：如點擊調(diào)整至XXX頁面。

在寫需求時，依據(jù)不同的需求內(nèi)容，盡可能的將全部內(nèi)容寫清晰。

這個時候肯定會有一個問題：寫不全。

我們可以明確一點，沒有產(chǎn)品經(jīng)理把全部狀況都考慮到，喬布斯、張小龍也考慮不了那么全。

我們需要做的是盡可能的考慮全，盡可能是個很虛的詞，受行業(yè)閱歷、項目閱歷等影響，不同級別的產(chǎn)品經(jīng)理的需求文檔寫的水平很顯而易見，當(dāng)然你考慮的越全面，產(chǎn)品力量可以說就越強。

我們可以在需求評審前，先和研發(fā)提前碰下，避開有大的遺漏。

也可以借助「需求自查表」來幫助，自查出遺漏的說明。

5.其它

1）文字描述言簡意賅，避開口語化，別使用模棱兩可的文字。需求文檔里的內(nèi)容必需明確，別寫「盡量」「盡快」。

2）添加示例：被誤會是表達(dá)者的宿命，文字說明都會有肯定的片面理解，對于比較簡單的內(nèi)容，我們可以添加示例說明：

同時在原型上，盡量使用貼合實際場景的內(nèi)容。比如說時間別寫出：13:88:99。

3）為了便于閱讀，可以采納多分段，多分行，加序號的方式。

4）使用標(biāo)點符號，將內(nèi)容說清晰，如：點擊「確認(rèn)」按鈕，跳轉(zhuǎn)至【XXX頁面】。

關(guān)于標(biāo)點符號，大家可以看這個文章：/p/359255980

5）結(jié)合axure的特性，添加文字鏈接，便于閱讀者快速跳轉(zhuǎn)查看，不用自己找。

添加「返回」按鈕，比如閱讀者跳轉(zhuǎn)到【全局說明頁面】，看完后，想在回到來源頁連續(xù)看需求，我們可以在【全局說明頁面】中添加個「返回來源頁」按鈕，加個返回上一頁的交互，直接能返回。

6）對于變量值，使用特別符號標(biāo)登記

對于會變化的值，我一般使用用兩個百分號，如下方的‘科室名稱’，會依據(jù)不同的選擇展現(xiàn)不同的名稱，所以我就通過‘%科室名稱%’進(jìn)行表示，然后單獨說明，并舉例說明。

7）重要內(nèi)容進(jìn)行標(biāo)記

可以通過加粗、換個顏色等方式進(jìn)行提示，當(dāng)內(nèi)容較多的時候，大家很簡單忽視掉，所以很有必要進(jìn)行加粗加大標(biāo)色提示。

8）涉及到規(guī)律時，可以使用公式進(jìn)行說明

如：當(dāng)A+B≥100時，則XXXX。

9）寫完后自己再過一遍

就像上學(xué)做題后，自己zai再驗算一遍，在寫文檔的時候，自己確定會有抽風(fēng)的時候，不知道哪個地方就給寫錯了。

10、對外供應(yīng)時，對于Axure，可以打包出html供應(yīng)。