目录
Toggle
要点总览（TL;DR）需求基线的准确定义需求基线包括什么、不包括什么需求基线如何建立并生效基线之后需求变更如何被记录和批准需求基线与需求版本、发布版本的区别一个具体例子与常见误解常见问题需求基线建立后，需求还能修改吗？一个项目需要建立几个需求基线？需求基线与配置基线需要同时建立吗？变更被批准后，是立即建立新基线还是累积一段时间再建？需求基线能直接作为发布范围的依据吗？
需求基线是在某个确认时点，把一组已评审通过的需求及其版本、状态和关键属性固定下来，作为后续变更比较、影响评估和批准记录的参照点。它固定的是需求对象在那一刻的已确认内容，不等于发布版本，也不覆盖代码、配置项等跨资产配置。本文聚焦需求对象版本层面的基线，说明它的组成、建立机制、变更处理方式，以及它与需求版本、发布版本的区别。
要点总览（TL;DR）
需求基线是在某个确认时点，把一组已评审通过的需求及其版本、状态和关键属性固定下来，作为后续变更比较、影响评估和批准记录的参照点。
基线内包含需求条目清单、版本号、确认状态和关键属性；跨资产配置和发布版本分别归研发配置与基线管理、研发版本与发布管理，不纳入需求基线。
基线通过明确的建立动作生效：约定触发时点、确认纳入条件、记录基线标识与版本，生效后需求内容进入受控状态，修改需经变更申请入口发起。
基线后的变更围绕差异比较、影响评估、申请与批准记录展开，批准实施后可建立新基线，形成可追溯的变更链条。
需求基线是需求集合级的参照点，需求版本记录单条需求的演进，发布版本描述对外交付内容，三者回答的问题不同。
需求基线的准确定义
需求基线可以概括为：在需求经过评审确认后，由项目或产品团队选定的一组需求条目及其当前版本，连同状态、优先级、验收标准等关键属性，被正式记录并赋予一个可识别的基线标识，此后所有针对这些需求的修改都以该标识对应的内容为比较起点。
这个定义包含三个要素，理解它们就能把握基线的实质。
固定的对象是需求条目及其版本信息。基线记录的是“哪些需求、在哪个版本、处于什么状态、具备哪些关键属性”，例如某条需求在基线中的版本号为 V1.2、状态为“已确认”、优先级为“高”。它固定的是需求内容本身，而非需求所衍生的代码、接口文档或测试脚本。
基线是一次确认时点的快照。基线在建立那一刻生效，之后需求继续演进，基线内容保持不变，成为历史参照。团队可以建立多个基线，每个基线对应不同的确认时点。
基线是后续比较与批准的参照点。当有人提出修改某条已基线化的需求时，评审者可以对照基线内容判断改了什么、影响哪些下游工作，批准记录也以基线为起点留存变更轨迹。
需要区分的是，基线固定的是“已确认的需求内容”，它回答的是“我们当时承诺做什么”，而不是“我们最终交付了什么”。后者属于发布版本要回答的问题。
需求基线包括什么、不包括什么
明确基线范围，比记住定义更能减少实际工作中的混淆。基线内应包含的内容和应排除的内容可以对照列出。
基线内应包含：
纳入基线的需求条目清单，以及每条需求在基线时点的版本号；
每条需求的状态，通常为“已评审通过”或“已确认”；
需求的关键属性，如优先级、验收标准、所属模块、关联的上游来源；
基线本身的标识、建立时间、建立人和基线说明。
基线不包括：
跨资产配置。代码分支、构建脚本、环境配置、部署参数等配置项的版本固定，属于研发配置与基线管理的范畴。需求基线只固定需求对象，不替代配置基线。
发布版本。一次发布包含哪些需求、以什么顺序交付、对外版本号如何命名，属于研发版本与发布管理。需求基线是发布规划的输入之一，但两者不是同一件事。
未评审或未确认的需求。草稿状态、待评审状态的需求不进入基线，否则基线就失去了“已确认”这一前提。
基线范围与项目范围相关但不等同。一个项目可以只对核心需求建立基线，把辅助性需求留在基线之外继续细化；也可以按模块分批建立多个基线。基线范围由团队根据确认节奏和变更风险划定，项目范围则描述整个项目要交付的工作边界。
需求基线如何建立并生效
基线不是自动产生的，它需要一次明确的建立动作。典型的建立过程包含触发、纳入条件、标识记录和生效锁定四个环节。
触发时点。常见触发点包括：需求评审会通过后、项目进入开发阶段前、合同或对外承诺确认时、迭代规划锁定范围时。触发时点由团队约定，关键是选择需求内容已经稳定、可以对外承诺的时刻。
纳入条件。进入基线的需求需要具备评审与确认状态。通常要求需求已完成评审、评审意见已闭环、验收标准已明确，并且需求负责人已确认内容。状态不满足的需求应先补齐再纳入，避免基线中混入未定稿内容。
标识与版本记录。建立基线时，为基线分配唯一标识，例如“基线 BL-2024-03”或按项目加序号的命名方式，同时记录建立时间、建立人、纳入的需求清单及每条需求的版本号。基线标识应能被后续的变更申请、评审记录和发布说明引用。
生效后的锁定与变更入口。基线生效后，基线内的需求内容进入受控状态：直接编辑受到限制，修改需要通过变更申请入口发起，由指定角色评审后决定是否接受。锁定的是基线快照，需求本身仍可继续演进，只是演进过程要留下记录。
在需求状态与变更记录需要统一管理的场景中，ONES 的 ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯。团队可以把基线建立作为需求状态流转中的一个节点，让基线标识与需求版本、变更记录相互关联，减少靠表格手工维护基线清单带来的遗漏。
基线之后需求变更如何被记录和批准
基线建立后，需求变更的处理围绕比较、评估、批准和形成新基线四个动作展开。
差异比较。变更申请提出后，第一步是把拟修改的内容与基线内容对照，明确改了哪些字段、涉及哪些需求条目、是新增、修改还是删除。比较的对象是基线快照，而不是当前最新草稿，这样才能看清本次变更相对已确认承诺的增量。
影响评估。评估对象包括受影响的关联需求、下游设计任务、测试用例、接口约定和交付计划。评估的深度与变更规模匹配：字段级的小修改可以快速评估，涉及验收标准或范围调整的变更则需要相关角色共同确认。在 ONES 的数字线程中，某个需求发生变化时，可以沿关联关系分析受影响的任务、测试和交付内容，同时保留过程追踪和审计依据，这一能力依赖需求与任务、测试、交付内容之间已建立关联关系。
申请与批准记录。变更申请应记录申请人、申请时间、变更内容、变更原因、影响评估结论和审批意见。批准记录与基线标识关联留存，形成“基线—变更申请—审批—新内容”的完整链条，便于后续回溯某条需求为何从 A 变成 B。
新基线或新版本的形成。变更被批准并实施后，团队可以选择建立新基线，把变更后的需求内容固定为下一个参照点；也可以在当前基线之上累积变更记录，待达到约定节点再统一建立新基线。两种方式都要求基线标识可追溯，避免出现“基线内容被悄悄覆盖”的情况。
需求基线与需求版本、发布版本的区别
这三个概念经常被混用，用同一组维度对照可以看清差异。
对比维度
需求基线
需求版本
发布版本
跨资产配置基线
固定对象
一组已确认需求及其版本、状态、属性
单条需求的内容演进记录
一次对外交付的内容集合
代码、配置、环境等配置项
回答的问题
我们在某个时点确认了什么
这条需求改过几次、每次改了什么
这次交付包含什么、何时可用
某个时点的技术资产状态是什么
范围粒度
需求集合级
单条需求级
交付物级
配置项级
典型用途
变更比较与批准参照
追溯单条需求历史
发布规划与对外说明
构建、部署与回滚
需求基线与需求版本的关系是集合与个体的关系：基线引用多条需求的特定版本，需求版本记录单条需求的演进。需求基线与发布版本的关系是输入与输出的关系：基线中的需求是发布规划的候选内容，但发布版本还包含排期、交付顺序和对外命名等基线不涉及的信息。需求基线与跨资产配置基线的区别在于对象不同：前者管需求，后者管技术资产，两者可以配合使用，但不能互相替代。
一个具体例子与常见误解
假设一个团队在开发报销系统。需求评审通过后，团队把“差旅报销单提交”“审批流配置”“发票影像上传”三条需求纳入基线 BL-01，记录各自版本为 V1.0，状态为已确认。两周后，业务方提出发票影像上传需要支持批量上传，团队发起变更申请，对照 BL-01 发现该需求验收标准需要修改，评估后确认影响上传测试用例和接口文档，审批通过后将需求版本更新为 V1.1，并在约定节点建立 BL-02。整个过程里，BL-01 的内容始终可查，任何人问“最初确认的验收标准是什么”，都能从基线找到答案。
围绕这个例子，有三类常见误解值得澄清。
误解一：建立基线就是冻结需求、不再允许变更。基线锁定的是快照，不是需求本身。需求仍可通过变更申请修改，基线的作用是让每次修改都有比较起点和批准记录。把基线理解为“变更的参照点”比理解为“变更的禁止线”更准确。
误解二：基线等于发布版本。基线只说明哪些需求在某个时点被确认，不说明这些需求何时交付、以什么顺序交付、对外版本号是什么。发布版本需要另行规划，基线是它的输入之一。
误解三：基线覆盖所有配置项。需求基线只固定需求对象。代码、构建脚本、环境配置的版本固定属于跨资产配置与基线管理，需要单独建立配置基线。两类基线配合，才能同时回答“需求确认了什么”和“技术资产处于什么状态”。
把定义、范围、建立机制和变更处理连起来看，需求基线的价值在于给变更管理一个稳定的比较起点。团队在约定时点建立基线、在变更时对照基线评估影响、在批准后留存记录并适时形成新基线，需求演进的过程就具备了可追溯的结构。ONES 的 ALM 方案覆盖需求、基线、版本、变更、测试与发布，以数字线程贯通这些环节，支撑影响分析、过程追溯和合规审计，适合需要把基线管理与需求状态、变更记录放在同一体系中维护的团队参考。
常见问题
需求基线建立后，需求还能修改吗？
可以修改。基线锁定的是建立时点的需求快照，需求本身仍可继续演进。修改需要通过变更申请入口发起，由指定角色评审后决定是否接受，变更内容、影响评估结论和审批意见与基线标识关联留存。基线的作用是提供比较起点和批准记录，让每次修改都能看清相对已确认承诺改了什么。
一个项目需要建立几个需求基线？
没有统一数量要求，取决于确认节奏和变更风险。常见做法包括：在需求评审通过、项目进入开发前建立一次基线；按模块分批建立多个基线；在重大变更批准后建立新基线。基线数量多，参照点更细，维护成本也更高；数量少则比较粒度更粗。团队可以按项目范围划定基线范围，把核心需求纳入基线，辅助性需求留在基线外继续细化。
需求基线与配置基线需要同时建立吗？
两者对象不同，可以配合使用。需求基线固定需求条目及其版本、状态和关键属性；配置基线固定代码、构建脚本、环境配置等配置项。需求基线回答“需求确认了什么”，配置基线回答“技术资产处于什么状态”。是否需要同时建立，取决于项目对需求追溯和技术资产追溯的要求，两类基线不能互相替代。
变更被批准后，是立即建立新基线还是累积一段时间再建？
两种方式都可行，取决于团队的确认节点安排。变更批准并实施后立即建立新基线，参照点更新及时，基线数量会增加；在当前基线之上累积变更记录，待达到约定节点（如迭代结束、里程碑评审）再统一建立新基线，基线数量少，但期间需要保证变更记录完整可查。无论哪种方式，都要求基线标识可追溯，避免基线内容被覆盖。
需求基线能直接作为发布范围的依据吗？
基线可以作为发布规划的输入，但不能直接等同于发布范围。基线说明哪些需求在某个时点被确认，发布版本还需要确定交付哪些需求、以什么顺序交付、对外版本号如何命名，这些属于研发版本与发布管理。团队通常从基线中的需求里挑选发布候选内容，再结合排期和交付条件形成发布版本。