[需求管理-4]：需求分析全过程：需求分析+资源评估+项目计划

前言：

需求收集后，需要经过漫长的需求分析和所需要评估过程，才能正式在某个软件版本中实现需求。

在软件开发人员通过编程实现需求前，中间经过了多种角色的辛苦劳动，最终才会生成需要规格说明书，需求规格说明书是逐步由粗到细的分解过程。一个需求，要进入项目计划中，除了范围管理的需要，进行技术分析和细化，还需要时间管理和人力资源管理，即需要多少人，多长时间才能实现这些需求，因此，还需要进行人力资源“人月”的评估。

除了软件故障的解决，几乎所有的软件开发和代码改动活动，都是基于“需求”进行的。

第1章需求分析全过程

1.1 需求收集

在前文我们已经探讨了需求收集的过程和防范。

1.2 需要分析与评估

（1）潜在商业价值报告FS0 -- 产品经理或需求经理

该阶段的目的是：识别、请求、建议需要列表，并在投入更多精力之前，筛选掉业务潜力低的功能。

（2）技术可行性报告FS1

FS1阶段，有三个主要的任务：

技术的可行性

技术可行性分析阶段一个重要的任务就是判断技术的可行性。并非所有的需求都需要进行可行性分析，对于简单的用户需要，很容易判断技术方案是否可行，可以不需要进行技术可行性分析。

是否需要进行FS1，是由FS0阶段决定的。

对系统中组件/模块的影响面

技术可行性分析阶段，另一个重要的任务，就是确定该客户的需要影响面有多大，影响多少个系统的模块。

如果是一个单一的功能需要，影响面很明显，也可以不用进行可行性分析。

所需人力资源的初步评估，即

（3）所需人力资源的初步评估E1： FS1

（4）系统需求范围的明确

（5）系统需求规范（业务场景+功能性需求+非功能性需求+约束条件）

（6）所需人力资源的进一步评估E2

（7）初始需求列表（产品经理建议的需求类别）

（8）最终需求列表（开发团队根据人力资源的现状，承诺实现的需求列表）

（9）项目计划基线（范围基线+时间基线+人力资源基线。。。。。）

1.3 需求实现

（1）组件的软件设计

（2）组件的编码

（3）组件的单元测试

1.4 需求验证

（1）组件的集成测试

（2）系统测试

第2章需要分析与需求规范

2.1 需要分析与状态

2.2 需要规范撰写的阶段划分

（1）CP1：确定需要范围和需求的切分， XXX-A, XXX-B, XXX-C.............

（2）CP2：对每个切分的子需求XXX-Y，明确功能

业务场景
功能性需求
非功能性需求
约束条件
与其他需求的依赖关系
与其他需求的交互关系
OAM参数：配置参数、告警、计数、状态等

（3）CP3：技术组件/模块/领域间需要

组件与组件的接口
组件与组件之间的业务场景
组件的功性能需要
组件的非功能性需要
组件的约束条件
..................

第3章需求与项目管理

3.1 需要管理与项目管理、软件开发流程的关系

3.2 需求管理与项目范围管理的异同

https://blog.csdn.net/HiWangWenBing/article/details/126827269

3.3 用Jira需要分析相关的项目工作/任务