BA ABCs: “C” is for Class Diagram


 Business Analyst ABCs: “C” is for Class Diagram

JNW, by Howard Podeswa, to be exhibited as part of the group exhibition
The “C” Word, from Feb 8 – Apr 4, 2012. (108x120 inches, oil on canvas)

#3 in the series: “C” is for Class Diagram

This blog continues a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each post, I move through the alphabet, highlighting a BA tool that begins with the letter of the day. Today’s letter is “C” – for Class Diagrams. Business Analysts use Class Diagrams to help them discover ‘structural’ business rules and to document them in a visual form that is readily understood by developers. What is a structural rule? It is any rule that is related to the ‘nouns’ of a business - for example, the rule that only one Salesperson is credited with a Sale (so that sales commissions are never split), or the rule for deriving the amount of the commission for making the Sale. These are considered structural business rules because they are about classes (UML-speak for types) of things within the business – such as SalesPerson or Sale.

Why Class Diagrams Matter to the BA

My company, Noble Inc., is often contracted to help clients set guidelines and good practices for the BAs working in their organizations. Of all the recommendations we make, one that almost invariably meets resistance is for the use of class diagrams (or a similar diagram, the Entity Relationship Diagram [ERD]) as a BA tool. BAs don’t see the point and developers often resent what they see as an intrusion on their turf. In every case, I’ve been able to get developers on-board once they realize that the class diagrams drawn by the BA and those created by the developers represent two very different perspectives: the BA’s model is an abstraction of the real-world business while the developer’s model represents the software solution (specifically, the design model for the software classes and database). Simply put, the BAs aren’t stepping on the developers’ turf because the BA’s class diagrams do not dictate what the solution design will be, they only state the business rules that must be satisfied by the solution – however it is designed. Nevertheless - and BABOK guidelines notwithstanding – my observation is that the practice of drawing class diagrams is not in wide use by BAs. In this blog I’d like to make the argument for why they (or similar diagrams, such as ERDs) are an important BA tool.

Case in Point: The Power of a Simple Sketch

I was speaking with a group of BAs about the requirements for their Human Resources (HR) system. I like to sketch, so as they introduced nouns from the business area, like Employee and Union, I sketched them on a class diagram.


It shows two classes – or categories – of things that are tracked by the business area: Employee and Union.

The sketch was missing a connection between the two, so I asked whether the business needed to know which Employees belonged to which Unions, leading to this version of the diagram.


Now any BA trained in Class Diagrams knows that this diagram is incomplete until numbers are added (two sets for each relationship)– so I asked, “How many Unions may an Employee belong to?” A simple question – and, to be honest, one I already thought I knew the answer to - one Union (per Employee). But the question drew an embarrassed silence. I soon learned that this question – or rather, the failure to ask it - had had costly consequences – namely the decision to purchase an HR system that only supported one Union per Employee. That decision turned out to be a problem because it was possible for an Employee to belong to more than one Union based on his or her collection of responsibilities. That rule is shown below.


(In case you’re wondering how to read the diagram: Read left to right, it states that an Employee belongs to any number of (i.e., zero or more) Unions. Read right to left, it states that a Union has zero or more Employees who belong to it.)

Because nobody thought to ask about this rule, it wasn’t in the requirements documentation, and because it wasn’t there, there was no recourse when the rule was not supported by the software. (In other words, the business had to pay for the fix.)

It’s a small example of the power of a simple sketch.

What we can learn from this example

This little example underscores a few key points about Class Diagrams, and, by extension about structural modeling.

  • Class Diagrams drawn by the BA have everything to do with the business. They are not technical specs.

  • The best time to create class diagrams is during the interview, where they can help reveal missing rules, not later.

  • The model does not have to be formal or complete to be of value. On an agile project, you might only create sketches like the ones above as you facilitate meetings between developers and stakeholders. They still have great value in that context because of the way they help reveal missing business rules.

As always, though, you need to know your audience. You can expect developers to interpret your diagrams exactly as you intended (assuming they are conversant with the UML standard, as many are), but business stakeholders – not so much. Instead, when communicating with them, translate the diagrams back into English.

Business Contexts for the Class Diagram

