软件项目范围计划——需求管理与任务分解

序言一、软件需求定义及层次1、定义2、层次二、软件需求管理过程1、管理过程2、需求获取3、需求分析4、需求规格编写5、需求验证6、需求变更（1）需求变更管理的主要工作（2）需求变更控制流程三、软件需求分析方法1、原型分析方法2、结构化分析法（基于数据流建模）（1）定义（2）结构化分析方法的技术3、面向对象的用例分析法（基于UML建模）（1）定义（2）UML需求视图4、功能列表（1）图例（2）基于功能列表的实例5、敏捷分析法四、任务分解1、任务分解定义（1）定义（2）WBS和工作包（3）WBS和工作包的区别2、任务分解形式（1）图表形式的WBS（组织结构图式）（2）提纲式3、任务分解过程（1）五大步骤（2）分解标准（3）分解标准举例阐述（4）WBS字典4、任务分解方法（1）模板参照（2）类比（3）自顶向下（4）自底向上5、任务分解结果（1）检验分解结果标准（2）WBS任务分解建议五、结束语🛵专栏直通车

序言

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

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

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

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

叮，开始学习吧~👏

一、软件需求定义及层次

1、定义

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

2、层次

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

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

二、软件需求管理过程

1、管理过程

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

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

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

2、需求获取

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

3、需求分析

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

4、需求规格编写

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

5、需求验证

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

需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字

6、需求变更

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

（1）需求变更管理的主要工作

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

建立需求基线确定需求变更控制过程建立变更控制委员会(SCCB)进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性

（2）需求变更控制流程

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

三、软件需求分析方法

1、原型分析方法

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

2、结构化分析法（基于数据流建模）

（1）定义

20世纪70年发展起来的面向数据流的方法是一种自顶向下逐步求精的分析方法根据软件内部数据传递、变换的关系进行分析的

（2）结构化分析方法的技术

数据流图(DFD)数据字典(DD)E-R图系统流程图

3、面向对象的用例分析法（基于UML建模）

（1）定义

基于面向对象的情景分析方法从用户角度出发考虑的功能需求用例是系统向用户提供一个有价值的结果的某项功能

（2）UML需求视图

用例视图 - Use case Diagram顺序图 - Sequence Diagram状态图 - State Diagram活动图 - Activity Diagram

4、功能列表

（1）图例

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

（2）基于功能列表的实例

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

5、敏捷分析法

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

用户故事模板

As a<type of user>,I want<some goal>,So that<some reason>.

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

评价用户故事

用户故事迭代优先级

第一组：①must have;②should have;③could第二组：have/want to have

四、任务分解

1、任务分解定义

（1）定义

任务分解指的是将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。

（2）WBS和工作包

WBS，即Work Breakdown Structure，表示任务分解结构。WBS是任务分解的结果。工作包，是WBS最低层次的可交付结果，是WBS的最小元素。

（3）WBS和工作包的区别

WBS和工作包的区别如下：

WBS是对项目由粗到细的分解过程；WBS是面向交互结果的；同时，WBS组织定义了整个项目范围；而工作包是WBS中最低层次的可交付成果（如下图所示）；且工作包应当由唯一主体负责。

2、任务分解形式

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

图表形式（组织机构图式）提纲式

（1）图表形式的WBS（组织结构图式）

如下图所示：

（2）提纲式

类似于下方这样：

1 变化计数器1.1 比较两个版本的程序1.1.11.1.21.1.31.2 找出修改后的程序中增加和删除的代码行1.2.11.2.21.3 统计修改后的程序中增加和删除的代码行数1.3.11.3.2

3、任务分解过程

（1）五大步骤

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

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

确认分解标准

确认分解是否详细

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

验证分解正确性

（2）分解标准

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

分解标准应统一；不能同时使用两种标准进行分解。

（3）分解标准举例阐述

第一种：分解标准应统一

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

（4）WBS字典

WBS字典如下图所示：

4、任务分解方法

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

模板参照类比自顶向下自底向上

（1）模板参照

如下图所示：

（2）类比

有些项目在某种程度上具有相似性；可以采用类似的WBS作为参考。

（3）自顶向下

如下图所示：

（4）自底向上

如下图所示：

5、任务分解结果

（1）检验分解结果标准

最底层要素是否是实现目标的充分必要条件；最底层要素是否有重复的；每个要素是否清晰完整定义；最底层要素是否有定义清晰的责任人；是否可以进行成本估算和进度安排。

（2）WBS任务分解建议

最低层是可控的和可管理的，但是不必要过细；每个Work package必须有一个提交物；定义任务完成的标准；有利于责任分配；推荐任务分解到40小时以内。

五、结束语

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

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

🛵专栏直通车

软件项目管理👉/column/7024826582841688077

如果觉得《「软件项目管理」软件项目范围计划——需求管理与任务分解》对你有帮助，请点赞、收藏，并留下你的观点哦！