高質(zhì)量的需求文檔

《不是人人都可以做產(chǎn)品經(jīng)理》---什么是高質(zhì)量的需求文檔1目錄一、前言...2二、什么是需求？...2三、撰寫需求文檔的目的是什么?.3四、什么是需求文檔？...3五、什么是高質(zhì)量的需求文檔（PRD）????4正確...4無歧義（無二義性）4完備...5一致...5具有優(yōu)先級...66. 可驗證...67. 可修改...68. 可追蹤...7六、 參考文獻...7一、 前言本文基于fanny騰訊入職測試實習第三天的當天感想與個人原有感悟。目的：更好的理解需求文檔的目的，了解高質(zhì)量的需求文檔如何撰寫。本文針對互聯(lián)網(wǎng)尤其web領(lǐng)域的產(chǎn)品文檔、不針對游戲等領(lǐng)域。有錯誤請各位及時指出！謝謝！文中有任何錯誤，或者您有任何疑問和建議，歡迎當面一起討論。不吝賜教！為了拉高行業(yè)準入門檻，提升行業(yè)薪資。故叫《不是人人都可以做產(chǎn)品經(jīng)理》。。本人blog:產(chǎn)品經(jīng)理新視線二、 什么是需求？其實我們沒有必要去思考什么叫做需求，因為這個議題太大了，無從談起。針對互聯(lián)網(wǎng)行業(yè)，我們所說的“需求”特指“產(chǎn)品需求”。那么什么是產(chǎn)品需求？站在公司的立場上，需求是為了滿足領(lǐng)導分配的KPI,為了達到特定的經(jīng)濟效益，由產(chǎn)品經(jīng)理制定的一些列的產(chǎn)品描述。那么互聯(lián)網(wǎng)產(chǎn)品都滿足了哪些需求？如果按照產(chǎn)品來劃分，那么騰訊1300多產(chǎn)品各自滿足了不同的需求。從現(xiàn)有理論角度，根據(jù)馬洛斯的需求層次理論：我覺得互聯(lián)網(wǎng)產(chǎn)品滿足了人類的精神性價值需求。傳統(tǒng)行業(yè)產(chǎn)品是滿足了人類的物質(zhì)性價值需求。精神需求是否被滿足是依據(jù)用戶預(yù)期來界定的。這個是動態(tài)平衡的過程，也就是說互聯(lián)網(wǎng)產(chǎn)品的研發(fā)的道路是無止境的！而互聯(lián)網(wǎng)中的電子商務(wù)卻很復(fù)雜，從幾千年前就存在的傳統(tǒng)行業(yè)演變成了現(xiàn)在線上環(huán)節(jié)為主導的行業(yè)，電子商務(wù)傾向于滿足人類物質(zhì)性的需求，這也是電子商務(wù)區(qū)別于一般互聯(lián)網(wǎng)的因素之一。本人更傾向于把電子商務(wù)從互聯(lián)網(wǎng)行業(yè)里面剝離出來看。。扯遠了。。從更高的抽象層次來講：從人類進化角度，弱弱的-，-，我傾向于把人類的需求單純的分為：-生存需求-繁衍需求。。。。扯遠了下篇文章再展開吧。。三、 撰寫需求文檔的目的是什么?了解了需求文檔的目的才能更好的撰寫需求文檔，才能有張有弛的去控制需求分析的粒度。我覺得其目的是:準確的描述需求，使得產(chǎn)品最終形態(tài)與預(yù)期吻合。要達到這個目標，需求文檔對需求的描述必須具備以下特征1.正確2.無歧義3.完備4.一致5.具有優(yōu)先級6.可驗證（易于測試）7.可修改8.可追蹤這樣一看，編寫高質(zhì)量的需求文檔是一件很難的事情。別著急，本文下文講詳細對每一個特征進行解釋。四、 什么是需求文檔？ 業(yè)內(nèi)對于需求文檔有很多種理解形式：PRD、SRS。。。。一般騰訊所指的需求文檔都是PRD(productrequirementsdocument),MRD則更偏市場，SRS則更偏技術(shù)實現(xiàn)(含有數(shù)據(jù)流、時序圖等)。有時候也稱需求文檔為“需求規(guī)格說明書”，其實“需求規(guī)格說明書”是傳統(tǒng)軟件行業(yè)里面用的叫法，如果需要寫得規(guī)范一點，那么就需要按照國家標準的GB，ISO,IEEE的規(guī)范來撰寫“需求規(guī)格說明書”，但是那樣的文檔是十分重型的。在小步快跑，快速迭代的騰訊模式下，輕量的產(chǎn)品需求文檔更加符合騰訊。當然這也不是絕對的。一般大型的項目還是需要有詳細，規(guī)范的，較重型的文檔來支撐的。需求文檔里面主要寫什么?我覺得需求文檔里面主要的內(nèi)容是對需求的描述，通過用例去描述。而在騰訊并不是所有人都知道用例是什么，一般來說都用“功能”、或者“特性”來代替描述用例。傳統(tǒng)軟件行業(yè)過來的人一般都知道吧。。。就是說騰訊內(nèi)部對于“用例”，“功能”，“特性”并沒有形成一個統(tǒng)一的認知。每個人的認知不統(tǒng)一，這是一個比較大的問題，我覺得必須不斷的加強這方面的規(guī)范。我覺得用例其實是UML建模中用例分析環(huán)節(jié)中的輸出物。UML建模是現(xiàn)代軟件產(chǎn)業(yè)常用的較敏捷的方法。適合產(chǎn)品生命周期較短的項目來使用。其實騰訊是蠻受用的。至于UML那一套體系是否適合騰訊，還需要實踐去論證。

