Write Requirements You Can Check

“The program should work well” is a worthy goal, but it does not tell you how to recognize success.

A checkable requirement connects a situation to an observable result.

For the quiz engine, compare:

The program should judge answers fairly.

with:

Ignore surrounding spaces and capitalization when comparing answers, but otherwise require the complete answer to match.

The second version gives you examples you can test. " Pacific " matches "pacific", while "Pacific Ocean" does not.

Identify four parts

For a small program, write down:

1. Inputs: values the program receives.

2. Outputs: values it returns or text it displays.

3. Stored data: values it must keep while doing the work.

4. Rules: decisions and calculations that connect inputs to outputs.

For the quiz engine:

This is not code yet. Think of it as a map of the information and behavior the code will need to represent.

Include unsuitable and empty cases

Requirements often describe the normal case and forget everything else.

For this project, useful questions include:

• Is a plan with exactly three questions ready, or does it need more than three?

• Can a title, prompt, or expected answer contain only spaces?

• What happens when two prompts differ only in capitalization or surrounding spaces?

• Can the final score be zero? Can it equal the number of questions?

• What should happen when the learner submits an empty answer?

Not every program needs to support every possible input. It does need a deliberate contract.

For example:

A quiz plan satisfies its question-count requirement when it has at least three questions.

The phrase “at least” settles the boundary: exactly three is enough. Another project could choose five. The important part is choosing and stating the behavior before the code quietly chooses for you.

Avoid hidden words

Words such as “fast,” “friendly,” “properly,” and “reasonable” need clarification. They sound precise right up until two people interpret them differently.

Instead of:

Clean the answer properly.

write:

Ignore surrounding whitespace and capitalization when comparing the answer.

Instead of:

Handle empty answers helpfully.

write:

If the cleaned answer is empty, show "Please enter an answer." and ask the same question again.

Now another person can build the program, and both of you can agree whether it satisfies the requirement.

Make an acceptance checklist

Before coding, turn the quiz brief into a small checklist:

• padded and differently capitalized versions of one answer match;

• a different complete answer does not match;

• exactly three questions satisfy the question-count requirement;

• empty titles, prompts, answers, and responses have defined outcomes;

• the final report contains the promised score.

That checklist will become concrete examples and automated checks in the next lessons. We are giving future-you fewer mysteries to solve.