用戶需求文檔怎么寫？

       許多剛開始開發(fā)產(chǎn)品的人，首先要了解的就是如何繪制產(chǎn)品原型，如何編寫需求文檔，這是很奇怪的。比如在這個平臺上可以搜索到大量關(guān)于需求文檔的文章，告訴大家需求文檔應(yīng)該怎么寫，但很少提到為什么要這樣寫？每個人都在關(guān)注如何實(shí)現(xiàn)，如何呈現(xiàn)，但并沒有關(guān)注為什么會這樣寫？象許多大咖常說的術(shù)道一樣，術(shù)重要，道更重要，知其然，知其所以然。下面就由小編為您帶來用戶需求文檔怎么寫的相關(guān)介紹。

暢寫Office

3.2

20條點(diǎn)評

咨詢產(chǎn)品

免費(fèi)試用

解決用戶選型困難的好軟件，有各維度的信息

客戶案例

暫無

合作品牌

57

一、需求文檔的起源

     碰到任何問題，最長見的思維方式即為：問題三要素——是什么、為什么、怎么做。這是幾乎所有行業(yè)、所有人群面對事情時，最常見的思維方式。

   筆者認(rèn)為基于最經(jīng)典、高效、實(shí)用的思維方式的基礎(chǔ)上，可以每個人針對不同的知識體系、思考方式、經(jīng)驗(yàn)總結(jié)等維度，總結(jié)出自己的思維方式。

   筆者常使用的方式為多年前從社會經(jīng)濟(jì)學(xué)老師那里學(xué)來的，做了補(bǔ)充和優(yōu)化，分享給大家：在特定的時間、特定的地點(diǎn)、特定的人群因?yàn)樘囟ǖ脑蚨隽颂囟ǖ氖录＿_(dá)成該特定事件前，有哪些預(yù)期，實(shí)際達(dá)成的效果是什么樣的，中間有怎么的落差，以后處理該類事件時，如何優(yōu)化方式。

   按照上述思維方式，我們將要寫的需求文檔當(dāng)做一個特定的事件，通過剖析該特定事件被觸發(fā)的前置條件、后置補(bǔ)充內(nèi)容，來實(shí)現(xiàn)對需求文檔的分析。

二、什么是需求文檔？

    筆者將需求文檔定義為：用于闡述產(chǎn)品，滿足協(xié)同人員開發(fā)的內(nèi)容文檔。該定義中有兩個重要點(diǎn)：

1. 闡述

    即為說明要開發(fā)的產(chǎn)品是什么。此處的“是什么”區(qū)別于產(chǎn)品說明文檔，產(chǎn)品說明文檔類似于商品說明書，用于告知使用者我的產(chǎn)品該怎么使用。

    而此處的“是什么”是告知該產(chǎn)品的相關(guān)人員，該產(chǎn)品有哪些功能，這個功能要怎么呈現(xiàn)，該怎么實(shí)現(xiàn)。具體包含以下幾個方面：

（1）為什么要做這個產(chǎn)品？

該產(chǎn)品是來自哪里的需求，是內(nèi)部版本迭代優(yōu)化、Bug修復(fù)、新增功能點(diǎn)，還是來自業(yè)務(wù)部門的需求，或者來自用戶的反饋需求。

必須交代清楚做該產(chǎn)品的項(xiàng)目背景，一方面有利于開發(fā)人員更好的了解整體項(xiàng)目，從而更順利地制定項(xiàng)目計(jì)劃、項(xiàng)目進(jìn)度、項(xiàng)目達(dá)成；

另一方面，產(chǎn)品開發(fā)完成后存檔的文檔，有助于后續(xù)對該產(chǎn)品的復(fù)盤、版本迭代，Bug問題溯源，甚至對出現(xiàn)人員異動時，有助于接盤人員快速了解項(xiàng)目，熟悉產(chǎn)品整體的前因后果。

（2）該產(chǎn)品要解決哪些沖突？

需求來自于用戶的沖突，用戶在使用中遇到了什么困難、疑惑、焦慮等不可調(diào)和的問題等待被解決。