Like many BA tools, the Class Diagram is an extremely transferrable tool, as you move from business sector to business sector. Some of the contexts in which I’ve used it run the range from the macabre, to the ordinary. These contexts include:

  • Funeral Homes: to capture ways the business needed to store information about deceased individuals, and track their relationships to products (coffins) and grave-site locations.

  • Military: to elicit and document rules regarding military equipment and the maintenance work that relates to it.

  • Travel: to capture rules regarding how travel packages are constructed from Land, Air and Hotel components and how these are billed and ticketed

  • • Manufacturing: to explain to developers how defective components are traced backwards and forwards through the supply chain.

  • Justice systems: To determine how cases are tracked.

  • Customer Relationship Management (CRM): To track how clients are grouped and assigned to agents.

How to read a Class Diagram

Following is a simplified version of a CRM example. It illustrates most of the Class Diagram features a BA needs to be aware of, except for ‘generalization’. More on that one later:


Let’s start from the top. The boxes, as we’ve seen, are classes – each representing a type of business object (thing) that is tracked by the business. The diamond symbol touching “Client Group” means that Client Group is an “aggregate” - a collection of components. The component part (or parts) is listed on the other end of the relationship; in the example it is “Client”. In other words, a Client Group is made up of Clients. How many? The ‘numbers’ (referred to as multiplicities or cardinalities) are written at either end of each relationship. You can specify:

  • a range: [number]..[number], e.g., 1..5 (meaning 1 through 5)

  • a single number, e.g., 1 (meaning 1 and only 1)

  • a limitless range ending in an asterisk, e.g., 2..* (meaning 2 or more)

  • zero or many: Shown as 0..* or simply, as *

When reading a relationship from one end, you ignore the numeric symbols next to the starting point and use the ones at the far end. In this case, from top to bottom, we read: A Client Group is made up of 1 or more Clients. From bottom to top we read, A Client is a component of one and only one Client Group.

The rest of the diagram can be translated into English as:

  • Each Client is assigned one Lead Service Partner. Each Lead Service Partner is assigned to zero or more Clients.

  • Each Client is in 1 Market. Each Market has zero or more Clients.

  • Each Market belongs to 1 Industry. Each Industry has zero or more Markets.

I think you can see how, strictly from the point of view of understanding the way business terms are used, this is a valuable document. (For example, it explains that an Industry is segmented into Markets, not the other way around.) In addition, it tells the developers about important rules that must be supported by the solution, such as the rule that only one Lead Service Provider is assigned to a Client.

Testing your Class Diagram Prowess


If you think you are ready to tackle a complex model, try this one. It describes the corporate structure of a typical Client. It introduces a new symbol, the arrow (seen below Client), referred to as ‘generalization’. It points to a general type (‘generalized class’) which is broken down into sub-types (‘specialized classes’), indicated at the tail end(s) of the arrow. Here we see that here are two sub-types of Client: A Parent Company and a Subsidiary. Fair enough. But the relationship at the bottom tells us that a Parent Company controls zero or more Subsidiaries and that a Subsidiary is controlled by a single Parent Company. It’s an elegant way to get across the fact that we have two types of Clients and the nature of the relationship between them. In case you’re interested this is an example of a Composite Pattern – and patterns are an advanced topic in Class Diagrams. (So if you understood the diagram, give yourself a pat on the back.)

And – by the way – if you are wondering what the connection is to the painting at the head of this blog, the answer is coincidence (or “synchronicity” – as the Jungians would call it). Just as I am writing this blog on the letter “C”, I am also preparing a painting for shipment to the art exhibit, The “C” Word at the Doris McCarthy Gallery in Toronto. This is that painting. It is a life-size (9 ft x 10 ft) reconstruction of Rembrandt’s The Night Watch, based on measuring high and low points in the original composition.

Howard Podeswa is a leader in Business AnalysisAuthor: Howard Podeswa is a leader in Business Analysis, having contributed to the formalization of the profession as SME for NITAS, a BA apprenticeship program for CompTIA, as a member of the BABOK review team and as an author. A highly sought-after speaker, he has 30 years experience in many aspects of the I.T. industry, beginning as a developer for Atomic Energy of Canada, Ltd., and continuing as Systems Analyst, Business Analyst, and course designer. He is the author of The Business Analyst’s Handbook and UML for the IT Business Analyst, a practical guide to requirements gathering and documentation for the BA, now in its 2nd edition, published in 3 languages. Through his company, Noble Inc., Howard has provided BA consulting services to a broad range of industry sectors, including health care, defense, energy, government and banking and finance with a diverse client base that includes the Mayo Clinic, Canadian Air Force, the South African Community Peace Program (CPP), Deloitte, the ISO, UST Global (U.S, and India) and BMO/ Harris Bank. In addition, Howard has designed BA training programs for numerous institutions, including CDI (now Global Knowledge), Boston University, Humber College and New Horizons.

