SRS 是什么
软件需求规格说明书是需求基线的正式载体，写明系统要做什么、做到什么程度、受哪些约束、如何验证。它把散落的业务诉求固化成可评审、可追踪的条目，是合同项目与合规行业的验收依据。现代实践更强调每条需求可验证、可追踪、有唯一责任人，而不追求章节面面俱到。
基本信息
| 参考标准 | ISO/IEC/IEEE 29148:2018，替代 IEEE 830-1998 |
|---|---|
| 典型章节 | 引言、总体描述、具体需求、外部接口、约束、验证方法 |
| 配套物 | 需求 ID 体系、追踪矩阵、变更流程 |
| 适用范围 | 合同型项目、合规行业、多方协作的定制开发 |
| 常见替代 | 轻量需求库加用户故事与验收标准 |
条目质量检查点
| 要素 | 说明 | 不合格表现 |
|---|---|---|
| 唯一 ID | 全生命周期不变，可被引用 | 用标题当标识，重命名后链接全断 |
| 验收标准 | 可测的通过条件 | 写成响应要快这类无法判定的描述 |
| 优先级与来源 | 需求方与业务价值 | 来源缺失，变更时找不到决策人 |
| 约束 | 合规、性能与兼容性限制 | 把约束写进功能描述，测试无从下手 |
| 追踪关系 | 关联设计、测试与代码 | 只有正文，没有可追溯的连线 |
典型使用场景
- 招投标与合同项目：SRS 是需求范围与验收的依据
- 合规行业：留档证明需求已经过评审与验证
- 多方协作：甲方乙方与第三方接口方以同一基线协作
- 需求基线冻结：变更走正式流程，避免口头追加
- 遗留系统改造：先整理现状需求再界定重构范围
为什么要可验证
不可验证的需求无法验收：写「响应要快」和写「95% 的查询在 500 毫秒内返回」是两种截然不同的交付结果。把每条需求配上可测量的验收标准，测试用例才有对齐的目标，变更评审也能判断影响程度。这也是 ISO/IEC/IEEE 29148 反复强调需求应具备可验证性、无歧义与可追踪的原因。
文档形式不是目的：关键是每条需求可验证、可追踪、有责任人。用需求工具承载条目，规格说明书只做汇总视图，比维护一份长篇文档更耐久。