需求文件

一、為什麼軟體開發專案中，需要需求文件這麼個東西？

在稍微大一點的開發團隊中，產品經理未必能向所有開發人員，傳達具體的產品開發需求。這時就需要一份文件來供所有的專案參與人員閱讀。產品經理常常愛拍腦袋、容易變卦，開發和UI常常偷工減料，自己發揮，所以文件也是約束各方人員的一項武器。在產品上線前的測試環節，測試人員也同樣會拿產品需求文件來驗收產品質量。當團隊進入新人時，文件也可以讓新人更快地瞭解產品。

所以產品需求文件有三個核心作用：

• 傳達產品開發需求；
• 保證各部門溝通有理有據
• 產品質量控制有具體標準

二、什麼是產品需求文件？

PRD（Product Requirement Document）也就是產品需求文件，該文件是產品專案由“概念化”階段進入到“圖紙化”階段的最主要的一個文件，其主要目的是像研發部門和設計部門說明產品的功能和效能要求。

要注意：需求文件分為BRD(Business RequirmentsDocument)商業需求文件、MRD（MarketRequirments Document）市場需求文件、PRD（Product Requirement Document）產品需求文件三類。

PRD與MRD、BRD的關係辨析

三、如何寫好產品需求文件（PRD）？

一、頭部。

1、檔案撰寫相關資訊。

這裡的相關資訊都是非常常規的資訊，包括檔名稱、檔案撰寫人、撰寫日期、檔案版本號、檔案稽核人、檔案稽核日期等。

2、檔案宣告。

一般是檔案使用許可權宣告、檔案保密宣告。

3、檔案版本與修訂記錄

PRD跟產品一樣也需要不斷的迭代更新優化，那麼每一次PRD版本的更新與修改都需要做詳細的記錄。

如圖：

這裡的AMD分別代表：新增（added）、修改（modified）、刪除（deleted），每次版本的相應操作都必須做出對應的標註。

二、前言

1、編寫目的。

這部分主要闡述PRD的作用：

•  開發人員開發依據

•  設計人員輸入源

•  產品經理跟進產品執行實現程度的依據

•  測試人員編寫功能測試用例的輸入源

•  外部人員產品理解或執行的依據

•  等等

2、產品（專案）週期。

這部分則是闡述清楚產品需求、設計、開發、測試、上線等的相關週期（可用甘特圖表示）。一個專案開發週期確定後，沒有特殊情況下就必須嚴格把控和執行專案進度。

附上簡單甘特圖：

3、相關參考文件資料。

附上相關參考文件的資訊。以便相關人員獲取更詳細的資訊。

如圖：

三、產品（專案）概況

1、產品（專案）簡述。

此部分主要是從整體的角度來去闡述一個專案或者產品，包括產品或專案解決的需求、包含哪些產品、包含哪些功能

1.1、產品或專案的整體描述。

整體上描述該產品或專案的全域性，從解決的問題、如何解決問題、所創造的價值等方面進行闡述。

1.2、描述專案中包含的產品。

如果是一個相對較大的專案則需要分別闡述清楚專案下擁有的各個產品。比如，從客戶端來說，有PC端、微信端、ios和安卓端；從使用者端來說，有B端、有C端。簡述各個產品在專案中發揮的作用。

1.3、描述產品中包含的功能。

接下則闡述各個產品所包含的主要功能。

如：對於某款K12實時一對一答疑輔導產品來說，他有老師端和學生端兩款產品。老師端的主要功能有為學生解題。學生端的主要功能為上傳問題。

2、專有名詞解釋。

此部分主要解釋產品中涉及的相關專業名詞的解釋。

如下圖，主要為教育機構中的業務專有名詞：

3、產品（專案）使用者角色描述。

當今網際網路產品中，產品的使用者都不止一個，PRD需在概況中描述清楚產品中涉及的每一種使用者角色。

如下圖：主要為教育機構中的各種業務角色：

4、產品（專案）總體架構。

此處畫出產品的總體功能結構圖：功能結構圖根據產品的每個功能逐一深入畫出結構圖。

如下圖：為K12教育產品學霸君的功能結構圖；

5、產品（專案）業務流程圖。

此處畫出產品總體的功能業務流程圖：（該流程圖為現階段搜提類K12線上學習APP的大致業務流程，流程中並沒有對子流程進行細化。實際工作PRD中的細化子流程或文件可在功能性需求中詳細附上並詳細描述。）

流程圖中的圖示：

四、產品功能性需求

任何產品的需求都可以分為功能性需求和非功能性需求兩類。

