目录

第4章 软件过程的需求管理

4.1 需求管理的模型和流程

4.1.1 软件需求工程概述

4.1.2 需求过程系统模型

4.2 需求开发

4.2.1 需求获取的过程和方法

4.2.2 基于用例的需求获取和分析 

4.2.3 需求定义

4.3 需求管理

4.3.1 需求确认

4.3.2 需求跟踪

4.3.3 需求变更控制

---

第4章 软件过程的需求管理

4.1 需求管理的模型和流程

4.1.1 软件需求工程概述

4.1.2 需求过程系统模型

所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪。

软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。

•  业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。
•  用户需求(user requirement) 文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。
•  功能需求(functional requirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。 

4.2 需求开发

4.2.1 需求获取的过程和方法

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 

需求获取概述 

需求获取是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。

需求获取的方法 

• 需求研讨会
• 头脑风暴
• 用例模型
• 访谈
• 角色扮演
• 原型法

4.2.2 基于用例的需求获取和分析 

基于用例的需求获取 

执行者的识别	谁使用系统的主要功能？ 谁将提供、使用和删除信息？ 谁负责维护、管理并保持系统正常运行？ 谁会对某一特定需求感兴趣？ 系统的外部资源是什么？ 系统需要和哪些外部系统交互？
用例的识别	某个执行者要求系统为其提供什么功能？该执行者需要做哪些工作？ 执行者需要阅读、创建、销毁、更新或存储系统中哪些（类）信息？ 系统中的事件一定要告之执行者吗？执行者需要告诉系统一些什么吗？那些系统内部的事件 从功能的角度代表什么？ 由于新功能的识别，执行者的日常工作被简化或效率提高了吗？ 系统需要什么样的输入输出？输入在哪里？输出去往哪里？ 该系统的当前情况存在哪些问题？

4.2.3 需求定义

需求定义 

需求定义指的是解释涉众需求,并根据需求规模整理成对要构建系统的明确的说明。

• 前景文档是用一般的语言定义系统特征的文档
• 软件需求规格说明书是用更专业的术语定义系统特征的文档。

4.3 需求管理

4.3.1 需求确认

需求确认

如何进行需求评审？

（1）分层次评审

• 目标性评审
• 功能性评审
• 操作性评审

（2）分阶段评审

如何保证需求规格说明书的质量？

• 正确性
• 完备性
• 易理解性
• 一致性
• 可行性
• 健壮性
• 易修改性
• 易测试性和可修改性
• 易追溯性
• 兼容性

4.3.2 需求跟踪

需求跟踪

1.  需求的标识
2. 需求的属性
3. 需求状态

• 正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。  
• 逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。 

4.3.3 需求变更控制

需求变更控制流程

需求的变更是不可避免的，因此如何有效控制需求的变化对于项目成功至关重要。

需求变更控制策略 

（1）项目启动阶段的变更预防

（2）项目实施阶段的需求变更

（3）项目收尾阶段的总结