产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

26 评论 326981 浏览 851 收藏 7 分钟

在产品和技术领域里都有UML的技能知识,而对于产品人员的UML则更多的是指用例图,也就是我所称呼的用户流程图。在讲PRD文档写作的第二篇文章里,我提到了用户流程图的制作,实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式,由于以结构化的方式描述用例太抽象,缺少逻辑性表达,并且那篇文章更偏向于功能性用户流程,还不是实际意义上的用例,因此今天我补文一篇,细讲一下UML用例图和用例文档。

用例文档是由多个用例组成的一份文档,主要用于技术开发与测试使用,他是PRD中的重要辅助文档,用于讲解某个环节的功能逻辑,例如用户注册、活动报名等等功能都是需要用例辅助说明的。用例文档的写作时间在原型设计之后,通常和PRD文档同步撰写。

用例文档中有两个关联文件,分别是用例图和流程图。用例图是UML的一种类图表现方式,是从用户角度描述产品功能,并指出该用户在产品各功能中的操作权限。流程图是通过线框图形的方式描述产品功能的处理过程,主要是描述功能的执行顺序、分支和循环的逻辑。

写用户文档的常用软件是Word,其中用例图和流程图的制作软件常用的是Visio,当然也有用Axure RP软件制作的,例如下面的第三步流程图就是用Axure RP制作的。

一份完整的用例文档分别是由以下三点内容组成,其中第3点的“用例”是描述功能逻辑的部分,根据功能的多少决定有多少个用例。

用例文档的大概组成部分如下:
1、修改记录:每次修改的备注记录,同PRD文档。
2、角色介绍:描述参与系统中的各个角色
3、用例:同下方步骤的第4步,其中第3步中的流程图是直接插入到第4步的流程图表格项中的。

用例文档的模板格式如同以上三点内容,通过Word文档绘制表格,在表格中撰写用例描述,表格的格式和样式参考以下示例图。

1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。(如下图)

角色

2、第二步是以用例图的方式注明角色在前后端的用例关系。(如下图)

会员中心UML用例图

3、第三步是以流程图的方式注明角色在各个功能环节的活动过程。(如下图:以活动报名为示例)

流程图

4、第四步则是以用例文档的方式将以上三步整合到一起,并撰写各个功能环节的用例描述。(如下图)

流程图

表格说明:
4.1、用例名:此功能环节的名称
4.2、用例编号:在此产品中该用例的编号
4.3、行为角色:参与或操作(执行)该功能的角色
4.4、简要说明:用最少的文字描述一下该用例的需求
4.5、前置条件:参与或操作(执行)此功能的前提条件
4.6、后置条件:执行完毕后的结果条件
4.7、流程图:该功能的角色活动过程(处理过程)图(第三步中的图)

上面示范的用例描述相对简单,也是最常用和基本的用例描述内容,当然也有稍微复杂一点的用例文档,文档中会详细描述使用场景、事件流和信息字段,也有一些用例文档还会插入产品界面效果图。

使用场景主要描述行为角色在不同情况下使用产品时,根据情况或问题给出相应的系统反馈。事件流类似流程图,只不过是通过文字的方式描述角色的活动过程。信息字段主要是描述用例中所用到的数据字段。

这些更多的描述内容取决于个人的习惯,最终目的都是为了描述清晰产品逻辑,因此我的原则就是用越少的文字描述清晰越多的需求说明。(毕竟这些文档是产品开发中的执行文档,文字不在多,表达清晰即可。)

产品需求文档(PRD)的写作:
产品需求文档(PRD)的写作方法(文章的摘要介绍)
产品需求文档的写作(一) – 写前准备(信息结构图)
产品需求文档的写作(二) – 梳理需求(产品结构图和用户流程图)
产品需求文档的写作(三) – 原型设计(手绘原型,灰模原型,交互原型)
产品需求文档的写作(四) – 撰写文档(PRD文档)
产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

本文出自 产品经理 唐杰

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写的什么玩意啊,大哥,你学过软件工程么,知道什么是用例,什么是用例规约?

    来自广东 回复
    1. 没学过软件工程,但是从其他途径了解过,这门学科可以让软件的逻辑更加清晰

      来自四川 回复
    2. 我也觉得,这是用例??

      来自广东 回复
    3. USB?

      来自广东 回复
  2. 内容很棒哦,但是可以请专栏主吧文章来源放在更明显一些的位置(比如开头)么?放在结尾真的不太容易看到。

    来自湖北 回复
  3. 用例图用啥画好看

    来自北京 回复
  4. 看你写的东西感觉心都累,太啰嗦,不够简洁,当然了这是你几年前写的,能看出,你不是技术出身,像我这种技术出身、企划属种的人,马上准备入行,好好给产品经理这一岗位正正名。你们这样的人都有一个特点,就是描述事情特别细,但忽略了整理思路的逻辑,缺乏罗辑思维能力,让阅读者摸不清头脑,也许你们自己本身也没去太关注逻辑。不过,总的来说,内容上还是说的过去的。

    来自北京 回复
    1. 我的天,技术出身企划属种,满口你们这种人,是有多大的优越感。这五篇文章完全是从唐杰的博客搬运过来的,文章都看不懂戾气还这么重,就别入行来笑死人了

      来自上海 回复
    2. 我错了,对不起,是我有问题,我时刻反思。

      来自北京 回复
    3. 笑死人了,你们俩

      来自上海 回复
    4. 哈哈,优越感都要溢出屏幕了,我们公司的产品总监就是你们这种技术出身,企划属种的人,然而他设计的产品真的只在乎逻辑,凡事从开发角度考虑,做出来的产品,啧啧啧,一言难尽。

      来自广东 回复
    5. 已经截图并邮件至你产品总监邮箱 🙂

      来自中国 回复
    6. 笑了,凡事从思维逻辑出发,用户体验排哪了。软件开发出来是给普通人用的,他们是以程序猿的思维思考问题的么

      来自广东 回复
    7. 笑死,扯什么“凡事从逻辑出发”啊,层主哪里说了这个意思了?这不是需求文档嘛,要不要给开发看的啊,连基本的思维逻辑正确都做不到,这软件还怎么开发啊?你不是程序员嘛,不知道您什么职位的,遇事不决,用户体验排第一嘛,是啊,什么文档为什么做得跟屎一样都是为了用户体验嘛

      来自广东 回复
    8. 找个厂上班吧你,下饭

      来自广东 回复
  5. 不错,学习了

    来自四川 回复
  6. 非常感谢!

    来自上海 回复
    1. 如果我没有看错。。

      来自上海 回复
  7. 就问一个问题,画给谁看?

    来自上海 回复
    1. 开发和测试

      来自福建 回复
  8. 第三步中流程图画的 看起来有点儿不舒服,个人更喜欢用 圆角矩形 矩形 棱形 这三个基本元素画图,或者是泳道图。

    来自天津 回复
  9. 有话不说,憋着难受,非常感谢你的分享

    来自北京 回复
  10. 学习

    来自江苏 回复
  11. 不错,学习了。

    来自北京 回复
  12. 来自北京 回复
  13. 学习了!

    来自北京 回复