3. 系统需求基础
在监管变化驱动系统改造的场景中，需求工程是把“合规条文”翻译成“可验证系统行为”的桥梁。很多项目失败并非技术不可行，而是需求本身模糊、层次混乱、分类缺失，导致开发、测试与合规三方对同一句话理解不同。本节聚焦需求工程的核心概念、需求层次、需求分类与需求规格说明，为后续影响分析建立共同语言。
一、核心原理：需求是分层的沟通契约
需求工程的核心不是写文档，而是建立可追溯、可验证、可协商的契约。监管条文通常以自然语言描述业务目标与约束，系统需求必须将其转化为可测试的陈述。这里的关键原理有三点：
- 可验证性：每条需求必须能设计出通过/不通过的判定条件，否则只是愿望。
- 可追溯性：从监管条款到业务需求、系统需求、设计、测试用例，形成双向链路。
- 层次分离：不同层次回答不同问题，避免把“为什么做”和“怎么做”混在一句话里。
二、需求层次：从业务目标到系统行为
需求通常分为三个层次，每层关注点不同，参与者也不同。业务需求回答“为什么”，用户需求回答“谁在什么场景下要什么”，系统需求回答“系统必须表现出什么行为”。在监管场景中，还需增加“合规约束层”，它往往横切所有层次。
层次之间必须保持“派生关系”：系统需求应能追溯到用户需求，用户需求应能追溯到业务目标，而合规约束层则可能直接作用于任意一层。例如“数据保留不少于5年”是合规约束，它可能同时影响业务需求（存储策略）、用户需求（查询历史）和系统需求（归档任务）。
三、需求分类：功能、非功能与约束
需求分类决定了后续影响分析的检查清单。常见分类如下表所示，监管变化往往同时触发多类需求。
| 需求类别 | 定义 | 监管场景示例 | 验证方式 |
|---|---|---|---|
| 功能需求 | 系统必须执行的行为或计算 | 自动计算可疑交易评分并生成报告 | 功能测试、场景测试 |
| 非功能需求 | 对行为质量或运行方式的约束 | 预警生成延迟不超过4小时 | 性能测试、监控指标 |
| 合规约束 | 来自法规、标准或审计的强制要求 | 交易记录保留5年且不可篡改 | 审计检查、合规评审 |
| 接口需求 | 系统与外部系统或用户的交互约定 | 向监管平台报送XML格式数据 | 接口测试、联调 |
| 数据需求 | 数据实体、属性、生命周期与质量要求 | 客户身份信息字段完整性校验 | 数据质量检查、抽样 |
四、需求规格说明：从模糊到可验证
需求规格说明（SRS）是需求工程的输出物，但它的质量取决于每条需求的写法。监管条文常包含“及时”“合理”“适当”等模糊词，必须转化为可测量的陈述。推荐使用“条件—主体—行为—对象—约束”的结构化模板。
【需求编号】SYS-REG-003
【来源条款】《金融机构交易报告管理办法》第12条
【需求描述】当单笔交易金额超过等值5万元人民币时，
系统应在交易发生后30分钟内生成大额交易报告，
并将报告状态置为“待复核”。
【约束条件】报告字段必须包含交易时间、金额、币种、双方账户。
【验证方法】构造边界值交易，检查报告生成时间与字段完整性。
【优先级】高
【追溯】BR-002 → UR-005 → SYS-REG-003 → TC-REG-012上述写法把“及时”变成了“30分钟内”，把“报告”拆成了可检查的字段和状态。在监管变化影响分析中，这种结构化需求可以直接用于差异比对：新条款与旧条款的差异，会精确落在“时间阈值”“字段列表”“状态流转”等具体参数上。
五、案例复盘：一次监管变化的需求层次误判
某支付机构收到新规：跨境交易需在T+1内完成合规审核。团队最初只在系统需求层增加了一个“审核任务”，但上线后发现大量交易仍超时。复盘发现：
- 业务需求层未明确“T+1”的起算时点，导致时区与工作日定义缺失。
- 用户需求层未考虑复核人员排班，夜间交易无人处理。
- 系统需求层只增加了任务，未增加“超时升级”与“自动提醒”行为。
- 合规约束层未同步更新数据保留策略，审计时无法提供完整轨迹。
修正后，团队在四个层次分别补充需求，并建立追溯矩阵。再次上线后，超时率从18%降至2%以下。这个案例说明：监管变化的影响分析必须逐层检查，不能只改最底层。