企业系统需求分析(04):业务场景识别与分析

0 评论 7979 浏览 55 收藏 5 分钟

做一款产品前,我们事先要做的就是明确需求与对应场景。对一款企业系统来说,关注点也是如此。

继上一篇业务流程识别与分析篇后,本文主要分享业务场景识别与分析相关知识点。

一、识别业务场景

首先是要理解用例和用户故事的本质,它要求我们不是去关注系统提供什么功能,而是用户在什么场景下需要系统提供支持!

1. 用例的关键知识认知

  1. 用例名称要基于用户场景去设定,使用业务语言去描述,而不是机械式的使用“增删改查”
  2. 在业务场景中的用例粒度是由组织分工决定的,特征是独立、可汇报、可暂停的单元(一般不会是太细化的动作)
  3. 2人/周的工作量分拆成更小的故事,另外大故事要保留的原因是方便组织小故事,不忘初心。

2. 基于流程图识别参与系统的角色。

  1. 对这个流程提供支撑需要有哪些角色?
  2. 非必需的角色纳入系统支持中有什么价值?不纳入的话有什么影响?(在优先级排序时有指导作用)
  3. 一般执行层的角色会用岗位名称命名
  4. 在权限系统中要如何抽象各个角色

3. 基于流程图识别业务场景

我们要思考在流程过程中,哪些业务活动要系统支持,哪些是部分支持,审批点是否属于系统内,判断点是否为独立环节。

(下图是一套体检系统的流程图,假如工程排期优先内部作业电子化,故体检者一栏暂时不纳入电子系统。红圈则是现要开发的系统所支持的任务活动)

4. 补充业务场景

常见如由时间、状态而触发的业务场景,如信用卡到期还款以及长期逾期状态导致信用卡冻结的场景。

5. 绘制用例图

注意常见三个关系_包含、扩展、泛化。

  • 包含关系——公共子事件流(不需给用户看),如检查座位信息。
  • 扩展关系——不一定执行的扩展事件流(需给用户看),如处理等候队列。
  • 泛化关系——公共事件流,如办理结账。

二、六步分析业务场景

1. 概述业务场景(包括业务目的、前后置条件等)

2. 把场景细化成事件流,整理去用户预期的步骤,并思考扩展和异常事件流。

注意两点:

  • 用例描述重在人机交互和意图,不需要过多些人机界面和动作
  • 结构化语言描述,少用“如果..就”的表达方式了;扩展或备选事件流单独列出来分支,降低理解成本。

3. 针对每一个步骤,思考并罗列用户可能遇到的问题

4. 针对问题思考解决方案

5. 考虑环境与业务特点带来的影响或要求,主要是性能、易用性、部署环境等三方面

6. 开始初步的交互设计

 

本文由 @PM达云霄 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!