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 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?

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, suzannemaxted@bcs.org or suzanne.maxted@telecom.co.nz

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.

Comments (11)

Subscribe to this comment's feed

...
written by Ken Howard, November 03, 2008

I completely agree with Suzanne. The domain model is one of the most important tools I use to remove ambiguity from requirements. It provides business and technology folks to specify business rules that don't belong in a behavioral model. Nevertheless, it's rare to find other requirements analysts who subscribe to this practice.

• 
• -1
• 
• 

..., Low-rated comment [Show]

...
written by Abhishek Kashyap, November 03, 2008

This article is very useful Suzanne. I agree that the UML plays a very important role in eliciting the requirements. I would like to see more on the categorization of various UMLs as per their usage

• 
• -1
• 
• 

...
written by Mick Wren, November 04, 2008

Suzzanne, I couldn't agree more with the principles. Analysing processes without a thorough understanding of the underlying data is a capital offence in my book. Also, I would sleep a lot sounder if the word 'requirements' was removed from the dictionary and all so called requirements management tools were consigned to a rubbish skip. Listing requirements in a log instead of modelling is like trying to describe someone using only their vital statistics.

However, I would also sleep a lot sounder if UML had never been 'invented'. As a BA it offers me nothing that we didn't already have and further clouds the issue (not to mention, restricts us to systems related work). Most people still think a Use Case is a process and the UML forums are still debating the meaning of 'include' and 'extend'.

You fail to mention good old relational data modelling as an alternative to class diagramming. Without the rigour provided by normalisation (which appears to be optional with OO approaches)class diagramming can fail to provide the required rigour and understanding.

Having said all that it's vital that we get BAs to recognise the value of modelling (in whatever form). As our 'profession' has expanded it has also diluted to the point where the debate is not about how to model, it is about whether to model (as illustrated by the need to publish your article).

Keep up the good work.

Mick

• 
• +2
• 
• 

...
written by Brian Chugg, November 04, 2008

Mick you make some real valid points and I like the one about UML not offering what we didnt already have. You are quite correct we already had DFDs and Flow Charts and Structured english (Use cases) and ER models (Class Diagrams) for modelling the business. We are still making the same mistakes now that we made with them tho. Its just another methodology that we dont use correctly. The problem of course with UML is that it is in IT talk, Use Cases, Class Diagrams, State Diagrams, Activity Diagrams.

Suzanne makes the comment about every BA and Solution Architect in the world would understand a class diagram. Thats great but does the business. We are building a system to solve a business problem and we describe a solution in IT speak. We seem to expect business people to come in to our world and speak our language. Most of them just role their eyes when we start talking UML.

Dont get me wrong I think Use Cases and Class diagrams are great for modelling a business domain. We just need to call them something else to get business engagement. At the end of the day it is really about process (user and system interaction), data and the application of rules to that data within the process.

Suzanne, yes, gotta love those 300 page requirements documents with the "the system shall...." repeated line after line after line after line ........blah blah blah, not to mention all the time taken to manage them with the wonderful set of tools available and the traceability matrices to help us identify what we didnt deliver because we spent to much time manageing our set of one line requirements that resembled swiss cheese. (-:

Would be interested in your thoughts on how User Stories can or cant fit into our world of UML and requirement one liners and business domain modelling.

Brian.

• 
• +2
• 
• 

...
written by Jon Borden, November 13, 2008

Business Domain Modeling is not a panacea. It is only one component (albeit and important one) in depicting a business domain.

I agree that a 300 page narrative does not present a useable tool for analyzing and designing complex business processes. But I would argue that a series of simplified business domain models themselves only provide value if the user of these models have a clear understanding of the attributes and behaviors of the objects depicted.

The value of an electrical circuit diagram or architectural drawing will be negated if the users of these diagrams do not understand the complicated rule of physics and engineering that accompany the objects used in the model.

Vastly different than manufacturing or physical construction efforts, the core elements (object classes) of knowledge work are often not based on the well established laws of science and engineering. Without common definitions for classes and objects, and absent of having a well established pattern of behavior of these objects, knowledge work processes require additional documentation well beyond standard modeling processes to properly depict the business process being analyzed.

Without simplified models, pages and pages of business rules, business regulations, and business object definitions can become a disjointed, inefficient, ineffective tool to analyze business domain process. But, without complete, clear, unambiguous, agreed upon definitions for the model objects, business analysis is bound to fail. Be sure both are known, documented as required by the business and used.

• 
• +1
• 
• 

...
written by Ken Howard, November 13, 2008

Response to Brian: (Hopefully this does the discussion too far off track.) On my projects, User Stories are equivalent in size and scope to what Cockburn calls "Use Case Briefs". The Agile practices could be applied well using Use Case Briefs, as long as proper attention is paid to when they are explored further, and what you do with them. That being said, it's a completely different topic than the use of domain models to express concepts in the domain and their relationships.

• 
• -1
• 
• 

...
written by Quentin R Suskin, December 16, 2008

Brian raises a good point about any kind of modeling. I advise I give to other BAs when doing models of any sort, is to ask themselves this question: Does the model convey the message or understanding required to assist either the business or IT?

At the end of the day, as Brian quite rightly points out, the models must be of use to the audience they are for, otherwise it all is a very nice, but academic, exercise.

• 
• +1
• 
• 

...
written by Suzanne Maxted, February 18, 2009

Thank you so much for all your comments. I appreciate them. Suzanne Maxted

• 
• +0
• 
• 

...
written by Martin Abkiewicz, March 03, 2009

I liked the way that business modelling is described as the way to find beauty and uniqueness in each process and having fun doing it.

• 
• +1
• 
• 

...
written by a guest, June 02, 2010

I remember doing a large formal Domain Model using UML notation for a project a few years ago and alienating a large proportion of the business stakeholder community. The one business stakeholder who did value it greatly happened to be also an experienced and competent OOAD programmer. Recently, I did a lighter Concept Model which I talked through with a (much smaller) set of business stakeholders (sales/marketing). They said they "just about" understood it and it was fruitful exercise. I feel Business Analysts are primarily there to bridge technology with the business and need to produce models that can communicate to all upstream and downstream stakeholders in the process. I do question whether UML is really the end-all, be-all notation to achieve this.

• 
• +1
• 
•