需求文檔是以一種文檔記錄的方式，Excel需求文檔的優勢在于能夠幫助更好地查閱信息。如何編寫Excel格式的需求文檔？作者根據自身經驗，并結合案例分享了相關經驗，希望對你有用。

之前參加枯葉講師的公開課，提到了Excel需求文檔的優勢，剛好目前工作中也是通過Excel來編寫需求文檔，于是總結如下通過Excel來編寫需求文檔的經驗和技巧。

一、需求文檔的常見問題

産品經理的日常工作中，編寫需求文檔是一項必備的技能。

需求文檔的重要性是不言而喻的，對團隊的研發和測試人員，他們需要産品經理提供詳情的需求文檔，以便以此為依據，開展開發和系統測試的工作。

但是往往由于時間緊迫、産品經驗不足等原因，提供的需求文檔，常常出現需求描述不清楚、邏輯不通、需求遺漏等問題，這些問題很容易在研發和測試工作中發現，例如：

研發抱怨需求文檔中沒有描述清楚：比如：文檔中寫到：點擊新增按鈕，打開新增頁面。前端就會跑過來疑問：這裡新增頁面是新開頁面，還是當前頁面打開。

研發在開發過程中，發現需求邏輯不通，找産品經理反饋，産品經理發現确實如此，趕緊補救。從而導緻在研發過程中産生需求變更，引起衆怒，還是引起研發人員質疑産品經理的能力。

需求有遺漏，不完整。産品在驗收的時候，發現某個功能的排序規則不對，然後讓研發修改。結果研發抱怨你的需求文檔中，沒有定義這個列表的排序規則，從而會産生團隊矛盾。

那麼，我們如何才能把需求說明清楚，盡量減少需求不清、需求遺漏、需求質量問題呢？

二、Excel需求文檔

需求文檔是以一種文檔記錄的方式，進行信息的溝通和傳遞。以便有迹可循，有理可依。

前面出現的：需求不清、需求遺漏、需求質量問題，我們可以通過編寫Excel形式的需求文檔，逐漸減少此類情況的發生，從而提升需求文檔質量。

需求文檔也是一個叠代的過程中，通過多次的叠代過程，一方面我們可以形成思考的方式，然後查漏補缺，進而逐漸可以完成出完整的需求文檔。另一方面我們可以積累出需求文檔庫，便于後期的複用。

1. 曆史叠代可追溯

首先Excel的需求文檔，可以很清楚每個版本叠代的功能有哪些。産品不斷的叠代更新，或是人員的交接，經常需要回溯之前的線上邏輯，需求文檔的缺失或不完善，會導緻線上邏輯不明确，甚至後續的産品需求設計的邏輯與線上矛盾或沖突，為項目的開發帶來麻煩。

Excel需求文檔中，可以通過sheet保留每一個叠代版本的需求内容。方便進行信息的查閱！

2. 需求顆粒度細

我們經常會很糾結，需求到底要寫到多細，常常以為寫的很詳細了，結果研發還是有很多疑問。通過Excel的需求文檔，對每一個元素進行描述，這樣細化之後的需求，可以防止遺漏，思考就更加清楚，方便檢查，查漏補缺，從而提升需求文檔的質量。

例如：後台系統都有導出某個頁面上的數據的功能，比如導出用戶列表的數據。有些産品經理在寫這個導出需求時隻有一句話的描述：點擊『導出』按鈕後，将表格中的數據導出為excel文檔。

但是我們經過一步一步拆解到不能再細的程度，這樣再來審視這句話，會發現有很多不明确的點：

• 導出的文件格式是什麼？xlsx？xls？還是csv？（這三種格式都很常見）
• 導出的表格是否區分sheet？sheet名稱是什麼？
• 導出的表格包含哪些字段？
• 如果還有圖片（頭像）等信息，怎麼處理？
• 導出列表數據的最大上限值是多少？
• 導出的文件如何命名？

上述這些問題，如果在需求文檔中不明确，在需求開發過程中通常會出現兩種情況：要麼是技術同學過來問産品經理如何定義（可能不止一次的溝通），要麼是技術同學按自己的想法實現。前者增加了溝通成本，後續還是要花費時間完善文檔或是再給測試同學講需求，後者如果實現的方案在測試環節發現與産品或測試的想法不同，就需要返工再調整，兩種情況無論怎樣，都會浪費時間。

3. 叠代更新，沉澱需求庫

需求傳遞到研發和測試人員之後，通過團隊後續反饋，産品經理可以及時補充遺漏的地方，完善需求文檔，并且總結遺漏的原因，避免後期再出現同樣的問題，從而最終能夠完成一個高質量的需求文檔。

通過這樣叠代，可以形成一個通用的需求庫。其實在需求中，發現不同需求所用到的功能很多都是類似的，那麼後面如果再碰到這樣的需求，我們可以在這個基礎上面進行複用，從積累的需求庫中，提取出相應的功能即可。

三、Excel需求文檔的模闆介紹

下面來介紹Excel形式的需求文檔的模闆，定義好模闆結構之後，可以快速編寫。

