web

需求规格说明与验收标准

第 6 章 · 软件工程

先看两种协作方式。 A 项目：需求散落在群聊、邮件和会议纪要里，开发问「导出到底要哪些字段？」产品说「上次说过啊」，开发翻半天找不到；验收时测试说「按我的理解做的」，产品说「我理解的不是这样」——各说各话。B 项目：有一份需求规格说明书（SRS），功能一条条写清楚，每条下面有验收标准；开发对着 SRS 做、测试对着验收标准测、产品对着同一份文档确认。需求有变更就走流程、更新文档、再同步大家。差别不在谁更负责，而在有没有把需求「规格化」、把「做完」定义清楚、把变更管起来。本章讲需求规格说明与验收标准：SRS 的作用与结构、如何写出清晰无歧义可测试的表述、验收标准与 Definition of Done，以及需求变更与基线管理。

一、需求规格说明书（SRS）的作用与结构

需求规格说明书（Software Requirements Specification, SRS）是一份正式文档，用来描述系统应满足的需求，作为设计、开发、测试和验收的共识依据。它的核心作用有三：共识（干系人对「要做什么」有一份统一的参照）、追溯（设计、代码、测试能对应到具体需求）、验收依据（验收时能逐条对照「做到了没有」）。

1. 引言 / 范围
项目背景、目标、范围、读者、术语与缩写。
2. 功能需求
按模块或特性列出的功能需求，每条可带 ID、描述、优先级、验收标准。
3. 非功能需求
性能、安全、可用性等；尽量量化、可验证。
4. 附录与索引
术语表、参考文档、需求追溯表等。
SRS 典型结构：引言 → 功能需求 → 非功能需求 → 附录

实际项目中 SRS 的详略可以按规模调整：小项目可以是一份几页的文档或结构化 Backlog；大项目或合规要求高的会写得很细、带版本与变更历史。关键是有一份「唯一的真相来源」，大家以它为准，而不是靠口口相传或零散记录。

二、清晰、无歧义、可测试的表述

写进 SRS 的每一条需求，都应尽量做到清晰、无歧义、可测试。这样设计不会猜、开发不会偏、测试能对照着验。

清晰
简单直白、主语明确、避免「尽量」「方便」等模糊词。
无歧义
同一句只有一种合理理解；关键术语在文档中定义。
可测试
能通过操作或测试判定是否满足；虚的拆成可验收条款。
SRS 表述三原则：清晰、无歧义、可测试

例如：「用户能导出订单」不够具体；改成「已登录用户能在订单列表页选择时间范围后点击『导出』，下载包含订单号、金额、状态的 CSV 文件，且单次最多 1 万条」——谁、在哪、做什么、结果是什么、有什么限制都清楚了，测试也能据此写用例。

三、验收标准与 Definition of Done

验收标准（Acceptance Criteria, AC）是针对某条需求或某个用户故事的「通过条件」：满足这些条件，就算这条需求或这个故事验收通过。通常写成「Given… When… Then…」或 bullet 列表，每条都可直接对应测试用例。

示例（用户故事：作为用户，我能导出订单列表） Given 用户已登录且订单列表有数据；When 用户选择时间范围并点击「导出」；Then 在 10 秒内下载到 CSV 文件，且包含订单号、金额、状态列，编码 UTF-8。单次导出超过 1 万条时，提示用户缩小范围。

Definition of Done（DoD，完成定义）是团队对「什么算做完」的共识，通常是一条清单：代码已提交并合并、通过评审、通过自动化测试、文档已更新、产品/负责人确认等。一条需求或一个迭代不仅要「功能实现」，还要满足 DoD 才算真正「完成」——可发布、可交付。

  • ✓ 代码已合并到目标分支，并通过 CI
  • ✓ 已通过 Code Review
  • ✓ 相关自动化测试已通过（或已补充）
  • ✓ 验收标准已满足（产品/测试确认）
  • ✓ 文档/帮助已更新（若适用）
Definition of Done 示例：合并、评审、测试、验收、文档

验收标准回答「这条需求怎样算做到」；DoD 回答「交付物怎样算可以 release」。两者配合：需求有 AC、交付满足 DoD，质量和交付节奏才有保障。

四、需求变更与基线管理

需求在项目进行中难免会变：业务调整、理解深化、市场变化。若变更没有流程，就会出现「有人口头说改、有人不知道」「改完不知道影响了哪些设计和测试」——混乱与返工。所以需要变更流程和基线管理。

变更流程

典型步骤：提出变更（谁、改什么、为什么）→ 影响分析（对范围、进度、设计、测试的影响）→ 决策（接受/拒绝/延后，由谁拍板）→ 更新文档与通知（SRS、Backlog、设计文档等更新，并同步干系人）。小团队可以简化，但「有记录、有分析、有决策」不能省。

1提出变更
→
2影响分析
→
3决策
→
4更新与同步
需求变更流程：提出 → 影响分析 → 决策 → 更新与同步

基线管理

基线（Baseline）是某一时点「已批准、冻结」的需求（或设计、计划）版本。例如「V1.0 需求基线」表示在某个里程碑上，这些需求是大家共识、后续变更要对照的参照。新变更与基线对比，能看出「改了什么」；发布或合同验收时，也可以按基线来验。基线不阻止变更，但要求变更走流程、有版本、可追溯。

基线：某版本冻结为参照，变更经流程后形成新基线

一句话： SRS 是需求的「唯一真相来源」，结构上包含引言、功能需求、非功能需求与附录；表述要清晰、无歧义、可测试。验收标准定义「这条需求怎样算通过」，Definition of Done 定义「交付物怎样算完成」。需求变更要走流程（提出→分析→决策→更新），基线管理保证有版本可追溯、变更受控。

小贴士： 若团队还没有正式 SRS，可以从「当前迭代或当前版本的 Backlog + 每条故事下的验收标准」起步；再逐步补上非功能需求、术语表和变更记录。先有一份大家对着干的文档，再慢慢完善结构。

五、小结

需求规格说明书（SRS）是系统需求的正式文档，作用在于共识、追溯与验收依据；典型结构包括引言/范围、功能需求、非功能需求、附录。SRS 中的表述应清晰、无歧义、可测试，必要时对术语下定义、把虚词拆成可验收条款。验收标准（AC）定义单条需求或用户故事的通过条件；Definition of Done（DoD）定义交付物「做完」的清单（合并、评审、测试、验收、文档等）。需求变更应走流程：提出→影响分析→决策→更新与同步；基线管理使需求有版本、变更可追溯。下一章我们讲用例与用户故事：如何用用例和用户故事把需求拆成可开发、可验收的条目，以及 Backlog 管理入门。