开发人员通常希望在完成一些初始工作后冻结软件需求，然后继续开发，不受那些烦人的变更的阻碍。这是经典的瀑布模式。在大多数情况下，它效果不佳。定义需求基线，然后管理对该基线的变更，这更为现实。
什么是需求基线？
需求基线是时间快照，代表已达成一致、经过审查和批准的一组已提交给特定产品版本的需求。
该“版本”可以是已交付的完整产品，也可以是产品的任何临时开发增量。当利益相关者“签署”需求时，他们实际上是在同意并承诺特定的需求基线（无论他们是否这样认为）。
一旦项目团队建立了需求基线，团队就应该遵循务实的变更控制流程，以做出有关添加新请求的功能以及更改或删除现有需求的良好业务和技术决策。
变更控制流程不是要抑制变化；而是要为决策者提供信息，使他们能够及时做出适当的决策来修改计划的功能。计划的功能就是基线。
通常，基线还具有唯一的名称，以便所有项目参与者都可以明确地引用它。良好的配置管理实践使团队能够准确地重建任何先前的基线及其所有组件。
实施需求基线
范围定义区分了哪些是输入内容，哪些是输出内容，而需求基线则明确标识了项目将实施的需求规范。基线不是有形项目，而是已定义的项目列表。一个可能的存储位置是软件需求规范 (SRS) 文档。
如果该 SRS 文档仅包含特定产品版本的所有需求，则 SRS 构成了该版本的需求基线。但是，SRS 文档可能包括用于后续版本的其他低优先级需求。
相反，大型项目可能需要多个软件、硬件和接口需求规范来完全定义基线的组件。目标是让项目利益相关者清楚地了解即将发布的版本中究竟包含哪些内容。
也许您将需求存储在需求管理解决方案中，而不是文档中。在这种情况下，您可以将基线定义为存储在数据库中、计划用于给定版本的特定需求子集。
将需求存储在 RM 解决方案中，可让您维护当前已提交的需求和计划的未来需求的汇总集。一些商业需求管理工具包括基线功能，用于区分属于特定基线的需求（甚至可能细分到每个需求的特定版本）。
或者，您可以在解决方案中定义需求属性来保存发布号或另一个基线标识符。将需求从一个基线移动到另一个基线只是更改该需求属性值的简单操作。
当每个需求仅属于单个基线时，属性方法将起作用。但是，如果您同时开发产品的多个版本（例如家庭版和专业版），则可能会将相同的需求（或相同需求的不同版本）分配给多个基线。工具支持对于这种复杂的基线管理至关重要。
在遵循增量或迭代开发生命周期时，每次迭代的基线仅代表整个系统功能的一小部分。
例如，我们团队曾经开展的一个小项目就采用了这种方法。该项目的发布周期为三周。对于每个周期，BA 都会指定接下来三周内需要设计、编码、集成和验证的软件需求。因此，每个需求基线都非常小。在经典的敏捷方法中，随着开发人员定期向用户发布有用的版本，产品会逐步发展到完整功能。
何时执行基线
业务分析师有时会纠结于何时定义需求基线。这是一个重要的决定，因为建立基线具有以下含义：
正式变更控制开始。变更请求是根据既定的基线提出的。因此，基线为每个提议的变更提供了参考点。在定义任何项目基线之前，请确保变更控制流程和参与者到位。
项目经理确定所需的人员配备水平和预算。软件项目必须管理五个维度：功能、质量、进度、人员和预算。在基线中定义功能和质量目标后，项目经理会调整其他三个维度以实现项目目标。反之亦然。如果人员、预算和/或进度是由外部力量预先确定的，则基线组成必然受到限制，以适应受这些限制限制的项目框。
项目经理做出进度承诺。在建立基线之前，需求仍然不稳定且不确定，因此估计同样不稳定且不确定。一旦建立了基线，发布的内容就应该得到充分的理解，以便管理人员能够做出切实可行的承诺。管理人员仍然需要预测需求的增长（根据他们的需求管理计划），方法是在他们承诺的时间表中包含合理的应急缓冲。
过早地确定需求基线可能会使你的变更过程超速运行。事实上，在定义基线后收到大量变更请求可能表明你的需求引出活动不完整，甚至无效。另一方面，等待太长时间建立基线可能是分析瘫痪的迹象：也许 BA 在将需求集交给开发团队之前过于努力地完善它们。
请记住，需求引出试图定义一组足够好的需求，让团队在可接受的风险水平下继续建设。使用表 1 中的清单来判断你何时准备好定义需求基线作为继续开发工作的坚实基础。
表 1. 定义需求基线前要考虑的因素
| 商业规则 | 确定您是否已确定影响系统的业务规则，以及是否已指定执行或遵守这些规则的功能。 |
| 变更控制 | 确保已制定实用的变更控制流程来处理需求变更，并组建和授权变更控制委员会。确保您计划使用的变更控制工具已到位并配置完毕，并且已对工具用户进行培训。 |
| 客户视角 | 与您的主要客户代表核实，了解自上次交谈以来他们的需求是否发生了变化。是否有新的业务规则发挥作用？现有规则是否已修改？优先级是否已更改？是否已确定具有不同需求的新客户？ |
| 接口 | 查看是否已定义功能来处理所有已确定的外部用户接口、其他软件系统、硬件组件和通信服务。 |
| 模型验证 | 与用户代表一起检查任何分析模型（可能通过测试用例进行），以查看基于这些模型的系统是否允许用户执行其必要的活动。 |
| 原型 | 如果您创建了任何原型，相应的客户是否对其进行了评估？BA 是否使用获得的知识来修订 SRS？ |
| 一致性 | 检查定义的一组需求是否可能实现项目的业务目标。寻找业务需求、用户需求和功能需求之间的一致性。 |
| 评审 | 让需求的几个下游消费者对其进行评审。这些消费者包括设计师、程序员、测试人员、文档和帮助编写者、人为因素专家以及任何将根据需求开展工作的人。 |
| 范围 | 确认正在考虑用于基线的所有需求都在当前定义的项目范围内。范围可能已发生变化，因为它最初是在项目早期定义的。 |
| 待定事项 | 扫描文档以查找待定事项（细节尚未确定）。待定事项代表尚待完成的需求开发工作。 |
| 模板 | 确保已填充 SRS 文档模板的每个部分。或者，查找某些部分不适用于此项目的迹象。常见的疏忽是质量要求、约束和假设。 |
| 用户类别 | 查看您是否已收到您为产品确定的所有用户类别的适当代表的意见。 |
| 可验证性 | 确定如何判断每个需求是否得到正确实施。用户验收标准对此很有帮助。 |
您永远无法获得完美、完整的需求。BA 和项目经理必须判断需求是否趋向于产品描述，该产品描述将满足部分客户需求，并且可在已知的项目约束内实现。
此时建立基准可让项目利益相关者就他们完成后将拥有的产品达成共识和期望。如果没有这样一个商定的基准，项目结果很可能会让人感到惊讶。
而软件惊喜很少是好消息。
