需求分析所需要了解的常见问题

1.需求的基础问题

        1.需求定义（IEEE）：
（1）用户为了解决问题或达到某些目标所需要的条件或能力。
（2）系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的的要求而需要具备的条件或能力。
（3）对（1）或（2）中的条件或能力的一种文档化表述。

        2.问题域：要解决问题，就需要改变现实中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。
这些实体和状态构成了问题解决的基本范围，称为该问题的问题域。

        3. 解系统：软件系统通过影响问题域，能够帮助人们解决问题，称为解系统

        4,。共享现象：软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。 问题域中的某些信息能够和模型中的信息建立映射关系，这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象。

        5.需求规格说明：解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。

        6.约束：问题域中有些特性完全不受共享现象（解系统）的影响，同时却可能很大程度上影响共享现象、解系统，甚至关乎解系统的成败。这些特性被认为是解系统对环境的依赖特性。特性非常明确时，称为约束；特性不明确时，称为假设。

2 需求获取问题

2.1 需求来源

干系人

干系人（Stake holder）：对于系统有利益关系的个人，团队、组织和其他系统。

项目干系人包括但不限于：

投资方：系统的投资方

主管方：批准/管理系统的

最终用户：用户/系统受益方

操作方：操作/维护系统的

监管方：认证系统的

测试方：负责系统验收

2.2 需求分类

实际上需求要分好几个种类，针对不同角色，就有不同角色的需求，比如软件项目中常定义的业务解决方案和技术解决方案。我们把需求进一步细化分类，可以发现这些分类可以大致概况为以下几类：

1、业务需求 ：这个也许是项目的最原始，最高级的需要。项目中大部分的操作或过程都要围绕解决业务需求而展开

2、干系人需求：干系人或干系人群体的需要，这个可能不会影响大的业务需求方向，但是一种业务需求的补充，要重视干系人的需求。

3、解决方案需求：一般我会叫它为“系统需求”或“技术需求”。它是为了满足业务需求和干系人需求，我们提供的产品、服务或成果必须具备的 特性、功能和特征。同时解决方案可以分解为功能需求和非功能需求：

3.1、功能需求是关于产品能开展的行为。比如流程，数据，以及与产品的互动。

3.2、非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量。比如安全性、性能、可扩张性、服务水平等

4、过渡需求：从“当前状态”过渡到“将来状态”所需的临时能力，如数据收集转换和培训需求等

5、项目需求：项目需要满足的行动、过程或其他条件

6、质量需求：用以确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准

3 需求要素

3.1 角色、场景

一般来说每个业务活动是对用户使用场景的抽象（例如电商购物活动），每个业务活动可能包含多个场景（例如商品浏览、购物车、下单、支付），分析使用场景时应按照业务活动为主线逐个进行分析，每个业务活动分析时应包含如下内容：

1.明确活动执行角色

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

3.明确不同场景：

一个业务活动可能包含正常的使用场景、备选使用场景和异常使用场景

4.明确每个场景的执行步骤

5.业务规则和约束：

明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则，或与数据实体相关的数据规则（比如某个字段的长度）

3.2 数据实体

针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件数据实体和展现数据实体，接口类需求需要分析接口传递数据实体，具体分析包含如下内容：

1.明确数据实体

确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。

2.明确所有数据实体间关系

实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它数据实体。

3.明确数据实体字段

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

4.数据权限分析

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

3.3 功能性需求

系统功能分析是结合系统现状和上述分析进一步明确实现相应用户场景的系统功能，主要还包含内容如下：

1.功能列表

分析得出实现上述业务活动对应的功能/接口列表，并明确新增功能、改造功能；

2.功能/接口关联影响分析

实现某个业务活动需要新增或改造的功能对其它关联功能/接口的影响分析。比如改造请购池受理功能，可能会影响采购项目创建功能；采购项目创建功能修改一个字段取值范围，会影响项目统计分析和同步ES系统接口。

3.系统交互原型分析

需求人员应遵循界面规范，并与研发沟通确定系统交互原型，帮助研发或用户更好的理解需求场景。

在交互原型中应包含如下内容：

原型界面的名称、入口，原型间关联关系和使用角色

页面内容、格式及排序方法

操作要点：比如交互的信息提示、界面规则和约束（比如界面以不同颜色显示不同的校验结果）。

4.算法分析：

在系统功能交互时涉及比较复杂的算法，需要单独对算法进行分析。

3.4 非功能性需求

包含需求的可行性分析、健壮性分析、可扩展性分析、执行效率分析，可行性分析从以下几个方面进行：

1.技术可行性 系统交互实现方式与研发确认是否可行，需求人员在与研发沟通过程中需要不断积累哪些功能实现在技术层面很难支撑。

2.时间可行性 根据用户的上线时间要求分析是否可满足要求。

3.合法合规可行性 分析用户需求是否满足国家法规或公司法规要求。

4.数据安全性分析 用户需求是否满足信息系统安全要求。