2. 需求追溯与验收标准

在PI System工业数据项目中，验收争议往往不是发生在技术实现阶段，而是发生在“需求是否被满足”的判定阶段。根本原因通常只有一个：用户需求说明书（URS）中的一句话，在功能设计说明书（FDS）中被拆成了若干条设计条目，而在验收测试中又被压缩成一条笼统的“功能正常”。三者之间没有建立可追溯的映射关系，验收时就只能靠口头解释。需求追溯矩阵（RTM）就是解决这个问题的核心工具。

URS、FDS与验收测试的三层关系

URS回答“业务要什么”，通常由工艺、运维或质量部门提出，语言偏业务化，例如“能够追溯每批产品在关键工序的温度曲线”。FDS回答“系统怎么做”，由PI System实施方编写，把业务语言翻译成PI标签命名、AF模板、事件帧、通知规则等技术设计。验收测试则回答“怎么证明做到了”，用可执行的测试用例验证FDS条目，并反向确认URS被覆盖。

追溯矩阵的本质是一张带方向的关系表：每一行是一条需求，列则记录它在FDS中的设计编号、在测试脚本中的用例编号、测试结果与偏差处理。正向追溯确保每条URS都有设计落地和测试覆盖；反向追溯确保没有凭空增加、无人认领的设计和测试。二者缺一不可。

PI System功能需求与非功能需求的区分

PI System项目的需求通常分为两类。功能需求描述系统“做什么”，例如：采集DCS的2000个位号、按批次建立事件帧、超限触发PI Notification、在PI Vision中展示趋势。非功能需求描述系统“做到什么程度”，例如：数据采集延迟不超过5秒、归档可用性不低于99.9%、单点查询响应时间小于2秒、支持50个并发用户、历史数据保留3年。

非功能需求最容易被写成无法验证的形容词，如“系统应稳定可靠”“界面应友好”。这类表述在验收时无法判定通过与否。正确的做法是把它转化为可测量的指标，明确测量对象、测量条件、目标值和判定方法。例如“系统应稳定可靠”可以改写为：在连续30天运行期内，PI Data Archive服务不可用时间累计不超过43分钟（对应99.9%可用性），通过系统日志和监控记录统计。

可测量验收指标的编写方法

一条合格的验收指标应包含五个要素：测量对象、测量条件、指标阈值、测量方法和判定规则。以“报警响应时间”为例：测量对象是PI Notification从事件触发到通知送达的时间差；测量条件是正常生产负荷、网络无异常；指标阈值是≤30秒；测量方法是注入模拟超限值并记录AF分析触发时间与邮件到达时间；判定规则是连续10次测试中至少9次满足阈值。

再以“数据完整性”为例：测量对象是某关键位号在指定时间段内的有效归档点数；测量条件是采集接口正常运行；指标阈值是数据完整率≥99%；测量方法是统计实际归档点数与理论应归档点数之比；判定规则是连续7天每日统计均达标。这样写出的指标，验收时不需要争论，只需要执行测试并记录数据。

追溯矩阵的维护与验收应用

追溯矩阵不是一次性文档，而应随项目推进持续更新。URS变更时，检查受影响的FDS条目和测试用例；FDS调整时，确认是否仍覆盖原URS；测试执行后，记录实际结果和偏差。验收评审时，矩阵就是检查清单：每条URS是否有FDS编号、是否有测试用例、测试结果是否通过、未通过项是否有偏差处理记录。

一个常见的实践是给每条需求分配唯一编号，并在FDS和测试脚本中引用该编号。例如URS-02对应FDS-02和TC-02，形成一条可追踪的链路。当验收方质疑“报警功能是否满足要求”时，可以直接调出URS-02的原始描述、FDS-02的设计说明和TC-02的测试记录，用证据链回应，而不是靠解释。

上表是一个简化示例，实际项目中矩阵可能包含数十到数百条需求。关键不在于表格多复杂，而在于每条需求都能沿着“URS→FDS→测试用例→验收指标→结果”这条链路走通。走不通的地方，就是验收风险所在。把追溯矩阵作为验收前的自检工具，可以提前发现覆盖缺口，避免在验收会上被动应对。