Like this article:
  44 members liked this article


Tony Markos posted on Tuesday, February 14, 2012 8:33 AM

Very good article: BA's need to understand the essential entities within scope and their interrelationships.

The question remains though: Why don't BA's typically create Class Diagrams (or ERD's)? It is generally not because of lack of knowledge of the data modeling techniques.

To answer this question, it is key to remember that data models are, as Yourdon used to say, inert. That is there they are not strong at actually guiding a BA through the data discovery process. Think data flow diagram and data dictionary; that is data discovery.

In all practical terms, few, very few, actually create a rigorous a data dictionary. However, it has been my experience that even a rough cut one, which a focus on the most essential is a tremendous help towards the discovery needed for data modeling efforts.

Artur Kasprzyk posted on Wednesday, February 15, 2012 9:01 AM
Hi Howard,

Good idea to raise an interest of BA to information structure modeling. As you pointed out, despite many articles and books available on this class diagrams are still being perceived as technical not business artefact. Hopefuly one day it'll change.

Greetings, Artur
bizguy72 posted on Wednesday, February 15, 2012 9:15 AM
Hi Howard,

Good article. I always start out with a conceptual class diagram as you've described here and I use that in conjunction with a 'glossary of terms' as well. The glossary compliments well as it provides the meaning of each noun/term and can include other alias names for each as well should there be any.

Then I make sure that in all other artefacts, whether that be Use Cases, Requirements, Business Rules etc that each of these are framed back to the class diagram so that everything ties together clearly.



Steve Orr posted on Wednesday, February 15, 2012 10:19 AM
Hi Howard

I recognise what you say about resistance from both analysts and developers. Like you I have long been trying to get across the message that BAs need to build this type of model.

In common with many others I like to refer to the models built by BAs as domain models rather than class models in order to distinguish between a business and design views of the data - two distinct types of model, each with a distinct goal.

Steve Orr
Rajan Singh posted on Wednesday, February 15, 2012 11:35 PM
Hi Howard,

thanks for creating insterest for BA group to cover the study of class diagram. But we hardly get the material to business senario of class diagram. It would be great if you could share both class diagam technical and business one, showing of same application.

Howard Podeswa posted on Thursday, February 16, 2012 10:52 PM
Artur - great hearing from you. As to your point, who was it who said "We are the change we have been waiting for?"

To Torajan Singh - I'll see what I can do - time permitting (time being in short supply these days) - but, briefly, - and at the risk of losing the non-techies who might be reading this, let me say that .....
The technical diagram might look just like the conceptual one, except that it would include more detail - for example about the properties of attributes, primary keys, foreign keys etc., and, additionally, about the operations of the class (if it is to be coded in an OO language). Then again, the designer may decide, for practical reasons, to split one of the business entities up into two (for example, to restrict access to sensitive fields) or, conversely to combine entities (in order, say, to speed data access). The net result of all of that is a model of objects/classes that are 'persistent' - i.e., saved within a database. The technical model would also include other classes that do not relate back to the business (i.e., not traceable back to the Domain Model) - such as Control Classes, Interfaces and so on. Hope this helps.
radiohead posted on Friday, March 2, 2012 9:21 PM
Howard, big fan of your blogs, articles and books.
can you show us one example (with two class diagrams), one is business domain and one is derived from the business domain class diagram, to show the differences between the two, and how designers/deverlopers make some design choices that make the two different and for difference purposes.
Kirk Fleming posted on Saturday, May 19, 2012 9:34 AM
What you've shown is, I think, among the highest 'bang-for-buck' tools ever devised for BA work. With near-identical outcome but different language, the ER diagram and the business rules it captures is an astoundingly fast and compact way to document stuff that is generally of very high impact to system design.

The non-technical pick up on it quickly, and, although they may not care too much for learning to read cardinality notation, it's easy to simply provide the narrative equivalent rules.
Kay posted on Thursday, March 9, 2017 8:29 AM
Howard, thank you for your very succinct explanation of class diagrams! Class diagrams are definitely an invaluable BA tool!
Helen posted on Saturday, March 11, 2017 12:39 AM
Great article. I wrote an article on this subject matter myself and what I didn't realise until I published it on a forum about there indeed were some Business Analysts with the view that this technique didn't have a place for gathering requirements. I agree with everything you say about their usefulness and find them very valuable myself. Another reason why I find them useful is when stakeholders use lots of terminology to mean the same thing. It is then brilliant at getting everyone to agree the same term.
Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC