主要涉及的文檔是產品需求文檔（PRD），內容有：
工具：markdown、Axure、visio、墨刀、xmind
寫作前準備
梳理需求
原型設計
撰寫文檔
用例文檔
http://www.woshipm.com/pd/80054.html
寫作前準備
PRD是基于BRD、MRD的延續文檔，主要用于產品設計和開發測試使用，因此閱讀人群大多數是設計和技術人員。在這類人群中，設計師跟多依賴于原型進行交互或視覺設計，因此看這份文檔的人就會偏向于技術人員。相對于技術人員，他們不太援助產品的商業需求和市場愿景，因為在進行產品討論立項時，產品的定義就已經向參與設計和研發的人員宣講過，因此技術人員跟多的關注界面，功能，交互，元素等內容，因此PRD文檔是一份詳細的產品功能需求說明文檔，是產品文檔中最底層和最細致的文檔。
所以規劃產品的第一步就是梳理出產品的信息結構，有了信息結構我們才能繼續往下規劃產品結構，并且信息結構是服務端技術人員創建數據庫的依據，是數據機構的輔助文件。對于新產品或者新功能，沒有人能夠比產品經理更加清楚所需要的信息內容了，因此第一步我們就需要先將這些信息羅列出來，形成結構化。
梳理需求
上一節說到信息結構，羅列出產品的所有信息內容，現在我們就要依據信息結構開始規劃產品的功能需求，繪制出產品結構圖和用戶流程圖。首先我們要規劃處產品的頻道和子頻道、子模塊或子頁面：
然后就是用戶流程圖，用于展現產品經理腦海中的比較抽象的產品邏輯，也就是產品經理對自己的產品想法進行梳理的一個過程：
這樣做的目的是梳理產品邏輯，讓我們清楚知道產品有幾個頻道，頻道下面有沒有子頻道或者子頁面，有無疏漏，可以對整個產品做一個鳥瞰式的查看。而且修改起來比文檔或者原型方便很多。也易于給開發人員灌輸一個整體框架。
原型設計
前兩節幫助我們結構化梳理，接下來進行可行性推演，驗證是否可行，花費多少資源，原型設計幫我們更加細致的考慮。
撰寫文檔
PRD文檔沒有標準的規范，也沒有統一的模板，每個公司不一樣，取決于團隊要求和個人習慣。但是也有兩項是必不可少的，那就是文件表示和修改記錄。文檔在撰寫過程中，我們自行不斷修改完善，但是如果正式交付給團隊其它人員后，一旦有了修改，為了文檔的同步，我們就需要標注出文檔的修改內容，備注修改記錄。關于標識和修改記錄：
word文檔
傳統意義上的PRD文檔，主要有四個部分組成：結構圖、全局說明、頻道功能、效果圖。前面說過，這是給技術人員看的說明文檔，所以最簡單明了，用最少的文字交代清楚最好，大多數技術人員沒有足夠的耐心認真看完PRD文檔。
1）結構圖：
2）全局說明：主要講解產品的全局性功能的說明，例如網站產品的頁面編碼、用戶角色、移動產品的緩存機制、下載機制，這類全局性功能的說明，這里舉一個例子：
狀態的維持與恢復
當用戶退出產品時（誤操作、Home鍵、鎖屏、自動關機），產品需要維持用戶操作前的狀態，當用戶返回產品時仍可以恢復到之前狀態，并繼續使用。
維持狀態包括流程操作、信息瀏覽、文本輸入、文件下載。
鎖屏狀態時，如果用戶在產品中有下載任務時，仍然保持下載。
3)頻道功能：以頻道為單位，頁面為子項，分別描述產品的頻道、頁面及頁面模塊元素的功能需求(格式如下)。
示例格式
1、頻道名：頻道介紹及需求說明
2、頁面1：頁面介紹及需求說明
2.1、頁面模塊1：模塊功能需求說明
2.1.1、頁面模塊1-元素1：功能說明
2.1.2、頁面模塊1-元素2：功能說明
2.2、頁面模塊2：模塊功能需求說明
在撰寫功能需求時，我們需要考慮用戶的流程，例如一個“完成”按鈕，我們需要描述他完成后，系統要不要給出反饋提示(反饋提示是什么樣的形式反饋，內容顯示成什么，有沒有內容需要調取數據庫)，或者要不要跳轉頁面(跳轉到哪個頁面，這個頁面是其他頻道頁面，還是這個功能的子頁面，如果是子頁面就需要再描述這個子頁面的模塊及元素內容)。
4)效果圖：效果圖是由設計師完成的產品圖，和實際開發完成的產品保真度一致。
用例文檔
在產品和技術領域里都有UML的技能知識，而對于出品人月的UML則更多的是指用例圖，也就是我們所說的用戶流程圖。
用例文檔是由多個用例組成的一份文檔，主要用于技術開發與測試使用，他是PRD中的重要輔助文檔，用于講解某個環節的功能邏輯，例如用戶注冊、活動報名等等功能都是需要用例輔助說明的。用例文檔的寫作時間在原型設計之后，通常和PRD文檔同步撰寫。
用例文檔中有兩個關聯文件，分別是用例圖和流程圖。用例圖是UML的一種類圖表現方式，是從用戶角度描述產品功能，并指出該用戶在產品各功能中的操作權限。流程圖是通過線框圖形的方式描述產品功能的處理過程，主要是描述功能的執行順序、分支和循環的邏輯。
寫用戶文檔的常用軟件是Word，其中用例圖和流程圖的制作軟件常用的是Visio，當然也有用Axure RP軟件制作的，例如下面的第三步流程圖就是用Axure RP制作的。
一份完整的用例文檔分別是由以下三點內容組成，其中第3點的“用例”是描述功能邏輯的部分，根據功能的多少決定有多少個用例。
用例文檔的大概組成部分如下：
1、修改記錄：每次修改的備注記錄，同PRD文檔。
2、角色介紹：描述參與系統中的各個角色
3、用例：同下方步驟的第4步，其中第3步中的流程圖是直接插入到第4步的流程圖表格項中的。
用例文檔的模板格式如同以上三點內容，通過Word文檔繪制表格，在表格中撰寫用例描述，表格的格式和樣式參考以下示例圖。
1、撰寫用例文檔的第一步是注明使用產品的各個角色(參與者)和角色說明(角色介紹)。（如下圖）
2、第二步是以用例圖的方式注明角色在前后端的用例關系。（如下圖）
3、第三步是以流程圖的方式注明角色在各個功能環節的活動過程。（如下圖：以活動報名為示例）
4、第四步則是以用例文檔的方式將以上三步整合到一起，并撰寫各個功能環節的用例描述。（如下圖）
表格說明：
4.1、用例名：此功能環節的名稱
4.2、用例編號：在此產品中該用例的編號
4.3、行為角色：參與或操作(執行)該功能的角色
4.4、簡要說明：用最少的文字描述一下該用例的需求
4.5、前置條件：參與或操作(執行)此功能的前提條件
4.6、后置條件：執行完畢后的結果條件
4.7、流程圖：該功能的角色活動過程(處理過程)圖（第三步中的圖）
上面示范的用例描述相對簡單，也是最常用和基本的用例描述內容，當然也有稍微復雜一點的用例文檔，文檔中會詳細描述使用場景、事件流和信息字段，也有一些用例文檔還會插入產品界面效果圖。
使用場景主要描述行為角色在不同情況下使用產品時，根據情況或問題給出相應的系統反饋。事件流類似流程圖，只不過是通過文字的方式描述角色的活動過程。信息字段主要是描述用例中所用到的數據字段。
這些更多的描述內容取決于個人的習慣，最終目的都是為了描述清晰產品邏輯，因此我的原則就是用越少的文字描述清晰越多的需求說明。（畢竟這些文檔是產品開發中的執行文檔，文字不在多，表達清晰即可。）
