Module 5 · Requirements & static testing

What Are Requirements?

By the Mutqan Soft QA team · · 20 min · Beginner

A requirement is a statement of something a product must do, or a quality or limit it must meet, because someone with a stake in the product needs it. "The system shall send an SMS reminder 24 hours before each booked appointment" is a requirement. So is "patients must be able to cancel without phoning the clinic", and so is the clinic’s goal behind both: fewer missed appointments.

Those three statements sit at different levels — business, stakeholder and system — come from different people, and are written down in different forms: a strategy document, a user story, a specification, a design, a contract. As you saw in the lesson on test analysis, testing starts from the test basis, and in most products requirements are the largest part of it. This lesson shows how to recognise requirements in all their forms and read them as a tester.

Why it matters

A defect can be born in a requirement before any code exists. If a requirement is missing, vague or wrong, design, code and tests all copy the mistake, and a system can pass every test and still fail the people it was built for. A requirement defect found while the text is being written costs a conversation; found after release, it costs a fix, a retest, sometimes a data clean-up, and the users’ trust.

For the product, requirements are where scope, cost and risk are decided. For the tester, reading them well is the first skill of the role: it decides what you test, what you test first, and how precisely you can explain a failure. "The requirement says 24 hours before; the reminder arrived 2 hours before" is a bug report a developer can act on at once.

Three levels: business, stakeholder and system requirements

Requirements are usually described at three levels. Each level answers a different question, is owned by different people, and refines the level above it: a business goal is reached through things users need to do, and those needs are met through things the system must do.

Names vary. The requirements engineering standard ISO/IEC/IEEE 29148 describes separate specifications for business, stakeholder, system and software requirements; many teams call the middle level "user requirements", and say "software requirements" when the system is only software. In agile teams the levels show up, roughly, as a product goal, the user stories that serve it, and the acceptance criteria and technical notes under each story.

  • Business requirements: why the organisation wants the product — a goal to reach or a problem to solve. Stated by the sponsor, management or the business owner. Example: "Reduce missed appointments at our clinics by a fifth within six months."
  • Stakeholder (user) requirements: what users and other stakeholders need to do or achieve, in their own words. Gathered by the product owner or a business analyst. Example: "As a patient, I want a reminder before my appointment so that I can come on time or cancel early."
  • System (software) requirements: what the system must do and how well, precisely enough to build and test. Agreed with developers and architects. Example: "The system shall send an SMS reminder 24 hours before each booked appointment." This level holds functional and non-functional requirements and constraints; the next lesson separates them.
Clinic appointment reminders at three levels: the business goal of fewer missed appointments, the patient’s need for a reminder, and the system’s SMS sent 24 hours before.

Each level refines the one above it and should trace back to it

At the layer “Business requirements”: Broad goalAt the layer “System (software) requirements”: Precise enough to build and test

  1. 1Business requirementsWhyThe organisation’s goal, stated by the sponsor or business owner: reduce missed appointments by a fifth

    Tester sets priorities and checks that the goal can be measured

  2. 2Stakeholder (user) requirementsWhat users needNeeds in the users’ own words, gathered by the product owner or analyst: a reminder so I can come on time or cancel

    Tester asks whether the product meets the real need (validation)

  3. 3System (software) requirementsWhat the system doesPrecise behaviour, agreed with developers: an SMS reminder 24 hours before each booked appointment

    Tester derives test conditions and expected results

Names vary: ISO/IEC/IEEE 29148 also separates system from software requirements, and agile teams often show the levels as a product goal, user stories and acceptance criteria.

Where requirements come from and the forms they take

Every requirement has a source — the person, document or rule it came from — and a form — the way it is written down. Typical sources are customers and end users, the product owner or business analyst, support tickets and usage data, laws and regulations, standards such as WCAG 2.2 for accessibility, contracts, and the behaviour of an existing system that the new one replaces. Knowing the source tells you whom to ask when the text is unclear.

