3、需求规格说明书（SRS）验收：功能需求核对、非功能需求验证、需求变更管理

说到SRS验收，我脑子里立刻浮现出几年前的一个项目。那是个通信基站的信号处理模块，需求文档写了三百多页。结果验收时发现，有个关键功能需求描述得模棱两可——「系统应能快速响应」。你想想看，「快速」到底是多快？100毫秒还是10毫秒？这就是典型的SRS验收没做到位。

今天咱们就聊聊SRS验收的三个核心环节。我个人习惯把这步叫做「需求落地前的最后一道防线」。守住了，项目就成功了一半。

3.1 功能需求核对：别让需求「漂移」

功能需求核对，说白了就是检查「文档写的」和「实际要的」是不是一回事。我在项目中遇到过最头疼的情况是：开发团队按文档做完了，客户却说「这不是我要的」。为什么？因为需求在传递过程中「漂移」了。

核对功能需求，我建议按这三步走：

1. 逐条对照：把SRS里的每条功能需求编号，跟实际系统功能一一对应。别跳着看，一条都不能漏。
2. 场景验证：每个功能都要设计测试场景。比如「信号滤波」功能，你得准备几组典型信号，看滤波效果是不是符合预期。
3. 边界测试：功能在极限条件下还能不能正常工作？我记得有个项目，滤波功能在正常信号下没问题，但输入信号频率超出范围时，系统直接崩溃了。这就是边界没测到。

这里有个实用技巧：做一张功能需求核对表。格式大概这样：

需求编号	功能描述	验证结果	备注
REQ-001	信号采样率不低于1MHz	通过	实测1.02MHz
REQ-002	支持3种调制方式	未通过	仅支持2种，需整改
REQ-003	误码率低于10^-6	通过	实测8.5×10^-7

嗯，这张表看着简单，但能帮你省掉很多扯皮的功夫。

3.2 非功能需求验证：看不见的「硬骨头」

非功能需求，比如性能、可靠性、可维护性，这些往往比功能需求更难搞。为什么？因为功能需求「有就是有，没有就是没有」，但非功能需求经常是「差不多就行」——这种态度最容易出问题。

我曾经参与过一个雷达信号处理项目。功能需求全部通过，但系统连续运行72小时后，内存泄漏导致响应时间从10毫秒飙升到2秒。这就是非功能需求没验证到位。

非功能需求验证，我重点关注这几个方面：

• 性能指标：响应时间、吞吐量、并发能力。别只看平均值，要看95分位甚至99分位的值。
• 可靠性：MTBF（平均无故障时间）、可用性。我习惯让系统跑个72小时压力测试，看看会不会出幺蛾子。
• 可维护性：日志是否完整？模块是否解耦？升级是否方便？这些在验收时容易被忽略。
• 安全性：数据加密、访问控制、防攻击能力。特别是信号系统，数据安全是红线。

你想想看，非功能需求就像房子的地基。地基没打好，装修再漂亮也没用。所以验收时，这块一定要较真。

3.3 需求变更管理：别让项目「失控」

需求变更是项目中最常见也最头疼的事。我见过一个项目，半年内需求变更了47次，最后文档和代码完全对不上。验收？根本没法验。

需求变更管理，核心就三个字：控流程。

具体怎么做？我建议这样：

1. 变更申请：任何变更都必须书面提出。口头说的不算，微信发的也不算。
2. 影响分析：变更会影响哪些模块？成本增加多少？工期延多久？这些必须量化。
3. 评审决策：项目经理、技术负责人、客户代表一起评审。该拒绝的拒绝，该接受的接受。
4. 更新文档：变更一旦通过，SRS必须同步更新。我见过太多「口头变更、文档不变」的坑。

这里有个实用工具——需求变更追踪表：

变更编号	变更描述	提出人	影响范围	状态
CHG-001	增加信号类型	客户A	模块2、模块5	已通过
CHG-002	修改采样率	开发组	模块1、模块3	评审中
CHG-003	删除冗余功能	测试组	模块4	已拒绝

说白了，需求变更管理就是「把无序变成有序」。你控制不了变更的发生，但你可以控制变更的处理方式。

3.4 验收清单与签字确认

最后一步，也是最容易被忽视的一步——签字确认。我见过太多项目，验收时大家口头说「没问题」，结果过了一个月又翻旧账。

验收清单必须包含：

• 功能需求核对结果（通过/未通过）
• 非功能需求验证结果（附测试报告）
• 需求变更记录（所有变更的最终状态）
• 遗留问题清单（未解决的问题及解决方案）

签字的人要明确：客户代表、项目经理、技术负责人。三方签字，缺一不可。

好了，关于SRS验收，我就聊这么多。记住：功能需求核对要细，非功能需求验证要严，需求变更管理要控。这三板斧砍下去，项目验收基本稳了。