（译自Simon Brown的Software Architecture for Developers II；译者：伍斌）
背景
一家办公室设在伦敦、纽约和新加坡的全球投资银行，与其他银行（交易对手）进行金融产品交易（买卖）。当股票市场的股价上涨或下跌时，银行要么赚钱要么赔钱。在每个工作日结束时，银行需要通过对所持有的交易数据进行一些计算，以了解他们所面临的风险（例如赔了多少钱）。该银行现拥有“交易数据系统”（TDS）和“参考数据系统”（RDS），但需要一个新的“风险系统”。

• 交易数据系统
  “交易数据系统”存储了银行所有交易数据。在纽约每天工作日（下午5点，即新加坡次日早上6点）结束时，该系统会生成并导出基于文件的XML交易数据。导出数据包括银行当天进行的每笔交易的以下信息：

  • 交易ID
  • 日期
  • 以美元计的当前交易价值
  • 交易对手ID

• 参考数据系统
  “参考数据系统”维护银行所需的所有参考数据。这包括交易对手的信息。交易对手可以指一个人或一家银行。“参考数据系统”也可以导出基于文件的XML参考数据，并且包括关于每个交易对手的基本信息。一个新的面向全公司的“参考数据系统”将在未来3个月内完成，目前的“参考数据系统”最终将被替代。

功能要求
新的“风险系统”的功能要求如下。
1.从“交易数据系统”导入交易数据。
2.从“参考数据系统”导入交易对手数据。
3.将两组数据结合在一起，用交易对手方的信息丰富交易数据。
4.对于每个交易对手，计算银行所面临的风险。
5.生成可导入Microsoft Excel的报告，其中包含银行已知的所有交易对手的风险数据。
6.在新加坡的下一个交易日（上午9点）开始之前将报告分发给商业用户。
7.为部分业务用户提供配置和维护风险计算所使用的外部参数的方法。

非功能性要求
新“风险系统”的非功能性要求如下：

• 性能
  • 风险报告必须在新加坡的下一个工作日上午9点之前生成（即3小时之内生成）。
• 可伸缩性
  • 该系统必须能够应对未来5年的贸易量。
  • 目前每次“交易数据系统”导出约5,000笔交易，预计每天还会增加10笔交易。
  • 目前“参考数据系统”交易对手导出约20,000名交易对手，未来增长可忽略不计。
  • 全世界有40-50个需要访问报告的商业用户。
• 可用性
  • 风险报告应该全天候为用户提供，但可以容忍少量停机时间（每天不到30分钟）。
• 故障转移
  • 对于所有系统组件都可进行手动故障转移，前提是可以实现上述可用性目标。
• 安全
  • 该系统必须遵循银行政策，该政策规定系统访问仅限于经过认证和授权的用户。
  • 报告只能分发给授权用户。
  • 只有授权用户中的一部分人被允许修改风险计算中所使用的参数。
  • 没有实现单一登录的要求（例如与Active Directory，LDAP等的集成），当然如果有会更好。
  • 所有对系统和报告的访问将在银行全球内部网络的范围内进行。
• 审计
  • 以下事件必须记录在系统审计日志中：
    • 报告的生成。
    • 风险计算参数的修改。
  • 用于调整计算风险的输入参数必须有理由说明。
• 容错和弹性
  • 如果可能的话，系统应该采取适当的步骤来从错误中恢复；所有的错误都应该被记录。
  • 如果某个交易对手的风险计算发生错误，那么应该将错误记录下来，并继续进行余下交易对手的风险计算。
• 国际化和本地化
  • 所有用户界面仅以英文显示。
  • 所有报告将仅以英文呈现。
  • 所有交易价值和风险数据将仅以美元呈现。
• 监控和管理
  • 在下列情况下，应将“简单网络管理协议”（SNMP）陷阱发送给银行的中央监控服务：
    • 系统组件发生致命错误时；
    • 新加坡时间上午9点之前还没有生成报告时
