Requirements Review

Review a feature's acceptance criteria before development begins — identify gaps, ambiguities, and risks, write clarifying questions, produce improved testable criteria, and generate an initial test-ideas list with traceability.

Role

Manual QA engineer

Difficulty

Intermediate

Time limit

60–90 min

Scenario

You are a QA engineer joining the sprint planning session for a new 'User Profile Edit' feature. The product owner has shared the following four acceptance criteria and asked whether they are ready to hand to development: (1) Users can update their display name. (2) Users can upload a profile photo. (3) Email address can be changed. (4) Changes are saved when the user clicks Save. Your task is to review these requirements before a single line of code is written — identify every gap and ambiguity, raise clarifying questions, document assumptions, surface risks, rewrite the criteria to be specific and testable, and produce an initial list of test ideas derived from the improved criteria.

Requirements

1.Identify at least six specific gaps or ambiguities in the four acceptance criteria — reference which AC each gap belongs to
2.Write one targeted clarifying question per identified gap, phrased as you would ask the product owner in a refinement session
3.Produce an assumptions list: for each gap you cannot resolve before development starts, state the assumption you will test against
4.Build a risk register with at least four risks derived from the requirements (technical, UX, or security), each with a likelihood, impact, and mitigation suggestion
5.Rewrite all four acceptance criteria in Given-When-Then or a structured format that removes ambiguity and is directly testable
6.Produce an initial test-ideas list with at least eight items, each traced back to the source AC by ID
7.Flag which of the original four ACs are not testable as written and explain what is missing

Starter data

›AC-1: Users can update their display name — no character limits, allowed characters, uniqueness constraint, or profanity-filter requirement stated
›AC-2: Users can upload a profile photo — no accepted file types, maximum file size, minimum/maximum dimensions, or image processing (crop, resize) behaviour stated
›AC-3: Email address can be changed — no re-authentication requirement, no email verification step, no uniqueness check, no mention of what happens to active sessions after the change
›AC-4: Changes are saved when the user clicks Save — no success confirmation UI, no error state for a failed save, no partial-save behaviour (what if display name saves but photo upload fails?), no unsaved-changes warning on navigation away
›Context: the app is a SaaS product with thousands of registered users; users log in with email + password; there is an existing session management system using JWTs

Expected deliverables

✓A numbered gaps-and-ambiguities list (minimum six items), each referencing its source AC and explaining why the gap is a testability issue — not just a style preference
✓A clarifying questions document with one specific, actionable question per gap
✓An assumptions list covering every gap where no clarification will be available before sprint start
✓A risk register with at least four risks, each with: description, likelihood (High/Medium/Low), impact (High/Medium/Low), and a one-sentence mitigation
✓Rewritten acceptance criteria for all four AC items — specific, measurable, and unambiguous
✓An initial test-ideas list (minimum eight items) with a traceability column linking each idea to its source AC

Evaluation rubric

Dimension	What reviewers look for
Gap and ambiguity identification	Are the identified gaps genuine testability issues rather than stylistic preferences? Does the candidate catch the most critical gap — AC-3 allows email changes without re-authentication or verification, which is an account-takeover risk? Gaps should be specific: 'no maximum character limit on display name' is actionable; 'AC-1 is vague' is not.
Risk awareness	Are the risks specific and technically grounded? The security risk in AC-3 (email change without re-auth = account takeover vector) is the highest-stakes finding and should appear with High likelihood and High impact. The candidate should also flag the partial-save ambiguity in AC-4 as a data-integrity risk, not just a UX issue.
Quality of improved acceptance criteria	Do the rewritten ACs contain concrete, measurable constraints? For example, AC-1 improved: 'Given a logged-in user on the profile edit page, when they enter a display name of 2–50 characters (alphanumeric, spaces, hyphens only) and click Save, then the display name is updated and shown in the header within 2 seconds.' A rewrite that just rephrases the original without adding constraints shows the candidate has not understood what makes an AC testable.
Testability thinking	Are the test ideas directly traceable to specific ACs? Do they cover positive, negative, edge, and security cases — not just happy-path scenarios? A test-ideas list that covers only 'upload a valid photo' and 'update display name successfully' without addressing duplicate emails, oversized file uploads, or session behaviour after email change is incomplete.
Communication — question quality	Are clarifying questions phrased to elicit a concrete decision from the product owner? 'Can you clarify AC-2?' fails the bar. 'What file formats should be accepted for profile photos, and what is the maximum file size in MB?' passes it. Questions should be specific enough to get a yes/no or a specific value, not a discussion.

