UML: Class & Object Diagrams

Finding Classes from Requirements

18 min Lesson 2 of 10

Finding Classes from Requirements

You have a signed-off requirements specification in front of you. Your next task is to turn that text into the skeleton of a class diagram — identifying the things the system needs to know about and manage. This process is called domain class discovery, and two complementary techniques make it systematic: noun analysis and CRC cards.

Step 1 — Noun Analysis

The simplest entry point is linguistic. Read each requirement or user story and underline every noun and noun phrase. Nouns represent things; things become candidate classes (or attributes, or actors — you refine them next). Consider this excerpt from a clinic-booking system specification:

"A patient registers on the system using their name, date of birth, and contact details.
 The patient then searches for an available appointment slot with a chosen doctor in a
 specific clinic department. Once a slot is selected the system creates a booking
 and sends a confirmation to the patient."

Underlining nouns yields: patient, system, name, date of birth, contact details, appointment slot, doctor, clinic department, booking, confirmation.

Now filter the list using four standard questions:

Is it relevant to the domain? — system refers to the software itself; remove it.
Is it an attribute of something else? — name, date of birth, and contact details are properties of Patient; demote them.
Is it a result or output, not a stored thing? — confirmation is a notification sent out; often not a class unless you store its history.
Is it an actor (external to the system)? — Actors appear in use cases, not class diagrams.

Applying those filters leaves four strong candidates: Patient, AppointmentSlot, Doctor, Department, and Booking. That is your first draft class list.

Start wide, filter later. It is safer to over-collect nouns and discard duplicates than to miss a class early. Keep a discard list with brief reasons — stakeholders sometimes challenge your decisions, and documented reasoning builds trust.

Step 2 — CRC Cards

A Class-Responsibility-Collaborator (CRC) card is a 3-by-5 index card (or a table on a whiteboard) with three sections: the class name at the top, a left column for what the class knows or does (its responsibilities), and a right column listing which other classes it needs help from (its collaborators). CRC cards were introduced by Kent Beck and Ward Cunningham as a lightweight design tool that non-technical stakeholders can participate in directly.

Here are CRC cards for the clinic domain:

CRC cards for the five core domain classes in the clinic booking system.

Notice how the Collaborators column on each card traces an implicit relationship: Booking needs both Patient and AppointmentSlot; AppointmentSlot needs Doctor. These collaborations become the associations you will draw as lines in the full class diagram.

CRC sessions are workshops, not solo exercises. Gather domain experts, developers, and the lead analyst around a table. Hand each person one or two index cards representing classes and ask them to act out a user scenario — "I am a Booking; what do I need from you, AppointmentSlot?" This role-play quickly surfaces missing responsibilities and hidden dependencies that text analysis alone misses.

Applying Both Techniques Together

In practice, noun analysis and CRC cards are used iteratively:

Run noun analysis on the requirements document to generate a candidate class list.
Create one CRC card per surviving candidate.
Walk through key scenarios (user stories or use cases) with the cards, assigning responsibilities and noting collaborations.
Discard classes with no responsibilities; merge classes whose cards look nearly identical; split classes whose responsibility lists are too long to fit a single card.

Consider a second domain — an online bookstore. A brief scenario: "A customer browses the catalogue, adds books to a shopping cart, places an order, and receives an invoice." Noun analysis yields: Customer, catalogue, Book, ShoppingCart, Order, Invoice. Running the filter:

catalogue — lower-case, refers to a collection behavior, not an independent class. Demote to a query method on Book (or keep if the catalogue has its own rules).
Customer, Book, ShoppingCart, Order, Invoice — all survive.

CRC cards would then reveal that ShoppingCart collaborates with Book (holds line items) and Customer (belongs to a session), and that Order collaborates with ShoppingCart (is created from it) and Invoice (triggers generation of one).

Draft candidate-class map for the online bookstore domain, derived from noun analysis and CRC sessions.

Common Pitfalls to Avoid

Keeping system/UI nouns: Words like screen, page, button, and report describe the interface, not the domain. Remove them.
Treating every attribute as a class: email address, phone number, and ISBN are values stored inside another class, not classes in their own right — unless the business imposes rules specific to them (e.g., a PhoneNumber class with formatting and validation logic).
Missing implicit classes: Some important classes never appear as nouns because the requirement describes their effect. For example, "the system keeps a history of all changes" implies a ChangeLog or AuditEntry class that no sentence names directly.

A candidate list is not a final class diagram. At this stage you are discovering scope, not designing structure. Multiplicity, inheritance, and method signatures all come later. Treat your noun list and CRC cards as working hypotheses — every conversation with a domain expert is a chance to refine them.

Summary

Domain class discovery turns a requirements document into the raw material for modeling. Noun analysis gives you a fast, repeatable method for extracting candidate classes from prose. CRC cards give you a workshop technique for assigning responsibilities, surfacing collaborations, and validating your list with domain experts. Together they produce a defensible starting point for the formal class diagram you will build in the next lessons.