编写需求规格说明书，先明确文档要回答的问题和主要读者，再按“范围与背景—角色与场景—功能需求—数据与接口—非功能需求—验收标准—变更与追溯”的顺序逐项填写。每条需求写成可验证的陈述，标注编号、来源、优先级和验收方式，最后通过评审与基线确认。本文给出可直接套用的章节骨架、逐章写法、角色分工和交付前检查清单。
要点总览（TL;DR）
- 先定文档定位与读者，再按“范围与背景—角色与场景—功能需求—数据与接口—非功能需求—验收标准—变更与追溯”搭骨架，先写范围与验收标准框架，再补细节。
- 单条需求用固定字段书写：编号、名称、描述、触发条件、输入输出、异常处理、优先级与来源，确保测试能据此设计用例。
- 编写由产品/需求分析人员主责，评审由业务、研发、测试共同参与，基线由需求提出方与产品负责人确认，变更须做影响分析并更新版本。
- 交付前按完整性、一致性、可验证性、可追溯性与版本规范逐项核对，存在无验收标准或相互矛盾的需求时不得进入基线。
- 需求条目、评审记录与变更历史可在 ONES 中关联留存，ONES Wiki 的页面模板与版本记录可承载文档模板和基线版本。
一份可用的需求规格说明书先定什么
需求规格说明书的核心用途，是让业务方、研发、测试和验收方对“要做什么、做到什么程度算完成”形成同一份书面依据。它服务于四类读者：业务与需求提出方用它确认理解一致；研发用它评估实现方案和工作量；测试用它设计用例；验收方用它判断交付是否达标。动笔之前先想清楚这份文档主要给谁看、要支撑哪些下游动作，章节详略就有了依据。
推荐采用以下章节骨架，每章回答一个明确问题：
| 章节 | 回答的问题 |
|---|---|
| 范围与背景 | 为什么做、解决什么业务问题、本次包含和不包含什么 |
| 角色与场景 | 谁在什么情况下使用，操作路径如何展开 |
| 功能需求 | 系统要提供哪些具体能力，每条需求的触发条件、输入输出和异常如何处理 |
| 数据与接口需求 | 涉及哪些数据字段、来源、约束，依赖哪些外部系统 |
| 非功能需求 | 性能、安全、可用性、兼容性等要达到什么可度量水平 |
| 验收标准 | 每条需求用什么条件判定通过 |
| 变更与追溯 | 需求编号如何关联来源、版本和后续变更记录 |
编写顺序上，建议先写范围与背景、验收标准的框架，再补角色场景和功能细节。原因是范围和验收标准决定了文档边界：范围写清楚“不做什么”，能避免后续需求无限扩张；验收标准先立框架，写功能需求时就会自然追问“这条怎么验证”，减少写完再返工。功能需求、数据接口和非功能需求放在中间逐条填充，变更与追溯章节随编写同步维护。
文档粒度按两个因素取舍：一是需求的不确定程度，不确定性高的部分写细，把假设和待确认项显式标出；二是下游依赖程度，测试和验收要直接引用的条目必须写到可验证，内部实现细节则留给设计文档。一份规格说明书覆盖一个可独立交付的需求集合为宜，范围过大时拆分为多份并建立编号关联。
逐章编写：从范围到验收标准怎么写
以下按章节给出输入、动作、输出和完成标志，可以照着逐章推进。
背景与目标
输入是业务方的原始诉求和现状问题。动作是写清业务问题、目标用户和成功判据三件事：业务问题描述当前哪里不顺、造成什么影响；目标用户说明主要服务哪些角色；成功判据给出可观察的结果，例如“订单录入环节人工操作步骤从若干步减少到若干步”。输出是一段不超过一页的背景说明加目标列表。完成标志是业务方读后能确认“这就是我们要解决的问题”。
角色与场景
输入是目标用户清单和典型业务过程。动作用“角色—场景—操作路径”的结构描述：先列角色及其职责，再列每个角色在什么场景下触发使用，最后按步骤写出操作路径，包括正常路径和关键分支。输出是场景清单，每个场景对应一组功能需求编号。完成标志是每个角色至少有一个完整场景，且场景能覆盖主要业务过程。
功能需求
这是文档的主体。单条需求建议采用固定字段：
- 需求编号：全局唯一，便于追溯和引用，如 FR-001。
- 需求名称：一句话概括能力，避免笼统的“优化体验”类表述。
- 描述：系统在什么条件下、对什么对象、执行什么动作、产生什么结果。
- 触发条件：什么操作或事件引发该功能。
- 输入与输出：接收哪些数据、字段要求，输出什么结果或状态变化。
- 异常处理：输入缺失、越权、超时、重复提交等情况下系统如何响应。
- 优先级与来源：标注优先级和需求提出方，便于排期和回溯。
完成标志是每条需求都能被测试人员据此设计出至少一个用例，且不依赖口头补充。
数据与接口需求
输入是功能需求中涉及的数据对象和外部系统清单。动作是逐项列出字段名称、类型、来源、取值范围与约束，以及对外部系统的调用方向、频率和失败处理方式。输出是数据字典和接口清单。完成标志是研发能据此判断数据模型和集成工作量，且没有“待定”字段未标注负责人。
非功能需求
非功能需求要写成可度量的表述，避免“响应要快”“要安全”这类无法验证的说法。常见维度包括：性能（如关键查询在约定数据量下的响应时间上限）、安全（如权限控制粒度和敏感数据保护要求）、可用性（如允许的中断时长）、兼容性（如支持的终端和版本范围）。每条非功能需求同样编号，并注明验证方式。完成标志是每条都有度量口径和验证方法。
验收标准
每条功能需求对应一组可验证的通过条件，写法上采用“给定前提—执行操作—预期结果”的结构。验收标准由需求提出方与测试方共同确认，作为后续验收的依据。完成标志是全部功能需求都有对应验收标准，且不存在无法判定的模糊表述。
角色分工与各环节交付物
需求规格说明书的质量取决于编写、评审、基线确认和变更四个环节的责任是否清晰。下表给出角色—环节—交付物的对照：
| 环节 | 主要负责角色 | 输入 | 输出交付物 |
|---|---|---|---|
| 编写 | 产品/需求分析人员 | 业务诉求、用户反馈、现有流程资料 | 需求规格说明书初稿、待确认问题清单 |
| 评审 | 业务提出方、研发、测试共同参与 | 初稿、待确认问题清单 | 评审记录（问题、结论、责任人、期限）、修订稿 |
| 基线确认 | 需求提出方与产品负责人 | 修订稿、评审结论 | 基线版本及版本号、确认记录 |
| 变更 | 变更提出人发起，产品人员做影响分析，研发与测试评估工作量 | 变更申请、基线版本 | 变更记录、影响分析结论、更新后的版本 |
评审记录应包含：评审时间与参与角色、逐条问题的描述与处理结论、未关闭问题的责任人和关闭期限、是否同意进入基线的明确结论。评审的目标是发现遗漏、歧义和不可验证的表述，而非逐字润色文字。
需求变更时，由提出人提交变更申请，产品人员分析对范围、进度和相关需求条目的影响，研发与测试评估实现和验证成本，结论记录在变更记录中并更新文档版本号。已基线的内容发生变更时保留原版本，便于追溯“当时确认的是什么”。
在工具承载上，需求条目、评审记录和变更历史需要在同一处关联。ONES 通过统一的业务需求池与产品需求池联动业务反馈和产品开发，形成需求—任务—测试—缺陷的闭环；ONES Wiki 支持页面组关联项目，使需求与文档互相对应，并记录页面版本、支持查看与回滚，评审结论和基线版本可以随文档一并留存。文档模板可通过页面模板库统一，减少每次从零搭目录的重复工作。
示例：一条需求从描述到验收怎么写
以下为演示情景，用于说明字段填写方式，不代表任何真实项目。
需求条目
- 需求编号：FR-012（来源：业务方反馈单 REQ-035，关联场景 SC-03 订单录入）
- 需求名称：订单提交前必填项校验
- 描述：用户在订单录入页提交订单时，系统校验客户名称、收货地址、商品数量三项必填字段，任一缺失则阻止提交并提示缺失项。
- 触发条件：用户点击“提交订单”按钮。
- 输入：订单表单中的客户名称、收货地址、商品明细（含数量）。
- 输出：校验通过时生成订单并跳转至订单详情；校验不通过时停留在当前页，逐项标出缺失字段。
- 异常处理：网络中断时保留已填内容并提示重试；重复点击提交时仅生成一笔订单。
- 优先级：高。
对应场景：销售人员在客户现场录入订单，网络条件不稳定，需要避免因漏填字段反复返工。正常路径为填写完整后一次提交成功；异常路径包括漏填单项、漏填多项和提交过程中断网。
验收标准
- 给定表单中客户名称为空，执行提交，预期订单不生成且客户名称字段被标出。
- 给定三项必填均完整，执行提交，预期生成一笔订单并进入详情页。
- 给定提交过程中网络中断，预期页面保留已填内容并给出重试提示。
- 给定连续点击提交两次，预期仅生成一笔订单。
这条示例体现了编号与追溯关系：需求编号关联来源反馈单和场景编号，验收标准逐条对应需求描述中的正常与异常路径，测试人员可直接据此编写用例，变更时也能定位受影响的范围。
完成检查：交付前逐项核对
文档进入评审或基线前，按下表逐项核对。任一项不通过即视为阻断项，需修订后重新检查。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 完整性 | 章节骨架是否齐全 | 范围、角色场景、功能、数据接口、非功能、验收、变更追溯均有内容 |
| 完整性 | 每条功能需求字段是否填全 | 编号、描述、触发条件、输入输出、异常、优先级、来源均无空缺 |
| 一致性 | 术语与角色名称是否统一 | 全文同一对象使用同一名称，术语表与正文一致 |
| 一致性 | 需求之间是否矛盾 | 不存在两条需求对同一行为给出冲突规定 |
| 可验证性 | 每条需求是否有验收标准 | 验收标准可按给定—操作—预期结构判定通过与否 |
| 可验证性 | 非功能需求是否可度量 | 每条有度量口径和验证方法，无“尽量快”类表述 |
| 可追溯性 | 编号是否唯一且被引用 | 需求编号全局唯一，场景、验收标准、变更记录均能回指编号 |
| 规范 | 版本与变更记录是否更新 | 版本号、修订说明、变更记录与当前内容一致 |
阻断项包括：存在无验收标准的功能需求、存在相互矛盾的需求条目、存在未标注负责人的待定项、基线版本缺少确认记录。以上任一项存在时，文档不进入基线。全部检查通过后，由需求提出方与产品负责人确认基线版本，文档即可作为研发、测试和验收的共同依据。
常见问题
需求规格说明书和产品需求文档（PRD）需要各写一份吗？
两者可以合并，也可以分开，取决于团队的下游使用方式。PRD 侧重业务目标、用户价值和方案取舍，需求规格说明书侧重可验证的需求条目与验收条件。如果研发和测试直接依据同一份文档工作，可以在 PRD 中嵌入规格章节，按本文骨架补齐功能条目、数据接口、非功能需求和验收标准；如果存在外部验收或合同交付场景，单独维护规格说明书更便于基线确认和版本追溯。关键是同一需求只保留一个权威来源，避免两份文档各自更新造成冲突。
需求还没完全确定时，规格说明书要不要先写？
可以先写，但要把不确定部分显式标注。做法是把已确认的范围、角色场景和验收标准框架先落下来，未确定的需求条目标注“待确认”并写明负责人和确认期限，避免用模糊表述掩盖空白。这样评审时能集中讨论待确认项，而不是通读全文找问题。待确认项在进入基线前必须关闭或明确移出本次范围，否则会变成研发过程中的返工来源。
非功能需求写不出具体数字怎么办？
先确定度量维度和验证方式，再逐步补口径。例如性能可以先写清关键操作、数据量级和期望的响应时间上限，安全可以写清权限控制粒度和敏感数据的处理要求。暂时没有准确数字时，标注测量方法和待定原因，由提出方与研发共同确认，不要用“尽量快”“足够安全”代替。每条非功能需求同样编号并注明验证方式，验收时才有判定依据。
需求变更后，原来的验收标准怎么处理？
变更获批后，同步更新受影响的需求条目和对应验收标准，并在变更记录中写明变更原因、影响范围和结论。已基线的版本保留原样，新版本号对应新内容，便于回溯“当时确认的是什么”。如果变更只涉及实现方式而不改变外部行为，验收标准可以保持不变；如果改变了输入输出、异常处理或非功能指标，验收标准必须同步修订，并由测试方确认可验证。
评审会上业务方和研发各关注什么，怎么提高效率？
业务方重点确认范围、场景覆盖和验收标准是否符合预期；研发关注需求描述是否完整、数据接口是否清晰、非功能指标是否可实现；测试关注每条需求能否设计出用例。提高效率的做法是评审前发出初稿和待确认问题清单，会上按问题清单逐条过，记录结论、责任人和期限，会后输出修订稿。评审目标是发现遗漏、歧义和不可验证的表述，逐字润色可以放到会后处理。
