3-项目计划之范围计划(需求管理)

过分简略的需求说明以致遗漏某些关键需求。
－－这种方法可能适合于尖端研究性的产品或需求本身 就十分灵活的情况（ McConnell 1996）。但在大多数情况 下，这会给开发人员带来挫折（使他们在不正确的假设前 提和极其有限的指导下工作），也会给客户带来烦恼（他 们无法得到他们所设想的产品）
不当的需求过程引来的风险：
需求工程基本概念
2.需求管理是一种用于查找、记录、组织和跟踪系统需求变更的
系统化方法，可用于获取、组织和记录系统需求并使客户和项目 团队在系统需求变更上保持一致。
－有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适 用的属性，以及与其它需求和其它项目工件之间的可追踪性。

需求管理活动包括
－定义需求基线 IEEE对基线的定义：已经正式通过复审和批准的某规约和产品，它因此可 以作为进一步开发的基础，并且只能通需求定义 二、软件需求管理过 程 三、需求建模的基本 方法 四、案例分析

什么是软件需求？
I E E E软件工程标准词汇表（1 9 9 7年）中定义需求为： （1）用户解决问题或达到目标所需的条件或权能（C a p a b i l i t y）。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档 条件或权能。 （3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。


宽泛地讲，需求来源于用户的一些“需要”（欲望），这些“需 要”被分析、确认后形成完整的文档，该文档详细地说明了产品 “必须或应当”做什么。 所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经 掌握了需求，那是自欺欺人。
什么是软件需求？
在RUP中定义了需求工作流程的工作目的：

客户和其他涉众在系统的工作内容方面达成并保持一 致。 使系统开发人员能够更清楚地了解系统需求，定义系 统边界（限定）。 为计划迭代的技术内容提供基础。 为估算开发系统所需成本和时间提供基础。 定义系统的用户界面，重点是用户的需要和目标。

7
项目范围的界定，首先是需求问题
现实的问题：

项目会涉及哪些工作？——即：为了实现项目目 标，必须的工作是哪些？ 这些工作由谁负责?——每个负责人会对自己负责 的项目内容和目标清楚吗？他们是不是会作出改 变范围的决定？

前面的问题不确定，是因为需求的
不确定
在用户立场上看，需求不能马上、全部确定，是 现实的，也是合理的。 需求的渐进确定，符合软件开发的特征——易于 改变的特征。 因此，开发软件首先意味着开发需 求。
2. 一致性 －－一致性是指与其它软件需求或高层（系统，业务）需求
不相矛盾。在开发前必须解决所有需求间的不一致部分。 只有进行一番调查研究，才能知道某一项需求是否确实正 确。
需求规格说明的特点
3. 可修改性
－－在必要时或为维护每一需求变更历史记录时，应该修订 S R S。这就要求每项需求要独立标出，并与别的需求区别 开来，从而无二义性。每项需求只应在S R S中出现一次。 这样更改时易于保持一致性。另外，使用目录表、索引和 相互参照列表方法将使软件需求规格说明更容易修改。
－－对不准确的要求所提问题的正确响应是“等我真正明白你的需求
不当的需求过程引来的风险：

不完善的需求说明使得项目计划和跟踪无 法准确进行。
需求规格说明的特点：
1. 完整性 －－不能遗漏任何必要的需求信息。遗漏需求将很难查
出。注重用户的任务而不是系统的功能将有助于你避免不 完整性。如果知道缺少某项信息，用T B D (“待确定” )作 为标准标识来标明这项缺漏。在开始开发项目之前，必须 解决需求中所有的T B D项。
入什么、输出什么、查询什么？相互之间如何接口？….

范围问题，在项目初期并不严重，但在常规的 “需求阶段”结束后的设计和编码阶段中，因 用户需求的不断被发现或增长，范围控制就遇 到挑战。
3
范围管理的目的

范围不清的问题，引出了项目的范围管理目 标——在接受需求变更的实际情况下，控制住 项目的整个范围保持清晰并趋于稳定。 项目范围管理，就是围绕项目包括什么与不包 括什么的定义，以及内容的变化，开展有计划 的控制过程。


涉众：涉众是所有会受到项目结果重大影响的人。如客户（或客户代表） 用户（或用户代表） 、投资者 、股东 、生产经理 、买方 、设计员、测 试员 、文档编写员等
什么是软件需求？

需求的重要性

Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：
－－处理模棱两可需求的一种方法是组织好负责从不同角
不当的需求过程引来的风险：

用户增加一些不必要的特性和开发人员画蛇添足 ( g o l d - p l a t i n g )。
去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业 务任务的核心功能。
－－应确信：你明白为什么要包括这些功能，以及这些功能的“来龙
本章要点
一、软件需求定义 二、软件需求管理过 程 三、需求建模的基本 方法 四、案例分析

