需求文檔是典型的說明文，力求邏輯清楚、言簡意賅。對語序、用詞要求嚴格。寧可枯燥也不能模稜兩可，這就暗示需求文檔有它的語法。
本文繼“後端產品經理筆記：數據傳輸和寫入”之後，梳理了需求文檔的語法，有興趣的朋友可以一起交流，歡迎指正。
一、需求文檔概述
（1）一些移動端產品不寫文檔，直接在原型上備註，但遇到邏輯複雜的時候還是要寫文檔。
建議大家寫文檔，因為寫的過程會發現更多。
（2）文檔內容涵蓋：背景、目標、需求範圍、需求用例（正文）、備註、參考資料。
不管是用誰的模板，這都是要有的。
- 背景：業務的習慣是xxxx，現在的是xxxx這麼處理的，問題是xxxx，因此需要xxxx。
- 目標：本需求要實現1、xxxx。2、xxxx。3、xxxx。
- 需求範圍：可以用一個腦圖或者用例圖表示。
- 備註：開發注意xxxx，測試提醒xxxx。
- 參考資料：本需求涉及的數據表/字段為xxxx。涉及的腳本是xxxx，接口xxxx，歷史文檔是xxxx，流程圖xxxx，原型xxxx。
（3）需求用例（正文）：避免散文化思維，要按正常的順序去描述。
比如：要在已有接口增加獲取一個字段，並在頁面展示，可以這樣：
- 在xx接口增加獲取xx字段，存入後臺表xx——接口邏輯調整為xx。舊數據初始化方案是xx。
- 在xx頁面列表，新增xx列，對應取值是xx後臺表中的字段的xx。
（4）正文只寫要開發做的事情。因為開發就是照著你的地圖去打怪完成任務的。
把開發當直男，告訴他兩點：在哪裡，做什麼。避免前面巴拉巴拉一堆，後面又接著一個“即xxxxx”、“也就是說xxxxx”。
（5）避免詞語失準，如果用詞拿不準的話，建議不要用。
在文檔中很常見的比如：“維度”、“顆粒度”、“參數”、“字段”、“項”、“列”、“表”。
可以這樣用：
- 以‘訂單號+產品編碼’維度進行唯一性判斷。
- 列表數據細到‘訂單’顆粒度。
- 以‘時間’作為請求參數。
- 後臺表的字段為number。
- 頁面搜索欄的‘姓名’搜索項，
- 頁面列表的‘年齡’列。
（6）如果需要開發參考舊功能的，比如做優化，可以這樣的結構：
修改前：xxxx
修改後：xxxx
也可以寫完需求點，然後在後面跟上（已有，詳見參考資料1）
（7）如果熟悉數據庫，可以直接寫數據表的字段。比寫頁面的更準確，前提是你要準確。
（8）避免模稜兩可
比如：你寫‘該字段默認取空’，就不如說是‘空字符串’。因為我們看後臺是這樣：NOT NULL DEFAULT ”——表示不能為空 ，默認為空字符串。
（9）寫接口的時候記得加上數據量級和接口響應要求
比如：預計半年內數據100萬/天，要求接口響應3s內，因為開發的實現方式多種，他要做評估。
（10）通用規範統一， 這些是早期文檔要建立起來的規範。
比如：
- 刪除/禁用/關閉/封存、開啟/啟用/生效、配置/設置、編輯時間/修改時間/更新時間。
- 是否寫入用is_use/is_write？
- 已寫入/未寫入用1/0，還是用1/2？
- 空字符串時，前端展示什麼，是‘/’還是空白？
每個開發習慣不同，所以要固定用哪一種，避免千人千面。比如：有個開發比葫蘆畫瓢，把goods_sn寫成good_sn，就尷尬了。
二、條件反射出邏輯規則
（1）遇到輸入框，就要限定輸入的範圍，且做輸入校驗。
比如：輸入框下方紅色字體提示：請填寫寄樣信息！最省事的辦法是，輸入的不負荷就不予寫入。
比如：年齡欄位寫‘張三11.2’則能寫進去的只有‘11’。
這種也不用考慮校驗的時間是輸入時還是最後保存時。
（2）遇到下拉搜索框，考慮下拉的同時是否支持輸入搜索，是否支持多選？
（3）導入文檔要校驗文檔內容，最安全的辦法是一旦校驗到一處重複或者不合規格，則全部不予導入。
（4）已有功能的邏輯規則變更，則要考慮舊數據。
（5）基礎數據刪除，則要考慮基礎數據被調用的地方，刪除和編輯怎麼處理。 比如：產品分類中維護的類型刪除，那麼歷史生產出的該分類下的數據再編輯和刪除時候就可能報錯，所以記得基礎數據維護時候校驗調用情況。
（6）設置規則時，考慮規則去重、規則優先級。嚴格說，沒有優先級的情況下，規則的校驗比較累。比如參數A選項有n個，參數B的選項m個，那麼可以搭配出至少n*m種規則條件（如果加上多選、全選、全不選就更多），就要確保這些規則之間不重複。
（7）列表的數據一般按照修改時間的倒敘排列，最新的序號為1。也可以用id代替序號，好處是用戶自己就可以用規則與產生的數據對應，方便追溯。
（8）異常機制：每時每刻都要有異常思維，告訴開發怎麼算異常？異常了怎麼標示出來。 比如：表1字段A，匹配表2字段B，將匹配成功的數據寫入表3。就要考慮表1無該字段A的情況。
（9）頁面長期不登錄，則給自動退出。主要考慮到後端系統的保密性。
（10）凡是帶操作的一般都要設置頁面權限。最簡單的方式是所有系統的權限都分三個等級：不能查看、只能查看、可以編輯。
（文檔的模式和注意事項遠不止上述，後續整理再補充）
本文由 @ 環滁皆山也 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議