目录
Toggle
要点总览（TL;DR）需求基线的准确定义需求基线包括什么、不包括什么基线如何建立并约束后续变更需求基线、需求版本与发布版本的区别一个具体例子与常见误解常见问题需求基线建立后，如果变更申请被驳回，原来的基线需要调整吗？一个项目里可以同时存在多个需求基线吗？需求基线需要和测试用例、设计文档一起冻结吗？基线之间的差异比较应该关注哪些内容？小团队也需要建立需求基线吗？
需求基线是团队在某个确认节点冻结下来的一组需求版本，作为后续修改、评审和验收的共同参照。它记录“当时被批准的需求内容”，包括需求条目、版本号、状态和批准记录。理解需求基线，关键要弄清它冻结什么、边界在哪里、建立后需求还能不能改，以及它与需求版本、发布版本的区别。
要点总览（TL;DR）
需求基线是一组需求在评审或确认通过后被正式固定下来的版本集合，记录需求条目、版本号、状态和批准记录，作为后续变更与验收的共同参照。
需求基线只锁定需求对象；同时冻结设计、代码、测试用例等多配置项属于配置基线，对外交付的内容组合与上线安排属于发布版本。
基线建立后需求仍可修改，但要经过修改申请、影响分析、评审批准，再更新需求版本并重新建立基线，旧基线保留可查。
需求版本记录单条需求的迭代历史，需求基线是一组需求版本的确认快照，发布版本面向交付与上线，三者可以关联但不能互相替代。
把基线理解为可追溯的确认点，团队既能保持需求范围稳定，也能让合理变更按流程有序发生。
需求基线的准确定义
需求基线（Requirement Baseline）是指一组需求在通过评审或确认后，被正式固定下来的版本集合。它回答的问题是：在某个时间点，团队批准的需求究竟是哪些、处于什么状态、由谁批准。此后发生的修改、验证和验收，都以这个固定版本作为比较起点。
拆开来看，需求基线包含四个关键要素：
冻结对象：被冻结的是需求条目及其版本，不是项目里的全部文档。设计文档、测试用例、代码等资产各有自己的版本管理方式，需求基线只锁定需求这一层。
冻结时点：基线对应一个明确的确认节点，例如需求评审通过、阶段门评审完成或合同需求确认。时点决定了“以哪一版为准”。
参照作用：基线是后续变更申请的比较基准，也是验收时判断“交付内容是否符合当初批准的需求”的依据。
可追溯记录：基线需要保留版本号、状态和批准记录，使后来的人能够还原当时批准了什么、依据是什么。
需要强调的是，基线冻结的是“需求内容的一个版本状态”，它本身不是一条需求，也不是一个发布节点。把基线理解为“需求在这一刻的集体快照”，比理解为“需求被锁死”更准确。
需求基线包括什么、不包括什么
划定范围能避免基线概念被泛化。需求基线通常包含以下内容：纳入基线范围的需求条目清单、每条需求的版本号、需求当前状态（如已批准）、以及批准人与批准时间等记录。部分团队还会记录基线编号、基线说明和纳入基线的需求范围界定。
以下内容通常不属于需求基线的范围：
跨资产配置基线：当基线需要同时锁定需求、设计、代码、测试用例等多个配置项时，属于配置管理中的配置基线范畴，归研发配置与基线管理处理。需求基线只覆盖需求对象。
发布版本与上线计划：发布版本描述的是对外交付的内容组合、发布时间和上线安排，归研发版本与发布管理。需求基线可以成为发布版本的输入，但两者管理对象不同。
项目计划与资源安排：进度、人力、预算等计划信息不进入需求基线。
可以用一张归属对照来理解边界：需求条目、需求版本号、需求状态、需求批准记录属于需求基线；多配置项的统一冻结属于配置基线；交付内容组合与上线时间属于发布版本。边界清晰后，团队在讨论“基线”时就不会把不同管理对象混在一起。
基线如何建立并约束后续变更
需求基线的建立通常发生在需求经过评审并获得批准的节点。常见触发点包括：需求评审会通过、阶段里程碑评审完成、合同或订单需求确认。建立动作本身包括三步：确定纳入基线的需求范围，核对每条需求的版本与状态，记录批准信息并生成基线标识。
基线建立后，需求仍然可以修改，但修改需要走受控流程：
提出修改申请：说明要改哪条需求、改什么、为什么改，关联提出人与提出时间。
做影响分析：评估该需求变更对关联任务、测试用例、交付内容、进度和成本的影响，形成分析结论。
评审与批准：由相应角色评审变更申请和影响分析，给出批准、驳回或延后处理的结论，并留下批准记录。
形成新基线版本：变更被批准并实施后，更新需求版本，重新建立基线。新基线保留与旧基线的关联，旧基线作为历史记录继续可查。
这套机制的价值在于：每次变更都有申请、有分析、有批准、有记录，验收时可以对照基线判断交付是否偏离批准范围。旧基线不被覆盖，使追溯成为可能。
在工具承载层面，ONES 的 ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯。当某个需求发生变化时，可以沿关联关系分析受影响的任务、测试和交付内容，同时保留过程追踪和审计依据；这一能力以需求与任务、测试、交付内容已建立关联关系为前提。方案还将评审节点、交付物模板和过程数据沉淀为可复用资产，便于在项目执行中持续落实流程要求。具体操作路径与权限配置需按实际项目确认。
需求基线、需求版本与发布版本的区别
这三个概念经常被混用，但管理对象和用途不同。需求版本描述单条需求的迭代历史；需求基线是一组需求版本在确认时点的快照；发布版本面向对外交付与上线安排。
维度
需求版本
需求基线
发布版本
管理对象
单条需求
一组需求及其版本
一次交付的内容组合
核心用途
记录该需求的修改历史
作为变更与验收的参照
组织交付、上线与发布说明
形成时点
每次需求内容修改后
需求评审或确认通过时
交付计划确定与上线前
变化方式
版本号递增，保留历史
变更批准后重新基线，旧基线保留
按发布计划调整范围与时间
归属主题
需求变更与版本管理
需求变更与版本管理
研发版本与发布管理
理解差异的一个简单判断：问“这条需求改过几次”，看需求版本；问“这次批准的需求范围是什么”，看需求基线；问“这一版对外交付了什么、什么时候上线”，看发布版本。三者可以关联，但不能互相替代。
一个具体例子与常见误解
以下为演示情景，用于说明基线建立与重新基线的过程，不代表真实项目。某团队在需求评审会上确认了 20 条需求，逐条核对版本与状态后建立基线 B1.0，记录批准人与批准日期。两周后，客户提出其中一条需求需要调整。团队提交修改申请，分析该需求关联的 3 个开发任务和 5 条测试用例受影响，评审后批准变更。需求更新为新的版本，团队重新建立基线 B1.1，并保留 B1.0 作为历史记录。验收时，团队对照 B1.1 确认交付范围，同时可以回溯 B1.0 到 B1.1 之间发生了什么变更、依据是什么。
常见误解有两个：
误解一：建立基线后需求就不能改了。基线约束的是变更方式，不是禁止变更。需求仍可修改，只是需要经过申请、影响分析和批准，并形成新的基线版本。禁止修改会让基线变成僵化工具，反而促使团队绕过流程。
误解二：基线覆盖所有研发资产。需求基线只锁定需求对象。当需要同时冻结设计、代码、测试用例等多个配置项时，属于配置基线的管理范围；对外交付的内容组合与上线安排则属于发布版本。把三者混为一谈，会导致职责不清和追溯断点。
把基线当作“可追溯的确认点”而非“冻结一切的闸门”，团队才能在保持需求稳定的同时，让合理变更有序发生。
常见问题
需求基线建立后，如果变更申请被驳回，原来的基线需要调整吗？
通常不需要。变更申请被驳回意味着需求内容维持原状，原基线继续有效，驳回结论和理由作为记录留存即可。只有变更被批准并实际修改了需求内容，才需要更新需求版本并重新建立基线。若驳回时附带了“延后处理”的结论，可以在后续评审节点重新提出，此时仍以当前有效基线作为比较起点。
一个项目里可以同时存在多个需求基线吗？
可以。常见做法是按阶段或按需求范围分别建立基线，例如需求评审通过后建立第一版基线，某个里程碑确认后建立新的基线，或者按子系统、按合同范围分别建立。关键在于每条基线都有明确的纳入范围和标识，避免出现“哪条需求属于哪条基线”说不清的情况。基线数量增多时，建议在命名和说明中体现阶段或范围信息，便于追溯。
需求基线需要和测试用例、设计文档一起冻结吗？
需求基线本身只锁定需求对象。如果团队需要把需求、设计、测试用例等多个配置项在同一时点统一冻结，这属于配置基线的管理范围，归研发配置与基线管理处理。实践中两者可以配合使用：先建立需求基线确定批准的需求范围，再在配置管理层面把相关资产纳入统一冻结。是否需要这样做，取决于项目的合规要求、交付方式和变更频率。
基线之间的差异比较应该关注哪些内容？
差异比较通常关注三类信息：需求条目的增减，即哪些需求新纳入或移出基线范围；单条需求的内容变化，即同一需求在两个版本之间改了什么；以及变更的依据，即对应的修改申请、影响分析结论和批准记录。只比较内容差异而不看批准记录，容易在验收或审计时说不清变更是否经过授权。比较结果可以作为阶段评审和交付确认的输入。
小团队也需要建立需求基线吗？
是否建立基线取决于需求变更的频率和追溯要求，与团队规模没有必然关系。需求相对稳定、交付周期短、参与方少的项目，可以用轻量方式记录确认时点的需求版本和批准信息；需求变更频繁、涉及多方验收或合规要求的项目，建立正式基线更有价值。无论采用哪种方式，保留“当时批准了什么、后来改了什么、依据是什么”的记录，是基线管理的核心目的。