起點(diǎn)課堂會(huì)員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會(huì)特權(quán)
個(gè)人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場(chǎng)職場(chǎng)軟技能直播
12場(chǎng)求職輔導(dǎo)直播
12場(chǎng)專業(yè)技能直播
會(huì)員專屬社群
榮耀標(biāo)識(shí)產(chǎn)品需求文檔的寫作(五) – 用例文檔(UML用例圖、流程圖)
在產(chǎn)品和技術(shù)領(lǐng)域里都有UML的技能知識(shí)，而對(duì)于產(chǎn)品人員的UML則更多的是指用例圖，也就是我所稱呼的用戶流程圖。在講PRD文檔寫作的第二篇文章里，我提到了用戶流程圖的制作，實(shí)際上用戶流程圖是我在產(chǎn)品規(guī)則的初期對(duì)用例圖的一種結(jié)構(gòu)化的表達(dá)方式，由于以結(jié)構(gòu)化的方式描述用例太抽象，缺少邏輯性表達(dá)，并且那篇文章更偏向于功能性用戶流程，還不是實(shí)際意義上的用例，因此今天我補(bǔ)文一篇，細(xì)講一下UML用例圖和用例文檔。 用例文檔是由多個(gè)用例組成的一份文檔，主要用于技術(shù)開(kāi)發(fā)與測(cè)試使用，他是PRD中的重要輔助文檔，用于講解某個(gè)環(huán)節(jié)的功能邏輯，例如用戶注冊(cè)、活動(dòng)報(bào)名等等功能都是需要用例輔助說(shuō)明的。用例文檔的寫作時(shí)間在原型設(shè)計(jì)之后，通常和PRD文檔同步撰寫。 用例文檔中有兩個(gè)關(guān)聯(lián)文件，分別是用例圖和流程圖。用例圖是UML的一種類圖表現(xiàn)方式，是從用戶角度描述產(chǎn)品功能，并指出該用戶在產(chǎn)品各功能中的操作權(quán)限。流程圖是通過(guò)線框圖形的方式描述產(chǎn)品功能的處理過(guò)程，主要是描述功能的執(zhí)行順序、分支和循環(huán)的邏輯。 寫用戶文檔的常用軟件是Word，其中用例圖和流程圖的制作軟件常用的是Visio，當(dāng)然也有用Axure RP軟件制作的，例如下面的第三步流程圖就是用Axure RP制作的。 一份完整的用例文檔分別是由以下三點(diǎn)內(nèi)容組成，其中第3點(diǎn)的“用例”是描述功能邏輯的部分，根據(jù)功能的多少?zèng)Q定有多少個(gè)用例。 用例文檔的大概組成部分如下： 用例文檔的模板格式如同以上三點(diǎn)內(nèi)容，通過(guò)Word文檔繪制表格，在表格中撰寫用例描述，表格的格式和樣式參考以下示例圖。 1、撰寫用例文檔的第一步是注明使用產(chǎn)品的各個(gè)角色(參與者)和角色說(shuō)明(角色介紹)。（如下圖） 2、第二步是以用例圖的方式注明角色在前后端的用例關(guān)系。（如下圖） 3、第三步是以流程圖的方式注明角色在各個(gè)功能環(huán)節(jié)的活動(dòng)過(guò)程。（如下圖：以活動(dòng)報(bào)名為示例） 4、第四步則是以用例文檔的方式將以上三步整合到一起，并撰寫各個(gè)功能環(huán)節(jié)的用例描述。（如下圖） 表格說(shuō)明： 上面示范的用例描述相對(duì)簡(jiǎn)單，也是最常用和基本的用例描述內(nèi)容，當(dāng)然也有稍微復(fù)雜一點(diǎn)的用例文檔，文檔中會(huì)詳細(xì)描述使用場(chǎng)景、事件流和信息字段，也有一些用例文檔還會(huì)插入產(chǎn)品界面效果圖。 使用場(chǎng)景主要描述行為角色在不同情況下使用產(chǎn)品時(shí)，根據(jù)情況或問(wèn)題給出相應(yīng)的系統(tǒng)反饋。事件流類似流程圖，只不過(guò)是通過(guò)文字的方式描述角色的活動(dòng)過(guò)程。信息字段主要是描述用例中所用到的數(shù)據(jù)字段。 這些更多的描述內(nèi)容取決于個(gè)人的習(xí)慣，最終目的都是為了描述清晰產(chǎn)品邏輯，因此我的原則就是用越少的文字描述清晰越多的需求說(shuō)明。（畢竟這些文檔是產(chǎn)品開(kāi)發(fā)中的執(zhí)行文檔，文字不在多，表達(dá)清晰即可。） 產(chǎn)品需求文檔(PRD)的寫作：
1、修改記錄：每次修改的備注記錄，同PRD文檔。
2、角色介紹：描述參與系統(tǒng)中的各個(gè)角色
3、用例：同下方步驟的第4步，其中第3步中的流程圖是直接插入到第4步的流程圖表格項(xiàng)中的。
4.1、用例名：此功能環(huán)節(jié)的名稱
4.2、用例編號(hào)：在此產(chǎn)品中該用例的編號(hào)
4.3、行為角色：參與或操作(執(zhí)行)該功能的角色
4.4、簡(jiǎn)要說(shuō)明：用最少的文字描述一下該用例的需求
4.5、前置條件：參與或操作(執(zhí)行)此功能的前提條件
4.6、后置條件：執(zhí)行完畢后的結(jié)果條件
4.7、流程圖：該功能的角色活動(dòng)過(guò)程(處理過(guò)程)圖（第三步中的圖）
產(chǎn)品需求文檔(PRD)的寫作方法（文章的摘要介紹）
產(chǎn)品需求文檔的寫作(一) – 寫前準(zhǔn)備(信息結(jié)構(gòu)圖)
產(chǎn)品需求文檔的寫作(二) – 梳理需求(產(chǎn)品結(jié)構(gòu)圖和用戶流程圖)
產(chǎn)品需求文檔的寫作(三) – 原型設(shè)計(jì)(手繪原型,灰模原型,交互原型)
產(chǎn)品需求文檔的寫作(四) – 撰寫文檔(PRD文檔)
產(chǎn)品需求文檔的寫作(五) – 用例文檔(UML用例圖、流程圖)
本文出自 產(chǎn)品經(jīng)理 唐杰
寫的什么玩意啊，大哥，你學(xué)過(guò)軟件工程么，知道什么是用例，什么是用例規(guī)約？
沒(méi)學(xué)過(guò)軟件工程，但是從其他途徑了解過(guò)，這門學(xué)科可以讓軟件的邏輯更加清晰
我也覺(jué)得，這是用例？？
USB?
內(nèi)容很棒哦，但是可以請(qǐng)專欄主吧文章來(lái)源放在更明顯一些的位置（比如開(kāi)頭）么？放在結(jié)尾真的不太容易看到。
用例圖用啥畫好看
看你寫的東西感覺(jué)心都累，太啰嗦，不夠簡(jiǎn)潔，當(dāng)然了這是你幾年前寫的，能看出，你不是技術(shù)出身，像我這種技術(shù)出身、企劃屬種的人，馬上準(zhǔn)備入行，好好給產(chǎn)品經(jīng)理這一崗位正正名。你們這樣的人都有一個(gè)特點(diǎn)，就是描述事情特別細(xì)，但忽略了整理思路的邏輯，缺乏羅輯思維能力，讓閱讀者摸不清頭腦，也許你們自己本身也沒(méi)去太關(guān)注邏輯。不過(guò)，總的來(lái)說(shuō)，內(nèi)容上還是說(shuō)的過(guò)去的。
我的天，技術(shù)出身企劃屬種，滿口你們這種人，是有多大的優(yōu)越感。這五篇文章完全是從唐杰的博客搬運(yùn)過(guò)來(lái)的，文章都看不懂戾氣還這么重，就別入行來(lái)笑死人了
我錯(cuò)了，對(duì)不起，是我有問(wèn)題，我時(shí)刻反思。
笑死人了，你們倆
哈哈，優(yōu)越感都要溢出屏幕了，我們公司的產(chǎn)品總監(jiān)就是你們這種技術(shù)出身，企劃屬種的人，然而他設(shè)計(jì)的產(chǎn)品真的只在乎邏輯，凡事從開(kāi)發(fā)角度考慮，做出來(lái)的產(chǎn)品，嘖嘖嘖，一言難盡。
已經(jīng)截圖并郵件至你產(chǎn)品總監(jiān)郵箱 ??
笑了，凡事從思維邏輯出發(fā)，用戶體驗(yàn)排哪了。軟件開(kāi)發(fā)出來(lái)是給普通人用的，他們是以程序猿的思維思考問(wèn)題的么
笑死，扯什么“凡事從邏輯出發(fā)”啊，層主哪里說(shuō)了這個(gè)意思了？這不是需求文檔嘛，要不要給開(kāi)發(fā)看的啊，連基本的思維邏輯正確都做不到，這軟件還怎么開(kāi)發(fā)??？你不是程序員嘛，不知道您什么職位的，遇事不決，用戶體驗(yàn)排第一嘛，是啊，什么文檔為什么做得跟屎一樣都是為了用戶體驗(yàn)嘛
找個(gè)廠上班吧你，下飯
不錯(cuò)，學(xué)習(xí)了
非常感謝！
如果我沒(méi)有看錯(cuò)。。
就問(wèn)一個(gè)問(wèn)題，畫給誰(shuí)看？
開(kāi)發(fā)和測(cè)試
第三步中流程圖畫的 看起來(lái)有點(diǎn)兒不舒服，個(gè)人更喜歡用 圓角矩形 矩形 棱形 這三個(gè)基本元素畫圖，或者是泳道圖。
有話不說(shuō)，憋著難受，非常感謝你的分享
學(xué)習(xí)
不錯(cuò)，學(xué)習(xí)了。
贊
學(xué)習(xí)了！