Author: Suzanne Jane Maxted

Business Analysis Scenarios; Understanding the Business Interactions

Written by Suzanne Jane Maxted on June 1, 2010. Posted in Articles. 94 Comments on Business Analysis Scenarios; Understanding the Business Interactions

In previous articles we examined the use of a business context model, and which concepts exist and what is true, using a business domain model. And we looked at how business behaves in the business analysis process article.

This article discusses the role of Business Scenarios to express connections between people and business elements and suggests a way to model them. Even to this day, the clarity and beauty of the jewels of truth of a business are frequently obfuscated in an avalanche of inexplicit verbiage (ha ha!) – and the poor old techies have to pick out the gems from the piles of verbal diarrhea disguised as ‘documentation’.

A business scenario can be used to:

Understand the business interactions.
Prototype or storyboard a piece of software from a business point of view without presenting screens and buttons which distract from the point of the exercise, thereby keeping the design activity separate.
Test the completeness of requirements, thereby finding gaps in the logic understood so far. For instance:
- Test for completeness a single path through a business process or use case
- Find characters in the story (domain classes) that have been missed and their responsibilities
- Understand changes to characters in the scenario (state changes)
- Understand a ‘user story’
- Use as a test case for a new system component
Take notes as an observer or to further our own understanding; a tool for asking questions.

The aim of a scenario is to understand and communicate a single interaction between the people, systems or anticipated logical components of a business or system. In other words, a business scenario is simply a conversation between people or things/objects in the business.

Scenarios are also a good tool for testing theoretical business processes and domain models by using real-life examples or instances of a situation and the people in it. Although we are specifying behaviour in a business scenario; specifying one single real-life instance renders business scenario modelling a separate tool from modelling business process or use cases.

So how do we start building a business scenario? Using the idea of holding a conversation, imagine that all the things that exist in the business are people or invent people that can talk to other people. For example, I need a way to handle billing once I’ve placed an order. I don’t know what the concepts are yet for billing but I do know that there exists something called Order. Imagining that Order is a person, it will need to have a conversation with some other thing or person. I’m going to call it the Billing Manager (a logical component because I don’t know enough to break that down yet). Now these two ‘actors’ in the business process can have a specific dialogue (say, a single path through a business process or use case if these have been specified already).

Business scenarios can be written as a set of scenario clauses of requests and orders moving around the business using the following grammatical construct: – subject verb noun object

Example Scenario:

Joe asks “will you fix my bike?” to Fred
Fred replies “yeah, if you pay me” to Joe
Joe asks “how much?” to Fred
Fred replies “$100 mate” to Joe
Joe says “OK” to Fred
Joe gives bike to Fred
Fred fixes bike
Fred says “I’ve fixed your bike. Please give the $100 to Mum” to Joe
Joe says “thanks, I will” to Fred
Joe pays $100 to Mum
Mum asks “what’s the $100 for?” to Fred
Fred replies “savings for a new bike” to Mum

This is a perfectly valid way of expressing a business scenario. However, the old problems crop up. We have written “Joe” nine times instead of once, “Fred” 11 times instead of once and written “Mum” four times instead of once, thereby increasing our workload. We cannot reuse what we have created in this scenario To use or reuse “Joe” say, in other artefacts; we have to type “Joe” or copy “Joe” each time. In addition, the knowledge gained here will be lost in a document and difficult to find later on, as opposed to maintaining business architecture in a good modelling tool allowing us to simply drag Joe into the picture next time he crops up in conversation. The model element “Joe” would not be a modified clone. It would be the one and the only Joe.

One way of introducing stakeholders to modelling business scenarios is to begin writing it as above on a whiteboard, and then convert it into a diagram by erasing the object names on the left and right sides, and by adding the direction (arrows) of ‘conversation’ and the people (object lifelines) involved as follows:

Joe		Fred
~~Joe asks~~	“will you fix my bike?”→	~~to Fred~~
~~Fred replies~~	←“yeah, if you pay me”	~~to Joe~~
~~Joe asks~~	“how much?”→	~~to Fred~~
~~Fred replies~~	←“$100 mate”	~~to Joe~~

Messages are represented by an assortment of arrows (as with all modelling techniques, I recommend that the reader researches the notation available) but basically, the messages sent are either calls (an order or request) for a service of another object or returns (answers) to the calls. (Note that services offered by an object are operations on a class.)

Here is the scenario expressed as a UML sequence diagram:

I prefer to use the Unified Modelling Language (UML) because:

