一份好的需求文檔不僅能提高開發效率，還能避免需求誤解導致的返工。 開發喜歡看怎樣的需求文檔？我總結了以下7點。
-1-
需求文檔必備的基本要素
需求迭代、需求優先級、需求產品負責人、需求開發人員、需求背景、需求總體描述、需求功能描述是組成一份文檔的基本要素。
如果你們公司使用了需求管理工具，就更好了，比如tapd需求管理工具，以上提到的要素，在這個管理工具上面都會要求你填寫，還有狀態流轉、開發預計開始時間、結束時間、需求保密性管理、需求的評論補充等，已經結束的需求如果以後想重構功能，查看歸檔文件也很方便。
-2-
分工要明細，避免多人看同一份文檔
如果一份需求需要多個開發角色來完成，比如數據分析師、前端、後臺。建議把需求拆成1個父單和3個子單，父單有需求的總體描述，子單是對應到不同角色的需求描述。
子單給到不同的開發，開發不僅能快速瀏覽到需求明細，後續如果產生需求變更或者需求補充時也能實時反饋到對應的需求文檔中。
注：如果使用了需求管理工具，父單和子單可分在不同的鏈接文檔中，如果使用的word文檔，在文檔內寫好不同角色的分工模塊即可。
-3-
邏輯要清晰，避免口口相傳
1）避免一句話需求
舉個例子：產品想提一個和已經存在功能的類似功能，比如登錄功能。然後把以前的登錄界面截個圖，再加上一句話：實現和以前登錄一樣的功能。
在接這個需求時好像沒毛病，但是可能做起來全是問題。比如用戶體系是否用的同一套？登錄態是否要打通？等等。所以邏輯一定要清晰，關注到細節。
2）避免口口相傳
有些邏輯產品經理可能一時沒有顧及到，開發在讓產品補充時，建議產品把補充的邏輯都寫在需求文檔中，避免口口相傳。這樣有個記錄，在後期如果出現需求沒達到預期時，起碼有個依據看。
-4-
重點要突出，避免文案臃腫
文案臃腫是需求文檔常出現的問題，大概率的原因是沒有主次分明，突出重點。所有的細節都寫。對於常識性的細節，建議不要寫上，建議寫核心邏輯、關鍵分支、關鍵異常就可以了。
舉個例子：需要新增一個搜索下拉選擇框。
描述1（bad）: 搜索新增一個選擇食品的下拉選擇框，當選擇食品時，把食品名稱展示在輸入框中，支持單選搜索。
描述2（good）: 搜索新增一個選擇食品的下拉選擇框，支持單選。
這個需求的重點：下拉框選擇食品，僅支持單選。
描述1中有常識性的描述（把食品名稱展示在輸入框中，然後觸發搜索），描述2比較簡潔。描述1的做法，當需求內容多起來時很容易導致文案臃腫。
-5-
嚴謹全面，避免遺漏異常
異常包括：
執行者輸入異常。比如輸入為空、輸入非法字符、輸入重複單詞。
平臺業務異常。比如異常分支流程，超時異常
第三方異常。比如第三方調用失敗，第三方請求頻率被限制
-6-
需求所有地方的描述要保持一致性
一般一份需求會分為這幾部分：需求總體說明文檔、原形圖、設計稿。
1）避免同個功能邏輯分在多處展示。
目前發現比較多的需求模式是，需求文檔裡面，一個功能模塊一張原型截圖，然後底部寫上具體邏輯。但是發現有的需求文檔是這樣的：原型圖截圖裡面寫著一份邏輯描述，需求文檔也寫著一份邏輯描述。這2處地方的邏輯描述大同小異。
建議把邏輯統一寫在一處地方表示，好處是：一是開發可以不用來回切換看邏輯，二是以後變更需求時只要改一處地方就可以了。
2）避免原型圖和設計稿描述不一致。
這是我經常遇到的需求問題，可能產品和設計沒有溝通好，或者變更需求沒有及時更新，導致原型圖和設計稿展示的功能不一致。開發一般會在設計稿出來之前，按照原型圖做功能，等待設計稿出來後再繼續完善，如果兩個地方不一致容易讓開發誤解。所以在設計稿出來後，建議產品要做好設計走查，保持一致。
-7-
相比於文字，開發更喜歡看圖
能用圖展示的需求，儘量不要用文字。俗話說：一圖勝千言。 舉個例子：比如一個填寫的表單，描述輸入異常
用文字描述（bad）：
活動名稱為空時：提示請輸入活動名稱
活動區域為空時：提示請選擇活動區域
活動性質為空時：提示請至少選擇一個活動性質
用圖描述（good）：
↘好文推薦：
“百億補貼”真的能拯救一切嗎？
產品經理學PMP，有必要嗎？
美團外賣 | 離線數據倉庫建設實踐
