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

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