软件需求管理的过程
贯穿于项目过程的始终
需求是软件设计、实现实施以及产品验证的基本信息源——由此 可见，需求中的错误对项目的成本和进度具有负面的影响。
落实于软件的描述
保证软件需求以一种形式描述所有应该具有的功能、和性能。

但是，如果仅仅是按照这句话来编制程序代码， 那么很快就会遇到软件功能范围的决策问题。 ——随着编程的开始，原有的需求描述不清楚了
17
需求不明的具体事例:
1. 2.
3. 4. 5. 6.
输入电话号码时，是否对电话号码进行有效性检查？ 这个检查器应该设计成什么样的?——廉价的？强 大的？全球/本国通用的？ 有没有现成可复用的检查器？ 如自己开发，成本如何？以后还维护（升级）吗？ 当检查器查出问题，应该给出什么提示信息？ 这个检查器是不是需要与客户的住址捆绑？

范围管理起于项目相关人员之间的沟通

一个确定的项目范围，是制订软件开发计划 的根据，它包括对功能、性能、接口和可靠 性等要求的确定。

项目范围管理的基本目的：

认识一致——经常保持项目组和项目干系人对项目产品以及生产这些 产品所用到的过程有一个共同的理解。 按计划管理范围——制定计划，明确定义范围，实施有目标的范围管 理。
4. 可跟踪性
－－应能在每项软件需求与它的根源和设计元素、源代码、 测试用例之间建立起链接链，这种可跟踪性要求每项需求 以一种结构化的，粒度好（ f i n e - g r a i n e d）的方式编 写并单独标明，而不是大段大段的叙述.
小结

一、软件需求定义

什么是软件需求？ 需求的层次 需求不明带来的风险 需求规格说明的标准
需求工程基本概念
2.需求管理是一种用于查找、记录、组织和跟踪系统需求变更的
RoadMap
项目 初始 项 目计划 项目 执行控制 项 目结束
软件项目管理
范围计划之 软件项目需求管理
项目管理的经验显示：项目经理面对的最大挑 战，就是范围管理。 因为： “项目范围缺乏清晰性或可控性” 想想这是为什么？

——往深里说，是客户的目标、用户的需求，究竟是什么？？ ——往浅里说，是…项目究竟要开发哪些软件？每个软件究竟 输

关于软件需求：两个基本的视角

对于项目甲方，需求就是他的目标

对于项目乙方


对于软件企业经营管理者，需求就是市场，是 企业利润的来源。 对于承担项目的团队，需求是他们必须完成的 开发任务及其要交付的产品成果。 对于软件开发人员，需求是指用户对软件的功 能和性能的要求，就是用户希望软件能做什么 事情，完成什么样的功能，达到什么样的性能。
软件需求管理的过程
需求工程 需求开发 需求管理
问 题 获 取
分 析
编 写 规 格 说 明
验 证
变 更 控 制
版 本 控 制
需 求 跟 踪
需 求 状 态 跟 踪
业 务 需 求
用 户 需 求
功 能 需 求
图：需求管理过程所涉及到的工作
需求工程基本概念
1. 需求开发
包括需求获取、需求分析、编写需求规格说明、验证需求四个阶段， 在这四个阶段执行以下活动： －确定产品所期望的用户类； －获取每个用户类的需求； －了解实际用户任务和目标以及这些任务所支持的业务需求； －分析源于用户的信息以区别业务需求、功能需求、质量属性、业务规则， 建议解决的方法和附加的信息； －分解需求，并将需求中的一部分分配给软件组件； －了解相关属性的重要性； －划分实施优先级； －编写需求规格说明和模型； －评审需求规格，验证对用户需求的正确理解和认识。
用户需要（欲望） 产品需求 开发实现
满足用户的需要（欲望 ）
需求不明的根源

对需求的多视角认识，需求的3+1式的划分：
1. 2. 3.
4.
业务需求（business requirement） 用户需求（user requirement） 功能需求（functional requirement）。 +1：系统需求、非功能需求、质量需求（含约束和假设）
－－要想把需求变更范围控制到最小，必须一开始就对项目
不当的需求过程引来的风险：

模棱两可的需求说明可能导致时间的 浪费和返工。
度审查需求的队伍。仅仅简单浏览一下需求文档是不能解 决模棱两可问题的。如果不同的评审者从不同的角度对需 求说明给予解释，但每个评审人员都真正了解需求文档， 这样二义性就不会直到项目后期才被发现，那时再发现的 话会使得更正代价很大。
范围管理的原理