一份全面的用例描述是怎样的?

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

用例描述反映了系统分析员对用户需求的理解,要达到能够完全理解用户需求的目标以及实现系统良好运转的期许,例图和文字描述相结合才是最完整的用例描述。

一、描述

很多人在做用例描述的时候只注重于用例图的绘制,有的则只注重于文字的描述,这两者单单重其一都是有所欠缺的。

这样说吧,图形(比如用例图或者流程图)其实是文字说明的一种补充方式,它的直观性虽然可以,但是说明性确实不足,因此必须让那些图形能够表达其内心世界的想法,讲述图形背后的故事。通过文字描述程序的运行流程,描述参与者与系统的交互过程等。

单单只用文字描述也是片面的,文字描述尽管可以更为详细的说明一些问题,但是它的缺点就是没有所谓的直观性,相对复杂的用例会通过时间流图来补充,为架构师提供更加形象和直观的用例描述。

根据以上说法,用例图和文字描述相结合才是完整的用例描述,或者将其叫做能够形成一种多元化多角度多层面融合的需求分析方阵(比如:用例矩阵),用例矩阵的形成也许会更加能够表现出需求的直观性。

二、案例

2.1 项目筹划功能模块

2.1.1 模块描述

主要分为四个专题页,分别为:项目信息、项目初始化、计划管理和计划纠偏。

1)项目信息:主要展示的是项目相关的合同信息内容,项目经理在这里可以根据其内具体的信息进行相关的编辑和完善。

2)项目初始化:为项目经理提供标准化的WBS字典,通过形象进度项关联工程量清单,实现进度货币化管理,并及时提供全面的进度分析以及资源分析。

3)计划管理:主要分为进度计划、产值计划、成本计划、资金计划、施工风险计划、安全计划、质量计划、人员计划、材料计划、设备计划、供应商计划十一个计划,以项目初始化中的wbs字典数据为基础来进行所有计划(某些计划为必填)的信息录入和提交,通过流程审批从而激活整个项目。

进度货币化:进度货币化包括WBS工区分部分项树结构管理、分项部件管理、业主清单管理三个模块,WBS工区分部分项树结构关联业主清单实现进度计划编辑、实物量统计、对上计价对下计量自行关联,失效件进度产值货币化管理,帮助项目经理准确切形象的管控项目进度,提升工作效率和质量。

4)计划纠偏:分为资源平衡(与关键路径有关)和资源平滑(与关键路径无关)两种纠偏方式。根据时间和资源两种维度来进行项目跟踪的同时,并及时进行进度提醒及进度纠偏处理,从而帮助项目经理进行项目进度的把控。

2.1.2 需求分析

2.1.3 用例矩阵

2.1.4 界面描述

三、结语

用例矩阵反映了系统分析员对用户需求的理解,必须能够完全理解客户需求和对系统运行的期许。

通过一种图形结合文字描述的手法,是让客户在大脑中形成一个系统的运行蓝图,让客户能够明白在将来的系统中扮演的角色以及在这个角色中要承担的责任,和客户将通过哪些行为动作来完成自己的工作,并结合高保真原型(UE、UI)设计来更加立体的呈现所要印证的需求。

 

本文由 @卧枕江山 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 在这里能碰到河大的同学,幸会幸会,我虽然不是河大的,但是我家是开封的。跟作者探讨一个问题,两个方面吧,其实本质是一样的:一就是我看作者在回复里面说了,需求文档有100多页,我最近刚好在研究这个问题,PRD文档到底细致到什么程度合适?第二个问题就是作者的文章的用例,我想知道我们作为产品,编写用例是让谁看的?我之前咨询过这个问题,有的小伙伴告诉我,主要是测试用例,因为测试人员没有时间也没有耐心去了解整个PRD文档的功能逻辑,所以测试用例是方便他们进行测试。我最近研究用例的时候,用例的意图可以这样描述: 产品人员的用例主要是为了方便技术研发和功能测试时,让参与者更好地理解功能的逻辑,是从用户的角度描述产品功能,并指出该用户在产品功能中的操作权限。不知道作者对于我的观点有什么看法 ;-)

    回复
    1. 1.PRD文档细致程度要看所做产品深挖到什么程度,这个文档不想概要设计文档那样只是对面上的东西进行描述,应该越细致越好,不好还要有一个度,不然的话也是一种负担,一般能将大致的功能点描述清楚,并给与清晰的产品设计就已经足够。
      2.至于用例方面,这里确实要分测试用例和用户角度的用例,不过既然是给研发人员观看,那么最好两者都要兼得才行,这样研发人员在进行研发的时候既可以用用户的角度来进行功能点的研发,又可以按照测试用例的角度来对研发而出的功能点进行第一次测试(相当于漏补阶段,也是非常有用处的)。

      回复
  2. 说明性打成睡明星???

    回复
    1. :lol: 南面会出现一些错别字,见谅哈!

      回复
  3. 请路过的朋友们多多支持哈,笔者在这里先谢谢了,以后会有更多优质的文章在这个平台上进行发布,请尽请期待呦!

    回复
    1. 写太短了,完整的得有4~5的篇幅,想看写完的

      回复
    2. 只是从我的需求规格说明书(全篇有100多页)中摘选出来的,作为案例进行描述的,景工学习沟通和参考。

      回复