需求规格说明书模板的填写顺序是：先写清文档标识与范围，再逐条写功能需求，补上非功能需求、接口与数据要求、假设与依赖，最后做可验证性检查。核心判断标准只有一条：每条需求都能单独编号、单独评审、单独验收；写不出验收标准的需求，说明还没写清。下面给出一份可直接复制的空白表格模板，配合字段说明、必填判定和一条完整填写示例，拿到就能照着填。需求条目后续进入工具承载时，可衔接ONES的需求管理方向。
要点总览（TL;DR）
- 填写顺序：文档信息与范围→功能需求逐条→非功能需求→接口与数据→假设与依赖→可验证性检查。
- 每条需求必须能单独编号、单独评审、单独验收；写不出验收标准，说明需求还没收敛。
- 必填核心字段为编号、名称、描述、验收标准、状态；功能需求另需来源，非功能需求另需度量方式。
- 字段暂时无法确定时写“待确认：具体问题”并登记到待确认问题表，不留空也不填猜测值。
- 模板按项目规模裁剪，字段增删记入修订记录，已开发需求沿用编写时的版本。
可直接复制的需求规格说明书空白模板
以下模板按“文档信息—修订记录—范围与目标—功能需求—非功能需求—接口与数据—假设与依赖”的顺序排列。使用时整表复制到文档或表格工具中，逐区填写；功能需求主表一行对应一条需求，编号不复用。
一、文档信息区
| 字段 | 填写内容 |
|---|---|
| 文档名称 | |
| 文档编号 | |
| 版本 | |
| 编写人 | |
| 评审人 | |
| 编写日期 | |
| 状态 | 草稿 / 评审中 / 已通过 / 已变更 |
二、修订记录表
| 版本 | 修订日期 | 修订人 | 修订内容摘要 | 评审结论 |
|---|---|---|---|---|
三、范围与目标区
| 项目 | 填写内容 |
|---|---|
| 背景 | |
| 目标 | |
| 范围内 | |
| 范围外 |
四、功能需求主表
| 需求编号 | 模块 | 需求名称 | 需求描述 | 输入 | 处理规则 | 输出 | 优先级 | 验收标准 | 来源 | 状态 |
|---|---|---|---|---|---|---|---|---|---|---|
五、非功能需求表
| 编号 | 类别 | 指标描述 | 度量方式 | 优先级 | 验收标准 |
|---|---|---|---|---|---|
| 性能 / 安全 / 兼容性 / 可用性 / 可维护性 |
六、接口与数据要求表
| 编号 | 接口或数据对象 | 方向 | 格式与字段 | 频率或时机 | 异常处理 | 责任方 |
|---|---|---|---|---|---|---|
| 输入 / 输出 |
七、假设、依赖与待确认问题表
| 编号 | 类型 | 内容 | 影响的需求 | 责任人 | 确认期限 | 状态 |
|---|---|---|---|---|---|---|
| 假设 / 依赖 / 待确认 |
每个字段写什么：字段说明与填写口径
模板给出栏目，填写质量取决于每个字段是否写到可判断的程度。下表逐字段说明含义、写法要求和常见错误，功能需求主表的字段是重点。
| 字段 | 含义 | 写法要求 | 常见错误 |
|---|---|---|---|
| 需求编号 | 需求的唯一标识 | 采用“模块缩写-序号”规则，如 ORD-001；编号一经分配不复用，需求作废时保留编号并标记状态 | 多条需求共用一个编号；删除后编号被新需求占用，导致历史记录对不上 |
| 模块 | 需求所属的业务或功能分组 | 使用团队已有的模块划分名称，与需求池、任务列表保持一致 | 模块名随手写，同一模块出现多种叫法 |
| 需求名称 | 一句话概括这条需求 | 用动宾结构，如“订单提交前校验库存” | 名称写成整段描述，表格无法扫读 |
| 需求描述 | 说明谁在什么场景下要什么结果 | 一句话写清角色、场景、期望结果；复杂需求拆成多条，不在一格里堆叠多个目标 | 只写“优化体验”“支持导出”这类无法判断完成与否的表述 |
| 输入 | 触发或支撑该需求的数据与操作 | 列出字段、来源和必要的前置条件，如“用户提交的订单号、商品编码” | 写“用户数据”这类笼统说法，开发无法确定取哪些字段 |
| 处理规则 | 系统在输入到输出之间执行的判断与计算 | 按条件—动作逐条写，覆盖正常路径和主要异常路径 | 只写正常流程，异常分支留给开发自行猜测 |
| 输出 | 处理完成后呈现或返回的结果 | 写清结果形态、展示位置或返回格式 | 输出写成“正确提示”，没有具体文案或格式要求 |
| 优先级 | 需求实现的先后次序 | 使用团队统一分级，如 P0 必须本期交付、P1 本期尽量交付、P2 可延后；每级给出判断依据 | 全部标为高优先级，分级失去作用 |
| 验收标准 | 判断需求是否完成的检验条件 | 写成可执行的检查项，包含操作、预期结果和边界条件；一条需求对应一组检查项 | 写“功能正常可用”，评审时无法逐项核对 |
| 来源 | 需求的提出人与依据 | 记录提出人、提出时间、关联的访谈记录、工单或数据依据 | 只写“业务方”，后续追溯找不到人 |
| 状态 | 需求当前所处的处理阶段 | 按团队流程流转，如草稿→待评审→已通过→开发中→已验收→已关闭；每次变更记录时间 | 状态长期停留在“待评审”，实际已开发完成 |
验收标准的写法值得单独强调：把需求描述中的每个期望结果转成一条可操作的检查项。例如描述写“提交订单前校验库存”，验收标准就写“库存不足时点击提交，页面提示缺货商品名称且订单不生成；库存充足时订单正常生成并扣减库存”。检查项能覆盖描述中的每个结果，这条需求才算写清。
必填与选填：哪些字段不能空
时间紧张时，先保证必填字段完整，选填字段可以按场景补。判断依据是：缺了这个字段，需求是否还能被评审和验收。
| 字段 | 功能需求 | 非功能需求 | 接口与数据要求 | 说明 |
|---|---|---|---|---|
| 需求编号 | 必填 | 必填 | 必填 | 唯一标识是评审、变更、验收的共同锚点 |
| 需求名称 | 必填 | 必填 | 必填 | 用于快速识别和检索 |
| 需求描述 | 必填 | 必填 | 必填 | 没有描述就无法判断需求本身 |
| 验收标准 | 必填 | 必填 | 必填 | 写不出验收标准说明需求未收敛，应先补充再评审 |
| 优先级 | 必填 | 必填 | 选填 | 排期依赖优先级；接口需求通常随关联功能排期 |
| 来源 | 必填 | 选填 | 选填 | 功能需求涉及业务承诺，需要可追溯 |
| 状态 | 必填 | 必填 | 必填 | 流程流转的基础字段 |
| 输入 / 处理规则 / 输出 | 必填 | 不适用 | 按接口复杂度填写 | 小型项目可将三者合并为一栏“逻辑说明”，但不能省略 |
| 模块 | 选填 | 选填 | 选填 | 需求量大、跨团队协作时建议填写 |
| 度量方式 | 不适用 | 必填 | 不适用 | 非功能指标必须说明如何测量，否则无法验收 |
| 异常处理 | 选填 | 不适用 | 涉及外部系统时必填 | 跨系统调用失败的处理方式需要提前约定 |
字段暂时无法确定时，不要留空，也不要随手填一个猜测值。正确做法是在该字段写“待确认：具体问题”，同时在假设与待确认问题表中登记一条记录，写明责任人、影响的需求和确认期限。这样评审时能一眼看到缺口，而不是把空白当成已确认。
完整填写示例：一条功能需求从空白到可评审
以下示例为演示情景，用于说明字段之间的联动关系，不代表任何真实项目。背景设定：某电商系统的订单模块需要增加库存校验，需求来自运营团队在促销复盘会上提出的问题——大促期间出现过超卖。
| 字段 | 填写内容 |
|---|---|
| 需求编号 | ORD-012 |
| 模块 | 订单 |
| 需求名称 | 订单提交前校验商品库存 |
| 需求描述 | 买家在订单确认页点击提交时，系统校验所购商品的可售库存；库存不足时阻止下单并提示缺货商品，库存充足时生成订单并扣减库存。 |
| 输入 | 买家提交的订单明细（商品编码、购买数量）、商品当前可售库存 |
| 处理规则 | 1. 逐条比对购买数量与可售库存；2. 任一商品库存不足，整单不生成，返回缺货商品清单；3. 全部充足，生成订单并扣减对应库存；4. 扣减时若库存被并发占用，按失败处理并提示重试。 |
| 输出 | 成功：订单号及下单成功页；失败：缺货商品名称与可购数量提示，订单不生成 |
| 优先级 | P0（大促前必须上线，超卖已造成实际损失） |
| 验收标准 | 1. 单商品库存不足时提交，提示缺货商品名称，订单列表无新增记录；2. 多商品中一件缺货时整单不生成，提示仅列出缺货商品；3. 库存充足时订单生成，库存数按购买数量扣减；4. 两笔订单同时购买最后一件商品，仅一笔成功，另一笔收到重试提示。 |
| 来源 | 运营团队 2024 年 6 月促销复盘会，关联工单 SUP-2087 |
| 状态 | 待评审 |
这条示例体现了几个填写取舍。需求描述只写一个目标——提交前校验库存，没有把“库存预警”“自动补货”等相邻想法塞进同一条，那些另开编号。处理规则覆盖了并发扣减这一异常路径，因为超卖问题恰恰出在这里，省略它验收标准就无法检验。验收标准四条与描述中的“阻止下单、提示缺货、生成订单、扣减库存”一一对应，评审时可以逐条打勾。
非功能需求同样需要示例。假设同一系统要求订单提交接口的响应时间，非功能需求表可填：编号 NFR-003，类别性能，指标描述“订单提交接口在正常负载下 95% 请求响应时间不超过 2 秒”，度量方式“压测工具统计提交接口响应时间分布”，优先级 P1，验收标准“压测报告显示 95 分位响应时间≤2 秒”。指标、度量方式、验收标准三者指向同一个数，缺一项就无法验收。
模板的调整与维护方法
模板拿到后直接套用往往过重或过轻，需要按项目和团队裁剪，同时管好版本，避免各项目各用一套、字段对不上。
按项目规模与需求类型裁剪
- 小型项目或迭代周期短的团队，可把输入、处理规则、输出合并为“逻辑说明”一栏，保留编号、描述、优先级、验收标准、来源、状态六个核心字段。
- 涉及外部系统对接、资金计算或合规要求的需求，接口与数据要求表、异常处理字段不宜省略，这些正是评审和验收的高风险点。
- 非功能需求按系统实际约束选取类别，没有明确指标要求的类别可以不建行，避免为填而填。
新增自定义字段的判断标准
新增字段前先问三个问题：这个字段是否会影响评审结论或验收判断；是否已有字段可以承载同样信息；团队是否愿意在每条需求上维护它。三个问题都成立再新增，并在字段说明中同步补充含义和写法，否则新字段很快会变成无人填写的空列。
版本与修订记录维护
- 模板本身作为一个受控文档管理，字段增删、口径调整都记入修订记录，写明版本号、调整内容和生效范围。
- 已进入开发的需求沿用其编写时的模板版本，不因模板升级而批量改写历史需求，避免追溯混乱。
- 模板与需求评审、变更流程衔接：评审检查必填字段是否完整、验收标准是否可执行；需求变更时同步更新对应条目和修订记录，状态随之流转。
定期回顾模板有效性
建议每个季度或每个大版本结束后做一次回顾，用三个信号判断模板是否需要调整：评审会上反复追问的字段，说明写法口径不清；长期为空或全部填同一值的字段，说明价值不足；验收阶段频繁出现争议的需求，回看其验收标准写法，补充到字段说明中作为正例或反例。回顾结论落到模板修订记录，形成闭环。
当需求条目从文档迁移到工具中承载时，模板里的字段、状态和评审结论需要有对应的落点。ONES 的需求管理方向支持将需求条目按字段组织、按状态流转并关联评审记录，团队可以把本文模板的字段集合映射为工具中的需求属性，让编号、优先级、验收标准在评审和验收环节保持同一份数据，减少文档与工具两处维护的偏差。具体字段配置与流程设置，以团队实际使用的系统为准。
常见问题
需求描述和验收标准可以合并成一栏吗？
不建议合并。需求描述回答“要做什么”，验收标准回答“怎么判断做完了”，两者在评审中的用途不同：描述用来确认理解一致，验收标准用来逐项核对。合并后容易出现描述写得很完整、验收时却找不到对应检查项的情况。
小型项目可以把输入、处理规则、输出合并为“逻辑说明”一栏，但描述与验收标准仍应分开保留，这是需求可评审、可验收的最低要求。
需求写到一半发现范围不清，应该先填模板还是先确认范围？
先确认范围。范围与目标区的“范围内”“范围外”是后续所有需求条目的边界，边界不清时写出的功能需求容易越写越多，评审时反复返工。
实际操作中可以先填文档信息区和范围区，把不确定的部分登记到假设与待确认问题表，写明责任人和确认期限，再开始写功能需求。范围确认后再回头检查已写的条目是否超出边界。
非功能需求的指标没有历史数据参考，怎么写验收标准？
先写清度量方式，再定指标值。度量方式说明用什么工具、在什么负载或场景下、统计哪个指标，例如“压测工具统计订单提交接口的响应时间分布”。有了度量方式，指标值可以先用团队能接受的目标值，并在假设与依赖中注明该值待验证。
指标、度量方式、验收标准三者必须指向同一个数，缺一项就无法验收。没有历史数据时，宁可把指标标为待确认，也不要写“响应要快”这类无法检验的表述。
模板里的状态字段和团队现有的需求流程对不上，怎么处理？
以团队实际流程为准调整状态取值，不必照搬模板示例。做法是先列出需求从提出到关闭实际经过的环节，把每个环节对应成一个状态，再确认每个状态的进入条件和责任人。
状态调整后同步更新字段说明，并在修订记录中写明版本和生效范围。已进入开发的需求沿用其编写时的状态定义，避免历史记录对不上。
一条需求涉及多个模块，编号和模块字段怎么填？
优先拆成多条需求，每条只归属一个模块，各自编号。跨模块的需求在描述中写明模块间的衔接关系，并在假设与依赖表中登记依赖项。
确实无法拆分时，模块字段填主责模块，其余模块在描述或依赖表中说明。编号仍保持唯一，不复用，便于评审和变更时定位。
