在互联网市场日益激烈并相对成熟的今天，需求分析的作用也日益凸显。中培课堂《需求分析与管理最佳实践》培训专家刘老师指出，需求分析是通过需求收集获取的用户需求，选择一种业务导向的线索将零散的需求串联起来，进行业务分析、消除矛盾，并在业务分析基础上结合系统现状进行系统分析并最终形成方案和系统需求说明书的过程。

需求分析总体分为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. 功能/接口关联影响分析：实现某个业务活动需要新增或改造的功能对其它关联功能/接口的影响分析。

3. 系统交互原型分析：需求人员应遵循界面规范并与研发沟通确定系统交互原型，用户原型的目的是为了帮助研发或用户更好的理解需求场景而非真正系统实现后高保真原型。

　　六、数据割接分析

很多功能/流程改造都会涉及数据割接，需求人员应在需求分析阶段明确割接规则并与研发沟通明确割接方案

七、用户体验分析

主要针对业务流程分析、用户使用场景分析、系统交互原型分析时充分考虑用户体验

八、非功能需求分析

包含需求的可行性分析、健壮性分析、可扩展性分析、执行效率分析等四个组成部分。