Sample solution outline

›Gap-1 (AC-1): No character length constraints — Q: 'What is the minimum and maximum character length for a display name?' — Assumption if unresolved: 2–50 characters based on common patterns
›Gap-2 (AC-1): No allowed character set — Q: 'Are special characters (e.g. emoji, Chinese characters, angle brackets) allowed in display names?' — Risk: XSS via stored display name if not sanitised
›Gap-3 (AC-2): No accepted file types — Q: 'Which image file types are accepted for profile photos (JPEG, PNG, WebP, GIF)?' — Assumption: JPEG and PNG only
›Gap-4 (AC-2): No file size limit — Q: 'What is the maximum file size for a profile photo upload?' — Risk: DoS via multi-GB uploads if no limit enforced
›Gap-5 (AC-3): No re-authentication before email change — Q: 'Is the user required to enter their current password before changing their email address?' — Risk: session hijacker can silently reroute account recovery to attacker-controlled email (HIGH / HIGH)
›Gap-6 (AC-3): No email verification step — Q: 'Should the new email address be verified before it takes effect, or does the change apply immediately?' — Assumption if unresolved: verification required, change takes effect only after link clicked
›Gap-7 (AC-4): No error state defined — Q: 'What should the user see if the save operation fails due to a server error — a toast, inline error, or modal?' — Assumption: toast message with retry option
›Gap-8 (AC-4): Partial-save ambiguity — Q: 'If the display name saves but the photo upload fails in the same Save action, should the display name change be committed or rolled back?' — Risk: inconsistent profile state if partial saves are silently committed
›Improved AC-3: 'Given a logged-in user on the profile edit page, when they enter a new email address, enter their current password for re-authentication, and click Save, then (a) a verification email is sent to the new address, (b) the email is not changed until the verification link is clicked, (c) the link expires after 24 hours, and (d) all active sessions except the current one are invalidated once the new email is confirmed'
›Test ideas: TC-1 (AC-1) Enter 50-character display name → saved; TC-2 (AC-1) Enter 51-character name → blocked with error; TC-3 (AC-2) Upload 5 MB PNG → accepted; TC-4 (AC-2) Upload 25 MB file → rejected with size error; TC-5 (AC-3) Change email without re-auth step → must not be possible; TC-6 (AC-3) Change to email address already registered → error; TC-7 (AC-4) Simulate save failure (network offline) → user sees error, no partial commit; TC-8 (AC-4) Navigate away with unsaved changes → warning prompt shown

Common mistakes

Treating requirements review as copy-editing — fixing grammar or passive voice rather than identifying functional gaps, missing constraints, and testability issues
Writing questions that are too broad — 'Can you clarify AC-3?' gives the PO no direction; 'Is the user required to enter their current password before changing their email address?' gets a decision
Missing the security gap in AC-3 — changing an email address without re-authentication or verification is an account-takeover vector; QA is often the last line of defence before a security design flaw reaches production
Producing only happy-path test ideas — the value of a QA review at requirements stage is surfacing negative and edge cases before they are built in, not after
Confusing gaps (something not mentioned at all) with ambiguities (something mentioned but open to multiple interpretations) — both are valid findings but they produce different questions and different risk profiles
Improving ACs without traceability — every test idea should link back to a specific AC so that the team can verify that no requirement is untested and no test is untethered to a requirement

Submission checklist

At least six gaps/ambiguities identified, each referencing its source AC
One specific, actionable clarifying question per gap
Assumptions list covering all gaps not resolved before development starts
Risk register with at least four risks, each with likelihood, impact, and mitigation
All four ACs rewritten with specific, measurable constraints
At least eight test ideas, each with a traceability link to the source AC
At least one risk explicitly addresses the security gap in AC-3 (email change without re-authentication)
At least one AC identified as not testable as written, with an explanation of what is missing

Extension ideas

+Apply the same review process to a checkout or payment-flow requirements document and compare the types of gaps and risks you find
+Build a full test case suite from your improved acceptance criteria and verify that every rewritten AC has at least one corresponding test case
+Practise presenting your findings as a 10-minute refinement-session walkthrough: which gaps would you prioritise raising first, and how would you frame the security risk without blocking the sprint?