1 软件需求的本质（1）

1.1前言

软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。现实生产环境中的软件产品发现的缺陷有40%~50%是在需求阶段埋下的“祸根”（Davis 2005）。在具体说明客户需求和管理客户需求过程中用户输入不足和有误，是造成项目失败的罪魁祸首。在软件项目中，所有干系人的利益交接点主要集中在需求方面。（更多干系人方面的内容参考本栏目后面章节）这些干系人主要包括客户、用户、业务分析人员和开发人员等。若处理得当，这种交接既让客户满意，又能鼓舞开发团队。若处理不当。则会引发误解和摩擦，最终降低产品质量和业务价值。

本章将学习：

• 理解软件需求领域所用的一些关键术语；
• 区分船票需求和项目需求；
• 区分需求开发和需求管理；
• 警惕可能出现的与需求相关的一些问题。

给自己的需求把把脉：

• 从来没有清晰制定过项目的业务目标、愿景和范围。
• 客户太忙，没有时间与分析师或开发人员共同处理需求。
• 团队无法与用户代表直接互动，不理解他们的具体需要。
• 客户认为所有的需求都很关键，因此没有对需求排定优先级。
• 开发人员在写代码时遇到了模棱两可或者遗漏的信息，所以只能靠猜。
• 开发人员与干系人沟通的重点集中于用户界面展示或者特性，并没有关注用户要使用软件完成的具体任务。
• 需求从来没得到过客户的认可。
• 客户认可了某个发布或者迭代的需求，但事后不断更改。
• 不断接受客户的需求变更请求，项目范围随之扩大，由于没有增加资源或者删减功能，进度最后完全被打乱。
• 有人提出了变更请求，但被忽略，没人知道特定变更请求的具体状态。
• 客户提出特定的功能要求，而且开发人员也建好了，但就是没有人使用过。
• 在项目接近尾声时，虽然满足规范说明，却不满足客户或业务的目标。

1.2软件需求的定义

对于开发人员来说，客户定义的需求听上去更像是一种高级产品的概念。
对于用户来说，开发人员所说的需求理念听上去更像是一种具体的用户界面设计。
这种理解上的偏差都是普遍存在的。

1.2.1关于“需求”的一些解释

顾问布莱恩劳伦斯认为需求是“任何能够驱动设计做出选择的东西”，需求的目的是要做出合适的设计选项，最终满足客户的需要。
Ian Sommerville and Pete Sawyer（1997）提出：需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。
Tips：不要妄想项目中的所有干系人都能对需求达成统一的认识。提前确定定义，以便大家能够达成共识。

1.2.2字典中的“需求”

字典中对“需求”解释为：被命令或者强制性的东西；需要或者必要。这对软件界所使用的“需求”不是一个含义。人们有时会怀疑是否有必要对需求进行优先级排序，因为有的低优先级需求可能永远不会被实现。
需求包含一个时间维度，它们可能是描述目前系统性能的现在时。或者它们可能是近期（高优先级）、中期（中等优先级）或者想象中（低优先级）的未来。

1.3需求的层次和种类

1.3.1需求领域的常用术语

术语	定义
业务需求	开发产品的组织或者获取产品的客户所需的高层次业务目标
业务规则	策略、纲领、标准或者制度，能够定义或者约束某些方面的业务。虽然本身不是软件需求，但它却是一些类型的软件需求的鼻祖
约束	对开发人员在产品设计和构建上的限制条件
外部界面需求	对软件系统和用户、其他软件系统或硬件设备间的关联进行说明
特性	单个或者多个为用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述
功能需求	描述系统在特定条件下展现的行为
非功能需求	描述系统必须展现的属性或者特性，或者必须遵守的约束
质量属性	一种非功能能需求，描述的是服务或者一个产品的性能特征，例如性能、安全性、易用性和可移植性
系统需求	包含多个子系统的产品的顶层需求，子系统可以是软件，也可以是软硬件
用户需求	特定用户群必须能够用系统所完成的目标任务，或者用户期望有的产品属性

