Identifying classes from requirements in LLD - Deep Dive

Overview - Identifying classes from requirements

What is it?

Identifying classes from requirements means finding the main objects or things in a system based on what the system needs to do. These classes represent real-world concepts or entities that the system will manage or interact with. By spotting these classes early, we can organize the system's design clearly and logically. This step is key to building software that matches what users want.

Why it matters

Without identifying classes properly, software can become messy and hard to change. Imagine building a house without knowing which rooms you need; it would be confusing and inefficient. Good class identification helps developers understand the problem better and build software that is easier to maintain, extend, and test. It saves time and money by preventing costly redesigns later.

Where it fits

Before this, learners should understand basic object-oriented concepts like objects and classes. After this, they will learn how to define class attributes and methods, and how classes interact through relationships like inheritance and associations. This topic is an early step in designing software using object-oriented design.

Mental Model

Core Idea

Classes are the main 'things' or 'concepts' in a system that come from understanding what the system needs to do.

Think of it like...

Identifying classes is like planning a party by listing all the guests, their roles, and what they bring, so you know who is involved and what each one does.

Requirements Text
    ↓
Identify Nouns (Potential Classes)
    ↓
Filter by Relevance and Uniqueness
    ↓
Define Classes with Attributes and Behaviors
    ↓
Establish Relationships Between Classes

Build-Up - 7 Steps

1

Foundation

Understanding Requirements Basics

Concept: Learn what requirements are and why they matter for design.

Requirements describe what a system should do, often written as sentences explaining features or rules. They include nouns (things) and verbs (actions). Understanding these helps us find the important parts to model in software.

Result

You can read a requirement and spot key information about what the system must handle.

Knowing how to read requirements carefully is the first step to finding the right classes.

2

Foundation

Spotting Nouns as Class Candidates

Concept: Nouns in requirements often point to potential classes or objects.

Read the requirement sentences and underline or list all nouns. For example, in 'The library lends books to members,' nouns are 'library,' 'books,' and 'members.' These are candidates for classes.

Result

A list of possible classes based on nouns extracted from requirements.

Nouns give a simple, direct way to find what the system needs to represent.

3

Intermediate

Filtering and Validating Class Candidates

🤔Before reading on: do you think every noun in requirements should become a class? Commit to yes or no.

Concept: Not all nouns become classes; some are irrelevant or duplicates.

Review the noun list and remove things that are not important to model (like 'system' or 'process'). Combine similar nouns (e.g., 'customer' and 'client'). Keep only nouns that represent meaningful entities in the system.

Result

A refined list of classes that truly represent the system's core entities.

Filtering prevents clutter and keeps the design focused on what matters.

4

Intermediate

Identifying Class Attributes and Behaviors

🤔Before reading on: do you think verbs in requirements help find class behaviors or attributes? Commit to your answer.

Concept: Verbs help find what classes do (methods) or what properties they have (attributes).

Look at verbs linked to each noun. For example, 'members borrow books' suggests 'borrow' is a behavior of 'member' or 'book.' Attributes describe details like 'name' or 'ID.'

Result

Classes with defined attributes and behaviors that match requirements.

Connecting verbs to nouns builds a richer, more useful class design.

5

Intermediate

Recognizing Relationships Between Classes

🤔Before reading on: do you think classes always work alone or often relate to others? Commit to your answer.

Concept: Classes often connect through relationships like ownership, inheritance, or association.

Identify how classes interact. For example, 'a library has many books' shows a 'has-a' relationship. 'A student is a person' shows inheritance. These relationships organize classes logically.

Result

A map of classes connected by meaningful relationships.

Understanding relationships helps build a system that reflects real-world connections.

6

Advanced

Handling Ambiguous or Implicit Classes

🤔Before reading on: do you think all classes are explicitly named in requirements? Commit to yes or no.

Concept: Some classes are not named directly but are needed to model concepts or processes.

Look for implied entities like 'transaction' or 'event' that support system behavior. Use domain knowledge to add these classes. For example, 'payment' might not be named but is essential.

Result

A more complete class model that covers hidden but important parts.

Recognizing implicit classes prevents missing key system parts.

7

Expert

Balancing Class Granularity and Design Simplicity

🤔Before reading on: is it better to have many small classes or fewer big classes? Commit to your opinion.

Concept: Choosing the right size and number of classes affects maintainability and clarity.

Too many tiny classes make the system complex; too few big classes make it rigid. Experts balance by grouping related data and behavior logically, considering future changes and reuse.

