產(chǎn)品需求文檔PRD的寫作方法

1、產(chǎn)品需求文檔（PRD）的寫作方法無論我們做什么事都講究方式方法，寫產(chǎn)品需求文檔 （以下稱PRD文檔）也是如此，之 前我通過五篇文章分享了自己寫 PRD文檔的一些方法，而這一篇文章主要是對之前五 篇文章進行整體的摘要介紹，幫助大家快速了解寫作流程。產(chǎn)品需求文檔（PRD）的寫作五篇章：1、寫前準備（信息結構圖）2、梳理需求（產(chǎn)品結構圖和用戶流程圖）3、原型設計（手繪原型，灰模原型，交互原型）4、撰寫文檔（PRD文檔）5、用例文檔（UML用例圖、流程圖）1、寫前準備（信息結構圖）：在寫PRD文檔之前，我們需要先羅列出產(chǎn)品功能的信息內容，這一步是將想法逐 漸清晰的第一步，也是幫助我們接下來規(guī)劃功能的輔

2、助信息，同時也可以輔助服務端 技術人員創(chuàng)建數(shù)據(jù)庫。因為這是第一步，所以我們不需要羅列的很詳細，在之后的步 驟里，我們會逐步改進和完善信息內容。例如一篇文章的信息內容主要有：文章標題、文章正文、文章作者、發(fā)布時間、所 屬分類。初始的功能需求只有這些信息內容，但是在之后的功能規(guī)劃中逐漸更加細致 的考慮時，可能會增加或者刪減，因此第一步我們不用刻意的追求信息的全面。羅列信息內容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是 能夠清晰易懂，我最常用的方法就是思維導圖，因此我稱這一步為信息結構圖。2、梳理需求（產(chǎn)品結構圖和用戶流程圖）:當我們對產(chǎn)品的信息結構了解后，我們就需要規(guī)整腦海中的產(chǎn)

3、品需求， 讓想法更加結構化，因此這一步是梳理產(chǎn)品的需求。我們首先要羅列出產(chǎn)品的頻道及頁面（產(chǎn)品結構圖），其次再基于產(chǎn)品結構圖梳理出頻道及頁面中的功能，并延伸構建出用戶的操作 流程（用戶流程圖）。以上兩步是為了讓我們在撰寫產(chǎn)品需求文檔之前能夠對產(chǎn)品有一個全面的了解，類似鳥瞰式的一目了然，也方便調整完善。3、原型設計（手繪原型，灰模原型，交互原型）：當我們逐漸清晰了產(chǎn)品的需求后，并梳理了產(chǎn)品的各個頻道及頁面，那么這一步就 要開始驗證這些想法的具體界面表現(xiàn)和方案的可行性了。首先我建議通過手繪的形式快速在草紙上繪制出產(chǎn)品的原型，推演和討論方案的可行性，當有一定的進展之后，我們再通過軟件工具進行更深入的

4、設計。移動產(chǎn)品可以考慮灰模原型，網(wǎng)站產(chǎn)品可以考慮交互原型，對于這兩種原型方式，無論是移動產(chǎn)品還是網(wǎng)站產(chǎn)品都可以使用，具體取得于你的個人習慣和團隊要求。對于產(chǎn)品經(jīng)理來說，原型設計是為了幫助我們細致的考慮方案， 并論證方案的可行 性，同時也是為了避免產(chǎn)品宣講時，抽象的語言描述導致聽眾理解困難和理解偏差。4、撰寫文檔（PRD文檔）：當我們通過以上三個大的步驟之后，我們就已經(jīng)非常清晰產(chǎn)品的需求了， 一般情況 下，通過原型加描述的方式就已經(jīng)完成了PRD文檔的目的（很多產(chǎn)品經(jīng)理直接使用Axure 制作 PRD）。當然也會有一些個人或團隊的要求不一樣，對 PRD文檔有特定的規(guī)范標準，這類 情況可能是需要存檔

5、歸類。無論什么樣的規(guī)范標準， PRD文檔的目的都是相近的，因 此功能描述的方式也是相似的，所以在這里我分享了三種撰寫 PRD文檔的方式。5、用例文檔（UML用例圖、流程圖）：產(chǎn)品需求文檔（PRD）的寫作方法的補充文章，主要講解 PRD文檔中的重要輔 助文檔“用例文檔”。產(chǎn)品需求文檔的寫作（一）-寫前準備（信息結構圖）當我們初次接觸產(chǎn)品需求文檔時，首先會從網(wǎng)絡上尋找產(chǎn)品需求文檔模板，希望從中了解和學習具體的寫作要求，但實際上，現(xiàn)在網(wǎng)絡上絕大部分的PRD文檔都是與實際工作不相符的，或者說是復雜的。前幾天一位從事產(chǎn)品類工作的朋友，發(fā)來一份他寫的產(chǎn)品需求文檔目錄截圖給我（下圖），當時我就郁悶了，這些類

