From Requirement to Class Design

Concept Definition

Moving from requirement to class design means converting plain language into a small, testable object model. You identify responsibilities, ownership, variation points, and the first behavior to test. The goal is not a perfect diagram; the goal is a design good enough to start safely.

A useful analogy is planning a route before traveling. You can adjust later, but you should know the main stops before leaving.

Why It Matters

Without a workflow, students often write code in the order the requirement sentences appear. That can put input handling, storage, validation, printing, and business rules into one class. A design workflow separates thinking into small questions.

This habit is especially important in viva and project defense. You can explain why a class exists, why it owns certain data, and why a relationship is inheritance or composition.

Syntax Block

class RequirementClass {
private:
    OwnedData data;       // ownership decision

public:
    void behavior();      // verb from requirement
};

Explained Code

Example: Requirement to First Class

#include <stdexcept> // std::invalid_argument

class BankAccount {
private:
    double balance = 0.0;                         // account owns balance state

public:
    void deposit(double amount) {
        if (amount <= 0.0) {                      // validate requirement rule
            throw std::invalid_argument("amount must be positive");
        }
        balance += amount;                        // update valid state
    }

    double getBalance() const { return balance; } // query for tests and display
};

From "a user can deposit money into an account," the noun Account suggests a class, the verb deposit suggests a method, and the amount rule suggests validation.

Key Points / Rules

• Underline nouns as possible classes.
• Underline verbs as possible methods.
• Identify ownership before choosing relationships.
• Identify behavior variation before choosing polymorphism or Strategy.
• Write one small test before expanding the design.

Common Mistakes

1. Starting with menu code. UI should not decide the whole object model.
2. Skipping validation rules. Requirements often hide invariants.
3. Choosing inheritance too early. Confirm is-a before deriving.
4. Designing without tests. A small test reveals whether responsibilities are usable.

Quick Check

1. In the bank example, which requirement word becomes a method?
2. Why should ownership be decided before relationships?

Viva Answer

Requirement-to-class design turns nouns into candidate classes, verbs into candidate methods, ownership into relationships, and important rules into tests or invariants.