我們接下來文章內(nèi)容都是基于以上原則與前提，接下來正文開始~

二、需求文檔用啥寫

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

1. Axure一體化需求文檔

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

2. Word版

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

具體選擇那種方式，可以先看公司要求。

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

如果沒有要求，具體采用的方式可以看不同的需求類型：

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

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

如果是做的大項(xiàng)目，同時(shí)有功能需求，又有接口需求、算法需求的，我建議都放在一起，比如說都用Axure寫需求。

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

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

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

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

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

1. 文檔修改記錄

需求文檔在需求評(píng)審、研發(fā)、測試過程中一定會(huì)改的。

比如說加個(gè)限制，補(bǔ)充個(gè)遺漏的邏輯等等，不過我們一定要記錄下修改內(nèi)容，并及時(shí)更新需求文檔、及時(shí)同步項(xiàng)目成員。

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

• 修改內(nèi)容：說清楚修改的哪個(gè)模塊，哪個(gè)頁面、哪個(gè)功能點(diǎn)。當(dāng)然也可以分成修改模塊、修改頁面多個(gè)列。
• 修改原因：就是為啥要修改，比如說邏輯缺失需要補(bǔ)充等等。
• 修改人：誰改的。
• 修改日期：修改時(shí)間。

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

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

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

2. 項(xiàng)目背景 or 需求背景

背景同樣也是有大有小，對于新項(xiàng)目，則需要介紹下整個(gè)項(xiàng)目的大背景。對于每個(gè)需求，我們同樣也可以簡單說下需求背景。

參考格式如下：

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

3. 名詞解釋

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

在不同行業(yè)、不同公司、不同團(tuán)隊(duì)中都有專門的名詞，項(xiàng)目成員是不明白一些名詞的，這個(gè)時(shí)候一定要說明。

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

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

4. 流程圖

當(dāng)涉及跨角色、跨系統(tǒng)、跨模塊、多判斷邏輯時(shí)，我們一定要畫出來，讓各方更快地了解產(chǎn)品流程。

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

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

1）整體流程圖

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

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

2）單個(gè)模塊功能的流程圖

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

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

3）單個(gè)功能的流程圖

對于復(fù)雜的單個(gè)功能，涉及到的處理邏輯比較多時(shí)，我們也需要畫出單獨(dú)的流程圖進(jìn)行說明。

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

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

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

對于頁面流程圖，是表達(dá)出頁面之間的跳轉(zhuǎn)邏輯，像移動(dòng)端的頁面，我們可以直接平鋪出每個(gè)頁面，展示出頁面間的跳轉(zhuǎn)邏輯。

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

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

5. 需求說明

對需求的詳細(xì)說明，這一點(diǎn)肯定是必須的，我們下邊單獨(dú)說。

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

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

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

來自Processon

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

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

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

具體怎么畫，大家可以在平臺(tái)上搜一下，有很多。

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

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

我一次都沒有畫過。

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

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

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

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

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

• 功能架構(gòu)圖是展示出功能層級(jí)關(guān)系，體現(xiàn)出菜單-功能的層級(jí)邏輯。
• 信息架構(gòu)圖是展示出每個(gè)功能頁面內(nèi)的展示字段內(nèi)容，主要用于研發(fā)設(shè)計(jì)表結(jié)構(gòu)與表字段。

對于功能架構(gòu)圖和信息架構(gòu)圖，一般是在產(chǎn)品0-1的時(shí)候畫，而且涉及到的內(nèi)容比較多，多的內(nèi)容一定沒人去看。

到底要不要畫是一方面，大家一定要知道功能結(jié)構(gòu)圖和信息架構(gòu)圖是個(gè)什么東西，具體畫不畫大家自行選擇。

四、畫原型寫文檔

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

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

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

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

目的是將需求有層級(jí)的依次展示出來。

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

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

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

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

然后再對每個(gè)頁面單獨(dú)畫原型，寫文檔。

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

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

左邊展示原型圖，右邊展示需求說明。

對于word版，常為：原型頁面展示，單獨(dú)寫文檔說明。

3. 提取公共邏輯，放入全局說明

在畫原型、寫文檔的時(shí)候，一定會(huì)有相同的功能邏輯、相同的需求邏輯。

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

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

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

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

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

3. 功能點(diǎn)序號(hào)標(biāo)注

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

• 標(biāo)注順序：一般按照從左到右，從上到下的順序。
• 標(biāo)注哪些點(diǎn)：需要進(jìn)行功能說明的功能點(diǎn)，但是并不意味著每一個(gè)點(diǎn)都要進(jìn)行標(biāo)注。