Result

A class design that is both flexible and easy to understand.

Knowing how to balance granularity is key to scalable, maintainable software.

Under the Hood

Identifying classes works by analyzing language in requirements to extract entities (nouns) and their actions (verbs). This process maps real-world concepts into software models. Internally, this helps define data structures and behaviors that the system will implement. The relationships between classes form the backbone of the system's architecture, guiding code organization and interaction.

Why designed this way?

This approach was created to bridge the gap between human language and software design. Early software projects failed because developers misunderstood what to build. Using requirements as a source ensures the design matches user needs. Alternatives like guessing classes without requirements lead to poor designs. This method balances human understanding with technical structure.

Requirements Text
  │
  ▼
Extract Nouns and Verbs
  │
  ▼
Filter and Validate Candidates
  │
  ▼
Define Classes with Attributes and Methods
  │
  ▼
Establish Relationships
  │
  ▼
Build Class Diagram

Myth Busters - 4 Common Misconceptions

Quick: Should every noun in requirements become a class? Commit to yes or no.

Common Belief: Every noun mentioned in requirements must be a class in the design.

Reality: Not all nouns are relevant or useful as classes; some are attributes, roles, or irrelevant terms.

Why it matters: Including unnecessary classes clutters the design and makes the system harder to build and maintain.

Quick: Do verbs always translate to class methods? Commit to yes or no.

Common Belief: Every verb in requirements directly becomes a method in a class.

Reality: Some verbs describe processes or workflows, not individual class behaviors, and may belong to other design elements.

Why it matters: Misplacing behaviors leads to confusing class responsibilities and poor system structure.

Quick: Is it best to create many tiny classes for every detail? Commit to yes or no.

Common Belief: More classes with fine details always make the design better.

Reality: Too many small classes increase complexity and reduce clarity; balance is needed.

Why it matters: Overcomplicated designs are hard to understand, test, and change.

Quick: Are all important classes explicitly named in requirements? Commit to yes or no.

Common Belief: All classes must be directly mentioned in the requirements text.

Reality: Some important classes are implicit and must be inferred by the designer.

Why it matters: Missing implicit classes causes incomplete designs that fail in real use.

Expert Zone

1

Some nouns represent roles or states rather than entities and should be modeled as attributes or enums, not classes.

2

Class identification is iterative; initial classes often change as more requirements or constraints appear.

3

Domain-driven design techniques like using ubiquitous language improve class identification by aligning with user terminology.

When NOT to use

This approach is less effective for purely functional or procedural systems where data and behavior are not modeled as objects. Alternatives include functional decomposition or data flow diagrams.

Production Patterns

In real projects, class identification is combined with user stories and domain expert interviews. Tools like UML diagrams and CASE tools help visualize and refine classes. Agile teams revisit class design regularly as requirements evolve.

Connections

Domain-Driven Design

Builds-on

Understanding how to identify classes from requirements is foundational to applying domain-driven design, which emphasizes modeling software closely to the business domain.

Natural Language Processing

Shares techniques

Extracting nouns and verbs from requirements uses ideas from natural language processing, showing how language analysis supports software design.

Biology Taxonomy

Analogous classification

Just like biologists classify living things into groups based on traits, software designers classify system elements into classes based on roles and properties.

Common Pitfalls

#1 Treating every noun as a class without filtering.

Wrong approach:

Classes = ['system', 'user', 'process', 'data', 'book', 'member']

Correct approach:

Classes = ['Book', 'Member'] // filtered to relevant entities

Root cause:

Misunderstanding that not all nouns represent meaningful system entities.

#2 Assigning all verbs as methods to the wrong classes.

Wrong approach:

class Book { borrow() {} return() {} } // but borrow is member's action

Correct approach:

class Member { borrow(book) {} return(book) {} }

Root cause:

Confusing which class owns which behavior.

#3 Creating too many tiny classes for minor details.

Wrong approach:

class BookTitle {}, class BookAuthor {}, class BookPublisher {}

Correct approach:

class Book { title; author; publisher; }

Root cause:

Overthinking granularity and missing design balance.

Key Takeaways

Identifying classes from requirements transforms real-world needs into software models by focusing on key nouns and their actions.

Not every noun or verb in requirements becomes a class or method; filtering and understanding context is essential.

Recognizing relationships between classes helps build a system that mirrors real-world connections and behaviors.

Balancing class size and number is crucial to maintainable and clear software design.

Expert designers infer implicit classes and iterate on designs as requirements evolve to build robust systems.