•  功能性需求一般是指產品中具體的、使用者可使用和感知的功能需求，如登入註冊功能、導航功能、檔案下載功能、支付功能等等。

•  非功能性需求則一般偏向產品的效能需求，如產品響應速度需求、產品測試環境需求、產品的安全需求等等。

通俗的理解，就好比一部電腦功，能性需求是它能上網、能看電影、能聽歌、能玩遊戲等等；而非功能性需求則是它的CPU是雙核還是四核，記憶體是4G還是8G，電腦構成材質是塑料還是金屬等等。

某種程度上，一個產品的功能性需求決定了這個產品能不能用，一個產品的非功能性需求則決定了這個產品能用多久，而一個產品好不好用則是功能性需求及非功能性需求的雙重體現。

以下將以“註冊登入”功能為例，講解在PRD中一個功能性需求的闡述。功能性需求的闡述也是一份PRD中最重要的部分，在實際工作中功能性需求的描述佔了整個PRD的50%以上。

1、需求編號及名稱。

可根據需求的型別、需求的名稱以及需求的優先順序對需求進行編號。

需求的型別。如： I=輸入需求(Input)； O=輸出需求(Output)； W=介面需求(Window)； R=角色及許可權(Role)

需求的名稱。如：登入=longin；支付=payment。當然，除了大部分通用的功能需求外，大部分的需求名字是配有專業名詞的。如：課程消耗=CoursesConsumption。

優先順序。則可直接按序號排列。

2、需求說明。

對某一項需求功能進行描述，描述清楚功能的使用者、使用場景、使用動作與步驟、使用結果。

如：登入需求：該需求滿足了使用者在未登入的情況下，觸發相關條件，輸入使用者id及密碼即可完成使用者登入。

3、功能的使用者用例。

這裡將以使用者主動登入的一個功能作為例子，展示功能需求中的使用者用例。

相關概念的解釋：

•  前置條件：即要完成當前動作，必須經過的上一動作。

•  基本事件流：使用者在正常情況下無卡點完成某一動作的全部流程。

•  其他事件流：使用者在某動作的操作中操作有誤，由操作中的錯誤可能引發的相關流程情況。

•  異常事件流：異常事件流導致該用例無法完成。

•  後置條件：當前動作順利完成後抵達的頁面或觸發的條件。

4、功能流程。

同樣的將以登入業務流程作為例子展示登入業務中的流程圖。該流程圖詳細地展示了登入過程中的所有流程可能，可詳細檢視。

5、產品介面原型。

此產品介面原型為上面所講述的使用者用例中的產品介面原型：

通常的情況下，在原型介面需要附上各個部件的文字解釋以及頁面的動作和跳轉邏輯闡述。因為此登入功能為較常用功能，且使用者用例中也已經描述較為清楚了，故此處不做文字解釋及跳轉邏輯闡述。

6、相關欄位。

每個功能需求須要寫清楚該功能需求下包含的相關欄位。欄位則是指一個物件中包含的相關變數。

如：對於一個學生使用者來說，他的欄位可能包含以下幾種：id、username（使用者名稱）、手機號碼、qq、年級、所在學校等等

五、非功能性需求

1、產品效能需求。

•  使用者承載量需求。如：支援2萬用戶同時線上。

•  產品響應速度需求。如：在網路狀況良好的情況下，頁面跳轉速度不超過5秒。

2、測試環境需求。

•  產品測試環境與正式上線環境的需求。

3、產品資料統計需求。

•  自建的統計資料需求。如：相關事件埋點統計需求。

•  接入第三方資料統計介面需求。如：接入友盟統計。

4、安全性需求。

•  惡意註冊防範需求。

•  惡意刷資料防範需求

5、產品相容性需求。

•  客戶端。如：各種主流手機裝置均可正常使用，無顯示異常，無閃退。

•  WEB端。如：各種主流的尺寸及終端的WEB端顯示的頁面均無顯示異常。

實際上，PRD文件沒有統一的模板。一般而言，大公司要求文件規範、細節到位；小公司可能只需要記錄關鍵資訊，剩餘的靠口頭溝通；有的公司甚至都不需要文件，直接通過Axure描述產品需求。

所以務必記住，寫PRD是為了給研發和設計人員理解產品並製作產品，PRD本質是工具。只是服務於產品的執行，闡述一種產品執行思路。做產品的根本是需求和體驗，再好的PRD也不能幫你找準用戶體驗，再清晰的PRD也不能幫你理順使用者體驗。

洋氣貓臉

http://www.pmcaff.com/article/index/549454231946304