5.1 需求分类

需求分类的维度多种多样，一般有以下维度：实现层次、用户期望、提出人、执行情况、功能类型。

5.1.1 实现层次

从低到高依次是系统需求、用户需求和业务需求。

1. 系统需求：主要是从系统角度来说明软件需求，包括：功能需求（满足基本的业务需要）、非功能需求（质量属性）和设计约束（限制条件或其他补充说明）；
2. 用户需求：用户要求系统必须能完成的任务或功能（往往在基本需求之上添加的期望需求）；
3. 业务需求：客户对相同高层次的目标要求，通过业务需求可以确定项目范围和视图，往往来自于项目投资人（即战略需求，常常不为当前用户使用）。

5.1.2 用户期望

1. 常规需求：用户认为系统应该做到的功能或性能，实现越多用户越满意；
2. 期望需求：用户不能正确描述想要得到的功能需求，想当然认为系统应具备的功能或性能；
3. 意外需求：用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

5.1.3 提出人维度

1. 售前人员需求。
2. 客户人员需求。
3. 研发人员需求。
4. 测试人员需求。
5. 运维人员需求。
6. 其他按照业务角色划分的需求（领导需求、客户经理需求、值班组人员需求）等。

5.1.4 执行情况

1. 单体需求：一次开发，就可不再迭代的需求。
2. 迭代需求：有明确多次迭代实现计划的需求。
3. 不执行需求：不必开发的需求，多见于框架合同内，如：控标需求、占位需求等等。

5.1.5 构件复用情况

1. 完全复用：用已有的同类功能实现的需求。
2. 部分复用：用已有的类似功能修改实现的需求。
3. 个性定制：完全从零开始开发实现的需求。

5.1.6 测试发现

1. 缺陷：不满足原有需求的功能需求。
2. 优化：已满足原有需求，但被提出更高要求的功能需求。
3. 新需求：原有需求列表没有覆盖，或是约定的需求开发计划中不包含的功能需求。

5.1.7 数据类型

1. 基础数据需求；
2. 配置数据需求；
3. 业务数据需求；
4. 统计数据需求；
5. 中间件数据需求；
6. 主机和网络数据需求。

5.1.8 业务模块

1. 门户需求；
2. 云控制台需求；
3. 流程服务需求；
4. 自动化运维需求；
5. 监控告警需求；
6. 资源管理需求；
7. 智能算法需求；
8. 接口需求；
9. 安全保障需求。

5.2 管理目标

需求分类很多，目标也会根据不同维度去划分。作为现场人员，面对客户的时间是最多的，大部分需要现场人员去沟通处理的，也都是客户需求。所以，最值得我们关注的就是实现层次和用户期望这两个维度。

5.2.1 实现层次

5.2.1.1 系统需求：

这个需求来自于行业，行业会对某类产品有一定的标准，满足什么样的标准，则认为这个产品达到了什么样的级别，这些级别往往可以抽象成多个功能点和质量指标。在我们思特奇的环境下，可能要参考的是产品树构件和产品功能文档，来确认系统需求是否可以满足业务需要。

我们的目标是：项目全体人员必须执行、实现或满足的功能需求。

5.2.1.2 用户需求：

这些就是用户实际要用的功能，范围会比较大。但也基本会在满足当前客户实操或者是认知范围内的功能需求或性能需求。往往也是框架合同内，实际要实现的功能需求的主体内容。

我们的目标是：专注用户需求的挖掘，提升用户满意度。尽可能全力设计和研发，完成用户设定的目标。教育客户，明确其对产品的认知。引导客户，使其对产品有更高的依赖度。

5.2.1.3 业务需求：

战略目标的变动往往就是领导人的一念之间，乙方少有引导的余地。这些需求，可能仅仅是满足于某次参赛、某次评选或是某次重要的展示之后便有可能闲置，并没有很大的实操空间；又或者是以半成品的方式交付后，将来再继续开发。

我们的目标是：需求和运营分出一定的精力来跟进这部分需求，在减少研发工作量且不影响用户需求的情况下达成战略目标。必要的时候，让项目经理、售前和销售介入其中，与高层客户达成一致的实现目标。

5.2.2 用户期望

5.2.2.1 常规需求：

是控制在规划人员手中的，规划了什么产品，自然就要满足这个产品，在行业中已有共识的系统特性。如果当前产品不满足，就需要由技术负责人和产品负责人，尽快进行设计和研发，交付到现场以满足使用（参考系统需求）。这部分需求内容决定牌面的好坏，明确了项目的下限。

我们的目标是：项目全体人员必须执行、实现或满足的。

5.2.2.2 期望需求：

是控制在需求人员和运营人员手中的，客户的需求将会被他们翻译到研发和产品的耳朵里。这也是最好的，能在细节上引导客户的机会。优秀的期望需求管理，能够把一手烂牌打好；反之亦然。项目是否可以达到上限和下限，或者是达到程度都取决于此。

我们的目标是：需求、设计和运营人员必须识别、传达并全力争取的。

5.2.2.3 意外需求：

是控制在设计和研发人员手中的，研发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。类比成手牌也就是锦上添花，拉高上限，创造机会。

我们的目标是：需求、运营、设计和研发应当花一定时间去拓展的。