6、目更像是 MRD文檔，而不是PRD文檔了，因此我 決定寫幾篇講述寫作PRD文檔的文章，分享一些我關于PRD文檔的見解和寫作方法。PRD是英文ProductRequirementDocument的縮寫，中文的意思是產(chǎn)品需求文檔，具體的名詞介紹大家可以詢問 Google 。 PRD文檔是基于BRD、MRD的延續(xù)文檔，主要用于產(chǎn)品設計和開發(fā)使用，因此閱讀這份文檔的人群絕大多數(shù)是設計與技術人員。在這類人群中，設計師更多依賴于原型進行交互或視覺的設計，因此看這份文檔的人就會偏向于技術人員。相對于技術人員，他們不太關注產(chǎn)品的商業(yè)需求和市場愿景，因為在進行產(chǎn)品討論立項時，產(chǎn)品的定義就已經(jīng)向參與設計和研發(fā)的人

7、員宣講過，因此技術人員更多的是關注界面、功能、交互、元素等等內容，因此 PRD文檔是 一份詳細的產(chǎn)品功能需求說明文檔，是產(chǎn)品文檔中最底層和最細致的文檔。PRD文檔是一份沒有閑話，直入主題的功能說明文檔，因此我們在寫作時，腦海里構思的是成品產(chǎn)品的界面功能的邏輯線框圖。在寫作這份文檔前，我們需要先做一些準備，把BRD、MRD的相關需求消化并融合規(guī)劃出產(chǎn)品的結構圖。因為這些準備工作是屬于思維類的，所以我推薦使用思維導圖軟件（MindManager）進行規(guī)劃工作規(guī)劃產(chǎn)品的第一步就是梳理出產(chǎn)品的信息結構， 有了信息結構我們才能繼續(xù)往下規(guī) 劃產(chǎn)品結構，并且信息結構是服務端技術人員創(chuàng)建數(shù)據(jù)庫的依據(jù)，是數(shù)據(jù)結

8、構的輔助 文件。對于新產(chǎn)品或者新功能，沒有人能夠比產(chǎn)品經(jīng)理更加清楚所需要的信息內容了， 因此第一步我們就需要先將這些信息羅列出來，形成結構化。（如下圖）這張圖是以我的博客作為示例，在羅列信息結構時，我們更多的是考慮信息數(shù)據(jù)， 因此在這一步，我們還不需要深入的考慮產(chǎn)品的界面與功能。信息結構的考慮有面向 前端的，也有面向后端的，具體視產(chǎn)品類型而定。例如CMS之類的程序，這類程序采用框架式開發(fā)，將功能與模板獨立，因此前端 具有多變性，并且這類產(chǎn)品屬于平臺型產(chǎn)品。針對這類產(chǎn)品，我們在規(guī)劃信息結構時， 只需要簡單的考慮一些前端的功能需求，更多的是面向后端管理員操作進行考慮，從 后端入手規(guī)劃和羅列出所需要

9、的信息內容結構。無論是什么樣的產(chǎn)品類型，無論從哪里入手，我們第一步都是先要羅列信息結構， 因為信息結構圖不僅是輔助技術人員創(chuàng)建數(shù)據(jù)庫的圖表，也是輔助產(chǎn)品人員進行產(chǎn)品 功能規(guī)劃的參考，只有對信息或數(shù)據(jù)的結構了解，我們才能玩轉數(shù)據(jù)，玩轉產(chǎn)品。在信息結構轉數(shù)據(jù)結構時，如果是針對已經(jīng)存在的產(chǎn)品而增加的新功能， 那么技術 人員就需要根據(jù)這個信息結構進行數(shù)據(jù)庫對比，已經(jīng)存在的數(shù)據(jù)便直接調用，如果不 存在，則就需要具體的討論，確定新信息的使用途徑和以后的擴展方向，以便確認是 創(chuàng)建數(shù)據(jù)表還是創(chuàng)建數(shù)據(jù)字段。（雖然產(chǎn)品經(jīng)理不需要技術開發(fā)，但是如果能夠懂技 術原理和數(shù)據(jù)庫原理，非常有助于產(chǎn)品規(guī)劃和技術溝通。）信息結

