Banking Systems
From requirements to go-live: where the main functional risks are created
Production incidents are often blamed on the code. Yet, tracing the chain back, the cause frequently sits upstream: an ambiguous requirement, an implicit rule, an edge case never stated. Functional risk is created early and paid for late.
The ambiguity of requirements
A requirement written in business language often leaves room for several technical interpretations. Each unresolved interpretation becomes a silent assumption — and a potential defect. Naming these gray areas explicitly at scoping costs a few hours; discovering them during acceptance costs weeks.
Implicit rules
In banking, many rules “go without saying” for business experts and remain invisible in specifications. These are the ones that resurface at the worst moment. The analyst’s job is precisely to make explicit what is taken for granted.
Forgotten edge cases
Exotic currencies, accounting cut-offs, cancelled-then-replayed operations: edge cases are rarely described, often poorly tested, and almost always behind the most visible incidents. Anticipating them at functional design is more efficient than fixing them afterwards.
Continuity as a safeguard
The best antidote to functional risk is continuity: the same requirement scoped, specified, tested and validated by an unbroken chain of responsibility. That is exactly what an organisation loses when it multiplies intermediaries between business and delivery.