1 软件需求的本质（2）

1.4需求开发和管理

人们对需求术语的困惑甚至延伸到整个学科的称谓上。有些地方将整个范围都称为“需求工程”，有些统称为“需求管理”，还有些人认为这些活动属于广义上业务分析的一个分支。软件需求工程的细分：

1.4.1需求开发

需求开发细分为获取、分析、规范说明、验证，这些细分囊括的活动设计产品需求的开发、评估、记录和确认。

获取

需求发现的所有活动，例如访谈、研讨会、文档分析、原型等。

• 识别产品的预期客户群和其他干系人。
• 理解客户任务、目标以及这些任务相关的业务目标。
• 了解新产品的应用环境。
• 与每一类客户群的代表一起工作，理解他们对功能有哪些需要以及对质量有怎样的预期。

思考：以用途为核心还是以产品为核心？
以用途为核心的策略强调的是对客户目标的理解和探求，以便提取必要的系统功能。
以产品为核心的方法侧重与特性，目的是领先市场或者业务取得成功，其风险是实现的特性并没有得到很高的利用。我们建议先理解业务目标和用户目标，然后根据自己得出的见解确定合适的产品特性。

分析

分析需求设计深入并准确理解每个需求，然后将各个需求以不同的方式表达出来。主要活动如下：

• 分析来自用户的信息，将其任务目标与功能需求、质量预期、业务规则、建议解决方案和其他信息区分开。
• 将概要需求进行适当的细分。
• 从其他需求信息中引出功能需求。
• 理解质量属性的相对重要性。
• 将需求分配给系统架构所定义的软件组件。
• 协商需求实现的优先级别。
• 找出需求中的遗漏的或者多余的、不必要的需求，以便定义范围。

规范说明

需求规范说明以一种连贯并结构清晰的方式来表达和存储收集到的需求知识。主要活动如下：

• 将收集到的用户需求转换为书面形式的需求和图表，供目标读者理解、检查和使用。

验证

需求验证是指确认需求信息是正确的，能够使开发人员制定出能满足业务目标的解决方案。主要活动如下：

• 检查记录下来的需求，再交给开发团队认可之前解决所有问题。
• 开发验收测试和标准，保证产品的开发是建立在需求基础之上的，能够满足客户需求并达成业务目标。

迭代是成功需求开发的关键。规划出多周期的需求探究活动，我们要逐步优化概要需求，使其进一步准确和细化，并与用户共同确认得出正确的需求（解决新系统的不确定性）。

1.4.2需求管理

需求管理主要活动如下：

• 及时确定需求基线，提交一个供当前时间段使用的参考，提出一套大家商定的、经过评审和批准的功能需求与非功能需求，通常针对具体产品发布或开发迭代。
• 评估提议需求变更可能产生的影响，然后以可控的方式将获准的变更融入项目。
• 随着需求的演化，保持项目计划与需求同步。
• 根据预估的需求变更可能带来的影响，商定新的承诺。
• 定义各个需求之间存在的关系和依赖。
• 跟踪每个需求到它们各自对应的设计、源代码和测试。
• 在整个项目过程中跟踪需求状态和变更活动。

需求管理的目标不是抑制变更或加大其难度，而是为了预测和协调不可避免且实际的变更，最终最小化变更对项目的破坏性影响。
从另一个视角看需求开发与需求管理之间的区别：

1.5每个项目都有需求

布鲁克斯在1987年论文《没有银弹：软件工程的根本问题和次要问题》中对需求在软件项目的角色做出论述：

开发软件系统最困难的部分是准确判断开发什么。最难的概念性工作便是确定详细的技术需求，包括所面向用户、机器和其他软件系统的接口。这项工作一旦做错，就会削弱系统性能。后期的修改工作也会更困难。

软件涉及的相关系统都有对其依赖的干系人。花一些时间理解他们的需要，这对项目的成功是一种高杠杆投资。
我们通常不太可能也没有必要在开始涉及和执行之前就指定全部功能需求。在这种情况下，可以采用迭代或者渐进式方法，一次只执行一部分需求，然后获取客户的反馈，然后再进入下一个循环。

1.6人对了，得出的需求却很糟糕

