SRS需求规格说明书模板的主干由文档信息、引言与范围、总体描述、具体需求条目、外部接口、非功能需求、验收与追溯七部分组成，核心是一张可逐条填写的需求条目表。每条需求用唯一编号串联类型、优先级、来源、验收标准与状态，评审和变更都围绕这张表展开。下面给出可直接复制的空白模板、字段说明、必填取舍、填写示例与维护方法；若团队在ONES中管理需求，可把条目表落到工作项与Wiki文档，让模板随评审流程持续更新。
要点总览（TL;DR）
- 模板主干为文档信息、引言与范围、总体描述、需求条目表、外部接口、非功能需求、追溯与变更记录七部分，核心是需求条目表。
- 需求条目表必填编号、名称、类型、描述、优先级、验收标准、状态七项；来源、依赖、版本可在评审前补齐。
- 描述按触发条件、输入、处理、输出四段写，验收标准用“给定—当—则”结构，可直接转成测试用例。
- 最小可用版本适合需求早期收集，完整版本在进入开发基线前补齐追溯字段。
- 模板本身要有版本号和变更记录，按项目裁剪字段后登记说明，评审通过后冻结基线。
可复制的SRS空白模板
先复制整份结构，再按项目情况删减段落。空白模板保留标题层级和表格表头，填写时不要改动字段名称，便于后续评审与追溯使用同一口径。
一、文档信息
| 项目 | 内容 |
|---|---|
| 文档名称 | |
| 文档编号 | |
| 版本号 | |
| 作者 | |
| 评审人 | |
| 评审日期 | |
| 文档状态 | 草稿 / 评审中 / 已基线 / 已归档 |
| 适用范围 |
二、引言与范围
【编写目的】说明本规格书服务的产品、版本与读者对象。
【产品范围】说明本版本包含与不包含的业务范围。
【术语与缩写】
| 术语/缩写 | 全称 | 含义 |
|---|---|---|
三、总体描述
【用户角色】列出使用系统的角色及其主要目标。
【运行环境】说明部署方式、终端、浏览器或客户端要求。
【约束】列出法规、技术栈、工期或既有系统对接等限制。
【假设与依赖】列出成立前提和外部依赖项。
四、需求条目表（空白表头）
| 需求编号 | 需求名称 | 需求类型 | 描述 | 优先级 | 来源 | 验收标准 | 依赖 | 状态 | 版本 |
|---|---|---|---|---|---|---|---|---|---|
五、外部接口
| 接口编号 | 接口名称 | 对接系统 | 方向 | 数据内容 | 协议/格式 | 异常处理 |
|---|---|---|---|---|---|---|
六、非功能需求
| 需求编号 | 类别 | 指标描述 | 度量方式 | 目标值 | 验证时点 |
|---|---|---|---|---|---|
| 性能 / 安全 / 可用性 / 兼容性 / 可维护性 |
七、追溯与变更记录
| 需求编号 | 上游来源 | 关联设计 | 关联用例 | 变更说明 | 变更人 | 变更日期 | 版本 |
|---|---|---|---|---|---|---|---|
模板字段说明：每个格子填什么
字段说明的作用是让不同作者写出同一口径的条目。下表按需求条目表的主字段逐一解释，外部接口表与非功能需求表沿用相同编号规则，便于在追溯表中统一引用。
| 字段名 | 含义 | 取值 | 写法要点 |
|---|---|---|---|
| 需求编号 | 条目的唯一标识 | 模块缩写-类型码-序号，如 ORD-F-001 | 编号一经分配不再复用；删除的需求保留编号并标记作废 |
| 需求名称 | 一句话概括条目内容 | 动词开头的短语 | 控制在20字以内，避免与描述重复 |
| 需求类型 | 条目的性质分类 | 功能、性能、接口、数据、约束 | 一条需求只归一类；跨类内容拆成多条 |
| 描述 | 需求的具体行为 | 触发条件、输入、处理、输出四段式 | 写系统应做什么，不写实现方案；避免“友好”“快速”等不可判定词 |
| 优先级 | 交付先后顺序 | 必须、应该、可以（或P0/P1/P2） | 全文档统一一套取值，不混用两套标准 |
| 来源 | 需求提出方与依据 | 角色、会议、工单号或上游文档章节 | 写可回查的出处，便于后续确认 |
| 验收标准 | 判定需求完成的依据 | 可观察的条件与预期结果 | 用“给定—当—则”结构或明确数值，确保测试人员能直接转成用例 |
| 依赖 | 与其他需求或外部系统的关系 | 需求编号或系统名称 | 只写直接影响本条交付的依赖 |
| 状态 | 条目当前处理阶段 | 草稿、评审中、已确认、开发中、已验收、已作废 | 状态变更时同步更新版本号 |
| 版本 | 条目自身的修订次数 | v1.0、v1.1递增 | 内容实质变化才升版本，错别字修正可合并记录 |
描述字段的四段式是填写难点。触发条件说明什么情况下发生，输入说明系统收到什么数据，处理说明系统执行什么规则，输出说明用户或下游系统看到什么结果。四段齐全，验收标准通常可以直接从输出段推导出来。
必填与选填：哪些字段不能空
必填字段决定一条需求能否进入评审。缺少编号、描述或验收标准的条目，评审时无法判断范围与完成条件，应退回补充。选填字段服务于追溯和排期，可在项目早期留空，进入开发前补齐。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 需求编号 | 必填 | 追溯、变更记录和测试用例都依赖唯一标识 |
| 需求名称 | 必填 | 评审清单和需求列表需要可读的标题 |
| 需求类型 | 必填 | 决定后续由哪类评审人把关 |
| 描述 | 必填 | 需求的主体内容，缺失则条目无意义 |
| 优先级 | 必填 | 排期与范围裁剪的依据 |
| 验收标准 | 必填 | 没有验收标准的需求无法判定完成 |
| 状态 | 必填 | 反映条目所处阶段，影响评审范围 |
| 来源 | 选填（评审前补齐） | 内部发起的需求可先留空，外部客户或合规需求必须填写 |
| 依赖 | 选填 | 无跨条目依赖时留空，填写“无”也可 |
| 版本 | 选填（首次填写v1.0） | 条目首次录入时统一写v1.0，后续变更递增 |
最小可用版本只保留编号、名称、类型、描述、优先级、验收标准、状态七个字段，适合需求早期快速收集。完整版本增加来源、依赖、版本，并在追溯表中补齐上游来源、关联设计与关联用例，适合进入开发基线前的评审。字段留空时统一填“待补充”并标注责任人，避免空白格被误读为不适用。
填写示例：一条完整需求与一份节选
以下示例为演示情景，用于说明字段之间如何配合，不代表真实项目数据。
功能需求示例
| 字段 | 填写内容 |
|---|---|
| 需求编号 | ORD-F-012 |
| 需求名称 | 订单提交前校验库存 |
| 需求类型 | 功能 |
| 描述 | 触发条件：用户在购物车点击提交订单。输入：购物车商品清单与数量。处理：系统按商品逐项查询可用库存，任一商品库存不足时中止提交并提示缺货商品。输出：提交成功生成订单号，或返回缺货清单与可购数量。 |
| 优先级 | 必须 |
| 来源 | 运营团队2024年三季度需求评审会，工单号REQ-208 |
| 验收标准 | 给定购物车含2件商品且其中1件库存为0，当用户提交订单，则系统不生成订单并展示缺货商品名称；给定全部商品库存充足，当用户提交订单，则生成订单号并在3秒内返回结果。 |
| 依赖 | ORD-F-008 库存查询接口 |
| 状态 | 已确认 |
| 版本 | v1.1 |
这条示例中，描述的输出段与验收标准一一对应，依赖字段指向库存查询接口，追溯表可据此登记上游工单与关联用例。
非功能需求示例
| 字段 | 填写内容 |
|---|---|
| 需求编号 | ORD-N-003 |
| 类别 | 性能 |
| 指标描述 | 订单提交接口在常规促销流量下的响应时间 |
| 度量方式 | 压测工具统计95分位响应时间，连续运行30分钟 |
| 目标值 | 95分位不超过2秒 |
| 验证时点 | 上线前性能测试阶段 |
文档信息与变更记录节选
| 项目 | 内容 |
|---|---|
| 文档名称 | 订单中心需求规格说明书 |
| 文档编号 | SRS-ORD-2024 |
| 版本号 | v1.2 |
| 作者 | 产品经理 李某 |
| 评审人 | 研发负责人、测试负责人、运营代表 |
| 文档状态 | 已基线 |
| 需求编号 | 变更说明 | 变更人 | 变更日期 | 版本 |
|---|---|---|---|---|
| ORD-F-012 | 补充缺货提示文案要求 | 产品经理 李某 | 2024-08-14 | v1.1 |
模板的调整与维护方法
模板需要随项目类型调整，但调整本身要有记录。裁剪字段时先判断项目风险：涉及外部接口或合规要求的项目保留来源、依赖与接口表；内部工具类项目可先用最小可用版本，进入开发前再补齐。
- 裁剪依据：按项目规模、外部依赖数量、合规要求和团队评审习惯决定保留哪些字段，裁剪结果写入模板说明。
- 自定义字段：新增字段使用“业务域-字段名”命名，如“支付-退款时效”，并在字段说明表中登记含义、取值和责任人，避免同名异义。
- 版本维护：模板本身使用独立版本号，字段增删或取值调整时升版本，并在模板变更记录中写明影响范围。
- 评审与基线：需求条目评审通过后冻结为基线版本，后续变更走变更记录；模板调整在下一个项目启动前完成评审，避免中途改动影响在途需求。
- 工具落地：在ONES Wiki中可用页面模板库创建制式化文档，把SRS主干固化为页面模板；需求条目对应到项目工作项，页面组关联项目后需求与文档互相对应，页面版本记录支持查看与回滚。评审讨论可直接在文档页面添加注释和评论，减少线下传阅。
模板落地到协作工具后，维护重点从文档本身转向条目状态与版本的一致性。团队可在ONES中把需求条目作为工作项管理，把规格书作为关联文档，评审结论和变更记录回到同一条目上，追溯表就不必靠人工另建。ONES Assistant可基于项目与Wiki上下文执行操作并将结果保存为工作项或Wiki页面，适合在条目整理阶段减少重复录入；AI生成需求文档的具体用法不在本篇展开。
常见问题
SRS模板里的需求编号必须按什么规则编？
编号规则由团队自定，关键是全文档统一且不复用。常见做法是“模块缩写-类型码-序号”，如 ORD-F-001，类型码对应功能、性能、接口、数据、约束。编号一经分配，即使需求删除也保留并标记作废，避免追溯表和测试用例出现指向空号的情况。跨模块的需求归入主要归属模块，在依赖字段注明关联编号。
需求还没评审完，验收标准可以先空着吗？
验收标准属于必填字段，进入评审前应当写好。评审的核心是判断范围与完成条件，缺少验收标准的条目无法确认是否可交付。若需求早期确实无法给出精确数值，可先写可观察的行为结果，并标注“待补充”和责任人，在评审前补齐；涉及性能指标的，写明度量方式与验证时点，避免只写“响应要快”这类不可判定的表述。
一份SRS要覆盖所有非功能需求吗？
按项目风险取舍。涉及外部接口、合规要求或高并发场景的项目，性能、安全、可用性指标应逐条列入非功能需求表并给出目标值与验证时点；内部工具类项目可先保留与上线判断直接相关的类别，其余在开发前补充。非功能需求同样使用唯一编号，便于在追溯表中与设计、用例对应。
模板裁剪后，怎么保证不同项目写出来的文档还能互相对照？
裁剪只删段落和选填字段，保留字段名称、编号规则和取值定义。裁剪结果写入模板说明，注明适用项目类型和删减理由；新增自定义字段按“业务域-字段名”命名并登记含义与取值。这样不同项目的文档在需求编号、类型、优先级等关键字段上保持同一口径，跨项目汇总和追溯时不需要再做字段映射。
把SRS模板放进协作工具管理，需要关注哪些衔接点？
关注三处衔接：文档模板与需求条目的对应关系、条目状态与文档版本的同步、评审记录的回流。在ONES中可用Wiki页面模板库把SRS主干固化为制式文档，需求条目作为工作项管理，页面组关联项目后需求与文档互相对应，页面版本记录支持查看与回滚，评审讨论可在文档页面添加注释和评论。落地前建议先确认工作项字段能否覆盖条目表字段，以及模板库中是否有可直接改造的现成模板。