在與用戶開展調(diào)研、訪談等溝通時，充分了解用戶的沖突，及急需解決的痛點(diǎn)，有助于產(chǎn)品經(jīng)理在產(chǎn)品規(guī)劃階段，更精準(zhǔn)地把握好方向，做出更符合用戶訴求的產(chǎn)品。

同時，在了解沖突的溝通中，除了精準(zhǔn)獲取到用戶的核心訴求，還會得到很多非核心訴求，這些來自于用戶潛意識中的需求，為以后產(chǎn)品的發(fā)展提供了很好的幫助。

將這些需求羅列出來，整理到需求池，有助于以后與用戶、業(yè)務(wù)進(jìn)行再次溝通時作對比，從而去偽存真，對需求池中的需求做好優(yōu)先級排序，并根據(jù)實(shí)際業(yè)務(wù)發(fā)展階段和公司整體要求，劃分好產(chǎn)品階段，對需求池中的需求進(jìn)行實(shí)現(xiàn)，從而促使產(chǎn)品朝向更好的方向發(fā)展。

（3）該產(chǎn)品實(shí)現(xiàn)了哪些目的？

任何產(chǎn)品的實(shí)現(xiàn)，不僅僅要滿足用戶的需求，更要在解決沖突時達(dá)成更多的目的。而這個目的分為物質(zhì)層面和精神層面兩個維度。

需求文檔怎么寫

三、需求文檔的意義是什么？

把正確的東西交給正確的人，滿足協(xié)同人員的訴求，即是需求文檔存在的意義。

如何寫出滿足協(xié)同人員訴求的需求文檔？首先，需要觀察不同的協(xié)同人員具體的工作場景，基于他們工作場景中的沖突，發(fā)現(xiàn)他們的需求，從而輸出的解決方案，就是最好的需求文檔。

1. 產(chǎn)品經(jīng)理的訴求

（1）產(chǎn)品部門的版本需求討論、需求評審會。

在版本任務(wù)的討論中，在與其他產(chǎn)品經(jīng)理講述所規(guī)劃的功能時， 版本記錄、項(xiàng)目背景、項(xiàng)目框架圖、流程圖，可以快速讓其他產(chǎn)品經(jīng)理了解整體項(xiàng)目，并根據(jù)項(xiàng)目背景，給出意見。

（2）與其他產(chǎn)品經(jīng)理所負(fù)責(zé)的內(nèi)容有交叉點(diǎn)。

當(dāng)一個完整項(xiàng)目，每個產(chǎn)品經(jīng)理負(fù)責(zé)部分內(nèi)容的時候，各自負(fù)責(zé)部分功能的需求文檔有助于其他產(chǎn)品經(jīng)理從文檔中發(fā)現(xiàn)交叉點(diǎn)中的銜接是否合適，各功能模塊的整體融合性。

（3）Bug處理。

再厲害的程序員也不敢保證產(chǎn)品上線后不出現(xiàn)任何問題，當(dāng)產(chǎn)品上線后出現(xiàn)問題，需求文檔有助于產(chǎn)品經(jīng)理快速找到規(guī)劃的初衷，根據(jù)之前的情境給出精準(zhǔn)的解決方案。

（4）版本迭代。

當(dāng)產(chǎn)品在不同時期，做不同的版本迭代時，之前的需求文檔尤為重要，有助于負(fù)責(zé)該項(xiàng)目的產(chǎn)品經(jīng)理快速熟悉往期規(guī)劃的初衷、目的和當(dāng)前的效果及不足，并在迭代版本中對往期問題進(jìn)行修復(fù)，在新的規(guī)劃中避免不必要的坑。

（5）人員異動。

如果出現(xiàn)人員異動（人員項(xiàng)目變更、人員離職等），有助于新接手的產(chǎn)品經(jīng)理快速熟悉項(xiàng)目，確保項(xiàng)目規(guī)劃不會因個人經(jīng)驗(yàn)、個人喜好、習(xí)慣等原因，出現(xiàn)太大的偏差。