10、構圖是產(chǎn)品層面的理解，如果要入庫這些信息，還需要進行數(shù)據(jù)結構的討論。 一條信息的存儲有很多附加屬性，具體是存成字段還是數(shù)據(jù)表，還是說存在中間表或 者關聯(lián)表，這些都需要在完成PRD文檔后和數(shù)據(jù)庫技術人員共同討論。討論時除了展示信息結構圖，還要講解產(chǎn)品原型和功能需求，以便數(shù)據(jù)庫技術人員了解產(chǎn)品意圖, 方便他們做數(shù)據(jù)庫規(guī)劃時考慮到以后的擴展。信息結構圖是我們將概念想法形成結構化的第一步，也是我們接下來幾步工作的輔 助文件，同時在接下來的幾步工作中，我們還會不斷的完善信息的結構。產(chǎn)品需求文檔的寫作（二）梳理需求（產(chǎn)品結構圖和用戶流程圖）上一篇我們將概念想法形成了信息結構，羅列出了產(chǎn)品的所有信息內容，現(xiàn)

11、在我們 就要依據(jù)信息結構，開始規(guī)劃產(chǎn)品的功能需求，繪制出產(chǎn)品結構圖和用戶流程圖。首 先我們要規(guī)劃出產(chǎn)品的頻道及子頻道、子模塊或子頁面。（如下圖）圖注：講解一下我對于這個思維導圖的名詞理解1、頻道：某一個同性質的功能或內容的共同載體，也可稱為功能或內容的類別。2、子頻道：某頻道下細分的另一類別3、頁面：單個或附屬某個頻道或分類下的界面4、模塊：頁面中多個元素組成的一個區(qū)域內容，可以有一個或多個，也可以循環(huán)出現(xiàn)（例如:文章列表）5、模塊元素：模塊中的元素內容，以文章列表舉例：文章標題、文章摘要、文章 發(fā)布時間，這些都是元素，都是組成模塊的內容，同時他們也是可以循環(huán)出現(xiàn)的。元 素的類型可以是：文字、

12、圖片、鏈接等等如果你學過網(wǎng)頁設計，或者了解Web產(chǎn)品的模板機制，你就能夠理解這些名詞了。 如下圖所示，這是我的博客的首頁結構。當我們規(guī)劃出頻道后，我們就需要以用戶的視角進行一步一步的模擬操作，逐漸完善產(chǎn)品的結構導圖。我稱為用戶流程圖，用于展現(xiàn)產(chǎn)品經(jīng)理腦海中比較抽象的產(chǎn)品邏輯，也是產(chǎn)品經(jīng)理對自己腦海中的產(chǎn)品想法進行梳理的一個過程。（如下圖示例）這樣做的目的就是梳理產(chǎn)品邏輯，讓我們清楚的知道產(chǎn)品有幾個頻道， 頻道下面有 沒有子頻道或者有多少個頁面，這些頁面里又有哪些功能模塊，這些功能模塊里又有 哪些元素。這樣我們就模擬了用戶的整個操作流程，逐一的將產(chǎn)品的所有功能界面操 作了一遍，也列出了產(chǎn)品結構圖

13、和用戶流程圖。有了這份結構導圖，我們可以對產(chǎn)品進行鳥瞰式考慮和完善， 當有問題時，修改起 來也比原型和文檔方便很多。這樣的方法同樣適用于移動互聯(lián)網(wǎng)產(chǎn)品的規(guī)劃，并且比 起Web產(chǎn)品更加容易梳理產(chǎn)品結構。以上講的都是前端面向瀏覽者的用戶流程，但是如果規(guī)劃的是一個平臺級的大眾化 產(chǎn)品就不能從前端進行梳理了，例如 CMS、BBS之類的程序，他們采用框架式開發(fā)， 將功能與模板獨立，前端的界面布局僅僅是通過模板機制的標簽調用，因此在做產(chǎn)品 規(guī)劃時，前端是涉及不到的，也不應該從前端入手。遇到 CMS類平臺產(chǎn)品的規(guī)劃，也 同樣使用這樣的方法，只不過是從后臺入手模擬管理員的流程。PRD文檔寫前準備就是讓我們先通