如果需求出了问题，最大的后果就是返工，尤其是在开发末期或者发布之后。返工通常占到开发总成本的30% ~ 50%，而需求错误占返工的70% ~ 85%。有些返工确实能增加价值和改进产品，但大量的返工不仅是一种浪费，还会挫伤士气。确定更准确的需求是一种投资，并不只是成本。
下面介绍一下最常见的需求风险：

1.6.1用户参与度不够

在一些情况下，与实际使用产品的用户直接接触很难，而用户代表并不总能理解用户的真实需要，用户参与度不足会引发新的需求，造成返工并延误工期。
用户参与度不足的另一个风险是业务分析师无法理解并准确记录实际业务或客户需要，特别是在检查和验证需求时。要注意业务分析师误解了业务问题，与客户保持沟通，若客户检查需求时不够仔细，问题仍然在所难免。

1.6.2规划不当

软件成本估算不当的主要原因：频繁的需求变更、需求遗漏、用户沟通不足、低质量的需求规范和不完善的需求分析。
如果围绕需求来估算项目工作量和时间，就需要了解需求的规模和开发团队的生产效率。

1.6.3用户需求蔓延

随着需求在开发过程中的不断演化，项目经常会超出计划的时间和预算（计划几乎总是过于乐观）。
为了管理范围蔓延，必须一开始就对项目的业务目标、战略愿景、范围、边界和成功标准给予明确说明。以此为参照，对所有新特性或者需求变更进行评估。需求变更会发展。项目经理应当在时间表中设置应急缓冲区，以免打乱时间表。
敏捷项目采用的方法就是对特定的迭代范围进行调整，使其符合迭代中规定的预算和时间。随着新需求的涌现，我们可以将其植入到未完成的条目中，然后根据优先级分配到未来的迭代之中。变更也许决定着项目的成败，但是总是有价值的。

1.6.4需求模棱两可

需求模棱两可的一大特征就是读的人可以有许多种方式来解读需求说明。不同的人有不同的理解。
模棱两可的需求会使不同干系人产生不同的期望。模棱两可的需求会造成时间和人力的浪费。
要想找出模棱两可的需求，一个办法就是让那些具有不同视角的人来检查需求。非正式的同行检查只能从自己的角度来阅读，一般看不出来模棱两可的需求。如果不同的检查者只按照自己的理解从不同角度理解需求，也看不出歧义性需求。因此，干系人应作为小组以工作坊的形式来讨论和解读需求，共同获取和验证需求。为需求写测试或者建原型也可以帮助找出歧义性需求。

1.6.5镀金

镀金，指开发人员增加的功能并不在需求规范说明之中（或者超出范围），但开发人员却自认为用户肯定喜欢。若客户并不在意这个功能，那么实现这个功能就是浪费时间。开发人员和业务分析师不应只是简单插入新的特性，而应向干系人展示创意，供他们参考。开发人员应当尽可能简而精，不要未经干系人同意就善做主张。

1.6.6忽视干系人

大多数产品都有若干个不同的用户群，他们使用不同的特性，使用频率也有所差异，经验水平也不尽相同。如果早期无法为产品确定主要的用户分类，某些用户的需要可能就无法满足。确定了所有用户分类后，还要保证倾听用户的声音。除了显而易见的用户，还要考虑维护人员和现场支持人员，他们也有自身的需求，包括功能需求和非功能需求。有些干系人甚至不知道项目的存在，例如制定标准并影响系统的政府机构，但你需要了解他们对项目的影响。

1.7高质量需求过程带来的好处

有效的需求过程强调的是协同开发产品，并在整个项目过程中将干系人视为合作伙伴。通过需求获取活动，开发团队可以更好地了解用户或市场，这是成功的一个关键要素。
准确将系统需求分配给不同的软件、硬件和人工子系统是一种构建产品的系统方法。有效的变更控制过程可以最小化需求变更可能带来的负面影响。将需求清晰地记录下来对系统测试有着极大的帮助。最后增加交付高质量产品的几率。
潜在收益如下：

• 需求中的缺陷和交付产品中的缺陷更少。
• 开发的返工减少了。
• 不必要和无用的特性减少了。
• 减少成本的追加。
• 信息错误传达的现象减少了。
• 范围蔓延减少了。
• 项目的混乱现象减少了。
• 客户和团队成员的满意度更高了。
• 产品按照人们当初的设想顺利运行。