需求文檔都需要什麼内容?編輯導語：産品需求文檔撰寫可能是産品經理必備技能之一而在撰寫需求文檔時，我們應當先了解需求、從而可以更準确地下筆那麼，文檔撰寫是否有什麼注意事項？本文作者就結合其案例經驗向我們闡述了需求文檔的一些要點事項，讓我們一起看一下吧，我來為大家科普一下關于需求文檔都需要什麼内容?以下内容希望對你有幫助!
編輯導語：産品需求文檔撰寫可能是産品經理必備技能之一。而在撰寫需求文檔時，我們應當先了解需求、從而可以更準确地下筆。那麼，文檔撰寫是否有什麼注意事項？本文作者就結合其案例經驗向我們闡述了需求文檔的一些要點事項，讓我們一起看一下吧。
各位大大好，我是一枚工作一年的産品小白。撰寫産品需求文檔是自己工作職責的一部分，下面分享一些自己對需求文檔的理解，如有不當，還望各位大大多多指教～
本文分為如下4個模塊，全文約3500字，閱讀完畢大約需要5分鐘。
為什麼要寫産品需求文檔；
需求文檔需要注意的一些點；
實際案例；
個人小結。
在我看來，寫需求文檔的目的主要有如下幾個。
一個項目的需求有很多，把需求都記錄在文檔裡并把具體的邏輯縷清，這樣能避免需求遺漏，同時方便管理。
當團隊其他成員需要了解項目需求時直接閱讀文檔就好了，也方便了産品經理離職時的工作交接。
如果開發出的功能不合預期，那麼文檔可以作為依據，避免出現相關人員之間相互推诿責任的情況。
二、需求文檔需要注意的一些點文檔是寫給别人看的！文檔是寫給别人看的！！文檔是寫給别人看的！！！
既然文檔時給别人看的，那就應該讓讀者以最小的代價去看懂文檔。所以文檔的結構、可讀性、對産品描述的完整性和對文檔的維護更新非常重要。
個人理解的文檔結構是整個文檔是由哪些内容組成的，它們的層級關系是怎樣的。比如在一級标題下分别有哪些二級标題，每個标題的具體内容分别講什麼。
合理的結構可以讓文檔内容有條有理。可以先規劃好整體的文檔結構，然後再開始寫具體的内容，建議打開word或WPS中的導航窗格，方便預覽文檔的整體結構，也方便快速查看某個模塊的内容（單擊視圖中的導航窗格即可打開）。文檔結構規劃圖示例：
如果是B端産品的文檔，可能還會涉及一些非功能性的描述，比如安全性、與其他系統的數據交互規則、數據的存儲備份規則等等。其實沒有标準的文檔結構，具體看項目情況來定，能把需求明确清晰的表達出來就行了。
在WPS中打開導航窗格：
文檔的可讀性還是蠻重要的，先不說内容寫得怎麼樣，起碼排面要有，特别是一些要交給客戶和領導的文檔，沒有排面可不行。如果想要文檔具有比較強的可讀性，需要注意以下幾個點。
1）大段文字描述時，可以分點描述的内容就分點描述（以有序列表或無序列表的形式分點），同時也要注意内容的分段。示例：
2）盡量以表格的形式去展現内容，比如描述同一個事件的多種狀态時，用表格就比用大段文字合适。示例：
3）如果有某些需要重點強調的内容，可以給字體标上一些顯眼的顔色，以便讓讀者一眼就能注意到，特别是大段文字描述時，更應該突出重點内容，以便讀者能捕捉重點信息。示例：
4）文檔裡的配圖/表格加上題注，讓讀者知道這個圖/表主要想表達什麼内容，減少讀者的認知成本。通過通配符可以批量為圖片設置自動題注，有需要的小夥伴可以去百度一下。示例：=
5）此外還有一些細節。
文字的行間距、段落的段間距在很大程度上也會影響文檔的視覺效果，行間距、段間距太小，文檔看起來會顯得很擁擠，太大文檔看起來會顯得很松散。
至于行間距和段間距要設多少，就要看正文字體是多大了，比如5号字體比較适用單倍行距，具體的大家可以去百度一下，反正看起來順眼就行。
對産品描述的完整性是指盡可能的把一個産品的功能規則全部描述出來。
比如短信驗證碼的相關規則包括：多久能獲取一次驗證碼、某段時間内最多可以獲取多少次驗證碼、驗證碼有多少位數、有效期是多久等等。
如果對産品規則描述得不齊全，可能會導緻程序在開發時遺漏掉某些功能（有些程序真的是按照需求文檔進行開發，完全不多想其他），别人讀起來也可能會感到疑惑：為什麼這個功能沒有對xxx進行限制啊？
個人覺得要想做到盡可能全的把規則羅列出來，可以從以下3個方面着手：
1）寫文檔前一定要先把産品吃透，自己要先知道開發這個産品是為了解決什麼問題，有哪些功能和相關規則，各個功能模塊間的關系是怎樣的，有哪些需要特别注意的點，同時要能熟練地使用産品。
如果自己都沒有把産品吃透，那很難寫出文檔的。
2）培養自己全方位思考問題的意識。一件事情發生前、發生時、發生後的規則分别是什麼，是否有什麼前置條件或特殊條件，如果某個條件不滿足會怎麼樣等等，自己要主動有這樣的意識去思考，而不是單純的靠經驗，想到什麼就寫什麼。
平時可以有意識的去訓練自己，讓自己養成這樣思考問題的習慣。
3）多體驗各種産品，研究它們的功能都有些什麼約束規則，為什麼要這麼設計（比如淘寶的搜索框是怎樣設計的，具體有什麼規則，為什麼要這麼設計）。
可以對各種情況進行嘗試，比如在填寫某個信息時故意輸入很多位數，探究其對輸入信息的校驗。也可以多看一下别人寫的需求文檔，裡面也會對規則進行約束性的描述。
總而言之就是要多看文檔或多體驗其他産品，讓自己知道，這一類功能要進行這樣的約束，是怎樣進行約束的，而且也可以在這個過程中讓自己形成全方位思考問題的意識。
對于這個方面，個人的做法是這樣的，每一個功能模塊就起一個文檔來寫，如果把所有的功能都寫在一個文檔裡，文檔會非常的冗長，而且不利于分工進行開發。
實際案例：一個項目由多個産品經理同時負責，每個人都負責相應的功能模塊，如果把需求都寫在一個文檔裡的話，會很難同步各方的信息（用雲文檔可以解決信息同步困難這個問題，但我們公司沒有這樣做）。
每次對功能進行改動後，就複制一份文檔，然後在上面更新改動的内容，并給一個新的版本号，大版本直接由1.0升到2.0，小版本就由1.0升到1.1，如果是很小很小的改動，不給新的版本号也可以，直接在當前最新版本的文檔裡寫就好了。
同時還要寫明版本信息，說明是誰改動了文檔，什麼時候改的，相比于上一個版本改了什麼東西。一個功能模塊的文檔經過多次疊代後是這樣的：
三、實際案例版本信息
1）需求來源
對多款競品進行分析并結合産品自身戰略方向得出需求。
2）需求目的
提供多種登錄方式供用戶進行登錄，減少用戶登錄的操作成本，降低用戶流失率。
3）功能說明
1）UI原型圖
2）功能流程圖
3）前端規則
手機号登錄
手機号要輸入11位數，否則提示：手機号格式錯誤。暫不考慮海外手機号碼登錄。
60秒後才能再次獲取驗證碼，在此期間，獲取驗證碼按鈕置灰不可點擊且顯示倒計時動畫。
手機驗證碼最多能輸入5位數，否則提示：驗證碼格式錯誤。
手機驗證碼錯誤則提示：驗證碼錯誤。
輸入了過期的驗證碼，則點擊登錄後提示提示：驗證碼無效或已過期，請重新獲取。
在第5次獲取驗證碼時彈出提示：驗證碼已發送，請在[下次可獲取驗證碼時間點]再次嘗試獲取。在驗證碼冷卻期内再次點擊獲取驗證碼按鈕，則提示：請在[下次可獲取驗證碼時間點]再次嘗試獲取。
根據後端返回的标志判斷是否為第一次登錄，如果是，則登錄成功後進入創建賬号流程，否則直接進入APP。
賬号密碼登錄
如果登錄失敗則彈出提示：賬号或密碼錯誤，請重新輸入。
社交賬号快捷登錄
單擊社交賬号登錄按鈕後，根據相應社交APP的狀态作出響應：
其他
單擊“賬号密碼登錄”可以跳轉到賬号密碼登錄的界面，單擊“手機号快捷登錄”可以跳到手機号快捷登錄的界面。
單擊登錄遇到問題可以跳到“常見問題解答”界面。在兩種登錄模式下都是跳到同一個界面。
4）後端規則
手機号登錄
以第1次單擊獲取驗證碼按鈕的時間點為準，同一手機号一個小時内最多可以獲取5次短信驗證碼，以單擊第5次獲取驗證碼的按鈕時間點為準進行計時，60分鐘後可再次獲取驗證碼。比如在7:24:00第1次獲取驗證碼，則在7:24:00—8:24:00期間隻能獲取5次驗證碼。
獲取驗證碼後需要等待60秒才能獲取下一次驗證碼。
驗證碼有效期為5分鐘，發送多個驗證碼時以最後一個為準。
如果該手機号為首次登錄，則返回标志至前端。
賬号密碼登錄
如果賬号或密碼錯誤，或賬号不存在，則返回登錄失敗标志。
社交賬号快捷登錄
每個社交賬号都可以創建一個獨立的賬号，例如使用qq/微信登錄的賬号，它們之間的數據不共享。
5）測試要點
各個功能是否遵循如上規則。
四、個人小結這篇文章主要是講文檔的結構和關于可讀性的一些注意事項，都是一些偏展示形式的東西，但要真正寫好一份文檔，對産品的熟悉和理解才是最關鍵的，個人覺得，一份好的文檔=好的想法 好的展現形式。
文章中的登錄功能是是參考了簡書，上面關于社交賬号登錄的描述不是特别詳細，有興趣了解的小夥伴們可以去下載APP自己體驗一下。
小弟目前經驗尚且不足，歡迎各位大大對文章做出評論～
本文由 @活蹦亂跳的大鹹魚 原創發布于人人都是産品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