It is broadly accepted as a worldwide standard formal notation,
It allows me to cover all the types of modelling I need to do with only one notation
I can use an existing standard notation with my business audience rather than impose one or more non-universally understood notations that colleagues and I have invented.
I can maximise the reuse of model elements, reduce my workload and eliminate inconsistencies and errors in terminology, and in notation, across all diagrams.

In my experience, business and technical audiences love the precision and speed of describing the business given by a business analyst who can think in an abstract and logical way, and who uses meaningful labels for model elements. The only exception I have come across was a business owner who claimed to be a verbal thinker and who found it difficult to review a diagram later. However, her complaints to the business analysts were about endless repetition and inconsistencies in text and one feedback comment said ” …should not ignore the business scenarios analysis!” and another “I expected to see those stick diagrams …”.

My recommendation is to use UML sparingly and pragmatically, referencing help manuals to avoid breaking the rules as far as possible. I use only four to five symbols in a workshop session – easily digested by a high calibre business audience. My intention in a workshop is not to teach UML to my business. I may not even mention UML, but simply reassure the audience that I am using the current standard notation to the best of my knowledge for describing business. As I record (much more quickly than I could in prose) what is understood and agreed, I ‘speak’ the symbols as I draw them. Later, when I have formalised the model, I talk it through with those who would like another viewing. My other rule is never to send or hand over a model without having gone through the above process with the business audience.

Back to scenarios: a respected solution architect colleague told me that allowing a business analyst to do sequence diagrams is like handing a carving knife to a toddler. I protested but found myself wondering if he was right. Given the general propensity in organisations to jump into solution mode and talk about systems, he may have seen a number of business analysts stepping on the toes of the solution team instead of focussing on business concepts and objects when modelling, albeit not ignoring constraints imposed by existing solution components. I’ll come back to this point.

As with any modelling technique, it is important to judge when it would be appropriate to use, as there would not be time to develop every possible business scenario. To scope this work, think about the core business services that respond to the goals and expected outcomes of important external stakeholders. On the other hand, I know a business analyst who uses this tool by preference as a starting point for his understanding. If you do use them, then I would recommend modelling the successful happy day scenario i.e. what should happen 80% of the time, and a few major and typical exception scenarios for each major domain of the business. Certainly, in the book I’d like to write, they should be created by the business and testers with the help of the business analyst. For the advanced modeller, I recommend researching the principles of distributed control and encapsulation to reduce the impact of future changes by keeping related behaviour and data together.

Back to my point. Let’s not forget, a business analyst’s role is to analyse the business, describe it and its intentions. In this and the articles referred to at the start, we have focused on understanding, specifying and communicating the problem, the scope and the requirements of business change. If we stick to business concepts and business speak, we won’t run the risk of scaring our audiences with models of a technology bent. We need to record the business talk in a sophisticated and useful way, and keep it looking like a real human conversation.

Don’t forget to leave your comments below

Suzanne Jane Maxted BSc.(Hons), MBCS CITP, is a business architect and analyst with 17 years experience from around the world. She is an accomplished business modeller, workshop facilitator and presenter. Suzanne coaches business analysts and project managers, and is a regular contributor to the Business Analyst Times magazine, with extensive hits and positive feedback from readers. In 2008 and 2009, she was a speaker and panel member at the BA World Symposium in Wellington, NZ. Suzanne fills her spare time teaching and performing dance (performed NZ Dance Festival 2007, Wellington Cuba Street Carnival 2009) and having fun with her two little children. She can be reached at [email protected]

Business Process; A Thing of Beauty

Written by Suzanne Jane Maxted on March 3, 2009. Posted in Articles.

The English romantic poet John Keats wrote in the poem Ode on a Grecian Urn ‘”Beauty is truth, truth beauty,” – that is all/Ye know on earth, and all ye need to know.’ This article proposes that, by recognising and reflecting on how a business behaves, we can find, cultivate and hone its beauty by clearly seeing the culture and behaviour that will make that business uniquely successful in its chosen field.

The previous articles in this series looked at seeking out good by setting the scene using a business context model, and at finding the truth within a business by understanding what real things exist and are true at any time of the day, however the business behaves, using a business domain model. This article looks at why we model the dynamics of a business and its people.

Unless we can see how the business behaves, it is very hard to understand it. It is therefore important that we can encapsulate what the business does so that we can refine and streamline its behaviour, reduce unnecessary complexity and focus on purifying its business offering. As an analogy, an athlete will develop a process to maximise performance, eliminating all unnecessary activity. There may be a small measure of uniqueness in the process depending on the physical and mental nature and build of the particular athlete, but most athletes will follow a similar process for their sport.

