Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Trivialization of Business Requirements
Besides the encryption problem, UML models introduce another problem: trivialization of requirements.
In a business, the importance of a particular business requirement is invariably highlighted by its context. There will be a lot of discussion, debate, meetings, papers, and so on around a particular requirement that underscores its importance to the business. This context is entirely lost in a UML model. UML has no standard way of highlighting the importance of a particular business requirement after it has been expressed in UML. There is, of course, the catch-all of the note, which can be appended to any model element, but that’s as sophisticated as it gets, and it’s generally not enough.
Key requirements often become hidden once they are expressed in a UML model. A particularly good example of this is the code share example I describe in [Arlow 1] and [Arlow 2].
The business practice of code share is where one airline sells seats on another airlines flight under their own branding. For example, on a flight from London to Sydney operated by Qantas, there might be passengers traveling on other airlines’ tickets. Some tickets will have a Qantas flight code, and others might have a British Airways flight code, for example, but all passengers are on the same physical flight. In UML models, this multimillion dollar requirement for code share is reduced to a single UML association and a multiplicity.
In the UML model, these particular and important modeling elements are lost among a myriad of other similar elements. In [Arlow 1] we called this the "trivialization of requirements" by visual modeling languages.