在需求管理中，我们总会遇到各种各样的问题。比如：①需求的隐含错误；②客户不断增加需求、变更需求；③……。往往这些需求就是导致我们项目失败的根本原因。‘

那接下来，我们先用一张图来对项目失败的原因进行分析。具体如下图：

基于以上的原因分析，自然地，我们也就知道了软件需求在软件项目管理中不可撼动的地位。

那么在接下来的文章中，就来了解下软件需求各方面的内容。

叮，开始学习吧~👏

指用户对 软件功能和性能 的要求。（用户希望软件能做什么事情，完成什么样的功能，达到什么样的性能）

软件需求的层次有以下三个方面的内容：

业务需求→用户需求→功能需求

软件需求管理过程包含两个方面的内容，分别是需求开发和需求管理。

需求开发的路径是：需求获取→需求分析→需求规格编写→需求验证；而需求管理指的是：需求变更。

下面我们将对以上这几个概念进行一一解析。

首先我们要先分析用户的要求，分析完成之后，那么我们就要去获取这个用户的要求，并让软件去实现它。随之，软件就得到了软件需求。如下图所示：

需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 如下图所示：

需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。

在确定了需求之后，我们需要进行以下验证：

在软件的某些周期，我们总会遇到需求变更的问题。那对于需求变更来说，主要需要了解以下内容。

需求变更管理的主要工作有：

需求变更的控制流程如下图所示：

原型分析方法需要经过三个步骤，分别是需求分析→原型方法→原型评价。如下图所示：

功能列表法的图例如下所示：

现在，我们来看一个基于功能列表的实例。如下图所示：

敏捷分析法包含以下三个部分，分别是：

用户故事模板

用户故事常常写在卡片上，然后将其部署到墙上，便于讨论。

评价用户故事

用户故事迭代优先级

WBS 和工作包的区别如下：

任务分解主要有两种形式，分别为：

如下图所示：

类似于下方这样：

任务分解的过程要经过三个过程，输入→分解→ WBS 。有以下步骤：

确认并分解项目的主要组成要素

确认分解标准

确认分解是否详细

确认项目交付成果（可以编写 WBS 字典 ）

验证分解正确性

任务分解的过程有两大标准，分别是：

第一种： 分解标准应统一

第二种： 不能同时使用两种标准进行分解

WBS 字典如下图所示：

任务分解有4种方法，分别是：

如下图所示：

如下图所示：

如下图所示：

上述文章中，我们讲解了软件项目范围计划中的需求管理和任务分解，从多个方面去剖析软件需求分析。

到这里，本文的讲解就结束啦！希望对大家有帮助~

软件项目管理👉https://juejin.cn/column/7024826582841688077