There are two main camps nowadays when choosing a notation for modelling business process. I like to use the Unified Modelling Language (UML) because my business customers tell me that it is easy to pick up and read and because it covers all the types of business modelling that I require (dynamic and static). The Business Process Modelling Notation (BPMN) covers only business behaviour (both notations are owned and managed by the Object Management Group). In addition, many government bodies and industry groups such as the United Nations, the World Customs Organisation and the Telemanagement Forum set standards and industry patterns using the UML.

There is another faction – those who describe the business without a notation – the textual modellers who have the genuine concern that their business people will not like or understand the standard notation.

I have only ever experienced positive feedback on the notation, willingness and enthusiasm from the business and an immediate understanding of a few simple symbols, but, it is our job to create and communicate understanding, not the notation’s job. The notation is simply a language with a ‘dictionary’ and some ‘grammar’ rules. It is our job to ask all the right questions in the workshop (remembering we should always model with the business), to apply logic to a number of jumbled verbal descriptions of what is going on and to label each model element in a meaningful way in order to communicate the understanding reached. Otherwise the business will not understand the result! It is the combination of analytical skill and of the UML notation which won the following accolade. Recently during a domain modelling session (please see the article “The Importance of Business Domain Modelling“), a fellow business analyst, new to the UML, told me that he had looked down to think about something, then had looked back up at the whiteboard and exclaimed to himself how well the entire discussion had been recorded in a matter of seconds.

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) UML activity model of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

Note that a business process always has a starting point, a finishing point and directions on where to go when there are several paths to choose from. These are three of the most frequent review comments I make. Apply rigour and logic! For instance, I can only trade goods if a certificate was issued. Also note that the activity swimlanes (Goods Trader and Certification above) can be derived from the business context model (please see the article “The Business Context Model: As Good as it Gets“) by reusing the actors and business services or areas of interest already identified. The most frequent review comment I make is about the words used to name an activity. Each element in any model must be labelled in a meaningful way. I often see activities labelled like this – “Do Administration” or worse “Enter Data”. These have no meaningful business goal and therefore we cannot hope for good understanding.

Incidentally, it is useful to model at a higher level as we learn about the business; the business use case model is an ideal way to model disjointed business processes that do not logically flow one to another. For example, in international trade, we might identify the processes that are important to our piece of work in the following way, perhaps including a description (in a good modelling tool of course) before we model each process. They should be named to express an important result of value to the business or a major goal. We could even use the strategic business objective as the business use case name.

A business use case is also a useful container for business policies, business rules and constraints which can later be inherited by any software specified.

While some people think that specifying software requirements is the only aim of a business analyst, my view is that this activity should be regarded as a possible end goal depending on the findings of analysing the business. While the focus of this series is on business analysis, I will diverge a little to help refocus our attention on the business when we do step further into software specification i.e. to specify structured functional software requirements as system use cases (because a use case describes a single interaction between a user and a system that meets a goal of the user). There is misunderstanding about why we have use cases. Briefly, a system use case exists to partially or wholly automate and support a business activity in a business process. Therefore, we should not invent use cases from thin air. They should be derived. I have just read an article giving guidance on how to choose whether to model use cases or business process. I claim that we cannot know which use cases we need without studying the business process they are there to support. Otherwise, it’s like administering medicine without knowing what’s wrong with the patient.

How do we derive use cases? By studying the current behaviour of the business and improving it to a more desired state and then by looking at which activities we can enhance and support further. Please reference the Capability Maturity Model Integration [CMMI] which is an open framework for business process improvement describing five levels of business maturity: Level One is otherwise known as the ‘Beast’, and we might nickname Level Five as ‘Beauty‘. This begs the question – how do we know when we have found a system use case? The answer is when the goals of the business process are understood. What I mean is that we must model goal focused activities and those goals, once recognised, will guide us in informatively naming those activities in Verb + Noun format. When we understand the goal we have a system use case – possibly with the same name. If we don’t understand the goal of an activity, then we must look closer, like we do when showing a bee on a flower to a child – what is the bee doing and why? It may be that the activity identified is too ‘big’ or too ‘small’ and we need to ask many more questions.

Only by deriving use cases from a good logically thought out business activity model can we be sure that our software requirements analysis will be fit for purpose. How else would we know? By writing down the wish list of our business people, hoping that everyone can remember exactly what they said in the requirements meetings so that the 300 pages of free text that resulted are not subject to an endless round of revision? In addition, praying that the statements made can act, in a timely manner, as an accurate specification that really does meet the subset of business goals and objectives assigned to the piece of work from the overall business strategy?

