Concept modelling (BABOK 10.11, spelled concept modeling in the US) is the technique for organizing the business vocabulary of a domain so people can communicate about it consistently [2]. A concept model links noun concepts through verb concepts and a few standard connection types [10, 11]. For the CBAP exam (120 questions, 210 minutes), concept modelling BABOK questions test whether you can tell it apart from a data model and a glossary, and when to choose it [1].
Last verified: October 2026 (IIBA CBAP page, BABOK Guide v3 technique 10.11 page on IIBA KnowledgeHub, OMG SBVR 1.5).
What concept modelling is
A concept model is an analysis model of the core terms in a problem domain, their definitions and the verbs that connect them. BABOK frames its purpose as organizing the vocabulary needed to "consistently and thoroughly communicate" knowledge of a domain [2].
The idea comes largely from the business rules community. One of its main authors explains that a concept model begins with a glossary of business terms and then adds structure, so that rules and requirements can be written in sentences whose words mean one thing [3]. The governing standard behind that school is the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR), currently version 1.5 from December 2019 [8].
| Fact | Value |
|---|---|
| BABOK section | 10.11 Concept Modelling [2] |
| Elements | Noun concepts, verb concepts, other connections [10, 11] |
| Main task use | Conduct Elicitation (4.2), plus modelling work in Requirements Analysis and Design Definition |
| Related standard | OMG SBVR 1.5 (December 2019) [8] |
| Typical output | Definitions plus a diagram of terms and verb wordings [3, 4] |
| CBAP weight of RADD | 30% of the exam blueprint [1] |
Why concept modelling matters on the CBAP exam
Concept modelling is listed under Elicitation and Collaboration (12% of the CBAP blueprint), and its output feeds the modelling work of Requirements Analysis and Design Definition, the largest knowledge area at 30% [1]. Our map of all 50 BABOK techniques by knowledge area shows it among the core techniques of Conduct Elicitation (4.2).
The exam rarely asks you to draw anything. It gives a scenario where stakeholders use the same word for different things, or where a large rule set keeps contradicting itself, and asks which technique fixes the root problem. The answer pattern to recognize: when the trouble is meaning, choose concept modelling; when the trouble is storage structure, choose data modelling; when you only need a list of agreed definitions, a glossary is enough.
Concept modelling BABOK elements: the three building blocks
BABOK describes a concept model through three elements: noun concepts, verb concepts and other connections [10, 11].
1. Noun concepts
Noun concepts are the basic building blocks: the things the business talks about, such as customer, order or policy [11]. Each one needs a definition that is free of technical or implementation bias. A practitioner with more than 20 years in banking, retail and telecoms describes the target as vocabulary untainted by data or implementation concerns [10].
2. Verb concepts
Verb concepts provide the structural connections between noun concepts, for example customer places order [11]. In the business rules school they are the heart of the model. As one author puts it, "Without verbs, literally there are no sentences" [5]. He adds that missing verbs are a common source of ambiguity in business rules, and that a verb wording means exactly what it says, so party makes request and party submits request force the business to decide whether these are synonyms [4, 5].
3. Other connections
Other connections are standard structural links that recur in every domain [10, 11]:
| Connection type | What it says | Example |
|---|---|---|
| Categorization | One concept is a kind of another | Retail customer is a category of customer [10] |
| Classification | An instance belongs to a concept | France is classified as a country [10] |
| Partitive (whole-part) | One concept is made of others | A car is composed of body, wheels and engine [10] |
| Role | A concept plays a role in a connection | Party in the role of guarantor [3, 11] |
| Property | A concept has a characteristic | Employee has employee name [10] |
How a concept model differs from a data model and a glossary
A concept model is about the meaning of words; a data model is about how data is structured for storage; a glossary is a list of definitions without structure [3, 4]. A separate comparison article is planned, so here is the short version:
| Glossary | Concept model | Data model / ERD | |
|---|---|---|---|
| Question it answers | What does this term mean? | What do our terms mean and how do they connect in sentences? | How should data be organized and stored? |
| Structure | Alphabetical list | Nouns, verbs, categorizations, roles [3] | Entities, attributes, relationships, keys |
| Verbs | Absent | Central [5] | Little attention [4] |
| Cardinality, keys | No | Usually omitted [3] | Yes |
| Diagram | No | A convenience, not a requirement [4] | Usually the main artifact [4] |
| Audience | Everyone | Business stakeholders, rule authors | Data architects, developers |
Two points matter for the exam. First, a concept model usually starts from a glossary and goes further [3]. Second, the derivation runs one way: one author writes that "Data models can usually be rather easily derived from concept models" [3], and a practitioner adds that the reverse is largely impractical [10].
Notation options
BABOK does not prescribe one notation, and practitioners use three broad families.
- SBVR-style concept models. The business rules school draws noun concepts as labelled boxes, marks verb concepts with a starburst symbol, links them with thin lines and adds a small arrow to show the reading direction, so the diagram reads as person owns vehicle [5]. Definitions and wordings carry the meaning; the picture is secondary [4].
- Fact models. This is the older name for the same idea. SBVR 1.1 replaced the term fact type with verb concept, and one author argues the field should say concept model rather than fact model from then on [6].
- Concept maps. Concept maps come from education research. Two of their originators define them as "graphical tools for organizing and representing knowledge," built from propositions where concepts are joined by linking words [9]. They are looser than SBVR models but useful in early elicitation.
Many analysts also draw a conceptual-level entity-relationship diagram without attributes or keys. Whether that counts as a concept model is exactly where experts disagree (see below).
A worked example: equipment rental
Imagine an equipment rental company where branch staff, finance and the website team all use the word return differently. Here is how a concept model resolves it, step by step.
Step 1. Collect noun concepts from the glossary and documents. Customer, rental agreement, rental item, branch, return.
Step 2. Define each one without system language. Rental item: a physical unit of equipment that can be hired out on its own. Not a row in the inventory table.
Step 3. Add verb concepts with wordings people actually use.
- Customer signs rental agreement
- Rental agreement covers rental item
- Rental item is checked in at branch
- Branch inspects rental item
Step 4. Add other connections.
- Corporate customer and private customer are categories of customer (categorization)
- Rental agreement includes rental lines (partitive)
- Customer acts in the role of renter or guarantor (role)
Step 5. Test it with real sentences. The finance team says an item is returned when it is checked in. The branch team says it is returned only after inspection. The model now has two distinct verb concepts, is checked in at and inspects, so the business must choose which one ends the rental. It splits the old word into check-in and completed return.
Step 6. Write rules on top of the vocabulary. A rental agreement must cover at least one rental item. Rental charges stop at completed return. Each word in those rules now has one definition, which is exactly what the business rules analysis technique (BABOK 10.9) needs as its foundation.
A data modeller can later derive tables from this model, but the model itself never mentions keys or tables.
Concept modelling in real practice
Concept modelling is rarer in practice than data modelling, and it lives mainly in rule-heavy, knowledge-intensive work. An IIBA training provider notes that concept models are less common than data models, while data models require knowledge of notations and some IT background [15]. Practitioners place the technique where precise and subtle distinctions matter, such as complex rule sets and decision tables [10, 11].
Where it is used, the payoff can last. One business rules consultant reports that a fact model built in 1998 was still "about 90% accurate" in 2011 and was the only part of the client's legacy environment worth salvaging [7]. A parallel line of business that skipped the model ended up with only about 60% overlap in vocabulary [7].
Business people can build these models without training in notation. A data management consultant with more than 40 years of experience describes a railway group that started with no modelling terminology and ended up very happy with a 40-entity concept model they built themselves [12]. The same consultant warns that the most common error is treating an artifact, such as a form or report, as a concept: an admission request form bundles facts about several things [12].
The technique also still features in community events. A 2025 business analysis conference ran a three-slot immersive session where groups built a concept model, reached consensus on key terms and then aligned other artifacts, including business rules, to the agreed vocabulary [16].
Experts disagree on concept modelling
Practitioners agree that shared vocabulary matters, but not on whether a concept model is a separate artifact.
1. A concept model is not a data model. The business rules school argues the two have different purposes: one disambiguates what people say and write, including policies and agreements; the other organizes data for storage [4]. Its leading author even argues the term conceptual data model should be dropped [6].
2. A concept model is a conceptual data model with a business face. A data modelling consultant labels it "Business Concept Model (a.k.a. Conceptual Data Model)" and treats concept, domain and business object models as related names [12]. A BA career trainer uses a conceptual ERD to show how glossary terms relate and to align business experts and developers [13]. In this view, a well-run conceptual ERD session does the same job.
3. Verbs first versus things first. Rule-focused authors put verb concepts at the centre and treat the diagram as optional [4, 5]. Data-focused practitioners start from recognisable entities, summed up as things first, data later [12], and value the whiteboard picture as the main tool for engagement [12, 13].
4. How much rigour is enough. The concept modelling school puts a high premium on single, design-independent definitions [3]. An agile methodologist counters that definitions "just need to be good enough," that multiple definitions can coexist, and that forcing one agreed definition is often not worth the effort [14].
The real argument is between positions 1 and 2. For the exam, follow BABOK and position 1: concept modelling and data modelling are separate techniques with separate purposes.
Common misconceptions about concept modelling
- It is just a glossary. A glossary lists definitions; a concept model adds verb concepts and structural connections between them [3].
- It is an ERD without attributes. It ignores keys and cardinality and focuses on verb wordings and meaning [3, 4]. Whether a conceptual ERD can stand in for it is debated [12, 13].
- You need SBVR to do it. SBVR is the formal standard behind the business rules school [8], but practitioners build useful models on a whiteboard with minimal notation [12].
- The analyst builds it alone. The value comes from stakeholders agreeing on terms together [16].
- It is only for rules engines. Its main use is consistent communication about the domain, including policies, regulations and agreements [4].
Practice Questions
Question 1. A claims department, the call centre and the IT team each use the word claim to mean something different: a phone call, a submitted form and a database record. Rule documents contradict each other. Which technique best addresses the root cause?
- A. Data Modelling
- B. Concept Modelling
- C. Process Modelling
- D. Interface Analysis
Answer: B. The problem is meaning, not storage or flow. A concept model defines claim and related nouns, separates them where needed and connects them with agreed verb wordings [3, 4]. A data model would structure the record, but not settle what the business means by the word.
Question 2. A business analyst is drafting a concept model. Which item is a verb concept?
- A. Corporate customer is a category of customer
- B. Customer places order
- C. Order has order date
- D. Germany is a country
Answer: B. Customer places order connects two noun concepts with a verb wording [5, 11]. A is a categorization, C is a property and D is a classification, all of which fall under other connections [10].
Question 3. The data architect asks the business analyst to add primary keys and cardinalities to the concept model so it can be implemented. What is the most appropriate response?
- A. Add them, because a concept model is an early data model
- B. Replace the concept model with a physical data model
- C. Keep the concept model free of design detail and let a data model be derived from it
- D. Stop modelling and rely on the glossary
Answer: C. A concept model stays independent of data design, and a data model can be derived from it later [3, 10]. Adding keys mixes the two purposes.
Conclusion: the gap between BABOK concept modelling and real practice
BABOK presents concept modelling as a distinct vocabulary technique; in practice it is used mainly by rule-heavy teams, while many analysts do the same work with a conceptual ERD or a glossary.
| Area | Standard | Reality | Delta |
|---|---|---|---|
| Frequency of use | One of 50 techniques, used in elicitation and requirements analysis [2] | Rarer than data models [15] | Under-used |
| Separate from data model | Distinct technique with its own purpose [2, 4] | Often merged into a conceptual data model or ERD [12, 13] | Reduced to conceptual ERD |
| Verb concepts | A core element [10, 11] | Central for rule authors [5], secondary for entity-first modellers [12] | Under-used |
| Rigour of definitions | Consistent, thorough vocabulary [2] | Good-enough definitions in agile teams [14] | Reduced to glossary |
| Who builds it | Analyst with stakeholders | Collaborative workshops with business groups [12, 16] | No gap |
| Durability | Not stated | Models can stay accurate for over a decade [7] | Added by practitioners |
The standard's core holds up: shared vocabulary prevents contradictory rules and requirements, and practitioners on both sides agree on that. What differs is the packaging. On the exam, treat concept modelling as its own technique for meaning; at work, expect to meet it under other names.
Related topics
- Requirements architecture: how models and requirements fit together into one structure.
- Specify and model requirements: the RADD task where most models, including concept models, get built.
- Diagrams in practice for business analysts: a case study of building a visual knowledge base.
- CBAP exam simulator: practise scenario questions across all six knowledge areas.
FAQ
What is concept modelling in BABOK?
Concept modelling is BABOK technique 10.11. It organizes the business vocabulary of a domain so people can communicate about it consistently. A concept model defines noun concepts, links them with verb concepts and adds standard connections such as categorizations, classifications, whole-part links and roles.
Is a concept model the same as a data model?
No, according to BABOK and the business rules community. A concept model clarifies what words mean in business sentences, while a data model organizes data for storage and includes keys and cardinalities. Some data practitioners call a concept model a conceptual data model, but for the CBAP exam treat them as separate techniques.
What is the difference between a concept model and a glossary?
A glossary is a list of terms and definitions. A concept model usually starts from a glossary and adds structure: verb concepts that connect the terms and connections such as categories, roles and whole-part links. That structure lets you write rules and requirements whose words each mean one thing.
What notation is used for concept models?
BABOK does not mandate one notation. The business rules school uses SBVR-style diagrams with boxes for noun concepts and starburst symbols for verb concepts. Others use concept maps or simple boxes and labelled lines on a whiteboard. The definitions matter more than the drawing.
When should a business analyst use concept modelling?
Use it when stakeholders use the same words differently, when a project depends on many business rules or decision tables, or when knowledge must be retained across systems and years. For a simple project with few terms, a glossary is often enough.
Sources
- CBAP Certification — IIBA
- BABOK Guide v3, 10.11 Concept Modelling — IIBA KnowledgeHub
- What Is a Concept Model? — Business Rules Journal, 2014
- Concept Models vs. Data Models — Business Rules Journal, 2018
- ConceptSpeak (Part 3): Verb Concepts in Concept Models — Business Rules Journal, 2021
- Concept Model vs. Fact Model vs. Conceptual Data Model: Just a Matter of Semantics? — Business Rules Journal, 2012
- How Long Will Your Fact Model Last? — Business Rules Journal, 2011
- Semantics of Business Vocabulary and Business Rules (SBVR) 1.5 — OMG
- The Theory Underlying Concept Maps and How to Construct and Use Them — IHMC
- What Is A Concept Model? Introduction and Guidance — BusinessAnalystMentor
- BA Techniques: Concept Modelling — Fhyzics
- Concept Modelling — Alec Sharp, IRM UK, 2024 (PDF)
- How to Create an Entity Relationship Diagram (ERD) — Bridging the Gap
- Glossaries: An Agile Introduction — Agile Modeling
- Concept Model vs. Data Model — Adaptive US
- Concept Modeling: Creating a Shared Business Vocabulary — Building Business Capability 2025