14、過思維導圖梳理思路，明白產(chǎn)品有多少個頻道、有多少個頁面、頁面有多少個功能模塊、功能模塊有多少個元素，逐步的將腦海里的 想法明確梳理成結構。雖然已經(jīng)明確了產(chǎn)品的結構，但是這樣的思維導圖對于設計與 技術人員依舊是抽象的，他們仍然看不懂，同時對于產(chǎn)品經(jīng)理自己來說，這樣的結構 圖也是沒有經(jīng)過推演的，具體是否符合產(chǎn)品邏輯，是否符合用戶體驗，都是沒有深思 過的，因此我們接下來就要進行原型設計，開始具體的考慮結構方案的可行性。下一篇我將講解原型設計的幾種方法，并說明為什么原型設計要早于產(chǎn)品需求文檔 的撰寫。產(chǎn)品需求文檔的寫作（二）原型設計（手繪原型，灰模原型，交互原型）上一篇文章我們通過思維導圖將想法進行了

15、結構化梳理， 接下來我們就需要進行方 案的可行性推演，驗證產(chǎn)品功能是否可行，預估項目要花多少人力物力，因此我們就 要通過原型設計進行相關需求的論證。一開始就撰寫 PRD文檔，我們很難對產(chǎn)品進行 各方面的評估，也無法得知方案的可行性，并且無法直觀細致的考慮產(chǎn)品。原型設計是幫助我們更細致的思考， 并做各項需求的評估，同時也是將自己腦海里 的想法進行輸出，通過原型設計后，我們就可以進行產(chǎn)品宣講了。相對于之前抽象的 文字描述，原型則更加清晰產(chǎn)品的需求，設計和技術人員或者老板也能夠更加直觀的 了解到產(chǎn)品意圖。原型設計是將結構化的需求進行框架化， 因此原型也被稱為線框圖，具體的表現(xiàn)手 法有很多種，相關的輔

16、助軟件也有很多，例如： AxureRP、BalsamiqMockups 、 UIDesigner 等等。當?shù)搅嗽驮O計這一步時，已經(jīng)不僅僅是構思了，我們需要更加深入的了解每個頁 面上的元素和這些元素的屬性。例如按鈕元素，我們就需要考慮這個按鈕的功能，并 且這個功能操作后帶給后端和前端的反饋。舉例這個按鈕是注冊會員按鈕，用戶操作 后，第一步邏輯是驗證用戶輸入的信息是否合法，不合法則給出前端反饋；合法則和 后端通信驗證是否已經(jīng)存在同樣信息，已經(jīng)存在則給出前端反饋，不存在則進入下一 步，注冊成功；注冊成功后的反饋是跳轉頁面，還是彈出層提示用戶完善資料，這些 都是需要更詳情的考慮的。當然這些更細致的思

17、考是留在需求文檔撰寫時的，而此時 我們需要做的就是把這些元素通過原型表現(xiàn)出來原型設計的表現(xiàn)手法主要有三種：手繪原型、灰模原型、交互原型1、手繪原型因為原型也被稱為線框圖，因此手繪是最簡單直接的方法，也是最快速的表現(xiàn)產(chǎn)品 輪廓的手法（如下圖）。手繪原型在初期驗證想法時非常高效， 也方便討論和重構，同時也適合敏捷開發(fā)時 快速出原型。2、灰模原型灰模原型是由圖形設計軟件制作而成，我最常用 的軟件是PhotoShop 和 FireWorks ,相對手繪原型，灰模更加清晰和整潔， 也適用于宣講，但是需要產(chǎn)品人員 熟悉使用圖形設計軟件（如下圖）。灰模原型常用于移動互聯(lián)網(wǎng)產(chǎn)品的設計， 由于移動產(chǎn)品的交互需求

18、復雜，原型設計 軟件難以高效的表達需求，因此移動互聯(lián)網(wǎng)產(chǎn)品的設計通常是灰模原型加交互文檔組 合成PRD文檔。（過幾天我再詳情講講移動互聯(lián)網(wǎng)的產(chǎn)品設計）3、交互原型交互原型是使用原型設計軟件完成的原型，常用軟件是AxureRP ,通常情況交互原型的設計僅早于PRD文檔，是產(chǎn)品經(jīng)理想法推演的最后一步。通過 AxurePR之類 的交互原型軟件制作出來的產(chǎn)品原型，在功能需求與交互需求的表現(xiàn)和正式產(chǎn)品幾乎 是一致的，所以有時交互原型也被稱為產(chǎn)品 Demo版。通常情況下交互原型是產(chǎn)品經(jīng)理與交互設計師共同討論確定，然后由交互設計師制作，但是絕大多數(shù)的公司是沒有交互設計師這個職位的，因此這類工作最終是由產(chǎn)品

