Requirements and use cases

Most expensive mistakes are made before any code exists: a missing rule, a misunderstood actor, a feature nobody wanted. Modeling is cheap thinking on paper. UML, the Unified Modeling Language, is a shared set of diagrams for it. We start with the front of the process, understanding what the system must do.

A quick, reliable technique: write the requirement in plain sentences, then read it for nouns and verbs.

A driver enters the lot and receives a ticket for a free slot. On leaving, the driver pays by the hour.

• Nouns are candidate classes: driver, lot, ticket, slot, payment.
• Verbs are candidate operations: enter, receive, leave, pay.

Treat the list as candidates, not answers. Remove duplicates and synonyms, drop things that are only attributes (a plate number is data on a ticket, not a class), and drop what is outside the system. Then ask of each remaining noun what it knows and what it does.

An actor is a role outside the system that interacts with it: a driver, an attendant, a payment service. A role, not a person. One person can play several.

A use case is a goal an actor wants to achieve, named with a verb phrase: Enter lot, Pay and exit, Manage slots. A use case describes value to someone, not a screen or a button.

Each use case is detailed as a scenario. Write the main flow as numbered steps, then the alternate flows where things go differently.

• Pay and exit, main flow: the driver presents the ticket, the system computes the fee, the driver pays, the gate opens.
• Alternate: ticket lost, so the system charges a fixed fee after attendant approval.
• Alternate: payment fails, so the gate stays closed and the driver may retry.

The alternates are where the real design lives. Edge cases found here cost a sentence. Found later in code, they cost a release.

Agile teams often write a lighter form: As a driver, I want to pay by card, so that I do not need cash. A story names the actor, the goal and the reason. Pair each with acceptance criteria, concrete checks such as "a successful payment opens the gate within five seconds". These become tests.

By now you can list the actors, the goals, the nouns and the rules. Add the non-functional needs: how fast, how many cars, how reliable. These feed directly into the class diagram in the next lesson. Keep a short list of open questions as well. A requirement you could not state clearly is a risk you have found cheaply.