Many business process modellers like to model in ‘layers’ and I am often asked how many layers one should model and what level of detail is required at each level. Some industry standards also model in layers, such as the Telemanagement Forum’s eTOM business process model. My preference is not to layer the business process, because I want the model to be public and exposed, say on my business owner’s wall, and I want the model to be useful as a focus for meetings and discussions. This means that it must fit on one page if printed! I have often seen four walls completely covered by a single layer process, or layers upon layers of business process never used again after the model is “completed” – incidentally the model can never be completed in my book. It is really a judgement for each modeller to make depending on their piece of work, but I prefer a single layer with exceptions modelled on further pages so that I can keep the main process on one page (“main” = what happens most of the time with exception activities shown to indicate when something goes wrong). This may mean that I must keep the goal of each activity quite ‘big’.

Of course, the best businesses are never complacent, always proactively striving for enduring beauty: measuring and optimising business objectives and activities; and visualising the business economics (cost, revenue, benefits). Therefore a model of the business process can never be complete – it is a snapshot of an ever evolving set of activities.

With a smoother running process, we can focus our attention on what really counts – the value chain; designing and pricing products and services. It can be a painful realisation when we know we must actively go looking for inefficiencies in our daily business life. After all, beauty is pain, so the saying goes.

The Business Context Model; As Good as it Gets

Written by Suzanne Jane Maxted on December 1, 2008. Posted in Articles. 2 Comments on The Business Context Model; As Good as it Gets

The Greek philosopher Socrates said “In the world of knowledge the idea of the good appears last of all, and is seen only with effort”. This article proposes that as business analysts we must have the audacity to seek out the good of a project using thought and effort to find the real business goals early on.

A business context model needs to express the current business problem and to propose the goodness and scope of a project.

I vividly recall after one particular business context modelling workshop, a senior business manager at a government agency said to me “if only we had started project x in this way, we would have reached agreement about what we were trying to do so much faster.” I have received positive feedback from stakeholders in multiple projects and also from other business analysts who see this technique as a useful tool to engage the business and to orient themselves in the program of work.

The business context model should identify the actors (people, organisations, systems) who play a significant role in the business process or in the business domain, and the business areas of interest relevant to the scope of the work and potential change which may require exploration and further analysis.

At this early point in the project we are business modelling at a very high-level in a fairly imprecise way i.e. taking a helicopter view of the business. We should not model detail such as inputs, outputs, business rules, attributes, operations, or states. We are simply trying to set the scene. By doing this graphically, we gain all the usual benefits of modelling, not least using the business context model as a vehicle for merging differing business viewpoints quickly, and for asking the right questions.

We may start more detailed analysis alongside our context modelling depending on our style of modelling. We may create a snapshot context model to kick-start our project, or we may continue to correct the context models through the project, again, depending on need or style.

I have seen all manner of “context” diagrams – current state, future state, environment diagrams, system diagrams, network diagrams, communication diagrams, business process diagrams, relationship maps, organisation charts, etc. Most of these use inconsistent notation within the diagrams themselves and, more significantly, do not set the scene for a newcomer. They are usually meaningless and business illiterate. Putting business context modelling “in context”, we need a snapshot of the business and its problem and another of its intention.

How do we start modelling context? After gathering the business customers in a room, the end customer is the first thing I draw on the whiteboard. Otherwise I am unable to ask meaningful questions about the problem or to begin the task of analysis. Then we need to discuss the problem and draw it; this represents the current state only and the reason for initiating the piece of work. The example below represents the current problem with importing and exporting goods in some countries.

For readers not familiar with the Unified Modelling Language (UML), a package indicates an area of interest. A stick man represents any actor in the business domain – a person, an organisation (which in turn represents its customer facing channel such as a website or business-to-business gateway), or a system. I prefer to show a system as a stick man because I need to remember, as a business analyst, that it is playing a part i.e. it is an actor in the business process, performing some of the business activities. I am not in the business of drawing a map of the organisation’s systems but of focusing on the business activity and business logic. It is also worth bearing in mind that when modelling context, we are not yet trying to elicit software requirements.

I use the UML notation for context modelling because the modelling language is consistent with other model artefacts, such as a business domain model (please see my article, The Importance of Business Domain Modelling in the November 1/08 Business Analyst Times). It is understood worldwide and by audiences outside the current piece of work, for example, another business analyst on another project, and I can reuse or trace to elements already created.

I have always had positive feedback from my business customers while using the UML notation. Moreover, they have always understood what we have created together in the UML. There is no perception that I am using “IT speak”. In workshops, I talk about the business objects that we are interested in and only briefly mention, as we go along, the four or five simple symbols that I will introduce that day. I can only say that, as a business modeller and analyst, it is so much better, so much easier, so much quicker and so much fun compared to all the other techniques I have tried and used over the years.