基于以上場景和目的，其他產(chǎn)品經(jīng)理對需求文檔的訴求需要得到的信息：誰、在什么時間、因?yàn)槭裁丛颍隽耸裁磧?nèi)容，滿足了什么人的需求，變動內(nèi)容及節(jié)點(diǎn)、階段性規(guī)劃。

2. 設(shè)計(jì)師的訴求

設(shè)計(jì)師是項(xiàng)目實(shí)施階段的第一步。確定版的需求在落地執(zhí)行時，首先是由設(shè)計(jì)師開始制作設(shè)計(jì)圖。項(xiàng)目的整體功能有哪些、基于什么背景、未來的規(guī)劃方向，需要在文檔中給出建議和說明，有助于設(shè)計(jì)師按照產(chǎn)品經(jīng)理的設(shè)想，設(shè)計(jì)出符合或高于期待的產(chǎn)品設(shè)計(jì)圖。

基于上述場景和目的，針對設(shè)計(jì)師角色，產(chǎn)品經(jīng)理在編寫需求文檔時，需要告知的信息：因?yàn)槭裁丛颍o什么特點(diǎn)的群體，做什么圖，當(dāng)前競品什么情況、公司什么情況、市場什么情況，想達(dá)到什么效果，后期發(fā)展方向（業(yè)務(wù)、功能、設(shè)計(jì)方向等）。

3. 開發(fā)人員的訴求（前端、APP、后臺、測試）

1. 前端開發(fā)：開發(fā)過程中，側(cè)重了解涉及前端部分的頁面功能、交互效果、交互邏輯；
2. APP開發(fā)：開發(fā)過程中，側(cè)重了解頁面元素、頁面樣式、功能、與后臺間的接口參數(shù)傳遞；
3. 后臺開發(fā)：開發(fā)過程中，側(cè)重了解功能、這些功能在后臺的數(shù)據(jù)結(jié)構(gòu)搭建、如何建表、功能邏輯、與前臺兼的接口參數(shù)傳遞；
4. 測試工程師：在產(chǎn)品實(shí)現(xiàn)過程中，側(cè)重從產(chǎn)品規(guī)劃中了解整體功能，從而寫測試用例，以及產(chǎn)品上線前根據(jù)設(shè)計(jì)圖的樣式、文檔表述的功能規(guī)則，做功能測試。

基于刪除場景，產(chǎn)品經(jīng)理在編寫需求文檔時，需要告知開發(fā)人員的信息：因?yàn)槭裁丛颍槍κ裁错?xiàng)目，做什么功能，包含哪些頁面元素、頁面樣式、交互邏輯、實(shí)現(xiàn)效果。

4. 注意事項(xiàng)

盡信書不如無書。各公司的組織架構(gòu)、部門角色劃分、業(yè)務(wù)開展的推動因素、公司發(fā)展所處的階段均不相同，雖大道同源，但總有差異化表現(xiàn)。

需要產(chǎn)品經(jīng)理針對協(xié)同人員做好分層、分類，切實(shí)與相關(guān)人員深入溝通，了解他們的習(xí)慣，了解他們的認(rèn)知，輸出他們需要的需求文檔，才能夠確保信息的透明化，保證開發(fā)人員全面了解規(guī)劃的內(nèi)容。

同時，輔助以良好的溝通機(jī)制和技巧，則有助于開發(fā)效率的提高和產(chǎn)品上線的進(jìn)度保障。

四、如何寫需求文檔？

1. 寫文檔先看人

需求文檔與產(chǎn)品經(jīng)理前期做用戶調(diào)研時的用戶畫像很相似。

在做用戶畫像時，通過與目標(biāo)群體各種方式的溝通，獲取用戶的基本信息、興趣、習(xí)慣、家庭情況、對產(chǎn)品相關(guān)業(yè)務(wù)的了解程度、接受程度、煩惱和期待等等，從而建立用戶檔案，輸出用戶的判斷結(jié)果。

