需求文檔是典型的解釋性文本，邏輯清晰簡潔。對詞序和措辭的嚴格要求。它相當枯燥乏味，這意味著需求文檔有其語法。在“后端產品經理筆記：數據傳輸與編寫”之后，本文對需求文檔的語法進行了整理，感興趣的朋友可以一起溝通，歡迎糾正。
一，需求文檔概述
（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。
（4）文本只寫出要開發的東西。因為開發是按照你的地圖來完成任務的責任。把發展想象成一個直男，并告訴他兩件事：在哪里和做什么。避免一堆前巴拉巴拉，然后是“那是xxxxx”，“即xxxxx”。
（5）避免單詞錯位。如果單詞不準確，建議不要使用它。常見于文檔中，例如：“維度”，“粒度”，“參數”，“字段”，“項目”，“列”，“表格”。它可以這樣使用：唯一性判斷由“訂單號+產品代碼”維度決定。列表數據與“訂單”粒度一樣詳細。使用'time'作為請求參數。背景表的字段是數字。頁面搜索欄中的“名稱”搜索字詞，頁面列表的“年齡”列。
（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）凡是帶操作的一般都要設置頁面權限。最簡單的方式是所有系統的權限都分三個等級：不能查看、只能查看、可以編輯。
本文為@運營喵原創，運營喵專欄作者。
