02 需求范围与可追溯性

02.1 范围管理方法

本项目以批准的需求追踪矩阵（RTM）管理范围。每项需求应具有唯一标识、优先级、来源、适用阶段、实现状态、验证方法和验收证据。任何未出现在 RTM 或书面变更中的新增事项，均不自动成为本期验收不通过的依据。

02.2 需求分类

类别	范围内容	最低验证方式
业务功能	钱包、发行、转账、赎回、审批、查询、报表	UAT 场景、业务结果和审计记录
集成功能	RTGS、会计、银行/PSP、身份与通知系统	联调记录、契约测试、异常与对账测试
安全与合规	身份、授权、密钥、日志、隐私、审计	配置审查、测试、扫描、演练和证据抽查
非功能	性能、容量、可用性、恢复、可运维性	批准环境中的专项报告
交付与服务	软件包、文档、培训、支持、移交	交付清单、签收、演练和试运行记录

02.3 需求书写规则

需求应使用可验证的语言，至少包含：主体、动作、业务对象、前置条件、结果、异常处理、数据/审计要求和验收方法。性能、限额、保留期、SLA、RTO/RPO、可用性和安全级别必须有量化值、测量位置、测试周期和责任方，不能仅使用“高性能”“安全”“实时”等描述。

02.4 可追溯链路

每条需求按以下链路管理：

需求编号 → DTS 章节/设计决定 → 实现组件与配置 → 测试用例 → 测试记录 → 缺陷/偏差 → 交付物 → 验收结论

需求状态不得以代码合并替代验收。只有在关联测试通过、证据归档且未决缺陷按规则处置后，需求才可标记为“可验收”。

02.5 范围外与阶段化事项

范围外事项记录在 RTM 的“后续阶段/不适用”区，并说明提出方、原因、依赖和重新评估条件。下列事项通常需要单独立项或专项确认：

• 离线支付及离线价值同步；
• 面向公众链的代币表示、跨链桥或资产转移；
• 与其他国家/地区 CBDC、DLT 或外汇系统的互操作；
• 大规模跨机构性能目标及生产级跨城灾备；
• 甲方政策尚未确定的限额、KYC、AML/制裁筛查、争议处理和会计处理规则。

02.6 偏差与验收处理

不符合项必须分类为：产品缺陷、配置/部署问题、环境或第三方依赖、需求变更或已知限制。分类须由甲乙双方在验收治理机制下确认。P0/P1 缺陷、未解释的资金/账本/审计差异、严重安全问题和关键交付物缺失不得作为一般遗留项处理。

02.7 甲方需确认的范围基线

主题	需确认内容
业务场景	本期必须覆盖的发行、转账、赎回、G2C、B2B、P2P 等场景
参与方	中央银行、商业银行、PSP、财政部、RTGS 及第三方角色
监管与政策	KYC/AML、限额、冻结、争议、审计、数据保留和报送要求
外部接口	系统清单、协议、数据字段、测试环境、联调窗口和责任人
非功能目标	TPS、延迟、可用性、RTO/RPO、容量周期和测量条件
交付边界	源代码、镜像、部署包、培训、驻场支持和第三方测评责任

详细模板见附录 A。