A Rationale-based Model for Architecture Design Reasoning

7.1. The EFT system
Figure 7.9: Decisions to Support Centralised Control
tivational reasons. In this case, the decisions are AR23 and AR24 and the common
motivational reasons are R5 2 0 and R5 2 1. The result of the inter-related issues in this
case is C8 0 0. Although the two decisions themselves are independent, their causes and
their effects can be common. This example shows that a requirement may cause multiple
issues and decisions, and a design element may depend on multiple decisions. This
multi-way relationships are often difficult to represent in textual specifications.
7.1.7 Message sequencing
One key requirement about payment messages is that every single message must be traceable
and audit logged. This implies that each individual payment message must be
uniquely identifiable (R2 2 3 ). There are many ways to assign an identifier to a payment
message. The decision to be made is to decide which way is most appropriate to the
EFT system. Two alternatives were considered. One alternative is to use a contiguous
sequence number and the other way is to use a non-contiguous number. In either case,
the messages from the EFT system and the messages from the bank must each have its
own number sequence for their unique identification.
Figure 7.10 shows that two decisions are required. Decision AR25 considers that the
sequencing must be contiguous because a non-contiguous sequencing would make message
reconciliation and auditing most difficult. If gaps were allowed, the system could not tell
if a message is missing or if there was a gap in the sequence number. In this case, the only
119