Concept Modelling · Business Analysis Notes

What it is#

A concept model is a picture of how the business talks and thinks, not of how a database stores data. The BABOK Guide describes three kinds of building blocks:

Noun concepts — the things the business needs to name: customer, booking, repair order, spare part.
Verb concepts — short fact statements that connect noun concepts: customer makes booking, repair line uses spare part. Each one is something a business expert can confirm as true or false.
Other connections — categories and classifications (a walk-in customer is a kind of customer), whole–part links (a repair order includes repair lines), and roles (a person acting as a customer or as a mechanic).

The model is usually drawn as boxes (noun concepts) joined by labelled lines (verb concepts), with a glossary of definitions behind it. Because every line reads as a sentence, business people can review it without learning a technical notation.

The BABOK Guide uses the technique in three tasks: Conduct Elicitation (capturing key terms and how they relate), Analyze Current State (describing the vocabulary of the business domain), and Specify and Model Requirements (defining the terms that matter for the change).

When to use it#

Use a concept model when:

people use one word for different things, or different words for one thing;
the work is heavy on rules and decisions (pricing, eligibility, compliance), where every rule depends on precise terms;
you want a vocabulary that does not inherit the biases of an existing system or database design;
several teams or systems must share business terms.

Do not use it when a simple glossary is enough: a small domain where terms barely relate to each other. If you already need attributes, keys and cardinalities for a build, move on to data modelling. The two often follow each other: concept model first, data model later.

Keep the limits in mind. The BABOK Guide warns that a shared business vocabulary can raise unrealistic hopes about how quickly systems can be integrated; that the modeling style is unfamiliar to many stakeholders and takes focus and skill; and that the vocabulary only pays off if people can look terms up while they work, which usually needs some tool support.

How to do it#

Collect candidate terms. Pull nouns from interviews, documents, forms, screens, reports and existing rules. Note where each came from.
Resolve synonyms and homonyms. Merge words that mean the same thing and pick one preferred term. Split one word that means different things to different groups.
Define each noun concept in one sentence a newcomer would understand, and record it in the glossary.
Connect concepts with verb phrases. For each related pair, write a plain fact statement (“mechanic is assigned to repair order”). Read it in both directions to check it makes sense.
Add categories, whole–part links and roles only where rules or decisions depend on them.
Draw the model and keep it within the scope of the change.
Review with domain experts by reading the facts aloud. Ask “Is this always true? What are the exceptions?”
Use it. Write requirements, business rules and acceptance criteria only in terms from the model, and update the model when the business changes.

Example#

At The Workshop, a fictional chain of 12 bike-repair workshops planning online booking, front-desk staff say “job”, mechanics say “ticket” and the owner says “repair order” for the same thing. Meanwhile “booking” is used both for a reserved time slot and for the repair itself.

The analyst agrees on preferred terms with the owner and workshop managers, then draws this model:

Figure 1. Concept model for booking and repair at the Workshop. Boxes are business concepts; each labelled line reads as a short sentence. Notation: concept model (concepts and verb phrases)

View as text

Customer --makes--> Booking
Booking --reserves--> Time Slot --is at--> Workshop
Booking --becomes--> Repair Order          (when the bike is dropped off)
Repair Order --is for--> Bike --is owned by--> Customer
Mechanic --is assigned to--> Repair Order
Repair Order --includes--> Repair Line     (whole-part)
Repair Line --uses--> Spare Part --is supplied by--> Supplier
Repair Order --has--> Repair Status

Walk-in Customer, Registered Customer --are kinds of--> Customer

“Job” and “ticket” become aliases of repair order in the glossary. A rule such as “a booking becomes a repair order only when the customer drops off the bike” can now be written without ambiguity, and the notification requirements refer to repair status rather than to whatever label a screen happens to use.

Common mistakes#

Drawing a database instead of a vocabulary → leave out attributes, keys and technical tables; model what the business says.
Vague verbs such as “has” or “relates to” everywhere → use specific verbs that an expert can confirm or reject.
Modeling the whole enterprise → limit the model to the concepts the change touches.
Boxes without definitions → pair every noun concept with a glossary entry.
Building it alone → review by reading facts aloud with experts; early disagreements are a key output, not a nuisance.
Letting it go stale → give it an owner and update it when products, rules or regulations change.

Checklist#

Every noun concept has one preferred name and a one-sentence definition.
Synonyms are recorded as aliases, not as separate concepts.
Every line carries a verb phrase that reads as a sentence.
Categories, whole–part links and roles appear where rules depend on them.
Domain experts have reviewed the facts.
Requirements and rules use only terms from the model.
The model has an owner and a last-reviewed date.

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.11 “Concept Modelling”.
Watermark Learning. BABOK v3 Study Tables. 2016 (study aid for the BABOK Guide), technique 10.11.