需求文檔是怎么寫的？不同公司有不同的寫法，并沒有硬性規(guī)定，清晰、沒有遺漏即可。這篇文章，作者分享了自己寫需求文檔的經(jīng)驗，供大家參考。

01 什么是需求文檔

需求文檔是產(chǎn)品經(jīng)理用來詳細描述需求，滿足協(xié)同人員使用的內(nèi)容文檔。它面向的人群包括：設(shè)計、交互、開發(fā)、測試、項目經(jīng)理、運營及其他業(yè)務(wù)人員。

02 為什么寫需求文檔

寫需求文檔本質(zhì)上是為了提高工作效率和減少溝通時間。沒有需求文檔可以開展工作嗎？其實也可以。如果團隊只有兩個人，坐旁邊當(dāng)面溝通甚至比文檔的效率還要高。但一個需求只有兩個人的情況極少，沒有文檔的話，多方人員之間需要花大量時間不斷地進行溝通、信息同步，人越多效率就會越低。

此外，需求實現(xiàn)過程中也會出現(xiàn)遺漏和改動的問題，需要當(dāng)面溝通，時間長之后溝通的結(jié)論可能雙方都記不太清楚了，留存到文檔中可以避免反復(fù)扯皮，讓項目中的人員達成共識。

03 如何寫需求文檔

需求文檔沒有固定的模版，但是有大致的框架。主要是需求背景、需求范圍、需求詳細說明、埋點需求四部分。

3.1 需求背景

此模塊用來描述需求來源和產(chǎn)生此需求的背景，目的是幫助團隊成員理解項目的起源、目標(biāo)和重要性，以便產(chǎn)品經(jīng)理更好地推進項目。這部分內(nèi)容主要包括以下幾方面：

• 描述現(xiàn)狀及當(dāng)前存在的問題，可以通過數(shù)據(jù)或用戶反饋來支持；
• 本次需求可以解決哪些問題；
• 需求完成后可達成的具體的量化的產(chǎn)品業(yè)務(wù)目標(biāo)，非基建類的需求需要有具體數(shù)值；
• 需注明業(yè)務(wù)方的預(yù)期上線時間，評審后各方評估時間緊張的話，可能需要調(diào)整業(yè)務(wù)預(yù)期或倒排時間。

3.2 需求范圍

業(yè)務(wù)流程圖：一般需求比較大或者比較復(fù)雜時需要補充該模塊，讓文檔的受眾更好地了解業(yè)務(wù)的情況和本次需求的功能范圍，可以通過泳道圖的形式進行輸出；

變動范圍：如果是優(yōu)化產(chǎn)品需求，簡述本次需求在原有的框架中的變化（新增功能模塊/頁面，修改某功能模塊/頁面，以及刪除某個功能模塊/頁面等）；

功能優(yōu)先級：功能較多時可通過表格的方式來簡要描述涉及到的功能模塊和優(yōu)先級，以便于在人力不足或時間緊張時保證主要功能，放棄一些低優(yōu)的部分；

名詞解釋：若需求中涉及一些生僻專業(yè)的詞語，項目相關(guān)人員可能不懂，可以在此部分補充名詞解釋。

3.3 需求詳細說明

需求詳細說明中需要對每個模塊的功能分別進行需求描述。需要注意的是，需求一般是新功能，產(chǎn)品經(jīng)理需要明確定義每個頁面和每個模塊的名字，方便各方人員之間溝通時采用相同的口徑，效率更高。

需求詳細說明這部分需要注意的是規(guī)范、全面。需求文檔也是產(chǎn)品的一部分，需要從用戶角度去考慮，規(guī)范是為了易讀性，全面是為了不遺漏。

我一般是按照模塊/頁面名稱、原型圖、詳細說明（分點）的結(jié)構(gòu)來寫。描述每個功能時，考慮最常用的12個狀態(tài)：等待/加載（loading）、初始態(tài)、輸入、空狀態(tài)、有數(shù)據(jù)、數(shù)據(jù)過多、關(guān)注、正確反饋、錯誤提示、待確認、結(jié)束態(tài)、中斷恢復(fù)。

大部分狀態(tài)很好理解，不再過多解釋，關(guān)注態(tài)可能比較小眾一些。關(guān)注態(tài)適用于特定場景，指用戶在看但沒有操作的狀態(tài)，比如視頻播放時用戶觀看視頻。

在撰寫這部分的過程中，為了使描述更清晰，可以使用各種圖例來輔助表達，比如狀態(tài)圖、流程圖等等。

3.4 埋點需求

做需求時需要考慮到需求上線后的效果監(jiān)控，如果涉及到埋點，需要在文檔中注明。工程師一般在提測前最后一步才會進行埋點開發(fā)，如果需求比較緊急的話，可以先評審其他部分進行功能開發(fā)，然后再補充埋點文檔，做到敏捷開發(fā)。

3.5 需求版本及相關(guān)人員

在需求評審并確定排期后，如果公司沒有使用項目管理軟件，最好將需求版本和該需求的相關(guān)人員和排期均標(biāo)注在文檔中，后續(xù)需求有變動時可以直接找到對應(yīng)人員。（但是，這部分主要是利好項目不相關(guān)的人或后面交接的人，所以大部分人往往不會補充這個模塊）

示例如下：

04 小結(jié)

以上就是撰寫需求文檔的經(jīng)驗和方法。當(dāng)然，需求文檔的撰寫沒有硬性規(guī)定，清晰、沒有遺漏即可，每個團隊之間可能有不同的規(guī)范，核心還是讓項目相關(guān)人員能夠高效的讀懂，方便工作更好地開展。