在寫需求文檔前，面對我們的用戶——相關(guān)協(xié)同人員，產(chǎn)品經(jīng)理需要去了解他們。了解他們的工作方式、工作習(xí)慣、工作態(tài)度、工作認(rèn)知、工作能力等與工作相關(guān)的內(nèi)容，同時，對他們與人相處的方式、生活習(xí)慣、興趣愛好等等的了解，有助于產(chǎn)品經(jīng)理更全面的了解，從而建立更加立體的用戶畫像。

在輸出判斷結(jié)果時會更準(zhǔn)確，寫需求文檔會更有側(cè)重點(diǎn)——哪些是他們需要知道的，哪些是他們需要特別詳細(xì)表述的，哪些是需要特殊標(biāo)注的，哪些是省略表述即可的。

2. 文檔規(guī)范

（1）版本記錄

1. 誰：該文檔是誰編寫的，便于快速找到對應(yīng)的負(fù)責(zé)人員，同時，后期有助于在需求文檔庫中建檔分類。
2. 時間：什么時間編寫的該文檔，旨在告知該功能是什么時間要開始做，便于后期溯源時，快速定位。
3. 事件：針對什么產(chǎn)品、什么功能做的規(guī)劃，其實(shí)就是文檔標(biāo)題。
4. 版本號：便于記錄產(chǎn)品不同版本的節(jié)點(diǎn)做了什么內(nèi)容及調(diào)整，同時，針對不同的系統(tǒng)，有助于使用統(tǒng)一的版本號做管理。
5. 上線計(jì)劃：依據(jù)上線計(jì)劃倒推測試周期、開發(fā)周期、設(shè)計(jì)周期，從而給參與該項(xiàng)目的協(xié)同人員約定好時間，便于更好的把控項(xiàng)目進(jìn)度。
6. 評審及修改：項(xiàng)目完成后的需求評審建議和結(jié)果，針對初稿內(nèi)容做了哪些修改。此處一定要詳細(xì)，后續(xù)調(diào)整內(nèi)容時，評審建議和修改事項(xiàng)是很重要的可參考的細(xì)節(jié)點(diǎn)。

（2）版本說明

1. 項(xiàng)目背景：清楚地寫出為什么要做該項(xiàng)目，誰要求做的。
2. 核心需求：為了解決什么沖突。
3. 預(yù)期目的：想達(dá)到什么結(jié)果，后續(xù)有什么進(jìn)一步的規(guī)劃。

詳細(xì)的項(xiàng)目背景有助于所有參與人員快速地了解項(xiàng)目是怎么回事。

（3）設(shè)計(jì)規(guī)范

設(shè)計(jì)規(guī)范來源于產(chǎn)品經(jīng)理對該產(chǎn)品的整體了解：在做完市場分析、行業(yè)分析、競品機(jī)構(gòu)分析、用戶調(diào)研之后，針對自己要做的產(chǎn)品，產(chǎn)品經(jīng)理會形成自己的整體構(gòu)思和產(chǎn)品走向模型。

而這個構(gòu)思就是需要表達(dá)給設(shè)計(jì)師的理念——要做一款什么樣的產(chǎn)品，要達(dá)到什么效果。

關(guān)于設(shè)計(jì)理念的表達(dá)，不同的公司有很大的差別，以及整個行業(yè)對這塊內(nèi)容都沒有統(tǒng)一的觀點(diǎn)。

一種觀點(diǎn)認(rèn)為，產(chǎn)品經(jīng)理只需要輸出黑白灰原型圖即可，其他的都交給設(shè)計(jì)師處理，給設(shè)計(jì)師足夠的發(fā)揮空間；

另一種觀點(diǎn)認(rèn)為，設(shè)計(jì)師對要做的產(chǎn)品，不了解緣由，直接去設(shè)計(jì)會有偏差，最終交付的產(chǎn)品大部分都不符合；

還有種觀點(diǎn)認(rèn)為，要看設(shè)計(jì)師的水平再來決定，水平高的不需要產(chǎn)品經(jīng)理說什么，都可以交付足夠讓人驚艷的設(shè)計(jì)，水平低的說再多，也做不出效果，而大部分公司都屬于第二種情況。

（4）功能列表

