需求文檔

一、為什么軟件開發(fā)項(xiàng)目中，需要需求文檔這么個東西？

在稍微大一點(diǎn)的開發(fā)團(tuán)隊(duì)中，產(chǎn)品經(jīng)理未必能向所有開發(fā)人員，傳達(dá)具體的產(chǎn)品開發(fā)需求。這時就需要一份文檔來供所有的項(xiàng)目參與人員閱讀。產(chǎn)品經(jīng)理常常愛拍腦袋、容易變卦，開發(fā)和UI常常偷工減料，自己發(fā)揮，所以文檔也是約束各方人員的一項(xiàng)武器。在產(chǎn)品上線前的測試環(huán)節(jié)，測試人員也同樣會拿產(chǎn)品需求文檔來驗(yàn)收產(chǎn)品質(zhì)量。當(dāng)團(tuán)隊(duì)進(jìn)入新人時，文檔也可以讓新人更快地了解產(chǎn)品。

所以產(chǎn)品需求文檔有三個核心作用：

• 傳達(dá)產(chǎn)品開發(fā)需求；
• 保證各部門溝通有理有據(jù)
• 產(chǎn)品質(zhì)量控制有具體標(biāo)準(zhǔn)

二、什么是產(chǎn)品需求文檔？

PRD（Product Requirement Document）也就是產(chǎn)品需求文檔，該文檔是產(chǎn)品項(xiàng)目由“概念化”階段進(jìn)入到“圖紙化”階段的最主要的一個文檔，其主要目的是像研發(fā)部門和設(shè)計部門說明產(chǎn)品的功能和性能要求。

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

PRD與MRD、BRD的關(guān)系辨析

三、如何寫好產(chǎn)品需求文檔（PRD）？

一、頭部。

1、文件撰寫相關(guān)信息。

這里的相關(guān)信息都是非常常規(guī)的信息，包括文件名稱、文件撰寫人、撰寫日期、文件版本號、文件審核人、文件審核日期等。

2、文件聲明。

一般是文件使用權(quán)限聲明、文件保密聲明。

3、文件版本與修訂記錄

PRD跟產(chǎn)品一樣也需要不斷的迭代更新優(yōu)化，那么每一次PRD版本的更新與修改都需要做詳細(xì)的記錄。

如圖：

這里的AMD分別代表：添加（added）、修改（modified）、刪除（deleted），每次版本的相應(yīng)操作都必須做出對應(yīng)的標(biāo)注。

二、前言

1、編寫目的。

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

·  開發(fā)人員開發(fā)依據(jù)

·  設(shè)計人員輸入源

·  產(chǎn)品經(jīng)理跟進(jìn)產(chǎn)品執(zhí)行實(shí)現(xiàn)程度的依據(jù)

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

·  外部人員產(chǎn)品理解或執(zhí)行的依據(jù)

·  等等

2、產(chǎn)品（項(xiàng)目）周期。

這部分則是闡述清楚產(chǎn)品需求、設(shè)計、開發(fā)、測試、上線等的相關(guān)周期（可用甘特圖表示）。一個項(xiàng)目開發(fā)周期確定后，沒有特殊情況下就必須嚴(yán)格把控和執(zhí)行項(xiàng)目進(jìn)度。

附上簡單甘特圖：

3、相關(guān)參考文檔資料。

附上相關(guān)參考文檔的信息。以便相關(guān)人員獲取更詳細(xì)的信息。

如圖：

三、產(chǎn)品（項(xiàng)目）概況

1、產(chǎn)品（項(xiàng)目）簡述。

此部分主要是從整體的角度來去闡述一個項(xiàng)目或者產(chǎn)品，包括產(chǎn)品或項(xiàng)目解決的需求、包含哪些產(chǎn)品、包含哪些功能

1.1、產(chǎn)品或項(xiàng)目的整體描述。

整體上描述該產(chǎn)品或項(xiàng)目的全局，從解決的問題、如何解決問題、所創(chuàng)造的價值等方面進(jìn)行闡述。

1.2、描述項(xiàng)目中包含的產(chǎn)品。

如果是一個相對較大的項(xiàng)目則需要分別闡述清楚項(xiàng)目下?lián)碛械母鱾€產(chǎn)品。比如，從客戶端來說，有PC端、微信端、ios和安卓端；從用戶端來說，有B端、有C端。簡述各個產(chǎn)品在項(xiàng)目中發(fā)揮的作用。

1.3、描述產(chǎn)品中包含的功能。

接下則闡述各個產(chǎn)品所包含的主要功能。

如：對于某款K12實(shí)時一對一答疑輔導(dǎo)產(chǎn)品來說，他有老師端和學(xué)生端兩款產(chǎn)品。老師端的主要功能有為學(xué)生解題。學(xué)生端的主要功能為上傳問題。

2、專有名詞解釋。

此部分主要解釋產(chǎn)品中涉及的相關(guān)專業(yè)名詞的解釋。

如下圖，主要為教育機(jī)構(gòu)中的業(yè)務(wù)專有名詞：

3、產(chǎn)品（項(xiàng)目）用戶角色描述。

當(dāng)今互聯(lián)網(wǎng)產(chǎn)品中，產(chǎn)品的用戶都不止一個，PRD需在概況中描述清楚產(chǎn)品中涉及的每一種用戶角色。

如下圖：主要為教育機(jī)構(gòu)中的各種業(yè)務(wù)角色：

4、產(chǎn)品（項(xiàng)目）總體架構(gòu)。

此處畫出產(chǎn)品的總體功能結(jié)構(gòu)圖：功能結(jié)構(gòu)圖根據(jù)產(chǎn)品的每個功能逐一深入畫出結(jié)構(gòu)圖。

