產品經理必讀：需求文檔自檢清單

我們公司之前是沒有專業的測試的，所以測試都是我自己上。

我們的系統主要是數據邏輯比較複雜，一般我自己在測試時，主要是在正向邏輯上進行驗證。最多是在數據邏輯上考慮閉合，再為下一次寫相似的需求時，把類似的數據漏洞進行填補。

因此之前的測試中，很容易是自己寫的邏輯，自己發現邏輯漏洞，然後改掉。

現在我們具備了專業的測試團隊之後，發現專業的測試同事，他們會關注各種細節邊界，這讓我覺得需求文檔上寫的需求過於簡單了。

這種情況也不是一開始就暴露了，在需求評審和測試用例評審的時候，可能是大家都在原有的模式中，比較關注主線邏輯，因此對這些細節並沒有在意。

這導致測試過程中發現這些問題時，開發覺得需求增加了。這樣很影響項目的正常交付，未來也不好預估工期。

因此我整理這份需求文檔的自檢清單，防止設計過程中的遺留和問題。

關於需求文檔的自檢清單，我主要分三個方面：從文檔表達上、界面交互上和邏輯上。

一、文檔表達

我認為好的文檔，最基礎的就是表達上能讓開發測試清楚的知道需求，減少反覆的需求確認，因此我把它作為第一點。

1. 錯別字

對於錯別字，很容易導致一些誤會，讓開發理解錯誤的需求。或者對於一些系統提示，粗心的開發會直接根據文檔複製粘貼，不進行檢查，這樣的結果就是系統提示是帶有錯別字的提示。

所以這一定是我們要敲響鳴鐘的第一點，不能寫錯別字。

2. 言語通順性

團隊裏有一個小姑娘，每次寫出的文檔，表達出來的意思要麼很口頭，要麼讀起來和需求像是兩個意思，甚至語言都不通順。

我對她的建議是：每次寫好文檔，都自己反覆的去讀，讓語句能夠通順；如果實在不行，就看看其他人優秀的文檔，是如何進行表達的，進行模仿着寫。但一定要自己反覆讀自己的文檔，確認言語是通順的。

3. 語言表達的簡單整潔

這種情況是對於一個比較複雜的交互和邏輯，有時候很容易在表達上變得很拗口。

雖然意思的一樣的，開發在理解後也是沒問題的，但是讀起來就是需要花一定時間去理解；這會加大雙方的溝通成本，開發會確認自己是否有理解錯誤。

個人對這種情況的描述，一般情況下是儘量進行拆分，把邏輯分層段。能進行舉例説明的都進行舉例説明。

二、界面交互

在界面交互上，對於只陷在主線邏輯是否走通的思維裏時，往往會忽略很多異常情況。

1. 界面佈局

最基本的，就是界面設計時的佈局一致性等。這主要靠設計原則來規避，具體可根據“尼爾森十大可用性原則”進行自檢。

2. 非正向操作

用户按流程進行正向的操作的時候就是我們原本的設計，但實際情況中，如果用户沒有按照正向流程進行使用，且系統不進行提示，這很容易對系統數據產生影響；或者因為開發沒有考慮到這種情況，導致流程卡住不能正常進行。

因此在需求設計時，就需要考慮多種非正向操作的情況，對於非正向操作進行正向操作的提示或流程的阻礙。

3. 數據計算異常

因為是涉及的計算邏輯比較多，參數的未維護或者維護錯誤、中間過程計算異常，都會導致最終結果無法展示。

若產品中未考慮這些情況，當出現數據計算異常時，用户甚至不知道是哪裏出的錯誤，只能求助於服務公司。

因此，友好的提示：能夠快速讓用户意識到錯誤點在哪裏，快速的將流程走下去，而不是花人力去尋找一些簡單的問題，浪費業務的時間。

4. 數據填寫的異常

這個其實很多情況是上一個“數據計算異常”的前置條件，如輸入的數據格式不正確、輸入的數據過長、輸入的數據為空，這些都很容易導致後續的計算出錯。

輸入的數據在邏輯上處於什麼作用也需進行分析，需要根據邏輯來判斷是否要對該數據增加其他校驗。

三、邏輯

因為是數據系統，邏輯上的問題會比較多。

我們有專門的數據分析團隊，他們會給我進行一些特殊數據上的特殊邏輯處理，但是實際的業務數據中還是會出現一些我們考慮不全面的情況。

1. 邏輯上是否閉合、是否存在斷層

一般在數據分析提供給我們邏輯時，我們會進行邏輯圖的繪製。這一過程中，邏輯是否走通、是否存在斷層比較容易發現，這一習慣能保證正向邏輯上不存在漏洞。

2. 存在極端值的情況

雖然數據分析是通過實際值進行檢驗邏輯的正確性的，但因為樣本數據過小或者樣本數據中不存在極端值的情況，所以很容易在測試同事測試時造了極端值或者在客户遇到了極端情況下才暴露出問題。

這些極端值是存在共性的，因此把遇到極端值的情況進行羅列，在後續的文檔編寫時進行對照，能避免反覆遇到同類問題。

四、總結

自檢清單的對照，是為了讓我們吸取教訓。

在今後的文檔編寫時，更注重輸出文檔的需求準確性和邏輯嚴密性。讓人一讀文檔就知道需求是什麼，且開發的系統是完善的。

本文由 @汪仔6880 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Pexels，基於 CC0 協議