Most teams keep requirements in several forms at once. The ISTQB Foundation syllabus lists requirement specifications, product backlog items, contracts and models among the work products that static testing can examine, so most of these forms can be reviewed before any code exists. Read them as one set: the story says what the user needs, the design shows the screen, the API contract fixes the fields, and a decision in a chat thread may change all three.

  • Documents: business requirements documents, software requirements specifications, numbered "shall" statements. Precise and versioned, but slow to change.
  • Backlog items: epics, user stories and their acceptance criteria in a tracker. Short by design; the details are agreed in conversation, so make sure decisions are written back into the item.
  • Models: process flows, state diagrams, data models and API contracts such as an OpenAPI file. They expose what prose hides: every state, every field, every error response.
  • Prototypes and designs: wireframes, mock-ups and clickable prototypes. They show layout and flow; ask which parts are binding and which are only sample content.
  • Examples and unwritten expectations: worked examples, Given/When/Then scenarios, and the things nobody writes down because they seem obvious — saved data is not lost, the product obeys the law, it behaves like similar products. These implicit requirements still count.

Try it: OpenAPI Viewer

Worked example: appointment reminders at three levels

A clinic chain is adding reminders to its booking app. Below is the requirement set after the first refinement meeting, grouped by level. Every statement has an identifier, so that questions, test cases and bug reports can point to it.

Read it twice before the next section. Top-down: does every need have something below it that delivers it? Bottom-up: does every system requirement serve a need above it? One of the two checks fails.

Feature: appointment reminders (clinic booking app)

Business
BR-1  Reduce missed appointments at our clinics by a fifth within six months
      of launch.

Stakeholder (user)
UR-1  As a patient, I want a reminder before my appointment so that I can
      come on time or cancel early.
UR-2  As a receptionist, I want to see which patients confirmed so that I
      can call the others.

System
SR-1  The system shall send an SMS reminder 24 hours before each booked
      appointment, in the language the patient chose (Arabic or English).
SR-2  The SMS shall contain a link to confirm or cancel the appointment.
SR-3  When a patient cancels through the link, the slot shall become
      bookable again within 1 minute.

Try it: Requirements → Test Cases Try it: Requirements → Test Scenarios

Why testers read requirements, shown on the example

In the lesson on test analysis you evaluated the test basis and derived test conditions from it. Requirements are usually the largest part of that basis, and reading them early gives a tester everything below — each point visible in the reminder example.

  • Missing pieces, before code exists. The bottom-up check passes: SR-1 and SR-2 deliver UR-1, and SR-3 makes an early cancellation useful by freeing the slot for another patient. The top-down check fails: no system requirement delivers UR-2, so nothing says where confirmations appear or who sees them. Raised now, it is a review comment; found in system testing, it is a missing feature. Reviewing requirements like this is static testing, and the ISTQB principle "early testing saves time and money" applies directly.
  • Expected results. A requirement is the usual test oracle, the source of the expected result. SR-3 gives one directly: cancel through the link, and the slot must be bookable again within 1 minute.
  • Questions a test cannot answer by itself. SR-1 does not say what happens to an appointment booked less than 24 hours ahead, in which time zone "24 hours before" is computed, or which language is used if the patient chose none. Each answer becomes an expected result.
  • Priorities. BR-1 tells you why the feature exists: a reminder that never arrives defeats the goal, a typo in the SMS does not. It also reveals a hidden need: the goal can only be measured if the system records missed appointments.
  • Validation as well as verification. Checking the build against SR-1 is verification; asking whether an SMS 24 hours ahead is really what patients need is validation, as in the lesson on verification and validation.
  • Traceable work. Test conditions keep their source — "reminder sent 24 hours ahead (SR-1)", "appointment booked 3 hours ahead (SR-1)", "cancel link frees the slot (SR-3)" — so coverage and failures can be reported per requirement.

Common mistakes

  • Treating only a formal specification as "the requirements" and ignoring user stories, designs, API contracts and decisions made in chat — or the reverse, testing a story without opening the design and contract that add its details.
  • Reading only the system-level details and skipping the business goal, so you cannot tell which failures matter most or whether the feature solves the problem at all.
  • Waiting for a build before reading the requirements, which skips the cheapest moment to find a missing or contradictory requirement.
  • Filling gaps silently with your own assumptions. The test then checks your guess, not the agreed behaviour; ask, and write the answer into the requirement or the story.
  • Testing against an outdated version. Requirements change, so check the version or date of the story, specification or design you derive tests from.
  • Believing that what is not written is not required. Unwritten expectations — no data loss, legal compliance, consistency with the platform — are implicit requirements, and a product that breaks them can still be reported.

The QA perspective

