需求分析-以企业流程类软件为例,聊聊需求分析的9个步骤

以企业流程类软件为例，聊聊需求分析的
9个步骤
本文侧重企业流程类软件需求，其它类产品可参考，总体分为8
个步骤，按照顺序依次为：需求识别、业务流程/统计查询/接口分析、数据实体分析、角色及用到场景分析、系统功能分析、数据割接分析、用户体验分析、非功能需求分析。

需求分析是通过需求收集获取的用户需求，选择一种业务导向的
线索将零散的需求串联起来，进行业务分析、消除矛盾，并在业务分
析方案基础上结合控制系统现状进行系统分析并最终形成方案和系统
消费需求说明书的过程。

需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用
来确定需求实施的优先级。

1.需求类别确认：
需求类别包含流程一类需求、统计分析类需求、接口类需求，一
个需求可能为某一类型需求，也可能将包含多类需求。

确认需求类别后应对每类需求的数量进行初步分析（比如流程类
需求包含三四个流程、统计分析类需求包含几个报表、接口类需求包
含几个接口）。

2.需求复杂度分析：
一般需求受理工作量在1-5人天的融资需求复杂度低，工作量在
5-15人天的需求复杂度中所，工作量在15人天以上需求复杂度高。

（工作量表示需求受理全过程需求人员付出的工作量）。

3.价值分析：
需求人员收到需求后应根据收集需求内容初步分析需求痛点/目标、需求复杂度、业务重要程度确定资金需求价值，剖析能源需求价值分
析可参考如下模型：
针对流程类必须进行业务流程分析，统计查询进行和接口类需求
量可不进行详细的流程分析。

1.业务流程分为部门级、组织级和岗位级
2.需求识别阶段确认的调整期流程均为部门级流程
需求人员在进行流程应遵循如下方法：
（1）业务流程确认：
一个流程为一个业务事件，一般是内外部角色发起或系统内部主
动发起（比如时间事件或状态事件），发起后才积极展开会触发一系
列业务活动。

（2）角色及业务发展活动确认：
流程图中的每个同一个泳道都必须对应到角色，每个角色对应多
个业务活动。

需求人员在确认业务活动时一定要保证活动的粒度，一
个业务活动一定是由一个角色完成且每个业务活动都是有价值的活动。

比如项目输入项目名称是一个执行步骤，这个动作没有价值，项
目经理查询项目信息就是一个业务活动。

在需求描述时针对线下活动之前或新增活动应该应标识区分。

（3）业务活动间关系及数据确认：
确定所有业务活动的前后置关系，并明确操作流程间的传递的数
据实体。

（4）流程整体瓶颈分析：
一般若某个角色工作难度业务活动工作量较大，或流程涉及高级领导，一般都会造成瓶颈，这种情况需求值班人员应想办法分散工作量提出操作流程流程优化建议。

3.融资需求针对统计查询两大类需求及接口类需求，按照上述业务活动确定原则分析、确定角色，并明确每个角色所执行的业务活动即可。

针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件和查询展现数据实体、接口类需求需要分析接口传递数据实体，具体分析包含如下内容：
1.明确数据实体：
确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。

2.明确所有资料实体间关系：
实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它图表实体。

3.明确数据实体控件：
针对新增数据或改造数据实体需要明确新增字段的本体名称、字段类型、是否必填、字段取值方式（人工输入、系统内自动继承自其它数据实体、换算系统自动计算需要明确计算公式）。

4.数据权限分析：
需要分析不同角色在数据权限方面的差异，若牵涉到纵向多级用户，要说明对于集团/省/地市是用户的数据隔离。

活动一般来说每个业务公益活动是对用户使用场景的抽象，每个管理业务活动可能包含多个即便场景，分析进行使用场景时应按照投
资业务活动为主线逐个进行分析，每个业务活动建模时应包含如下内容：
1.明确活动执行角色。

2.明确活动执行的前置条件和后置条件。

3.明确不同场景：
一个业务包括活动可能包含正常的使用场景、备选使用场景和异常使用场景；
4.明确每个场景的执行步骤：
描述执行步骤时应使用简单的语法，主语恰当语义易于理解，每个步骤不应当在不能任何一方（执行角色、系统）停留两部以上，重点描述如何交互。

5.业务规则和约束：
明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则（比如项目周期时长超过90天必须提交二级领导审批程序），或与数据实体相关机构的数据规则（需求交接单拒收时候必须填写市场需求拒收原因，且拒收原因不能超过500字）。

系统功能分析是结合系统现状和上述分析上述情况进一步明确实现相应用户场景的系统功能，典型还包含内容如下：
1.功能列表：
分析得出实现上述业务活动对应的功能/接口列表，并明确新增功能、改造功能；
2.功能/连接器关联影响分析：
实现某个业务活动需新加新增或改造的功能对其它关联功能/接口的影响分析。

比如改造请购池受理功能，可能会影响采购项目创建功
能；采购项目创建功能修改一个字段取值范围，会影响项目统计分析
和同步ES系统接口。

3.系统交互原型分析：
需求人员应遵循界面规范，并互动与研发沟通确定系统交互原型。

用户原型的目的，是阐释为了帮助研发或用户更好的理解需求场景，
而非真正系统实现后高保真原型。

在交互原型中应包含如下内容：
4.算法分析：
在系统功能交互涉及比较复杂的算法，需要单独对算法进行分析。

很多功能/流程改造都会涉及数据割接，需求人员应在需求分析阶
段明确割接规则并与研发沟通明确割接配套措施，常见的割接场景如下：
1.流程环节变更（比如取消审批手续流程）。

2.数据实体新增字段。

主要针对业务流程分析、用户换用场景分析、用户系统交互原型
判断时充分考虑用户体验，进行用户体验分析时可遵循如下用户体验
要素模型：
1.战略层：
这个层次在需求识别分析阶段基本已完成。

2.范围层：
主要针对业务流程分析阶段、角色及使用场景分析阶段及减少系
统功能分析阶段增加用户体验分析，比如流程环节是否存在瓶颈环节、
整体流程使用效率是否高、使用情境的执行步骤是否是否繁杂、制定
的业务规则是否会增加工作量或导致难以实施等。

3.结构层：
主要针对系统原型交互设计用户体验分析，交互设计纲领如下：
4.框架层：
主要针对系统原型界面设计增加用户体验的分析，主要就由界面
规范和系统技术架构决定。

5.视觉层：
主要由界面规范逼不得已。

包含消费的可行性分析、健壮性分析、可扩展性分析、执行效率
分析，可行性下表分析从以下几个方面成功进行：
1.技术可行性：针对数据割接时间表、系统交互实现方式与研发
确认是否可行，需求人员研发与在沟通过程中所需要不断积累哪些功
能实现在技术层面很难支撑；
2.时间可行性：根据用户的上线时间要求分析是否可满足要求；
3.合法合规可行性：分析需求是否满足国家法规或公司法规要求；
4.数据安全性分析：用户需求是否满足信息系统安全要求。