需求规格说明书模板的核心是“一条需求一行、字段固定、状态可追踪”：主表记录需求本身，变更记录表留下修改痕迹，待确认问题表收拢尚未定论的事项。填写时建议先写验收标准，再回填功能描述与处理规则，让每条需求从写下第一笔起就具备可验证的终点。下文提供三张可直接复制的空白表、逐字段填写口径、必填与选填清单，以及一条填满的完整示例；模板字段也可在 ONES 等协作工具中落地为工作项属性，便于后续跟踪。
要点总览（TL;DR）
- 模板由三张表组成：需求主表（一条需求一行）、变更记录表、待确认问题表，按“先建主表、再记变更、后跟问题”的顺序使用。
- 主表共15个字段，其中需求编号、需求名称、来源、优先级、需求类型、功能描述、验收标准、状态、负责人、版本为必填；输入与前置条件、处理规则、输出与后置条件、异常与边界、关联需求为条件必填。
- 填写顺序建议先写验收标准，再回填功能描述与处理规则，让每条需求从写下第一笔起就有可验证的终点。
- 无法填写的字段统一标注“待确认”并登记到待确认问题表，让空缺本身成为可追踪事项。
- 模板可按项目类型增删字段，模板版本与单条需求版本分开维护；需求数量增多后可把字段映射为协作工具中的工作项属性。
可直接复制的需求规格说明书空白模板
三张表按“先建主表、再记变更、后跟问题”的顺序使用。主表是需求规格说明书的主体，每条需求占一行；变更记录表在主表字段发生修改后追加一行；待确认问题表在评审、开发、测试过程中随时登记，问题关闭后在表中标注结论，不删除原行。复制到文档工具时保留表头，空白行按实际需求数量增删。
表一：需求主表
| 需求编号 | 需求名称 | 来源 | 优先级 | 需求类型 | 功能描述 | 输入与前置条件 | 处理规则 | 输出与后置条件 | 异常与边界 | 验收标准 | 关联需求 | 状态 | 负责人 | 版本 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表二：变更记录表
| 变更编号 | 关联需求编号 | 变更字段 | 变更前内容 | 变更后内容 | 变更原因 | 提出人 | 确认人 | 变更日期 | 影响范围 |
|---|---|---|---|---|---|---|---|---|---|
表三：待确认问题表
| 问题编号 | 关联需求编号 | 问题描述 | 待确认方 | 提出人 | 提出日期 | 期望回复日期 | 结论 | 状态 |
|---|---|---|---|---|---|---|---|---|
每个字段填什么：字段说明与取值口径
字段说明的作用是让不同的人填出同一种结构。下表逐字段给出含义、填写口径和示例值，示例值取自后文完整示例，便于对照。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 需求编号 | 需求的唯一标识 | 按“项目缩写-序号”编制，一经分配不再复用 | ORD-012 |
| 需求名称 | 一句话概括需求 | 动宾结构，不超过20字，避免“优化”“完善”等模糊词 | 订单超时未支付自动取消 |
| 来源 | 需求由谁、通过什么渠道提出 | 写清提出方与渠道，如客户反馈、运营提报、合规要求 | 客服部转客户反馈 |
| 优先级 | 需求的相对重要程度 | 建议四级：P0必须本期交付、P1本期尽量交付、P2可延后、P3暂不排期 | P1 |
| 需求类型 | 需求的性质分类 | 建议取值：新增功能、功能优化、缺陷修复、合规调整、体验改进 | 新增功能 |
| 功能描述 | 系统要做什么 | 描述目标与范围，写“系统应……”，不写实现细节 | 系统应在订单超过支付时限后自动取消订单并释放库存 |
| 输入与前置条件 | 触发需求的数据与前提 | 列出必要输入项和必须满足的前置状态 | 订单状态为待支付，且已超过支付时限 |
| 处理规则 | 系统按什么逻辑处理 | 按步骤或条件分支写，覆盖正常路径与判断依据 | 1. 校验订单状态；2. 判断是否超时；3. 超时则取消并释放库存；4. 记录取消时间 |
| 输出与后置条件 | 处理完成后的结果与状态 | 写清输出内容、状态变化和通知对象 | 订单状态变为已取消，库存回补，向用户发送取消通知 |
| 异常与边界 | 异常情况和临界值如何处理 | 列出可预见的异常分支及边界取值 | 支付时限恰好等于阈值时按已超时处理；库存释放失败时记录日志并告警 |
| 验收标准 | 判定需求完成的依据 | 写成可观察、可复现的条目，每条对应一个验证动作 | 见下文验收标准写法 |
| 关联需求 | 与本需求有依赖或冲突的需求 | 填写需求编号，注明关系类型（依赖、冲突、替代） | ORD-008（依赖） |
| 状态 | 需求当前所处阶段 | 建议取值：草稿、待评审、已确认、开发中、待验收、已完成、已取消 | 已确认 |
| 负责人 | 对需求内容负责的人 | 填写需求负责人姓名，不填团队名 | 李敏 |
| 版本 | 需求内容的修订版本 | 从V1.0起，内容实质修改后递增，与变更记录表对应 | V1.1 |
功能描述与处理规则的区别
功能描述回答“做什么”，用一两句话界定目标与范围，读者据此判断需求是否被理解正确；处理规则回答“怎么做”，按步骤或条件分支展开系统行为，读者据此判断逻辑是否完整。两者分开写的好处是：范围变化时改功能描述，逻辑调整时改处理规则，变更记录能精确指向被修改的部分。
验收标准的可验证写法
验收标准要能被测试人员直接转化为用例。推荐句式是“给定某条件，执行某操作，得到某可观察结果”。例如：“给定一笔待支付订单已超过支付时限，系统自动取消该订单，订单状态显示为已取消，库存数量回补1件，用户收到取消通知。”避免写“系统运行正常”“体验流畅”这类无法判定的表述。一条需求通常配2至5条验收标准，覆盖正常路径和主要异常路径。
必填与选填：哪些字段不能空
字段能否留空，取决于它是否影响需求的判定与追踪。必填字段缺失会让需求无法评审或无法验收；条件必填字段在特定情形下必须填写；选填字段用于补充信息，缺失不影响需求成立。
| 档位 | 字段 | 理由或触发条件 |
|---|---|---|
| 必填 | 需求编号、需求名称、来源、优先级、需求类型、功能描述、验收标准、状态、负责人、版本 | 缺少任一项，需求无法被唯一识别、排序、评审或验收 |
| 条件必填 | 输入与前置条件、处理规则、输出与后置条件 | 需求涉及系统行为或数据处理时必填；纯文案、纯配置类需求可简写，但仍需说明预期结果 |
| 条件必填 | 异常与边界 | 需求涉及金额、库存、权限、时限等敏感逻辑时必填 |
| 条件必填 | 关联需求 | 存在依赖、冲突或替代关系时必填，无关联时填“无” |
| 选填 | 变更记录表、待确认问题表 | 首次提交时可暂空，发生变更或出现待定事项后必须登记 |
字段空缺时的标注方式
确实无法填写的字段，不要留白，统一标注“待确认”并在待确认问题表中登记对应问题编号，例如在异常与边界栏写“待确认（Q-003）”。这样空缺本身成为可追踪的事项，评审时能一眼看出哪些内容尚未定论。已经确认不适用的情况，填写“不适用”并简述原因，与“待确认”区分开。
填写示例：一条完整需求从空白到填满
以下示例演示一条订单类需求如何填满主表，并给出对应的变更记录与待确认问题。示例中的业务背景为演示情景，字段取值可按实际项目替换。
主表示例
| 字段 | 填写内容 |
|---|---|
| 需求编号 | ORD-012 |
| 需求名称 | 订单超时未支付自动取消 |
| 来源 | 客服部转客户反馈 |
| 优先级 | P1 |
| 需求类型 | 新增功能 |
| 功能描述 | 系统应在订单超过支付时限后自动取消订单并释放库存，减少无效占用 |
| 输入与前置条件 | 订单状态为待支付，且下单时间距当前时间超过支付时限（默认30分钟） |
| 处理规则 | 1. 定时任务扫描待支付订单；2. 判断是否超过支付时限；3. 超时则取消订单并释放库存；4. 记录取消时间与取消原因；5. 向用户发送取消通知 |
| 输出与后置条件 | 订单状态变为已取消，库存数量回补，用户收到取消通知，系统留存取消记录 |
| 异常与边界 | 支付时限恰好等于30分钟时按已超时处理；库存释放失败时记录日志并触发告警，订单状态保持待支付等待人工处理 |
| 验收标准 | 1. 给定待支付订单超过30分钟未支付，系统自动取消订单，状态显示已取消；2. 取消后库存数量回补1件；3. 用户收到取消通知；4. 库存释放失败时产生告警记录 |
| 关联需求 | ORD-008（依赖：库存回补接口） |
| 状态 | 已确认 |
| 负责人 | 李敏 |
| 版本 | V1.1 |
变更记录表示例
| 变更编号 | 关联需求编号 | 变更字段 | 变更前内容 | 变更后内容 | 变更原因 | 提出人 | 确认人 | 变更日期 | 影响范围 |
|---|---|---|---|---|---|---|---|---|---|
| CHG-005 | ORD-012 | 处理规则、验收标准 | 支付时限固定30分钟 | 支付时限默认30分钟，可按业务线配置 | 运营提出不同品类需要不同时限 | 王磊 | 李敏 | 2025-03-12 | 定时任务配置、验收用例第1条 |
待确认问题表示例
| 问题编号 | 关联需求编号 | 问题描述 | 待确认方 | 提出人 | 提出日期 | 期望回复日期 | 结论 | 状态 |
|---|---|---|---|---|---|---|---|---|
| Q-003 | ORD-012 | 库存释放失败时是否需要重试，重试次数上限是多少 | 库存服务负责人 | 李敏 | 2025-03-10 | 2025-03-14 | 重试3次，仍失败则告警并转人工 | 已关闭 |
对照字段说明表可以看到：功能描述只写目标，处理规则按步骤展开，验收标准逐条对应处理规则中的关键动作，异常与边界覆盖了临界值和失败分支。变更记录中的“变更字段”指向主表具体字段，待确认问题的结论回填后，主表相应内容同步更新，版本号随之递增。
模板的调整与维护方法
模板需要随项目类型和团队协作方式调整，但调整本身也要留痕，否则字段会越加越多、口径越改越乱。以下清单覆盖裁剪、版本维护、评审归档和工具落地四个动作。
按项目类型增删字段
- 涉及外部接口或跨系统调用的需求，增加“接口约定”字段，记录接口名称、调用方向和数据格式。
- 涉及合规或审计的需求，增加“合规依据”字段，注明条款出处。
- 纯内部工具或一次性活动类需求，可合并“输入与前置条件”和“输出与后置条件”为一栏“前后置说明”，减少填写负担。
- 删减字段前确认该字段是否被验收或变更流程引用，被引用的字段保留或改为条件必填。
模板版本号与变更记录
模板本身维护独立版本号，如模板V1.0、V1.1，并在模板首页附一张模板变更说明，记录每次调整的字段、原因和生效日期。需求主表中的“版本”字段记录单条需求的修订，两者分开管理：模板版本变化影响所有新需求，需求版本变化只影响该条需求。
评审与归档时的检查点
- 评审前检查必填字段是否齐全，空缺字段是否已登记待确认问题。
- 评审中核对验收标准能否逐条转化为测试用例。
- 归档前确认变更记录与主表版本号一致，已关闭的待确认问题结论已回填主表。
在协作工具中落地为工作项字段
当需求数量增多、跨角色协作频繁时，可把主表字段映射为协作工具中的工作项属性，把状态字段映射为工作流状态，让需求从草稿到验收的流转在系统中留痕。ONES 支持在 Wiki 中使用页面模板库一键创建制式化文档，页面组可关联项目，使需求与文档互相对应；文档记录所有页面版本，可随时查看与回滚。这样模板既保留了统一结构，又能在评审、变更和验收环节被持续追踪。
常见问题
需求规格说明书和需求文档、需求列表有什么区别？
需求规格说明书侧重把单条需求的完整规格写清楚，包括输入与前置条件、处理规则、输出与后置条件、异常与边界和验收标准，读者据此可以判断逻辑是否完整、能否验收。需求列表通常只记录名称、优先级和状态，用于排期和跟踪；需求文档的范围更宽，可能包含背景、目标、范围说明等章节。三者可以并存：需求列表做索引，需求规格说明书做单条需求的详细规格，需求文档承载整体背景。
需求数量很少时，还需要维护变更记录表和待确认问题表吗？
建议保留这两张表的结构，首次提交时可以暂空。需求数量少时，变更往往靠口头同步，一旦人员变动或时间拉长，修改原因和确认人就难以追溯；待确认问题如果只散落在聊天记录里，评审时容易遗漏。可以简化填写粒度，例如变更记录只记关键字段的修改，待确认问题只登记影响验收的事项，但表结构本身不建议删除。
验收标准应该由谁写、什么时候写？
验收标准通常由需求负责人主笔，测试人员和业务方参与确认，因为测试人员需要据此转化为用例，业务方需要确认结果符合预期。时间上建议在需求评审前完成初稿，与功能描述一起提交评审；如果评审时才发现验收标准写不出来，往往说明需求范围或处理规则还没想清楚。一条需求配2至5条验收标准，覆盖正常路径和主要异常路径即可，不必穷举所有组合。
模板字段和协作工具里的工作项字段如何对应？
常见做法是把主表中需要筛选、排序和统计的字段映射为工作项属性，例如优先级、需求类型、状态、负责人、版本；把功能描述、处理规则、验收标准等长文本放入描述字段或子页面；变更记录和待确认问题可以作为关联记录或独立工作项类型管理。状态字段映射为工作流状态后，需求从草稿到验收的流转会在系统中留痕。ONES Wiki 提供页面模板库，可一键创建制式化文档，页面组可关联项目，使需求与文档互相对应，文档记录所有页面版本，可随时查看与回滚。
模板调整后，已经写好的需求要不要按新模板重填？
通常不需要整体重填。可以在模板变更说明中注明生效范围：新提交的需求按新版本填写，已确认或开发中的需求保持原结构，仅在发生变更时顺带补齐新增字段。如果新增字段影响验收判定，例如增加了合规依据，则需要在归档前对相关需求补充填写，并在变更记录中登记。这样既避免大规模返工，也保证关键信息不缺失。