如下圖：為K12教育產(chǎn)品學(xué)霸君的功能結(jié)構(gòu)圖；

5、產(chǎn)品（項(xiàng)目）業(yè)務(wù)流程圖。

此處畫出產(chǎn)品總體的功能業(yè)務(wù)流程圖：（該流程圖為現(xiàn)階段搜提類K12在線學(xué)習(xí)APP的大致業(yè)務(wù)流程，流程中并沒有對子流程進(jìn)行細(xì)化。實(shí)際工作PRD中的細(xì)化子流程或文檔可在功能性需求中詳細(xì)附上并詳細(xì)描述。）

流程圖中的圖示：

四、產(chǎn)品功能性需求

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

·  功能性需求一般是指產(chǎn)品中具體的、用戶可使用和感知的功能需求，如登錄注冊功能、導(dǎo)航功能、文件下載功能、支付功能等等。

·  非功能性需求則一般偏向產(chǎn)品的性能需求，如產(chǎn)品響應(yīng)速度需求、產(chǎn)品測試環(huán)境需求、產(chǎn)品的安全需求等等。

通俗的理解，就好比一部電腦功，能性需求是它能上網(wǎng)、能看電影、能聽歌、能玩游戲等等；而非功能性需求則是它的CPU是雙核還是四核，內(nèi)存是4G還是8G，電腦構(gòu)成材質(zhì)是塑料還是金屬等等。

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

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

1、需求編號及名稱。

可根據(jù)需求的類型、需求的名稱以及需求的優(yōu)先級對需求進(jìn)行編號。

需求的類型。如： I=輸入需求(Input)； O=輸出需求(Output)； W=界面需求(Window)； R=角色及權(quán)限(Role)

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

優(yōu)先級。則可直接按序號排列。

2、需求說明。

對某一項(xiàng)需求功能進(jìn)行描述，描述清楚功能的使用者、使用場景、使用動作與步驟、使用結(jié)果。

如：登錄需求：該需求滿足了用戶在未登錄的情況下，觸發(fā)相關(guān)條件，輸入用戶id及密碼即可完成用戶登錄。

3、功能的用戶用例。

這里將以用戶主動登錄的一個功能作為例子，展示功能需求中的用戶用例。

相關(guān)概念的解釋：

·  前置條件：即要完成當(dāng)前動作，必須經(jīng)過的上一動作。

·  基本事件流：用戶在正常情況下無卡點(diǎn)完成某一動作的全部流程。

·  其他事件流：用戶在某動作的操作中操作有誤，由操作中的錯誤可能引發(fā)的相關(guān)流程情況。

·  異常事件流：異常事件流導(dǎo)致該用例無法完成。

·  后置條件：當(dāng)前動作順利完成后抵達(dá)的頁面或觸發(fā)的條件。

4、功能流程。

同樣的將以登錄業(yè)務(wù)流程作為例子展示登錄業(yè)務(wù)中的流程圖。該流程圖詳細(xì)地展示了登錄過程中的所有流程可能，可詳細(xì)查看。

5、產(chǎn)品界面原型。

此產(chǎn)品界面原型為上面所講述的用戶用例中的產(chǎn)品界面原型：

通常的情況下，在原型界面需要附上各個部件的文字解釋以及頁面的動作和跳轉(zhuǎn)邏輯闡述。因?yàn)榇说卿浌δ転檩^常用功能，且用戶用例中也已經(jīng)描述較為清楚了，故此處不做文字解釋及跳轉(zhuǎn)邏輯闡述。

6、相關(guān)字段。

每個功能需求須要寫清楚該功能需求下包含的相關(guān)字段。字段則是指一個對象中包含的相關(guān)變量。

如：對于一個學(xué)生用戶來說，他的字段可能包含以下幾種：id、username（用戶名）、手機(jī)號碼、qq、年級、所在學(xué)校等等

五、非功能性需求

1、產(chǎn)品性能需求。

·  用戶承載量需求。如：支持2萬用戶同時在線。

·  產(chǎn)品響應(yīng)速度需求。如：在網(wǎng)絡(luò)狀況良好的情況下，頁面跳轉(zhuǎn)速度不超過5秒。

2、測試環(huán)境需求。

·  產(chǎn)品測試環(huán)境與正式上線環(huán)境的需求。

3、產(chǎn)品數(shù)據(jù)統(tǒng)計需求。

·  自建的統(tǒng)計數(shù)據(jù)需求。如：相關(guān)事件埋點(diǎn)統(tǒng)計需求。

·  接入第三方數(shù)據(jù)統(tǒng)計接口需求。如：接入友盟統(tǒng)計。

4、安全性需求。

·  惡意注冊防范需求。

·  惡意刷數(shù)據(jù)防范需求

5、產(chǎn)品兼容性需求。

·  客戶端。如：各種主流手機(jī)設(shè)備均可正常使用，無顯示異常，無閃退。

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

實(shí)際上，PRD文檔沒有統(tǒng)一的模板。一般而言，大公司要求文檔規(guī)范、細(xì)節(jié)到位；小公司可能只需要記錄關(guān)鍵信息，剩余的靠口頭溝通；有的公司甚至都不需要文檔，直接通過Axure描述產(chǎn)品需求。

所以務(wù)必記住，寫PRD是為了給研發(fā)和設(shè)計人員理解產(chǎn)品并制作產(chǎn)品，PRD本質(zhì)是工具。只是服務(wù)于產(chǎn)品的執(zhí)行，闡述一種產(chǎn)品執(zhí)行思路。做產(chǎn)品的根本是需求和體驗(yàn)，再好的PRD也不能幫你找準(zhǔn)用戶體驗(yàn)，再清晰的PRD也不能幫你理順用戶體驗(yàn)。