定义和实施需求基线

在传统的瀑布开发模式中，开发人员通常在初始阶段就确定需求并将之“冻结”，以便在不受需求变更影响的情况下进行开发。然而，实际经验告诉我们，这种方法在多数情况下并不适用，更为有效的方法是先建立需求基线，然后进行基线变更管理。

一、什么是需求基线?

需求基线是一个时间快照，代表的是已经讨论过、批准过并且承诺会在特定产品发布中实现的一系列需求共同认同。

这个“发布”可能是一个完全交付的产品，或者是该产品的任何中间开发阶段。当利益相关者对需求“签字确认”时，他们实际上在做的就是同意并承诺一个特定的需求基线（无论他们是否以这种方式思考）。

一旦项目团队建立了需求基线，团队应当遵循一个务实的变更控制流程，以对新增的功能需求和修改或删除现有需求进行合理的商业和技术决策。

变更控制流程并不是为了压制变化，而是为了提供信息给决策者，使他们能够及时、适当地做出决定，修改计划的功能。这个计划的功能就是基线。

通常情况下，基线会被赋予一个唯一的名称，这样所有的项目参与者都可以明确无误地引用它。良好的配置管理实践可以让团队准确地重构任何之前的基线及其所有的组件。

二、实施需求基线

范围定义是为了区分项目中包含和不包含的部分，而需求基线则明确标识出项目将实施的需求规范。基线不是一个实物，而是一份定义清楚的物品清单。一种可能的存储位置是软件需求规范（SRS）文档。

如果SRS文档只包含并且全面覆盖了特定产品发布的所有需求，那么这个SRS就构成了该发布的需求基线。然而，SRS文档可能还会包含一些额外的，优先级较低的需求，这些需求是为了之后的发布准备的。

反之，一个大项目可能需要多个软件、硬件和接口需求规范，以完全定义基线的组成部分。目标是提供清晰的信息，让项目的利益相关者了解即将发布的内容到底是什么。

也许你是在一个需求管理工具（如PingCode等）中而不是在文档中储存你的需求。在这种情况下，你可以将基线定义为计划用于特定发布的数据库中的需求的子集。

使用需求管理工具储存需求，可以维护一组聚合的当前承诺的需求和计划的未来需求。一些商业需求管理工具包括基线功能，以区分哪些需求（可能是每个需求的特定版本）属于某个特定的基线。

另一种方法，你可以在需求管理工具中定义一个需求属性，用来保存发布编号或其他基线标识符。将需求从一个基线转移到另一个基线，只需要简单地改变那个需求属性的值。

当每个需求只属于一个基线时，这种属性方法就有效。然而，如果你正在并行开发产品的多个版本，如家庭版和专业版，你可能需要将同一个需求（或不同版本的同一需求）分配到多个基线。在这种复杂的基线管理中，工具的支持是必要的。

在迭代开发生命周期中，每个迭代的基线只会代表整个系统功能的一部分。

例如，我们的团队曾经在一个小项目中采取了这种方法。这个项目每三周发布一次。对于每个周期，业务分析员都会指定在接下来的三周内需要设计、编码、集成和验证的软件需求。因此，每个需求基线都非常小。在典型的敏捷方法中，随着开发者定期向用户发布有用的版本，产品逐渐增长到完全的功能。

三、什么时候执行基线

业务分析师有时会对确定需求基线的时机感到困扰。这是一个重要的决定，因为确定基线会有以下几个影响：

正式的变更控制开始：变更请求是对已确定的基线提出的。因此，基线为每个提出的变更提供了参照点。在你确定任何项目基线之前，需要确保变更控制流程及其参与者都已准备就绪。

项目经理确定所需的人员水平和预算：软件项目需要管理五个维度：特性、质量、时间表、人员和预算。一旦在基线中确定了特性和质量目标，项目经理就会调整其余三个维度以完成项目的目标。它也可以反向操作。如果员工、预算和/或时间表是由外部力量预先设定的，基线的内容必然会受限，以适应那些限制的项目框架。

项目经理做出时间表承诺：在确定基线之前，需求仍然是不稳定和不确定的，因此估计也同样是不稳定和不确定的。一旦建立了基线，发布的内容应被足够理解，以便管理者可以做出实际可行的承诺。管理者仍然需要预见需求的增长（根据他们的需求管理计划），并在他们承诺的时间表中包含合理的应急缓冲。

过早地确定需求基线可能会推动变更过程进入过度运行状态。实际上，在定义基线后收到大量的变更请求可能是一个信号，表明你的需求收集活动是不完整甚至无效的。另一方面，等待太久才确定基线可能是分析瘫痪的一个迹象：也许业务分析师过于努力地完善需求集，然后再交给开发团队。

我们要注意：需求的收集试图定义一套足够好的需求，以让团队可以在可接受的风险水平下继续开发。可以使用表1中的清单来判断你何时准备好定义需求基线，作为继续开发工作的坚实基础。

业务规则	是否确定了影响系统的业务规则，以及是否指定了执行或遵守这些规则的功能。
变更管理	请确认已建立了能有效处理需求变更的变更控制流程，同时，要确认所要使用的变更控制工具已经配置完成，并对用户进行了相应的培训。
客户意见	与关键的客户代表进行确认，了解是否在上次沟通后需求有所改变。是否有新的业务规则生效？现有规则是否有所调整？需求的优先级是否发生变动？是否有新的客户，他们的需求与旧的客户是否不同？
接口	检查系统是否有足够的功能去管理和操作用户、其他软件系统、硬件组件和通信服务封外部连接和交互。
模型确认	和用户代表一起审核所有的分析模型，并通过测试用例检查系统是否能允许用户执行他们需要的活动。
原型	如果制作了原型，务必确保有合适的客户进行评估。需求规范说明是否已经根据这些反馈进行了调整？
一致性	最后，检查所定义的需求集能否实现项目的业务目标，确保业务需求、用户需求和功能需求之间的一致性。
审查	确保所有下游的“需求消费者”进行了需求审查，这些“消费者”包括设计师、开发人员、测试人员、文档编写人员、辅助编写人员、人因工程师以及其他依据需求进行工作的人员。
范围	确认所有考虑加入基线的需求都在当前确定的项目范围之内。因为项目范围在项目初期确认，可能已经发生了变化。
TBDs（待定部分）	需要检查文档中是否有标记为”TBD”的部分，”TBD”通常表示某些细节或需求尚未确定或尚未完全定义。
模板	确保完成了软件需求规范(SRS)文档模板的每一部分，并检查是否有内容并不适用于本项目。常见的遗漏包括质量需求、约束和假设。
用户类别	核查所有用户类别的代表是否都给出了反馈。
可验证性	需要有明确的方式来验证每个需求是否得到了准确的实现，用户接受标准（User Acceptance Criteria）是非常有用的工具。