Write Requirements That Can Be Verified

A requirement must guide a decision

“The application should be easy and fast” sounds useful, but nobody can verify it consistently.

A better requirement defines observable behavior:

A teacher can open the current class list and begin attendance in no more than three actions.

User stories provide context

As a teacher,
I want to record attendance for my current class,
so that the institution has an accurate record of the session.

The story identifies the user, action and value. It does not contain all the rules.

Business rules remain explicit

• Only the teacher assigned to the class can record attendance.
• One attendance record exists per student and session.
• Corrections are allowed for 48 hours.
• Every correction keeps the previous value, new value, time and author.

Separating rules prevents them from disappearing inside interface descriptions.

Acceptance criteria make the story testable

Given an assigned teacher and an active class session
When the teacher marks a student absent
Then the system stores the student, session, status, time and teacher

Given an attendance record older than 48 hours
When the teacher tries to change it
Then the system refuses the change and explains the restriction

Given establishes context, When describes the action and Then defines the expected result.

Find vague words

Review requirements for words such as:

• fast
• simple
• user-friendly
• secure
• appropriate
• normally

Replace each vague word with observable criteria or document the decision that is still required.

Activity: improve this requirement

The system must quickly notify students when something changes.

Identify at least five missing decisions before rewriting it.

Missing decisions include what event triggers the notification, which students receive it, which channel is used, how quickly it must arrive and what happens after a delivery failure.

A possible requirement is: “When a teacher changes the time of a class scheduled within the next seven days, the system sends an in-app notification to enrolled students within one minute and records delivery status.”

Practice the mindset: make disagreement visible

"Loyal customers receive a discount on large orders."

Pause and write: Identify the words that two people might interpret differently. Write the questions; do not choose the answers on behalf of the owner.

New information

For this exercise, the owner confirms a rule: a customer with at least five completed purchases receives 10% off a full-price order whose subtotal is strictly greater than 100 units. Delivery is excluded from that subtotal. An order with an existing promotion is excluded.

Check the boundary

These examples expose the difference between "greater than" and "at least." Missing purchase history remains an open decision, not permission to guess a value.

Independent practice: The owner changes the threshold to "100 or more." Identify the example that changes, rewrite the rule and explain which examples remain unchanged.

Review your reasoning

The order at exactly 100 becomes eligible. The other examples keep their results because their relevant conditions did not change. Updating a rule should include checking its examples for consistency.

Engineering habit: A concrete example can reveal a disagreement that an apparently clear sentence hides. Have the responsible person confirm the rule and its examples together.

What you learned

• A useful requirement describes observable and verifiable behavior.
• User stories explain actor, action and value without hiding every rule inside one sentence.
• Business rules should remain explicit and reusable.
• Acceptance criteria define the context, action and expected result.

Knowledge check

1. What is missing from “The page must load quickly”?
2. Why should authorization rules not exist only inside a screen description?
3. What do Given, When and Then represent?

1. A measurable loading target, test conditions, device or network assumptions and the page state being measured.
2. The same rule may apply through several interfaces or APIs. Keeping it explicit prevents inconsistent implementation.
3. Given defines context, When defines the action and Then defines the expected observable result.