19、經(jīng)理來負責的。（很多公司給視覺設計師的職稱是交互設計師，但本質還是視覺設計）關于AxurePR制作交互原型我在這里就不多介紹了，網(wǎng)絡上有很多這類的教程,我個人建議是學習AxurePR時，隨便了解一下網(wǎng)站模板的結構，這樣可以幫助你更加 結構化使用AxurePR。以上三種方法并不是漸進的流程，而是三種原型設計的方法，具體取決于你的產(chǎn)品 需求和團隊要求。產(chǎn)品經(jīng)理設計原型是為了幫助自己更細致的思考方案的可行性，也是為了給別人講解的時候，讓聽眾能夠清晰直觀的了解產(chǎn)品，同時也是為了確保產(chǎn)品在執(zhí)行過程中， 是按產(chǎn)品經(jīng)理最初設想的需求和期望完成的。因此產(chǎn)品經(jīng)理的原型是沒有很高的要求 的，只要對方能夠聽懂看懂，

20、使用手繪原型是最高效率的方法。產(chǎn)品需求文檔的寫作（四）-撰寫文檔（PRD文檔）前三篇文章我們逐步梳理了產(chǎn)品的信息結構、框架結構、界面結構（原型），這一步我們就要根據(jù)之前完成的工作，開始正式撰寫產(chǎn)品需求文檔了（PRD文檔）。通過之前的準備工作，我們更加清楚了產(chǎn)品的需求，并細致的考慮了方案的可行性， 從而減少與避免了撰寫文檔時容易忽略的細節(jié)黑洞。PRD文檔沒有標準的規(guī)范，也沒有統(tǒng)一的模板，每個公司都不一樣，并且每個人 也不一樣，這個取決于個人習慣和團隊要求。雖然 PRD文檔沒有標準的規(guī)范，但是有 兩項是必不可少的，那就是文件標識和修改記錄。文檔在撰寫過程中，我們可以自行 不斷的修改完善，但是如果正

21、式發(fā)布或交給團隊其他成員后，一旦有了修改，為了文 檔的同步，我們就需要標注出文檔的修改內容，備注修改記錄。關于文件標識和修改 記錄，大家的格式都大同小異（如下圖）。PRD文檔的形式常見的有以下三種：Word、圖片、交互原型一、Word這是傳統(tǒng)意義上的 PRD文檔，主要有四個部分組成（具體視你的產(chǎn)品要求進行劃分），分別是：結構圖、全局說明、頻道功能、效果圖。（在第一篇文章里我有講過,PRD文檔的閱讀者更多是偏向于技術人員， 因此PRD文檔目的性很明確，就是要描述產(chǎn)品的功能需求，所有PRD文檔是沒有關于市場方面的描述，同時我也建議大家盡量減少不必要的文字，在能夠讓閱讀者看懂并且了解產(chǎn)品意圖的情況下

22、，文字越少越好。這主要是因為絕大多數(shù)人是沒有足夠耐心認真看完 PRD文檔的，因此我們要盡量減化文檔內容。）1、結構圖：1.1、 信息結構圖：主要是輔助服務端技術人員創(chuàng)建或調整數(shù)據(jù)結構的參考文件1.2、 產(chǎn)品結構圖：主要是輔助設計和技術開發(fā)人員了解產(chǎn)品的全局結構，他和用戶流程圖不一樣，產(chǎn)品結構圖只是羅列出產(chǎn)品的頻道和頁面。2、全局說明：主要講解產(chǎn)品的全局性功能的說明，例如網(wǎng)站產(chǎn)品的頁面編碼、用戶角色，移動產(chǎn)品的緩存機制、下載機制，這類全局性功能的說明。這里我舉一個移動產(chǎn)品的“狀態(tài)維持與恢復”的例子，示例如下。狀態(tài)的維持與恢復當用戶退出產(chǎn)品時（誤操作、Home鍵、鎖屏、自動關機），產(chǎn)品需要維持用戶

