Show Menu

Domain Modelling Cheat Sheet by

Systems Analysis ISYS215

“Things” in the Problem Domain

Problem domain = The specific area (or domain) of the users’ business. Scope of the system.
Examples: products, sales, shippers, customers, invoices, payments
“Things” eventually modelled.
Called “classes” (UML) or “entities”

Cardin­ality symbols ERD relati­onships

The brains­torming technique

1. Identify a user and a set of use cases.
2. Brainstorm with user to ID things involved
3. Use the types of things (categ­ories) to system­ati­cally ask questions about potential things, such as the following: Are there any tangible things you store inform­ation about? Are there any locations involved? Are there roles played by people that you need to remember?
4. Continue to work with all types of users and stakeh­olders to expand the brains­torming list.
5. Merge the results, eliminate any duplic­ates, and compile an initial list.
Joint effort between the analyst and the users.


Determine entities (things in the domain)
Attributes (of entities)
Keys (Primary, Foreign)
Data types (integer, string, etc)
Relati­onships (which entities are related)
Cardin­ality (how are entities related)

Details about Entiti­es/­Classes

Attribute: describes one piece of inform­ation about each instance of the class
Customer has first name, last name, phone number
Identifier or key: One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer
Compound attribute: Two or more attributes combined into one structure to simplify the model.
Object: Class is a type of thing. Object is a specific instance of the class. Each instance has its own values for an attribute
Associ­ation (UML) / Relati­onship (ERD): a naturally occurring relati­onship between classes (UML term). # rep by Multip­lic­ity­/Ca­rdi­nality. 1 to 1 or 1 to many.

Domain Class Model Diagram with an associ­ation

Types of things

e.g. book, plane, car, hat, document, worksheet
Employee, Customer, doctor
Org unit
Division, depart­ment, team
Sensor, timer, machine, printer
Sites / locations
Warehouse, branch, store, desk
Incident / event / intera­ction
Fligh, call, logon, order, payment

Types of associ­ations

UML notation for multip­licity of associ­ations

The Noun Technique

1. Using the use cases, actors, and other inform­ation about the system — including inputs and outputs — identify all nouns (names).
2. Using other inform­ation from existing systems, current proced­ures, and current reports or forms, add items or categories of inform­ation needed.
3. As this list of nouns builds, you will need to refine it. Ask these questions about each noun to help you decide whether you should include it:
- Ask questions, such as is it important and inside the scope, to see if it should be included.
- Ask questions to see if it really should be excluded, such as is it only a report or an input or is it an attribute.
- Ask questions to see if it needs further research. In other words that you cannot answer whether it needs to be included or excluded.
4. Create a master list of all nouns identified and then note whether each
one should be included, excluded, or researched further.
5. Review the list with users, stakeh­olders, and team members and then refine the list of things in the problem domain.
Mechanical approach to identi­fying classes


No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Conceptual Database Design Cheat Sheet
          Use Cases - Defining Requirements Cheat Sheet
          dig Cheat Sheet

          More Cheat Sheets by NatalieMoore