The trivialisation of business requirements in visual modelling
We all know that some business requirements are more important than others. But often, you can’t tell from a blunt statement of the requirement just how important it is to the overall operation of the business. In order to appreciate the true importance of a requirement, you need to see it in it’s business context, but it is precisely this business context that is lacking in conventional UML models.
In the real world, you may notice that important business requirements are often highlighted by a certain amount of activity and ceremony – there may be papers, working groups investigating the requirement and discussion at managerial level. This activity is a key indicator that something is perceived to be important to the business by those in charge.
But all of this valuable contextual information is absent from the UML model. Although you may have a statement of a particular business requirement as part of a UML use case, you have no formal mechanism to highlight the importance of this requirement or to set it in its true business context.
Worse, when the requirement is expressed in a class diagram, it becomes merely a cluster of modelling elements much like any other.
Rather than being highlighted in the UML model, essential business requirements tend to fade into the background. This is what we mean by trivialisation.
In [our paper] we present the following example from British Airways that illustrates trivialisation.
The last decade has been the decade of the global airline. Globalization often involves forming alliances so that one partner may sell seating capacity on another partner's flight. This practice is known as codeshare.
Codeshare is good for the airline, as it extends its network, and it is good for passengers, as they can complete a complex journey using a set of
co-operatingcompanies. It can also improve customer service. In fact, codeshare can generate new business worth millions of pounds.
For example, a single operating flight from London, Heathrow to EuroAirport (Basle, Mulhouse, Freiburg) on 23 July 2002 at 21:00 may have a BA flight number (BA6670), a Swiss flight number (LX371) and be operated by Swiss. It will also have an operational flight number that is the "real" flight number as far as air traffic control is concerned.
You can see that it is an essential business requirement for alliance partners to be able to support codeshare in their systems. The key to this support is that each flight must be able to have many flight numbers.
But how do you represent this key business requirement in a UML model?
From the use case perspective, it’s not entirely clear where the requirement gets captured. There will be a use case involving a BA customer flying on a BA flight. But it is unlikely that there will be any mention of codeshare in this use case as the principle of codeshare is that it is meant to be transparent to the BA customer.
In the class diagram codeshare is represented as a many to many relationship between
FlightNumberas shown in [the following figure].
multimillion-poundbusiness requirement, effecting an alliance of companies together worth billions, is represented as a multiplicity on a UML Analysis class diagram!
This sort of trivialisation is surprisingly common when you begin to recognize it.