23、操作前的狀態(tài)，當用戶返回產(chǎn)品時仍可以恢復到之前狀態(tài)，并繼續(xù)使用。維持狀態(tài)包括流程操作、信息瀏覽、文本輸入、文件下載。鎖屏狀態(tài)時，如果用戶在產(chǎn)品中有下載任務時，仍然保持下載。 一產(chǎn)品需求又檔小例：（見附件PDF）3、頻道功能：以頻道為單位，頁面為子項，分別描述產(chǎn)品的頻道、頁面及頁面模塊元素的功能需求（格式如下）。在撰寫功能需求時，我們需要考慮用戶的流程，例如一個“完成”按鈕，我們需要 描述他完成后，系統(tǒng)要不要給出反饋提示（反饋提示是什么樣的形式反饋，內容顯示成 什么，有沒有內容需要調取數(shù)據(jù)庫），或者要不要跳轉頁面（跳轉到哪個頁面，這個頁面 是其他頻道頁面，還是這個功能的子頁面，如果是子頁面就需要

24、再描述這個子頁面的 模塊及元素內容）。4、效果圖：效果圖是由設計師完成的產(chǎn)品圖，和實際開發(fā)完成的產(chǎn)品保真度一致。二、圖片圖片形式的PRD文檔是基于效果圖的說明文件， 將傳統(tǒng)Word形式的功能需求說 明標注在效果圖上，這種方式經(jīng)常使用在移動互聯(lián)網(wǎng)領域，實際上是圖文形式的交互 需求文件，只是在此基礎上更深入的描述出功能需求。對于圖片形式的PRD文檔，我們只需要另外再描述一下全局說明，其他頻道頁面的需求直接以圖片形式展示，這種方式相對于 Word文檔的純文字更加生動易讀并且 直觀，因此有一些產(chǎn)品經(jīng)理非常喜歡用這種方式代替Word形式的PRD文檔。三、交互原型這里指的交互原型就是上一篇文章講的原型設計

25、,使用AxurePR之類的交互原型設計軟件制作出來的產(chǎn)品原型非常真實和直觀，并且原型軟件還支持元素標注和導出 Word文檔，因此很多產(chǎn)品經(jīng)理都喜歡使用 AxurePR來代替Word完成PRD文檔。當我們通過AxurePR制作出產(chǎn)品原型后，實際上他已經(jīng)是很完善的產(chǎn)品 Demo 了, 因此我們只需要加上元素的標注，在標注中說明功能需求，這樣導出的 HTML文件相 比Word文檔更直觀易懂，是非常高效的產(chǎn)品需求說明方式。無論你采用哪種方式產(chǎn)出需求文檔，最終的目的都是為了方便團隊成員理解產(chǎn)品的意圖，因此哪種方法能夠避免細節(jié)黑洞，高效完成產(chǎn)品的設計和研發(fā)，那么這種方法就是最有效的方法。好了，關于產(chǎn)品需求

26、文檔（PRD）的寫作的介紹寫完了，一共四篇文章，希望能 夠幫助到你，如果覺得文章中有什么錯誤或者有疑問，歡迎評論留言。產(chǎn)品需求文檔的寫作（五）用例文檔（UML用例圖、流程圖）在產(chǎn)品和技術領域里都有 UML的技能知識，而對于產(chǎn)品人員的 UML則更多的是指用例圖，也就是我所稱呼的用戶流程圖。在講 PRD文檔寫作的第二篇文章里，我提 到了用戶流程圖的制作，實際上用戶流程圖是我在產(chǎn)品規(guī)則的初期對用例圖的一種結 構化的表達方式，由于以結構化的方式描述用例太抽象，缺少邏輯性表達，并且那篇 文章更偏向于功能性用戶流程，還不是實際意義上的用例，因此今天我補文一篇，細 講一下UML用例圖和用例文檔。用例文檔是由多個用例組成的一份文檔，主要用于技術開發(fā)與測試使用，他是PRD 中的重要輔助文檔，用于講解某個環(huán)節(jié)的功能邏輯，例如用戶注冊、活動報名等等功 能都是需要用例輔助說明的。用例文檔的寫作時間在原型設計之后，通常和 PRD文檔 同步撰寫。用例文檔中有兩個關聯(lián)文件，分別是用例圖和流程圖。用例圖是 UML的一種類圖 表現(xiàn)方式，是從用戶角度描述產(chǎn)品功能，并指出該用戶在產(chǎn)品各功能中的操作權限。流程圖是通過線框圖形的方式描述產(chǎn)品功能的處理過程，主要是描述功能的執(zhí)行順序、分支和循環(huán)的邏輯。寫用戶文檔的常用軟件是Word ,其中用例圖和流程圖的制作軟件常用的是 Vis