1. 文檔命名規範

文檔的編号和命名很關鍵，每個産品都是經過若幹個叠代才完成的，而每個叠代所完成的産品功能或者升級的需求都可能是不一樣的，因此需要定義清楚該文件屬于産品的哪個叠代，修改了幾個版本。

文件命名的方法一般是通過版本号定義，比如簡單的方法是：XX産品V1.0PRD_V2,前面的V1.0是産品叠代的編号，後面的V2 PRD的版本号。

2. 文檔基本信息介紹

需求文檔的封面基本信息，需要注明産品名稱、需求文檔的狀态、當前版本、編寫需求文檔的人員和完成的時間。

3. 文檔修改記錄

産品是分多個版本叠代的，關于需求文檔修改的記錄頁需要記錄下面，包括：版本号、修訂日期、模塊、修訂說明、修訂人、備注。文檔版本号顯示的當前修改的内容屬于文檔的第幾個版本(當前系統的版本XX産品V1.0 修改的版本V1)，模闆是具體到修改内容屬于的功能模塊，以便閱讀人及時找到修改後的内容，修改原因說明為什麼要修改該需求，讓閱讀者直觀的了解原因。日期是指需求文檔修改的時間，修改人是指需求内容的修改者。

4. 模闆說明

需求文檔的模闆參考上圖，需求文檔的關鍵屬性說明如下：

• 編号：編号就是功能的順序号，主要是需求的唯一性标識。
• 模塊：把需求劃分到系統的某個功能模塊，一般隻需要劃分到系統的一級菜單。
• 功能名稱：系統化到系統的功能菜單，比如注冊、個人中心、活動管理。
• 功能點：這個功能菜單中具體的功能點，比如修改個人信息、查詢訂單。
• 需求類型：需求類型一般包括：新增功能、功能改進、需求變更、界面優化、Bug修複、删除功能、接口需求等。
• 功能詳細描述：功能詳情是描述這個功能點的頁面展示、業務規則内容。是需求文檔的核心内容。
• 參數：對輸入的參數信息描述。提示信息的描述。
• 備注：其它任何信息，如：與哪個信息相關。

示例：如何以正确的姿勢編寫需求？

在編寫需求文檔的過程中，往往因進度緊而來不接寫的完整，這就需要技巧性的簡化文檔，不妨先出一個系統框架，然後再補充每個欄目中的内容，最後再來扣細節，這樣在檢查的時候，能夠及時發現需要是否有遺漏。沒有任何文檔是一次能寫好的，所以在初期版本不要一上來就追求完美，有瑕疵是很正常的，在考慮到不影響開發設計工作的前提下，将後期叠代的思考加入其中就好了。

• 搭建需求框架，細化了每個功能點上。
• 針對每個功能點，結構化描述詳情功能。
• 最後整體檢查，補充遺漏、摳細節，完善需求文檔。

例如：一個活動管理頁面如下，那我們要如何編寫活動管理模闆的功能說明。

1. 搭建框架

在寫需求文檔前，需要先搭建框架，首先會把這個模塊盡可能細化到功能點，其實就是先寫目錄。結合産品功能的操作，涉及到多個頁面或多個系統的狀态變化；另一個是大框架下的内容是不是有遺漏，有沒有遺漏描述某一項功能邏輯。

2. 結構化描述

通常完成了目錄框架，自己對整個需求就很清晰明朗了，一種一切盡在掌控的感覺，接下來就是挨個補齊具體的需求的功能描述。功能是有邏輯的。而不是隻講功能點羅列出來。通過結構化的梳理，也是自己對系統的進一步深入思考。

所以，産品交付給研發的，是詳細的系統功能說明。研發是實現功能，按照功能清單來，此時産品提供的就是簡明扼要的功能說明。

3. 摳細節

工作中我經常建議産品同學寫完需求文檔後自己再讀一遍，自己讀一遍就能發現很多問題和漏洞。更重要的是，要能代入看需求文檔的人的角色中，以他們的視角來審閱需求。最簡單的，我習慣于将文檔中我認為重要的，擔心他人閱讀時會忽視的段落文字加下劃線或背景色标識，或是特别注明（此處設計師請注意有多個狀态）等。代入測試的角色，試想自己看着這份需求文檔在寫測試用例，通常會發現很多漏洞。

總結

需求文檔不僅僅是為了交付給研發測試而編寫的，是為了降低需求遺漏的風險，降低團隊的矛盾，确保研發理解的功能與産品想要的功能一緻，從而有效避免了團隊甩鍋。

通過編寫需求文檔，産品經理也可以再次梳理一遍需求。或者在研發過程中，根據溝通發現問題，繼續查漏補缺需求文檔。最終反哺于自己，發現自己的遺漏，提升需求質量。這樣長期積累下面的需求文檔，就是一個功能庫，一方面可以引導我們把需求思考的更加清晰，一方面當做功能庫，便于後期的需求複用，幫助我們更快的完成需求文檔，提升效率。

本文由 @瓜子 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部