本文收集和分析了统一支付平台的功能需求，包括管理控制台的需求、统一支付服务的需求、平台对账和资金清结算的需求和系统监控需求。针对平台的核心功能，统一支付服务和对账清结算功能，分析了系统的处理流程。最后列出了平台的性能需求和安全性需求等非功能性需求。
1、系统功能需求
1. 管理控制台
为了能够动态参数化管理统一支付平台的各个功能模块，并且为银行业务人员提供实时的业务数据查询展现，需要建设系统展现层的管理控制台。管理控制台是统一支付平台的后台管理系统，仅供银行内部工作人员使用。根据用户的岗位职责，可以将用户分为不同的角色，分别访问不同的页面和数据，进行不同的权限按钮操作。
用户可以在管理控制台查询和管理平台的业务数据、维护平台的基础数据、监控平台的运行情况等。
管理控制台用例模型如图1所示。
图1 管理控制台用例图
2. 统一支付服务
通过对银行支付应用场景的分析得知，统一支付平台主要受理三种类型的支付业务，分别是代收业务、代付业务和网关支付业务。统一支付平台需要提供统一标准的服务接口，兼容银行网银系统和银行各类业务前置系统的发起的支付交易请求。此外，统一支付平台通过请求银行核心系统的相应服务接口，处理本行客户账户的借贷记账务。
统一支付服务用例模型如图2所示。
图2 统一支付用例图
3. 对账和资金清结算
按照银行自身的资金安全和操作合规性要求，支付平台之间每日都将进行对账，然后才能进行资金清结算。平台间对账的结果可分为对账成功、对账失败、对账存疑三种。
对于没有对账成功的支付订单，需要业务人员通过线下多种途径核实，并在平台中进行手工差错处理。统一支付平台的差错处理包括补账、冲正、登记三种方式。
统一支付平台对账完成并且业务人员核实对账金额与支付通道清算金额一致后，业务人员在平台中对相应支付通道进行资金清算处理，平台通过请求银行核心系统的清算通知服务接口，处理资金的清结算。
对账和资金清结算用例模型如图3所示。
图3 清结算管理用例图
4. 系统监控
统一支付平台的支付服务接口每日都会受理大量的支付请求，并且处理每笔支付订单都需要与多个银行内外部系统进行交互，因此为保证统一支付平台运行正常和业务数据正确，需要在统一支付平台中设置定时任务，定时对系统层面和数据层面进行监控。
统一支付平台的监控需求包括支付订单状态监控、支付通道异常监控、代付余额监控等。
系统监控用例模型如图4所示。
图4 平台业务监控用例图
2、系统非功能需求
1. 性能需求
系统投产后一年内的业务量预估如表1所示。
表1 系统投产后一年内的业务量预估
统一支付平台管理控制台页面操作，系统响应时间在 10 秒以内。
统一支付平台的支付服务接口最多支持同时受理100个同步或异步的并发支付请求，请求响应时间要求如表2所示。
表2 平台交易接口响应时间表
2. 安全需求
用户登录密码长度为 6 至 10 位，密码由数字、字母、下划线组成，且必须至少包含其中两种。在统一支付平台中对密码以密文方式存储统一支付平台中的用户按角色分为经办员和复核员。经办员提交业务请求，复核员审核通过后该业务请求才会生效。统一支付平台中可以为某一类角色单独分配菜单访问权限、数据访问权限和按钮操作权限。
平台日志文件中保存每个接口的请求参数和响应参数，日志中不允许出现敏感信息，对于敏感信息要用星号代替。
统一支付平台与支付通道之间的交易报文，必须采用数字证书加密和数字签名认证，以保证交易的合规性和报文的安全性。
3. 可靠性需求
统一支付平台支持 7*24 小时不间断运行。当本平台发生故障时，必须在 2 小时内恢复。当支付通道发生故障时，统一支付平台自动停用该支付通道 30 分钟，30 分钟后系统自动启用该支付通道。
4. 质量需求
统一支付平台基于 J2EE 架构，易于在各种操作系统上进行部署。平台支持 Tomcat和 WebLogic 中间件，支持多种接口协议包括 TCP、HTTP、WebService 等，支持接口的升级和扩展。
统一支付平台页面采用模态窗口，减少用户操作时页面的跳转次数，提高操作效率。
页面展示数据量适中，提供多种数据查询条件的组合，减少用户滚动页面或翻页次数。
统一支付平台界面设计合理，采用日期控件、可选下拉菜单等多种输入控件方便用户输入。对于每个输入控件均做了输入内容格式合法性校验和业务逻辑合法性校验。
