Requirement Defects

Why it matters

A requirement defect does not stay in the document. The developer builds one reading, the tester checks another, and the difference surfaces late, when design, code and tests all have to change. Where a requirement is missing, the behaviour is decided by accident, and the first person to see it may be a customer.

For the tester the cost is direct: a test case needs an expected result, and a defective requirement gives none, or two. Tests written from the same text can even pass against the wrong behaviour, because code and tests share the misunderstanding. This is the ISTQB principle "early testing saves time and money" in practice: a question in a review costs minutes, the same question after release costs a fix and a retest.

Four kinds of requirement defects

Name the kind when you raise a finding, because each kind is resolved differently. ISTQB lists inconsistencies and contradictions separately; this lesson counts both as contradictory. Whether a requirement is correct at all belongs to the lesson on requirements validation.

• Ambiguous: the text allows more than one reasonable reading, so two careful people could build or test different behaviour and both follow it. Causes include vague words, undefined terms, a missing unit, and a condition that may apply to one item in a list or to all of them.
• Incomplete: the requirement exists and its main path is clear, but part of its behaviour is not stated, such as an error path, a limit, a role, or what happens on rejection or timeout. You can test the happy path, not the rest.
• Contradictory: two statements cannot both be true in the same situation, so every possible result breaks one of them. The conflict may be inside a requirement, between requirements, or with a business rule, a design or an API contract (the agreed description of an interface’s requests and responses).
• Missing: a behaviour or rule the product needs is not written anywhere, so there is no sentence to mark. Unlike an incomplete requirement, the gap is not inside an existing requirement but where none exists.

Where each kind hides and how to look for it

Each kind needs its own search:

• Ambiguity: try to write two different expected results that both follow the text. If you can, it is ambiguous. Check every number for its unit, its starting point and whether the limit itself is included.
• Incompleteness: ask of every requirement who may and may not do this, and what happens when the input is invalid, a limit is reached, the action is rejected or a system it depends on fails.
• Contradiction: compare requirements that touch the same actor, data or rule, and compare them with business rules, designs and the API contract. A decision table, as in the lesson on business rules, shows combinations where two rules demand different actions.
• Missing requirements: walk the business process end to end, and the life of each object, such as a request, through creation, change, cancellation and expiry; listing its states and events shows events nobody specified. Then check each role and the quality characteristics of ISO/IEC 25010, such as security and reliability.

Try it: Decision Table Generator Try it: State Transition Generator

Worked example: a leave-request specification

An HR portal’s draft specification for leave requests is due for backlog refinement, and the tester reviews it first. Try to find one defect of each kind before reading the findings.

Leave requests: HR portal, release 3 (draft)

LV-1  An employee requests leave by choosing a leave type, a start date and an
      end date.
LV-2  A leave request must be submitted at least 5 days before the leave starts.
LV-3  Team leads and employees with more than 2 years of service receive 30 days
      of annual leave per year. Other employees receive 21 days.
LV-4  The employee’s manager approves or rejects the request. Requests longer
      than 10 days also need approval from HR.
LV-5  Sick leave can be requested on the day it starts.
LV-6  Approved leave days are deducted from the employee’s balance.

Try it: Requirements → Test Cases

The findings and the question to raise for each

Each finding names the kind, the case that exposes it and a question for the requirement owner, here the HR product owner. A good question offers the possible answers instead of asking "what does this mean?", so it can be answered in one line.

• Ambiguous, LV-3: "with more than 2 years of service" may apply to both groups or only to employees, so a team lead with 1 year of service gets 21 days in one reading and 30 in the other. Ask: "Does a team lead with 1 year of service get 21 or 30 days?"
• Incomplete, LV-4: it names the approvers, but for a request over 10 days only the outcome when both approve is clear. Ask: "For a 12-day request, who decides first? If the manager approves and HR rejects, what is the final status, and what happens if nobody responds?"
• Contradictory, LV-2 and LV-5: same-day sick leave is rejected by LV-2 and allowed by LV-5. Ask: "Is sick leave exempt from the 5-day notice in LV-2?" Usually one statement is narrowed; the owner decides which.
• Missing: nothing says whether an employee can cancel a request; LV-6 deducts days, but nothing returns them. Ask: "Can an employee cancel a pending or approved request, until when, and are the days restored? If this is out of scope for release 3, can we record that?"
• Also worth raising: are the 5 days in LV-2 calendar days or working days?

Try it: AI Requirement Ambiguity Detector Try it: AI Requirement Gap Analyzer

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.