我一般按照從大到小，按照模塊化的方式。

以下方的表單頁面為例：

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

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

因?yàn)辄c(diǎn)擊返回時(shí)，沒有添加其它判斷邏輯（如是否二次確認(rèn)），所以直接描述交互邏輯即可。

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

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

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

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

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

……

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

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

當(dāng)頁面內(nèi)出現(xiàn)彈窗時(shí)，我們需要對彈窗里的內(nèi)容進(jìn)行說明，單獨(dú)對彈窗里功能點(diǎn)進(jìn)行標(biāo)注，然后再下方繼續(xù)對需求進(jìn)行說明。

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

4. 需求詳細(xì)書寫

對需求的詳細(xì)描述，是最核心的內(nèi)容，我們可以按照下方的格式來寫：

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

比如：確定按鈕。

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

1. 當(dāng)XX未填寫時(shí)，按鈕顯示為禁用狀態(tài)，點(diǎn)擊時(shí)出現(xiàn)toast提示：請?zhí)顚慩XX。
2. 當(dāng)XXX、XXX全部填寫后，按鈕置為可點(diǎn)擊狀態(tài)，點(diǎn)擊后跳轉(zhuǎn)至XXX頁面。

極值說明：如輸入框輸入字符的長度，數(shù)字輸入的范圍值。

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

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

這個(gè)時(shí)候一定會(huì)有一個(gè)問題：寫不全。

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

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

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

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

5. 其它

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

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

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

3）為了便于閱讀，可以采用多分段，多分行，加序號(hào)的方式。

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

關(guān)于標(biāo)點(diǎn)符號(hào)，大家可以看這個(gè)文章：https://zhuanlan.zhihu.com/p/359255980

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

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

6）對于變量值，使用特殊符號(hào)標(biāo)記下

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

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

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

8）涉及到邏輯時(shí)，可以使用公式進(jìn)行說明

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

9）寫完后自己再過一遍

就像上學(xué)做題后，自己zai再驗(yàn)算一遍，在寫文檔的時(shí)候，自己肯定會(huì)有抽風(fēng)的時(shí)候，不知道哪個(gè)地方就給寫錯(cuò)了。

10、對外提供時(shí)，對于Axure，可以打包出html提供。

如果是word版本，可以提供出pdf版。

以上是對功能需求的說明，對于接口需求、性能需求、埋點(diǎn)需求等非功能性需求，當(dāng)涉及到的時(shí)候，一定要寫上，不然就是需求遺漏了。

我之前一直以為產(chǎn)品經(jīng)理只需要寫功能需求就夠了。

有一次讓我寫接口需求，我就很郁悶，這明明是技術(shù)的活，干嘛產(chǎn)品寫。后來，我明白了一件事，產(chǎn)品經(jīng)理不往前站，之后就會(huì)是一堆坑。

除了接口需求，還是像研發(fā)數(shù)據(jù)庫建表時(shí)，這些我也建議產(chǎn)品經(jīng)理去介入，因?yàn)楸砝镉心男┳侄?，字段最大長度是多少，需要建哪些字段等等，都是和業(yè)務(wù)有關(guān)系的。

舉個(gè)示例，藥品的「規(guī)格」這個(gè)字段，研發(fā)把最大長度設(shè)置成250個(gè)字符，但是在實(shí)際業(yè)務(wù)上，「規(guī)格」會(huì)有2000個(gè)字的情況。

研發(fā)絕對是不理解的，所以最清楚這個(gè)情況的是產(chǎn)品，就需要提醒研發(fā)關(guān)注下。避免上線后，字?jǐn)?shù)超長導(dǎo)致保存錯(cuò)誤。

對于性能需求怎么寫，大家可以看這篇：《5000字詳解性能需求》。

對于接口需求、埋點(diǎn)需求等大家可以在平臺(tái)上搜一下，接口需求可以看：http://www.codemsi.com/pmd/2297401.html

總結(jié)

寫出好的需求文檔受很多方面的影響，從前期的需求分析，當(dāng)確定業(yè)務(wù)流程，然后再到畫原型，最終把PRD寫出來，這里邊涉及到的內(nèi)容非常非常多。

這篇文章是給大家提供的概述，大家可以在日常中總結(jié)積累，多和項(xiàng)目成員溝通，每一次需求評(píng)審就是一次淬煉，挨個(gè)一次懟后就總結(jié)，下次別再犯。

另外，當(dāng)你把一篇完美的需求文檔交付后，一定會(huì)有研發(fā)、測試不看的，只會(huì)問，就不看文檔。我一般是“微笑服務(wù)”，把文檔內(nèi)容截個(gè)圖發(fā)過去。