UML统一建模语言建立了一套采用图解需求的标准方法,用它来解析和呈现业务需求,就能事半功倍~接下来详细说下需求文档中用图说到的事儿。
先简单讲讲画流程图的需要知道的基本元素
由于大家对这个超市结账的流程都比较熟悉,可以脑补出以上步骤所对应的角色,但是面对千千万万的业务场景,可能用以上简单的步骤图就描述不出来了,接下来简单介绍可以用到的泳道图。
在描述流程中活动的时候,可以使用泳道来区分角色即“谁做的什么事情”。如图:
产品经理在了解业务的流程后,为了便于后续的产品设计工作,还需要关注业务中的数据关系,接下来简单讲下可以用到的实体关系图。
实体关系图,又称做ER图,用来描述实体间的数据关系。
以上ER图(只画了一部分实体关系,像账单等实体省略掉了)表示:
产品经理在需求分析时,还需要理清每个实体的属性,也就是对于一个实体【顾客】,它有哪些数据属性,比如顾客的手机号、性别、年龄、是否是VIP等等。B端产品经理经常会设计配置后台等产品,用户在配置后台进行创建、删除、编辑、搜索等操作就是对数据的CRUD(增删改查),理清了这些数据属性,我们可以试着从数据角度进行需求的探索,即对需求进行查漏补缺。
举个🌰-账单实体 :
数据流图可以呈现数据的扭转,用户在系统中的每一步操作可以说都存在数据的输入和输出,了解这些不仅能让产品经理自身更清楚产品的功能和范围,还能跟开发更好地沟通。完整的数据流图难度较大,一般不做要求,有兴趣的可以去了解 数据流图 。
概括性地描述这是一件什么样的事情以及要实现的目标,这可能是产品的名称也可能是项目的名称。
背景主要是说明为什么要做这个需求,通常是说明现状及现状带来的问题。
讲清楚做了这个需求后预计达到的目标或是收益,比如能赚多少钱、能节省多少人力等等
在这里可以把需求以列表的方式概括性展示出来,可以让团队成员大概知道这些需求包含哪些内容,便于后续评估工作量。
这里需要放上实体关系图,以及每个实体的属性,有助于理清业务概念,也可以帮助开发拿到需求后设计数据结构。
这里需要放上流程图和数据流图,用于描述业务流程和数据扭转。
这是文档的核心部分,在这个阶段描述需求时,建议不要描述界面相关的内容,避免增加文档的复杂性,以下是对一个需求/用例的描述。
除了功能性的需求,非功能需求是用户指对产品的期望,举例说明:
本文地址: http://www.goggeous.com/20241218/1/775979
文章来源:天狐定制
版权声明:除非特别标注,否则均为本站原创文章,转载时请以链接形式注明文章出处。
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2025-01-08职业培训
2024-12-18 19:27:13职业培训
2024-12-18 19:27:13职业培训
2024-12-18 19:27:12职业培训
2024-12-18 19:27:12职业培训
2024-12-18 19:27:11职业培训
2024-12-18 19:27:10职业培训
2024-12-18 19:27:10职业培训
2024-12-18 19:27:09职业培训
2024-12-18 19:27:08职业培训
2024-12-18 19:26:58职业培训
2024-11-25 16:20职业培训
2024-12-18 06:28职业培训
2025-01-01 22:37职业培训
2024-12-10 12:34职业培训
2024-12-13 20:34职业培训
2024-11-26 22:39职业培训
2025-01-06 06:00职业培训
2024-12-16 23:57职业培训
2025-01-01 18:00职业培训
2024-12-14 16:54职业培训
扫码二维码
获取最新动态