From One Line to a List of Requirements

"Design a parking lot" is four words. The design you are asked for has about twelve classes in it. Everything between those two things is yours to decide.

That is not a trick. A real product starts the same way. Somebody gets a short request and has to turn it into a specification. This step is the work, and it is the step most answers skip.

This lesson turns one sentence into a written list you can design against.

Why the list has to exist first

A requirement is one thing the system must do. It is written so that you can tell whether the design does it. "Customers can pay at the exit" is a requirement. "The parking lot should be good" is not.

Without that list, three things go wrong.

The design has no edges. You keep adding classes because nothing tells you to stop. Ten minutes later you are modeling season tickets and number plate recognition. You have not written a line of code.

You cannot defend a choice. The interviewer asks why there is no Reservation class. The only honest answer is that you did not think of it. With a list, the answer is different. Reservations were out of scope, and you agreed that at minute four.

You cannot tell when you are finished. A bounded list is what turns "design a parking lot" into a task with an end.

The four questions that produce the list

Ask these in order. They take about five minutes and they cover most products.

Who uses this? Name the kinds of people and systems that touch the product. These are the actors. For a parking lot that is a customer, an attendant, an administrator, and the system itself. Each one brings requirements the others do not.

What can each of them do? Take one actor at a time and list their actions. Each action is a use case. A customer takes a ticket, parks, pays, and leaves. An administrator adds floors and changes prices. This is where most of the list comes from.

What are the limits? Numbers and rules. How many floors, how many spot types, how long a booking lasts, how many books a member may hold. Limits become constants and validation. They are the easiest requirements to gather.

What is out of scope? Say what you are not building. This is the most valuable question and the one most people never ask. It is the only one of the four that makes the problem smaller.

Ask about scope out loud

Scope questions are not a formality. They change the design, and asking them is part of what is being judged.

Three that are worth asking in almost any question:

• "Should I handle payments, or assume a payment service exists?"
• "Is this a single location, or many locations under one account?"
• "Do I need to model users and permissions, or can I assume an authenticated user?"

Each answer removes or adds two or three classes. Ask them early, while removing them is still easy.

If the interviewer says "your choice", that is not a refusal. Choose, say your choice out loud, and write it in the out of scope list. A stated assumption is as good as an answer.

What good looks like

Here is the parking lot, bounded in ten lines.

In scope

1. The lot has multiple floors, and each floor has many parking spots.
2. Spots come in types: compact, large, handicapped, motorbike, electric.
3. Vehicles come in types: car, van, truck, motorbike, electric car.
4. A customer takes a ticket at an entrance panel when they arrive.
5. A customer pays at an exit panel, at a floor portal, or to an attendant.
6. Payment is by cash or card.
7. Pricing is hourly, and the rate changes with the number of hours.
8. Each floor shows how many spots of each type are free.
9. The system refuses entry when no spot of a suitable type is free.
10. An administrator can add floors, spots and panels, and change the rate.

Out of scope

Season tickets, number plate recognition, reservations ahead of arrival, refunds, and multi location reporting.

Ten lines. Every one of them is either a class, a field, or a method in the design that follows. Nothing in the design will exist without a line here that asked for it.

Turn each requirement into something checkable

Two habits make the list usable in the next step.

Write the number. Not "a member can borrow a few books". Write "a member can hold at most five books at a time". The number becomes a constant, and the constant becomes a check in one method.

Name the actor. Not "books can be reserved". Write "a member can reserve a copy that is currently on loan". Now you know which class the method belongs to.

A requirement written this way is almost a test. You can point at one method and say that this line is where requirement five lives.

The mistake to avoid

The common failure is agreeing to everything. The interviewer suggests reservations, and you say yes. They mention multiple locations, and you say yes. Twenty minutes later the list has twenty two items and no design has started.

You are allowed to say no. "I would like to leave reservations out so I can get the ticket and payment flow working. If there is time at the end I will add it." That sentence is a good answer, not a weak one. It shows you are managing a fixed amount of time against an unbounded request. That is the same judgement the job needs.

Key Takeaways

• A requirement is one thing the system must do, written so you can check whether the design does it.
• Ask four questions in order: who uses this, what can each of them do, what are the limits, and what is out of scope.
• The out of scope list is the most valuable part and the one most people skip.
• Aim for 8 to 12 in scope lines. Every class you write later should trace back to one of them.
• Write the number and name the actor, so each requirement points at a constant and a class.
• Saying no to extra scope is a strength. Say what you are leaving out and why.

The list is the contract for the rest of the hour. Once it exists, the question stops being open ended. Every later decision has something to be measured against. The next lesson uses that list to find the classes.