The following business context model expresses how to “make good” the import / export problem expressed above. The scope of the project is indicated by the boundary box. I have named the new package as “new bunch of stuff” to highlight that we need to think carefully about a new name. We can include important statements such as business objectives – they may be sourced from a project brief, from some statements made and clarified in the context modelling workshop, or from any other source such as a staff communication from the Chief Executive.

Critical to the business modelling activity is traceability, from our solution defined elements, such as a use case, to the original business statements, such as business outcomes, objectives, benefits or scope statements, which the project activity is addressing. By including significant project statements in our model we begin immediately to create traceability and business engagement to clarify meaning.

Spending an hour or two in workshop with our business customers at this stage will save hours of revisiting these discussions amongst individuals. The workshop might be intense and hard going but it sets us up well for a smoother run when we begin modelling proper.

Replicating the model in a good modelling tool to formalise what was agreed in the workshop takes very little time and is simply a rubber stamp exercise, while of course having the enormous benefit of being straightforward, explicit and not open to individual interpretations and agendas. As an aside, in this example the scope context model took less time to create than the problem context model because I reused the model elements already created.

We can introduce other model elements for clarity. In this new example, the following context model expressing scope includes a package that contains a particular service offering (as an object) as a scope statement. We might also add primary information flows such as “customer order”. Of course, by moving the boundary box we can easily express the scope of another project.

A package in the UML can be used as a way of breaking up the mass of business complexity into manageable chunks; I use them to indicate a business area of interest. It is for each business analyst to judge just how these are cut, however it is important to name the packages in the same way that the business customers think of them. The general guideline is to use the package to contain a “bunch of stuff”. Hence, collective nouns are good words to use e.g. xyz management, family. I have named packages as departments, areas of functionality that align with an industry pattern e.g. sales order management, or again, simply a ‘bunch of stuff’ e.g. border security.

If we put effort into seeing the good in a business or in a project we can easily set ourselves up well for further analysis and full traceability to the original business need, saving us so much time later. Each area of interest could be the basis for some business process relevant to the piece of work. The package name may become a swimlane of activity in the first cut of our business process, alongside swimlanes for each actor identified in the context model, if appropriate. The packages within our boundary box will contain the business logic, rules and use cases to support the business activities and interactions in scope. One of our goals as modellers is to give ourselves maximum opportunity to reuse model elements already created.

We can use context modelling for anything important we wish to think about, perhaps even for making family plans or for helping us to think through strategic decisions and commitments, and regulatory requirements. Below is an incomplete example that I baked earlier about reaching fulfilment in all aspects of life.

The packages, actors and associations have been depicted in this way to allow analysis to take place, the results of which may relate directly to elements in the context model. We are aiming to reduce our workload and reuse work already done. Using a good modelling tool, not a drawing tool, allows us to do this provided the notation is consistent and is used correctly, i.e. we do not deviate from the standard UML to Pidgin UML. After all, we do not use Pidgin English if clarity is the order of the day in our written material.

If we are honest with ourselves and listen to the problem statements made by our project managers (“it takes too long”), our solution architects (“the requirements are not clear or consistent with one another”) and our business customers (“I don’t have the time to review so much written work or indeed the time to wait for it.”), we would stop writing and spend only the time it takes to clarify a few significant verbal statements as a baseline for traceability purposes, and invest in the intellectual activity required to model the business. We must use our time asking all the right questions, listening carefully to the answers, capturing and structuring the knowledge gathered as clearly and as explicitly as possible, using a formal notation such as the UML.

As Jim and Michele McCarthy say in their book Dynamics of Software Development, which provides us with rules for delivering great software on time, “the real task of software development management is to marshal as much intellect as possible …” If such investment is made in the early stages of a project, the business analyst can capture the essence of a business vision, the goodness of a project and then focus on channelling the business intellectual property (IP) into the subsequent business analysis artefacts.

Modelling the business context is not a mechanical assembly line task to map some of the things that already exist in the organisation. It is an intellectual activity that requires the business analyst to elicit the business problem and to visualise with the business how to make good that problem.

In a future article, we will look at modelling the business process and the rules that govern the activities it comprises.

This article is based on one of the “Truth, Beauty & Goodness” presentation series given by the author in 2008 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: LD, BL, JM, HT.

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 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. Suzanne can be reached at [email protected] or [email protected]

The Importance of Business Domain Modelling

Written by Suzanne Jane Maxted on November 3, 2008. Posted in Articles. 1 Comment on The Importance of Business Domain Modelling

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.

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.