產(chǎn)品需求文檔（PRD）重點描述一個被提議的新產(chǎn)品或者現(xiàn)有產(chǎn)品的改進需求。與MRD側(cè)重于從市場需要角度看需求的不同，PRD側(cè)重于從產(chǎn)品本身角度看待需求。通常在特點和功能需求上更深入細節(jié)，并也可能包括屏幕截圖和用戶界面流程。在那些MRD不包括具體需求和用例的機構(gòu)中，PRD就包含這些具體內(nèi)容OPRD通常是由產(chǎn)品經(jīng)理撰寫的OPRD通常是一份連續(xù)的1030頁Word文檔。在我看來需求文檔就是用例的集合。從表現(xiàn)形式來講需求文檔就是：一個用例列表+各個用例的詳細描述。用例的定義是：在不展現(xiàn)一個系統(tǒng)或子系統(tǒng)內(nèi)部結(jié)構(gòu)的情況下，對系統(tǒng)或子系統(tǒng)的某個連貫的功能單元的定義和描述[2]o一般用例主要包含以下條目：用例簡述、用例優(yōu)先級、用例圖、執(zhí)行者、前置條件、后置條件、交互稿及其描述、主流程、分支流（異常流）、業(yè)務(wù)約束。五、什么是高質(zhì)量的需求文檔五、什么是高質(zhì)量的需求文檔（PRD）?總的來講高質(zhì)量的需求文檔就是能最有效的達到需求文檔撰寫目的的文檔（太虛了。O）o即能夠有效協(xié)助產(chǎn)品干系人（視覺、交互、頁面、開發(fā)、測試）完成與預(yù)期吻合的產(chǎn)品。上文中提到，需求文檔對需求的描述必須具備以下特征1. 正確2. 無歧義3.完備4.一致5.具有優(yōu)先級6.可驗證（易于測試）7.可修改8.可追蹤而產(chǎn)品新人需要著重關(guān)注其中的：1、2、51.正確當且僅當PRD中的每一項需求都是產(chǎn)品應(yīng)滿足的需求，PRD才是正確的。不存在確保PRD正確性的工具或規(guī)程。宜把PRD與任何適用的上層規(guī)格說明（如,立項文檔、項目計劃書、MRD）、其他項目文件和其他適用的標準進行對比，以確保其相互一致。作為一種選擇，產(chǎn)品經(jīng)理可以確定PRD是否正確地反映了實際需要?？勺粉櫺允瓜鄳?yīng)的規(guī)程更加便利并減少缺陷。2. 無歧義（無二義性）我覺得需求描述的這個特性是產(chǎn)品經(jīng)理新人最需要注意的需求通常使用自然語言（如，漢語）來編寫。但自然語言固有的不明確性，尤其是漢語這樣的每個詞有很多意思的語言。使用自然語言編制的PRD宜由獨立的一方進行評審，以識別語言的含糊用法并予以糾正。這樣可以讓開發(fā)減少疑惑，讓測試寫的測試用例更加正確。為了消除歧義，其實可以使用需求文檔專用的語言的編寫，但是這樣成本太大了。那么什么叫做無歧義？當且僅當PRD中的每一項需求都只有一種解釋，PRD才是無歧義的。這要求最終產(chǎn)品的每個特征至少使用唯一的術(shù)語來描述。當在特定背景中使用的某個術(shù)語存在多種含義時，宜將該術(shù)語包含在術(shù)語表中，以便更加具體說明其含義。正如在GB/T8566中描述的那樣，SRS是軟件生存周期中需求過程的一個重要部分，并被應(yīng)用于設(shè)計、實現(xiàn)、項目監(jiān)控、驗證和確認，以及培訓活動中。對于編制人員和使用人員。其中的SRS其實可以換成PRD,軟件可以換成產(chǎn)品，即:PRD是產(chǎn)品生存周期中需求過程的一個重要部分，并被應(yīng)用于設(shè)計、實現(xiàn)、項目監(jiān)控、驗證和確認，以及培訓活動中。對于各種產(chǎn)品相關(guān)人員。PRD宜是無歧義的。但是，產(chǎn)品干系人通常并不具備相同的背景，因而對產(chǎn)品需求的描述不會傾向相同的形式。尤其現(xiàn)在騰訊校園招聘的產(chǎn)品經(jīng)理幾乎很少有相同專業(yè)的。每個人可能有各自的描述風格，這樣會降低團隊效率。所以產(chǎn)品新人必須對需求描述的二義性有深刻的理解和感知。這也是為什么我覺得：需求描述的這個特性是產(chǎn)品經(jīng)理新人最需要注意的。3.完備3.當且僅當PRD包含以下要素，PRD才是完備的:a） 所有重要的需求，不論是否與功能、性能、設(shè)計約束、屬性或者外部接口有關(guān)。尤其是由系統(tǒng)條件所施加的任何外部需求都應(yīng)當?shù)玫酱_認和處理。b） 產(chǎn)品響應(yīng)的定義，以說明產(chǎn)品對所有可實現(xiàn)的輸入數(shù)據(jù)類型的響應(yīng)。應(yīng)當注意，對于有效和無效輸入數(shù)值兩種情況，規(guī)定產(chǎn)品響應(yīng)是重要的。c） PRD中所有圖標的全部標記和索引，以及所有術(shù)語和度量單位的定義。任何含有“待定”詞語的PRD是不完備的。但是有時使用“待定”是不可避免的，若萬一使用“待定”時應(yīng)做如下說明：a）對導致使用“待定”的情形進行描述（為什么答案未知），以便問題能得到解決；b）描述為排除“待定”應(yīng)采取的措施、由誰負責排除以及何時必須排除。4. 一致這里的一致是指內(nèi)部一致性。如果PRD與某些更高層的文檔（如，概要設(shè)計文檔）不一致，那么它是不正確的。但是這個不是一致性所涉及的，這個是外部不一致。當且僅當在PRD中描述的任何單個需求的子集之間相互不矛盾，PRD才是內(nèi)部一致的。PRD中可能存在下述三種類型的矛盾顯示世界對象的規(guī)定特征可能相互矛盾。如：1)報告輸出的格式在一個需求中是表格形式，而在另一個需求中是文本形式；2)一個需求指出所有的燈是綠色，而另一個需求規(guī)定所有的燈是藍色。在兩個規(guī)定的行為之間可能存在邏輯上的或時間上沖突。如：1)一個需求規(guī)定程序?qū)蓚€輸入相加，另一個需求則規(guī)定程序?qū)@兩個輸入相乘；2)一個需求指出“A”必須總是在“B”之后，而同時另一個需求中要求“A和B”同時發(fā)生?？赡軆蓚€或更多的需求描述現(xiàn)實世界的相同對象，但使用不同的術(shù)語。如，在一個需求中程序?qū)τ脩糨斎氲恼埱蟪蔀椤疤崾痉?，在另一個需求中稱為“提示”。使用標準術(shù)語和定義可以改善一致性。5.具有優(yōu)先級如果PRD中每條需求(用例)賦有標明其優(yōu)先級的標示，那么該PRD便按照優(yōu)先級進行分級。通常，與產(chǎn)品有關(guān)的所有需求并不具有相同的重要優(yōu)先級性。某些需求可能是基本的(即核心需求，最能驅(qū)動利益增長的需求，最能達到特定KPI的需求)而其他的可能是所期望的需求，可有可無。PRD中的每個需求宜予以標識，以使需求在這方面的差異清晰和明確。另一種需求分級的方式是區(qū)別如下基本的、有條件的和可選的需求類別：基本的——除非表示同意并滿足了這類需求，否則產(chǎn)品將不被接受；有條件的——表示這類續(xù)期會增強軟件產(chǎn)品，但是，如果缺少這類需求，也不會導致軟件產(chǎn)品被拒收；可選的——表示該類功能需求可有可無，這賦予開發(fā)一定開發(fā)彈性。6.可驗證6.當且僅當PRD中的每個需求是可驗證的，PRD才是可驗證的。當且僅當存在某個有限的成本、有效的過程，人或機器依照該過程能夠檢查軟件產(chǎn)品滿足某個需求，該需求才是可驗證的。一般說來，任何有歧義的需求都是不可驗證的。所以一般保證了“無歧義”就可以保證可驗證，即關(guān)注“無歧義”是最重要的。不可驗證的需求包含諸如“工作良好”、“好的人機界面”和“通常應(yīng)該發(fā)生”之類的陳述。因為不可能定義“良好”、“好的”和“通?！?，因此，這些需求不可能驗證。陳述“程序應(yīng)絕對不進入無限循環(huán)”是不可驗證的，因為理論上該特性是不可測試的。可驗證陳述示例：程序輸出應(yīng)在時間開始20s內(nèi)達到60%,在30s內(nèi)達到100%。這樣的陳述是可驗證的，因為它使用了具體的術(shù)語和可測量的數(shù)值。需求描述一定要定量。如果不能設(shè)計出一種方法，以確定產(chǎn)品是否滿足某個具體的需求，那么該需求宜被刪除或被修改。7. 可修改當且僅當PRD的結(jié)構(gòu)和形式能夠?qū)θ魏涡枨筮M行容易、全面和一致的修改,同時保持該結(jié)構(gòu)和形式，PRD才是可修改的。一般地，可修改要求PRD：具有連貫、方便使用的結(jié)構(gòu)，包含目次、索引及清晰的相互引用；沒有冗余(即，相同的需求在PRD不應(yīng)當出現(xiàn)在多處)；c） 分別地表述每個需求，而不與其他需求相混淆。盡管冗余本事不是缺陷，但它容易導致錯誤。盡管冗余偶爾可以有助于PRD的可讀性，但當對存在冗余的文件更新時，可能會引起問題。例如，可能對出現(xiàn)多處的某個需求僅在一處做了修改，那么使得PRD內(nèi)容不一致。當需要冗余是,PRD宜包括一個清晰的交叉索引表，已增加其可修改性。8.可追蹤如果PRD每個需求的來源是清楚的，并在將來編制或增強文檔的過程中便于每個需求的索引，那么該PRD是可追蹤的。推薦以下兩種類型的可追蹤性：a） 逆向可追蹤性（即，到以前的開發(fā)階段）。這依賴于每個需求清晰地指向其在早期文件的來源；b） 正向可追蹤性（即，到由PRD產(chǎn)生的所有文件）。這依賴于PRD中每個需求具有唯一的名稱或索引號。當軟件產(chǎn)品進入運行和維護階段時，PRD的正向可追蹤性尤為重要。隨著代碼好設(shè)計文檔的修改，最要緊的是能夠確定這些修改可能影響的全部的需求集合?？勺粉櫺院檬沟眯枨笞兏尤菀?。六、 參考文獻1】 計算機軟件需求規(guī)格說明規(guī)范GB-T_9385-20082】 /view/706238.