功能列表為產(chǎn)品經(jīng)理在經(jīng)過足夠多的調(diào)研和分析，從匯總的產(chǎn)品需求池中篩選出的當(dāng)前應(yīng)處理需求列表 。

功能列表的作用為便于相關(guān)人員全面了解產(chǎn)品的功能，從而評估項(xiàng)目周期、處理優(yōu)先級等。

功能列表主要表述都做什么功能，哪些重要且緊急。列表參數(shù)包含：

1. 模塊
2. 功能點(diǎn)
3. 功能點(diǎn)描述
4. 優(yōu)先級（高、中、低）

（5）角色列表

角色列表為表述清楚該產(chǎn)品上線后，參與到該產(chǎn)品中的群體有哪些。列表參數(shù)包含：

1. 角色名稱
2. 職責(zé)：在產(chǎn)品參與中的簡要說明
3. 備注：特殊情形

（6）框架圖

框架圖為該產(chǎn)品包含什么內(nèi)容：模塊、功能。便于開發(fā)人員快速、便捷的了解產(chǎn)品全局。

框架圖沒必要做的很高大上，高大上固然很好，會讓使用的人賞心悅目。但是，功能介紹簡單易懂和開發(fā)人員能看懂、看明白更重要，千萬不能舍本逐末。

（7）流程圖

流程圖分兩個部分：

1. 整體流程圖：整體流程為將產(chǎn)品各大模塊之間的交互流程，一般做正向流程居多，輔助以部分判斷流程和異常處理機(jī)制
2. 功能流程圖：功能流程為涉及到具體的功能點(diǎn)的交互流程，包含：正向流程、規(guī)則、判斷流程、異常流程。

（8）功能需求

功能需求為具體的各功能點(diǎn)，是需求文檔的核心。主要是詳細(xì)的分解各功能點(diǎn)，包含兩個方面：

1. 前端：針對前端部分，頁面如何來、頁面元素、各功能點(diǎn)的規(guī)則、交互、跳轉(zhuǎn)規(guī)則、非常規(guī)流程的頁面元素、交互、跳轉(zhuǎn)規(guī)則等等。
2. 后臺部分：前端功能的實(shí)現(xiàn)，依靠后臺的哪些邏輯和數(shù)據(jù)，是否需要做新功能模塊、新功能模塊的內(nèi)容、數(shù)據(jù)的調(diào)用、存儲、接口數(shù)據(jù)傳值等等。

（9）非功能需求

非功能需求為用戶常規(guī)操作產(chǎn)品時的極端情況，涉及很多內(nèi)容，以下列舉幾個比較重要且常規(guī)規(guī)劃中需要考慮的點(diǎn)：

1. 產(chǎn)品性能：產(chǎn)品對用戶操作的響應(yīng)、對群體操作的并發(fā)預(yù)防等。
2. 安全性：公司數(shù)據(jù)、用戶信息的保密性處理，不同角色的權(quán)限設(shè)置、使用中的限制等。
3. 可靠性：用戶操作中出現(xiàn)異常情況，是否可繼續(xù)操作，遇到異常情況時數(shù)據(jù)或使用狀態(tài)是否可被恢復(fù)等。
4. 拓展性：拓展性主要針對公司內(nèi)部而言，產(chǎn)品完成后，無論是設(shè)計(jì)師、開發(fā)人員，還是測試人員，針對產(chǎn)品所做的工作，是否可以被復(fù)用到其他地方。用戶在產(chǎn)品中的使用情況是否可被系統(tǒng)獲取后用作不同維度的分析等。

    要求文檔并非越詳細(xì)越好，有許多不必要的說明，無需花費(fèi)大量的時間來編寫，最核心的始終是：讓自己公司的相關(guān)人員能夠快速看懂，全面了解。書不如人讀，書不如人寫，公司都不同。在充分了解相關(guān)協(xié)作方的情況下，產(chǎn)品經(jīng)理應(yīng)該站在自己公司的角度，輸出他們所需的需求文檔。以上就是小編為您帶來的用戶需求文檔怎么寫的相關(guān)介紹，希望對您有所幫助。