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
- What is missing from “The page must load quickly”?
- Why should authorization rules not exist only inside a screen description?
- What do
Given,WhenandThenrepresent?
- A measurable loading target, test conditions, device or network assumptions and the page state being measured.
- The same rule may apply through several interfaces or APIs. Keeping it explicit prevents inconsistent implementation.
Givendefines context,Whendefines the action andThendefines the expected observable result.