On a working team the tester joins the requirement conversation early: in refinement, in "three amigos" sessions with the product owner and a developer, or in the review of a specification. Ask the product owner or business analyst about the business and user levels ("Who needs this, and how will we know it worked?") and developers or architects about the system level ("What are the limits, and what happens when it fails?"). Support staff and the people who will use the product are often the best source of real user needs.

Record as you go. Note the identifier and version of every requirement you test against, put each question and its answer in the story or ticket rather than in your head or a private chat, and link test cases and bug reports to requirement IDs. When requirements are thin, write your understanding down as a short list of expected behaviours and ask the product owner to confirm it; testing against unconfirmed assumptions is a risk to state in your test report.

Practice exercise

Sort a requirement set by level, source and form

Your task

A pharmacy chain is adding online prescription refills to its app. Read the six statements below. For each one, decide its level (business, stakeholder or system), name its likely source and form, and write one question a tester would ask before designing tests.

Then check the set top-down and bottom-up, and name any need that has nothing below it.

Material
Feature: online prescription refills (pharmacy app)

R1  Cut phone calls to our branches about refills by half within a year.
R2  As a patient, I want to request a refill from my phone so that I do
    not have to call the branch.
R3  As a pharmacist, I want one list of the refill requests of my branch,
    ordered by pickup time, so that I can prepare them in order.
R4  The app shall list only prescriptions that have refills left and
    have not expired.
R5  The app shall send a push notification when a refill request
    changes to "Ready for pickup".
R6  Prescription data shall be stored and processed in line with the
    national health-data protection regulation.
Steps
  1. Label each statement with its level: business, stakeholder (user) or system.
  2. Note the likely source (who or what it came from) and the form it is written in.
  3. Link each system requirement to the need it serves, and each need to the business goal.
  4. Mark any need with nothing below it, and write one question per statement.
Show the model answer
Model answer

Levels: R1 is a business requirement (a goal of the chain, from management, usually written in a business case or a project goal). R2 and R3 are stakeholder (user) requirements, from patients and pharmacists through the product owner, written as user stories. R4 and R5 are system requirements, from the product owner and developers, in a specification or in the acceptance criteria of R2. R6 is a system-level constraint whose source is a regulation; its form here is a "shall" statement that points to a legal text.

Links: R4 and R5 serve R2, and R2 serves R1. R3 serves R1 only indirectly: when refills are ready at pickup time, patients have less reason to call. R6 serves no user need, and that is not a gap: a constraint traces to its source, here the regulation, not to a story. Gap: nothing at the system level delivers R3 — no requirement describes the pharmacist’s list, its order or its filters. Raise it as a review comment.

Questions: R1 — how are calls counted today, and what is the current number? R2 — which app platforms, and must the patient sign in? R3 — in what order do requests without a pickup time appear, and can a pharmacist see other branches? R4 — is a prescription that expires today still listed? R5 — what happens if the patient has turned notifications off? R6 — which regulation and which articles apply, and how long may refill data be kept?

R4 and R5 can become test conditions now; R3 cannot be tested until its system requirement exists, and R1 is measured after release rather than by a test case.

Frequently asked questions

Is a user story a requirement?

Yes. A user story is a common form of a stakeholder (user) requirement, but on its own it is short on detail; the details come from its acceptance criteria, examples and the conversation around it. User stories have their own lesson later in this module.

What do I test against when there are no written requirements?

Against whatever the team has agreed: conversations, designs, the existing system, similar products, regulations and the reasonable expectations of users. Write your understanding down as a short list of expected behaviours, ask the product owner to confirm it, and report any behaviour you tested against an unconfirmed assumption.

Do business requirements get tested?

Not usually by a test case before release. They are checked by measuring outcomes after release, which is a form of validation. Before release a tester uses them to set priorities and to check that the system records the data needed to measure them.

Is a requirement the same as a specification?

Not quite. A requirement is one need or condition; a specification is a document that collects requirements, often with other information such as context, definitions and designs. One specification usually holds many requirements, and one requirement can be spread across a story, a design and a contract.

References

Tools

Practise with Mutqan tools

Requirements → Test Cases

Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.

Test Design

OpenAPI Viewer

Render an OpenAPI 3.x / Swagger 2.0 spec (JSON or YAML) as browsable endpoint documentation.

Web

AI Requirement Gap Analyzer

Find missing requirements — error handling, permissions, edge conditions, non-functional needs — with Mutqan AI.

Requirement Analysis AI

Go deeper

Your progress on this topic

Part of the QA Roadmap

Before this topic