敏捷迭代里继续保留需求规格说明书，关键在“留追溯、去重述”：把需求标识与来源、目标与验收标准、范围与优先级、关键业务规则与约束、依赖与假设、变更记录六类章节留下，把大段背景、完整界面字段清单、详细设计、逐条测试用例和审批签字页交给原型、任务卡或测试系统承载。这样文档仍能回答“为什么做、做到什么算完成、改动过什么”，维护量却与迭代节奏匹配。
要点总览（TL;DR）
- 敏捷迭代保留需求规格说明书的核心判断是“留追溯、去重述”：每个保留章节都应能回答这条需求为什么做、做到什么算完成、改动过什么。
- 建议保留六类章节：需求标识与来源、目标与验收标准、范围与优先级、关键业务规则与约束、依赖与假设、变更记录。
- 可合并或删除的内容包括大段背景叙述、完整界面与字段清单、详细设计、逐条测试用例和审批签字页，前提是原型、任务卡或测试系统已经承载这些信息。
- 裁剪后的模板要嵌入需求提出、迭代评审、开发交付、变更四个节点，每次只补当前阶段需要的信息，避免迭代末期集中补文档。
- 效果验证用改进前后各三到五个迭代做观察对比，关注文档填写耗时、变更遗漏数和验收返工次数，属于团队自评口径。
当前模板在敏捷迭代中的典型做法与目标
多数团队沿用的需求规格说明书模板来自瀑布或阶段评审时期，章节通常包括：文档修订记录、项目背景与业务概述、术语表、干系人与审批签字、功能需求清单、界面与字段说明、业务规则、非功能需求、数据与接口设计、测试用例、上线与培训安排。这套结构在一次性交付、跨部门签字确认的项目里便于集中评审，但章节数量往往在二十个上下，单份文档动辄十几页。
进入两周或三周一个迭代的节奏后，团队保留这份文档的目标已经收窄为三件事。第一是需求追溯：某个功能上线后，能查到它来自哪条业务诉求、由谁提出、关联哪个迭代和任务卡。第二是验收依据：开发和测试对“做到什么算完成”有同一份文字依据，减少口头确认带来的偏差。第三是变更留痕：需求在迭代中调整时，能看出改了什么、为什么改、影响哪些任务。
建立现状基线时，建议直接统计现有模板的章节数和实际填写率。做法是把模板章节逐条列出，回看最近三到五个迭代的文档，标记每章是“每次填写”“偶尔填写”还是“长期空白”。常见结果是背景叙述和术语表填写率较高但少有人回看，界面字段说明与原型重复维护，测试用例章节与测试系统各写一份。这份清单不需要精确到百分比，能看出哪些章节在消耗时间却不承担追溯职责即可，它是后续裁剪的对照依据。
哪些章节在敏捷迭代中成为维护负担
负担章节的共同特征是：内容本身有价值，但价值已经由别的载体承担，文档里再写一遍就形成双份维护。识别时按“可删”和“需转移承载”两类区分，前者指信息在迭代语境下不再需要，后者指信息仍需要，只是换一个地方存放。
大段背景与业务叙述属于可压缩类。传统模板要求写清行业背景、市场机会和组织现状，这些内容在立项阶段有用，进入迭代后与当前要交付的功能脱节。团队每次复制上一版背景再略作修改，读者却只关心本次迭代的目标和验收口径。处理方式是把背景压缩成一段目标说明，保留“这次解决什么问题”即可。
完整界面、字段清单与详细设计属于需转移承载类。原型工具里的页面和交互已经是最新版本，文档里再维护一份字段表格，原型一改文档就滞后。详细设计中的表结构、接口定义、类图更适合放在技术设计文档或任务卡描述里，由开发在实现时维护。文档保留指向原型的链接和关键约束说明，字段级细节不在需求文档中重复。
逐条测试用例同样需要转移。测试系统管理用例的版本、执行记录和缺陷关联，需求文档里再列一遍用例，等于两套数据各自演进。文档只需保留验收标准，测试工程师据此在测试系统中编写用例，两边通过需求标识对应。
审批与签字流转记录在迭代评审中基本失效。敏捷迭代的确认动作发生在迭代计划会和评审会上，以口头达成一致加任务卡状态变更体现，纸质或电子签字页既拖慢流程，也无法反映迭代中的多次调整。修订记录章节可以保留，但记录的是内容变更，而非签字人列表。
这里有一个常见误区：把章节数量等同于追溯完整。追溯是否完整，取决于每条需求能否从来源走到验收、从变更走到任务卡，与文档写了多少章没有直接关系。章节越多，填写负担越重，反而容易出现关键字段空着、边缘章节凑字的情况。
保留章节清单与删减合并建议
裁剪的原则是每个保留章节都能回答一个追溯问题。下表给出可直接套用的取舍方案，团队可按自身情况微调，但建议保留六类核心章节的追溯职责不缺失。
| 处理方式 | 章节 | 承担的追溯职责 |
|---|---|---|
| 保留 | 需求标识与来源 | 这条需求是谁提出的、来自哪个业务诉求或工单，便于反向查询 |
| 保留 | 目标与验收标准 | 为什么做、做到什么算完成，是开发自测和测试用例编写的共同依据 |
| 保留 | 范围与优先级 | 本次迭代做什么、不做什么，优先级决定排期取舍 |
| 保留 | 关键业务规则与约束 | 影响实现方式的规则、合规要求和性能约束，避免开发自行假设 |
| 保留 | 依赖与假设 | 依赖哪些外部系统或团队、基于什么假设成立，风险发生时便于定位 |
| 保留 | 变更记录 | 改动过什么、何时改、影响哪些任务卡，形成变更链路 |
| 合并 | 背景与目标 | 合并为一段目标说明，保留问题背景，删除行业与市场叙述 |
| 合并 | 界面与字段清单 | 以原型链接替代，文档只写关键交互约束 |
| 删除 | 详细设计 | 移交技术设计文档或任务卡描述 |
| 删除 | 逐条测试用例 | 由测试系统承载，通过需求标识与验收标准对应 |
| 删除 | 审批签字页 | 以迭代评审结论和任务卡状态替代 |
保留章节的写法也要控制篇幅。需求标识建议采用“项目前缀加序号”的稳定编号，来源写清提出人和原始诉求链接；验收标准写成可判断的条目，避免“体验流畅”这类无法核对的表述；业务规则只写影响实现的关键几条，通用规则引用已有规范文档。变更记录按时间倒序追加，每条写明变更内容、原因和关联任务卡编号，这样从文档能直接跳到执行侧。
裁剪后的模板如何嵌入迭代流程
轻量模板能否运转，取决于填写动作是否嵌进团队已有的会议和工具节点。把填写分散到四个节点，每次只补当前阶段需要的信息，避免迭代末期集中补文档。
| 节点 | 填写与更新动作 | 完成标志 |
|---|---|---|
| 需求提出 | 填写需求标识、来源、目标与验收标准初稿 | 需求进入待办列表，标识唯一且可检索 |
| 迭代评审 | 确认范围与优先级，补充依赖与假设，验收标准与团队达成一致 | 需求被规划进迭代，任务卡拆分完成 |
| 开发交付 | 按验收标准逐条核对，测试据此编写和执行用例 | 验收标准全部通过，缺陷闭环 |
| 变更发生 | 更新变更记录，同步调整任务卡和验收标准 | 变更记录与任务卡状态一致，影响范围已通知 |
在工具承载上，可以把需求文档与需求工作项放在同一项目空间里管理。ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档互相对应，团队在文档里维护目标、验收标准和变更记录，在执行侧用任务卡跟踪拆分和状态。ONES Wiki 的页面模板库可以一键创建制式化文档模板，把裁剪后的六类章节固化成模板，减少每次新建文档时的结构整理。文档实时同步并记录所有页面版本，支持随时查看与回滚，变更记录之外还有版本层面的兜底。
迭代计划会上，产品负责人按优先级把待办需求规划进迭代，与团队对验收标准达成一致后，设计、研发、测试人员用子任务拆分需求，后续处理和跟踪都在任务卡上进行。测试工程师依据验收标准编写用例，未通过的用例转为缺陷提交至项目并指派修复。这条链路里，需求文档承担的是目标、标准和变更的沉淀，任务卡和测试系统承担执行明细，两者通过需求标识和关联关系衔接。
适用前提、代价与效果验证
裁剪方案成立有两个前提。一是原型与任务卡能够承载界面和字段信息，团队已有稳定的原型维护习惯，原型链接在迭代内保持可访问；二是测试系统独立管理用例，用例与需求之间能通过标识对应。如果团队目前没有原型工具，或测试用例仍散落在文档和表格中，直接删除对应章节会造成信息丢失，应先补齐承载载体再裁剪。
需要付出的代价主要有三项。初期要统一链接规范，明确原型链接、任务卡编号、测试用例编号分别写在哪一章、用什么格式，否则关联关系会随人员变动而失效。变更记录习惯需要培养，迭代中改需求时同步追加记录，比事后补写更省力，但要求提出人和开发在变更发生时就有记录动作。模板切换本身也有磨合期，前几个迭代可能出现字段填写不全或旧习惯回潮，需要有人在迭代评审时抽查。
效果验证建议用改进前后各三到五个迭代做观察对比，口径由团队自定，属于内部自评，不构成对外承诺。可观察的指标包括：单份需求文档的填写耗时、需求变更遗漏数（变更发生后未同步到任务卡或验收标准的次数）、验收返工次数（因验收标准不清导致的返工）。对比时保持统计口径一致，例如都按同一项目、同一类需求统计，避免把迭代规模变化或人员调整带来的波动直接归因于模板裁剪。若指标没有改善，先检查前提是否满足、链接规范是否被执行，再判断章节取舍是否需要调整。
常见问题
团队没有稳定的原型维护习惯，还能直接删掉界面与字段清单章节吗？
不建议直接删。界面与字段清单章节可以删减的前提，是原型或任务卡已经能承载页面、交互和字段信息，并且迭代内保持可访问。如果原型工具尚未统一、原型更新滞后，删掉文档章节会让字段级信息失去唯一来源。
更稳妥的做法是先补齐承载载体：确定原型放在哪里、由谁维护、迭代内如何更新，再把文档中的字段表格改为原型链接加关键交互约束说明。过渡期可以保留一份精简字段表，等原型维护习惯稳定后再撤掉。
验收标准写到什么颗粒度，才能既支撑测试又不让文档变重？
验收标准建议写成可判断的条目，每条对应一个能被验证的结果，例如输入什么条件、系统应返回什么、异常时如何处理。避免“体验流畅”“性能良好”这类无法核对的表述。
颗粒度以测试工程师能据此编写用例、开发能据此自测为准，不必细到逐条测试步骤。测试步骤和用例数据放在测试系统里，文档只保留验收口径，两边通过需求标识对应。这样文档篇幅可控，测试侧仍有完整的执行明细。
变更记录由谁维护，迭代中频繁改需求时怎么避免漏记？
变更记录通常由需求提出人或产品负责人维护，开发在实现中发现规则变化时同步告知。关键是让记录动作发生在变更当时，而不是迭代结束补写。
可执行的做法是把变更记录与任务卡绑定：每次调整需求，先在文档变更记录中追加一条，写明变更内容、原因和关联任务卡编号，再同步修改验收标准或范围。迭代评审时抽查变更记录与任务卡状态是否一致，前几个迭代需要有人盯，形成习惯后漏记会明显减少。
需求文档和任务卡、测试用例之间的关联关系怎么保持不失效？
关联关系失效通常源于编号规则不统一或人员变动后无人接手。建议先统一链接规范：需求标识采用稳定的项目前缀加序号，文档中固定写明原型链接、任务卡编号和测试用例编号的填写位置与格式。
在工具层面，可以把需求文档与需求工作项放在同一项目空间管理。ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档互相对应；文档实时同步并记录所有页面版本，支持随时查看与回滚。关联规范加上版本兜底，人员变动时接手者能顺着标识找到执行侧记录。
裁剪模板后指标没有改善，应该先查什么？
先查前提是否满足，再判断章节取舍是否合理。常见原因是原型或测试系统尚未真正承载对应信息，团队删了章节却仍在别处重复维护；也可能是链接规范和变更记录习惯没有执行，导致追溯链路断开。
可以按顺序检查：原型链接在迭代内是否可访问、任务卡是否按验收标准拆分、变更发生后是否同步更新记录。若这些动作都已落地而指标仍无变化，再考虑调整保留章节的范围，例如补充某类业务规则说明或细化验收标准。对比时保持统计口径一致，避免把迭代规模或人员调整的波动直接归因于模板裁剪。