• 数据保留和归档
  • 风险计算过程中使用的输入文件必须保留1年。
• 互操作性
  • 与现有数据系统的接口应符合并使用现有的数据格式。

Financial Risk System
(Software Architecture for Developers II by Simon Brown)
Background
A global investment bank based in London, New York and Singapore trades (buys and sells) financial products with other banks (counterparties). When share prices on the stock markets move up or down, the bank either makes money or loses it. At the end of the working day, the bank needs to gain a view of how much risk they are exposed to (e.g. of losing money) by running some calculations on the data held about their trades. The bank has an existing Trade Data System (TDS) and Reference Data System (RDS) but need a new Risk System.

• Trade Data System
  The Trade Data System maintains a store of all trades made by the bank. It is already configured to generate a file-based XML export of trade data at the close of business (5pm) in New York. The export includes the following information for every trade made by the bank:
  • Trade ID
  • Date
  • Current trade value in US dollars
  • Counterparty ID
• Reference Data System
  The Reference Data System maintains all of the reference data needed by the bank. This includes information about counterparties; each of which represents an individual, a bank, etc. A file-based XML export is also available and includes basic information about each counterparty. A new organisation-wide reference data system is due for completion in the next 3 months, with the current system eventually being decommissioned.

Functional Requirements
The high-level functional requirements for the new Risk System are as follows.

1. Import trade data from the Trade Data System.”
2. Import counterparty data from the Reference Data System.
3. Join the two sets of data together, enriching the trade data with information about the counterparty.
4. For each counterparty, calculate the risk that the bank is exposed to.
5. Generate a report that can be imported into Microsoft Excel containing the risk figures for all counterparties known by the bank.
6. Distribute the report to the business users before the start of the next trading day (9am) in Singapore.
7. Provide a way for a subset of the business users to configure and maintain the external parameters used by the risk calculations.

Non-functional Requirements
The non-functional requirements for the new Risk System are as follows.

• Performance
  • Risk reports must be generated before 9am the following business day in Singapore.
• Scalability
  • The system must be able to cope with trade volumes for the next 5 years.
  • The Trade Data System export includes approximately 5,000 trades now and it is anticipated that there will be an additional 10 trades per day.
  • The Reference Data System counterparty export includes approximately 20,000 counterparties and growth will be negligible.
  • There are 40-50 business users around the world that need access to the report.
• Availability
  • Risk reports should be available to users 24x7, but a small amount of downtime (less than 30 minutes per day) can be tolerated.
• Failover
  • Manual failover is sufficient for all system components, provided that the availability targets can be met.
• Security
  • This system must follow bank policy that states system access is restricted to authenticated and authorised users only.
  • Reports must only be distributed to authorised users.
  • Only a subset of the authorised users are permitted to modify the parameters used in the risk calculations.
  • Although desirable, there are no single sign-on requirements (e.g. integration with Active Directory, LDAP, etc).
  • All access to the system and reports will be within the confines of the bank’s global network.
• Audit
  • The following events must be recorded in the system audit logs:
    • Report generation.
    • Modification of risk calculation parameters.
  • It must be possible to understand the input data that was used in calculating risk.
• Fault Tolerance and Resilience
  • The system should take appropriate steps to recover from an error if possible, but all errors should be logged.
  • Errors preventing a counterparty risk calculation being completed should be logged and the process should continue.
• Internationalization and Localization
  • All user interfaces will be presented in English only.
  • All reports will be presented in English only.
  • All trading values and risk figures will be presented in US dollars only.
• Monitoring and Management
  • A Simple Network Management Protocol (SNMP) trap should be sent to the bank’s Central Monitoring Service in the following circumstances:
    • When there is a fatal error with a system component.”
    • When reports have not been generated before 9am Singapore time.
• Data Retention and Archiving
  • Input files used in the risk calculation process must be retained for 1 year.
• Interoperability
  • Interfaces with existing data systems should conform to and use existing data formats.