Course progress0%
Course content
22 min

Write Requirements That Can Be Verified

Turn discoveries into user stories, business rules and acceptance criteria that guide the solution.

By the end of this lesson

  • Write outcome-focused user stories
  • Express business rules separately
  • Create testable acceptance criteria
  • Detect vague requirements

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.”

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.

Lesson complete?

Your progress is saved on this device.