As human beings we created language and learned to classify objects in the world around us so that we could share concepts and ideas. Then we learned to write … and we haven’t yet learned when to stop! Often, repeated refinement of our customer’s problem and need statements are seen as measures of quality and completeness of requirements. It’s almost as if the greater the weight of the document the higher the quality!

The purpose of business modelling, and of our role as business analysts, is to describe the business and its intentions. According to The Unified Modeling Language (UML) User Guide, “a model is a simplification of a complex reality … so that we can better understand …” A model allows us to find meaning in the business domain and to communicate an understanding effectively to others. It helps the business owners to visualise together with us, and to specify their intentions in a disciplined and rigorous way. It is difficult for the business to manage what they cannot see. In a model, existing concepts and new requirements can be seen logically related to each other.

The beauty and uniqueness of a business is usually found in its business process and most business analysts are familiar with modelling the business process at some level. If we can answer the question “what happens next?” then we are dealing with a dynamic view of the world, i.e. depicting the behaviour and activity of the business area of interest. For example, the following (simplified) diagram of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

The (simplified) use case summary diagram depicts the proposed use of the system for the trader. To specify our requirements, we have developed the business process and the use cases in a model. Is there more to do? Can we assume that any audience of this view will understand the concepts referred to – the ingredients of the business process recipe? This article proposes that a critical part of requirements elicitation is to understand and provide a static or structural view of the business domain.

We may ask “What is the point of business domain modelling?” The point is that we need to understand the things that we are referring to in the business process and use cases. Remembering that human beings need to ‘classify’ objects around them in order to understand the world and to communicate an understanding, we use the concept of a “class” to sketch the important things that exist for our customer. It is a view of what we need to understand and reach agreement about.

It is the view that gives us the truth – it communicates the things that are true no matter how we behave, no matter what time of day it is and no matter where we are in the business process. In this example, we need to answer the questions: What is a “certificate”? Can a “trader” apply for more than one? What does a certificate certify?

For readers not familiar with the UML, the food export business domain model, in the form of a class diagram tells us that a Trade is an aggregation of a set of Commodity Goods Items. An Export is the type of Trade relevant to this piece of work, along with the CAP Export type Certificate.

In this example, if we do not understand the important concept of a certificate and how it relates to a “trade”, the proposed software may not capture the critical business rules to prevent the trader’s potential loss of thousands, even millions of tax refund. Seeing these two concepts, and the business rules that associate them, pictorially, in a formal standard notation, makes it easy for us to ask the right questions and for the business to see whether the description of their business and of their need is correct. Consider the impact of not understanding the ingredients of the business process recipe.

Only the important detail has been captured for the food export requirements, i.e. that one or more Certificates can authorise a single Trade and a single Certificate can authorise one or more Trades. This is important because if a Certificate is not fully ‘used’, the tax refund for the unused part cannot be claimed by the Trader.

It took many questions to understand this because some traders matched their certificates one-to-one with their trades; some traders had lost certificates, some had let certificates expire, some had checked that government regulation would allow them to use up portions of certificates to authorise a trade. It would have been difficult to find those questions had I not drawn what the traders were saying and instead, simply had written down verbatim what they thought they wanted based on their problems. Modelling the requirements was an easy way to resolve any contradictions and to capture the most important business rules to provide real benefit to the trader.

It is important to model the business domain or as my favourite writer on the UML, Martin Fowler says, the “logic that is the real point of the system”.

The alternative is to write a similar amount of text as found in this paragraph for each “requirement” and lose the advantage of adding to the model. In addition, the process of documenting, reviewing and refining this text would cost a great deal more than asking our business customers to sign the whiteboard with the confidence that the domain model / use cases (i.e. requirements) covered on it have been captured correctly.

So often errors are found in traditional requirement documents after sign-off because so many statements were made, unrelated to each other, where no logic could be applied to associate them. Another reason for so many errors could be that the requirements i.e. a very long list of textual requirement statements, are never read – they are so very boring and time-consuming to review.

I once reviewed a high-level requirements specification comprising 300 pages of textual requirement statements. I counted 321 instances of the word “customer” and 656 written instances of a few other major business classes. I counted nearly 7000 instances of eight common words such as “to”, “the”, and “system” – words of no value or interest. I wonder how many more words of the total 38000 were unnecessary and meaningless, and that required time to be written, read, refined and read again by numerous people up and down stream of the author.

In a requirements model, these few words of real interest would be written a few times only. In a business domain model, or class diagram, expressing those requirements in relation to each other, it would be necessary to write each word once only as the name of a class (while in a workshop with our business customers of course). If the business architecture was already established in the organisation, then it would be necessary to simply reference them, rather than re-invent them (again!); one would simply familiarise oneself with the area of interest and then visualise the proposed change together with the business owners.

Business domain modelling can be applied to any concept.

Modelling and communicating business concepts in a standard notation keeps it easy for our customers … our service remains consistent and audiences beyond the here and now can understand and reuse our work. When I draw a purple triangle, I know what it means. You, the reader, do not. However, if you or I were to draw the following simple class diagram, every single business analyst and solution architect in the world, even the occasional project manager, should be able to understand it.

I am currently working in a project team with English speaking Russians – there is no language barrier when we show them our model drawn in our common language – the UML. The UML modelling notation, for the purposes of describing business, commonly uses about 15 simple symbols which can be nonchalantly explained to subject matter experts during a workshop session without burdening them with any lengthy training. My experience of appropriately exposing the UML to my customers has been, without exception, very positive.

Modelling or graphical notations were invented to precisely convey a concept and to depict a great deal of information in a concise way, rather like electrical circuit diagrams or architectural drawings. Their other purpose is to act as precise shorthand for what we verbalise and know to be true. Would it be natural for an electrician to write “the electrical system must allow the electrical current to flow into a capacitor which must discharge into a resistor”? A simple line drawing with universally understood meaning and without ambiguity suffices to say the same thing. Its advantage is that further requirements will be part of the same drawing and any defects or conflicts can be spotted easily in relation to the other elements on the diagram. In addition, should any changes to the implemented electrical system be necessary later, the model could be reused by other people to understand the current system and the impact of the proposed changes. That is impossible with hefty volumes of prose.

Business modelling is much more fun than writing a requirements novel that few people have time to read. I call on project managers and business analysts to dispense with their document weighing scales and embrace clear, correct and effective communication of ideas and business concepts.

In a future article, we will look at modelling the business actors and areas of interest in order to express the current business problem and to propose the goodness or scope of a project i.e. setting the scene or business context ready for further analysis.

This article is based on one of the “Truth, Beauty & Goodness” series of presentations named “The Importance of Business Domain Modelling” given by the author at the Business Analysis World Symposium 2008 held in Wellington, New Zealand. The author wishes to express her thanks to the following people for their thoughts and ideas freely contributed to this article: Lawson Davies, Brent Lewis and John McPherson.

Copyright © Suzanne Jane Maxted, October 2008, [email protected] or [email protected]

Suzanne Jane Maxted is a Certified IT Professional Member of the British Computer Society. She gained a Bachelor of Honours degree from the University of Sussex, England, in Mathematics & Statistics with European Studies (French). Suzanne is a business analyst with 16 years information systems experience from around the world. She is an accomplished workshop facilitator and presenter in the business analysis space and has given presentations to senior Member State representatives at the European Commission and at the United Nations, among others. She takes pride in applying logic and order to differing business viewpoints and in communicating common understanding. Suzanne teaches ballet to 3-8 year olds on Saturday mornings and fills her spare time dancing and having fun with her two little children.