1.3.2软件需求的三个层次

• 业务需求：描述组织为什么要执行系统（组织期望获得的业务收益），其关注点在于组织或者提出系统要求的客户有哪些业务目标。
• 用户需求 ：描述了用户使用产品必须完成的目标或任务，并且这个产品要能够为人提供价值。用例、用户故事以及事件响应表都是用户需求的表达方式。用户需求表达的是用户通过系统来完成哪些具体工作。
• 功能需求：产品在特定条件下所展示出来的行为，主要描述开发人员需要实现的功能以便用户能够完成自己的任务（用户需求），进而满足业务需求。常将功能需求记录为传统意义上的“应当”句式：某某应当能进行什么动作。
  数据需求贯穿于这三个层次的需求之中。
  
  业务分析师（BA）将功能需求记录在软件需求规范说明（SRS）之中，尽可能详尽地描述人们对软件系统的预期行为。SRS用于开发、测试、质量保障、项目管理和相关项目功能。它还称作业务需求文件、功能规范说明、需求文件等。
  

1.3.3处理三种层次的需求

前面图1-1显示了三种主要的需求交付物：愿景、范围文档、用户需求文档和软件需求规范说明。无需为每个项目都创建这三种需求交付物。要注意这三种交付物包含不同的信息，要在项目的不同点进行开发，开发人员也可能不同，目的和目标受众也不相同。

前面图1-1展示了一个简单的自上而下的需求信息流。在现实中，我们见到的是以业务、用户和功能需求为中心的循环和迭代。只要提出某个新特性、用户需求或者一点点功能，分析师肯定会问“这在范围之内吗？”如果回答“是”，则将此需求纳入规范说明。若回答“不，但它支持业务目标，所以应该算是吧。”，这种情况下，项目发起方、项目经理或者产品负责人都必须当机立断，决定是否增加当前项目或者迭代范围以适应新的需求。这种业务决策对项目的计划和预算都有着很大的影响，可能要对其他功能做出妥协。

高效的变更过程包含“影响分析”以保证合适的人做出可靠的业务决策，确定哪些变更可以接受，解决时间、资源或特性权衡所关联的成本。

1.3.4产品需求与项目需求

到目前为止，讨论的需求主要描述软件系统的属性。我们将其称之为产品需求。项目还包含其他诉求和产出，不在团队执行的软件范围之内，但对项目整体成败尤为关键。这些都是项目需求而非产品需求。SRS包含产品需求，但不包括产品设计或执行细节、项目计划、测试计划等信息。要将这类事项独立出去，使需求开发活动聚焦于理解团队要开发的内容。
项目需求包括：

• 开发团队的物质需求，包括工作站、专用硬件设备、测试实验室、测试工具和设备、团队办公室和视频会议设备。
• 员工培训需求。
• 用户文档，包括培训材料、教程、参考手册和发行说明。
• 支持文件，例如帮助资源、硬件的现场维护和服务信息。
• 操作环境中所需要的基础设施变更。
• 需求和流程，用于发布产品，在实际操作环境中安装产品，对它进行配置和测试。
• 针对从旧系统迁移到新系统所做的需求和规则，例如数据合并和转换、安全设置、产品切换以及弥补技术空白而做的培训，我们又时也称为迁移需求。
• 产品认证和合规需求。
• 修改的策略、过程、组织结构和类似文档。
• 第三方软硬件组件的采购、收购和许可。
• Beta测试、生产、包装、市场和发行需求。
• 客户服务等级协议。
• 针对与软件相关的知识产权，为获取法律保护（专利、商标或者版权）所做的需求。

项目需求信息最好存储在项目管理计划中，详细列出全部预期项目活动和交付物。
特别是针对业务应用，人民有时认为“解决方案”包含产品需求（业务分析师的主要责任）和项目需求（项目经理主要责任）。在本次学习中，我们讨论产品需求，不管最终的交付物是某个商业软件产品、带嵌入式软件的硬件设备、企业信息系统、政府定制软件还是其他任何东西。