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

暢寫Office

3.2

20條點評

咨詢產品

免費試用

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

客戶案例

暫無

合作品牌

57

一、需求文檔的起源

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

   筆者認為基于最經典、高效、實用的思維方式的基礎上，可以每個人針對不同的知識體系、思考方式、經驗總結等維度，總結出自己的思維方式。

   筆者常使用的方式為多年前從社會經濟學老師那里學來的，做了補充和優化，分享給大家：在特定的時間、特定的地點、特定的人群因為特定的原因而做了特定的事件。達成該特定事件前，有哪些預期，實際達成的效果是什么樣的，中間有怎么的落差，以后處理該類事件時，如何優化方式。

   按照上述思維方式，我們將要寫的需求文檔當做一個特定的事件，通過剖析該特定事件被觸發的前置條件、后置補充內容，來實現對需求文檔的分析。

二、什么是需求文檔？

    筆者將需求文檔定義為：用于闡述產品，滿足協同人員開發的內容文檔。該定義中有兩個重要點：

1. 闡述

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

    而此處的“是什么”是告知該產品的相關人員，該產品有哪些功能，這個功能要怎么呈現，該怎么實現。具體包含以下幾個方面：

（1）為什么要做這個產品？

該產品是來自哪里的需求，是內部版本迭代優化、Bug修復、新增功能點，還是來自業務部門的需求，或者來自用戶的反饋需求。

必須交代清楚做該產品的項目背景，一方面有利于開發人員更好的了解整體項目，從而更順利地制定項目計劃、項目進度、項目達成；

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

（2）該產品要解決哪些沖突？

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

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

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

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

（3）該產品實現了哪些目的？

任何產品的實現，不僅僅要滿足用戶的需求，更要在解決沖突時達成更多的目的。而這個目的分為物質層面和精神層面兩個維度。

需求文檔怎么寫

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

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

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

1. 產品經理的訴求

（1）產品部門的版本需求討論、需求評審會。

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

（2）與其他產品經理所負責的內容有交叉點。

當一個完整項目，每個產品經理負責部分內容的時候，各自負責部分功能的需求文檔有助于其他產品經理從文檔中發現交叉點中的銜接是否合適，各功能模塊的整體融合性。

（3）Bug處理。

再厲害的程序員也不敢保證產品上線后不出現任何問題，當產品上線后出現問題，需求文檔有助于產品經理快速找到規劃的初衷，根據之前的情境給出精準的解決方案。

（4）版本迭代。

當產品在不同時期，做不同的版本迭代時，之前的需求文檔尤為重要，有助于負責該項目的產品經理快速熟悉往期規劃的初衷、目的和當前的效果及不足，并在迭代版本中對往期問題進行修復，在新的規劃中避免不必要的坑。

（5）人員異動。

如果出現人員異動（人員項目變更、人員離職等），有助于新接手的產品經理快速熟悉項目，確保項目規劃不會因個人經驗、個人喜好、習慣等原因，出現太大的偏差。

基于以上場景和目的，其他產品經理對需求文檔的訴求需要得到的信息：誰、在什么時間、因為什么原因，做了什么內容，滿足了什么人的需求，變動內容及節點、階段性規劃。

2. 設計師的訴求

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

基于上述場景和目的，針對設計師角色，產品經理在編寫需求文檔時，需要告知的信息：因為什么原因，給什么特點的群體，做什么圖，當前競品什么情況、公司什么情況、市場什么情況，想達到什么效果，后期發展方向（業務、功能、設計方向等）。

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

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

基于刪除場景，產品經理在編寫需求文檔時，需要告知開發人員的信息：因為什么原因，針對什么項目，做什么功能，包含哪些頁面元素、頁面樣式、交互邏輯、實現效果。

4. 注意事項

盡信書不如無書。各公司的組織架構、部門角色劃分、業務開展的推動因素、公司發展所處的階段均不相同，雖大道同源，但總有差異化表現。

需要產品經理針對協同人員做好分層、分類，切實與相關人員深入溝通，了解他們的習慣，了解他們的認知，輸出他們需要的需求文檔，才能夠確保信息的透明化，保證開發人員全面了解規劃的內容。

同時，輔助以良好的溝通機制和技巧，則有助于開發效率的提高和產品上線的進度保障。

四、如何寫需求文檔？

1. 寫文檔先看人

需求文檔與產品經理前期做用戶調研時的用戶畫像很相似。

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

在寫需求文檔前，面對我們的用戶——相關協同人員，產品經理需要去了解他們。了解他們的工作方式、工作習慣、工作態度、工作認知、工作能力等與工作相關的內容，同時，對他們與人相處的方式、生活習慣、興趣愛好等等的了解，有助于產品經理更全面的了解，從而建立更加立體的用戶畫像。

在輸出判斷結果時會更準確，寫需求文檔會更有側重點——哪些是他們需要知道的，哪些是他們需要特別詳細表述的，哪些是需要特殊標注的，哪些是省略表述即可的。

2. 文檔規范

（1）版本記錄

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

（2）版本說明

1. 項目背景：清楚地寫出為什么要做該項目，誰要求做的。
2. 核心需求：為了解決什么沖突。
3. 預期目的：想達到什么結果，后續有什么進一步的規劃。

詳細的項目背景有助于所有參與人員快速地了解項目是怎么回事。

（3）設計規范

設計規范來源于產品經理對該產品的整體了解：在做完市場分析、行業分析、競品機構分析、用戶調研之后，針對自己要做的產品，產品經理會形成自己的整體構思和產品走向模型。

而這個構思就是需要表達給設計師的理念——要做一款什么樣的產品，要達到什么效果。

關于設計理念的表達，不同的公司有很大的差別，以及整個行業對這塊內容都沒有統一的觀點。

一種觀點認為，產品經理只需要輸出黑白灰原型圖即可，其他的都交給設計師處理，給設計師足夠的發揮空間；

另一種觀點認為，設計師對要做的產品，不了解緣由，直接去設計會有偏差，最終交付的產品大部分都不符合；

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

（4）功能列表

功能列表為產品經理在經過足夠多的調研和分析，從匯總的產品需求池中篩選出的當前應處理需求列表 。

功能列表的作用為便于相關人員全面了解產品的功能，從而評估項目周期、處理優先級等。

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

1. 模塊
2. 功能點
3. 功能點描述
4. 優先級（高、中、低）

（5）角色列表

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

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

（6）框架圖

框架圖為該產品包含什么內容：模塊、功能。便于開發人員快速、便捷的了解產品全局。

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

（7）流程圖

流程圖分兩個部分：

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

（8）功能需求

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

1. 前端：針對前端部分，頁面如何來、頁面元素、各功能點的規則、交互、跳轉規則、非常規流程的頁面元素、交互、跳轉規則等等。
2. 后臺部分：前端功能的實現，依靠后臺的哪些邏輯和數據，是否需要做新功能模塊、新功能模塊的內容、數據的調用、存儲、接口數據傳值等等。

（9）非功能需求

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

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

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