How to Review Requirements
A requirements review is a static test of the test basis: before anyone designs, codes or tests, a small group reads the requirement or user story and asks whether it is clear, complete, consistent, correct, testable, feasible, traceable and explicit about non-functional needs. Every question answered here is a decision the developer will not have to guess and a defect the tester will not have to find later.
This guide gives the process a tester can run in any team, a checklist with the questions to ask for each criterion, the words that signal trouble, and a complete worked example — a user story, the review comments it received, and the story after rework. It ends with how Mutqan’s AI requirement tools fit in: they draft findings; a person decides.
What a requirements review is and why it pays
In the ISTQB vocabulary, requirements and user stories are part of the test basis — the material tests are derived from. Reviewing them is static testing, and CTFL v4.0 lists requirement defects — inconsistencies, ambiguities, contradictions, omissions, inaccuracies and duplications — among the defects that static testing finds more easily and cheaply than dynamic testing. A requirement defect that survives becomes code, then tests written to the same misunderstanding, and it is finally found by a user.
A requirements review also produces shared understanding, which no document delivers on its own. When the product owner, a developer and a tester read the same story together — the practice many agile teams call the “three amigos” — each brings different questions: what the business needs, how it can be built, and how it can fail. The review type is usually informal or a short technical review; for regulatory or financial rules, an inspection with a checklist is justified. The review types and roles are compared on their own page.
How to run a requirements review, step by step
- Choose the moment. Review a story before it is accepted into a sprint (many teams make “reviewed” part of their definition of ready), and review it again when it changes.
- Gather the context. Open the epic, linked business rules, the API contract, designs and any regulation the story touches. Many contradictions are between documents, not inside one.
- Read individually first. Each reviewer reads with the checklist below and writes findings before any discussion, so that the first opinion voiced does not anchor everyone else.
- Write findings as review comments. One finding per comment: where, what is wrong, why it matters, a proposed rewrite or a question, and who must decide.
- Discuss and decide. In refinement or a short meeting, the author accepts, rejects or changes each finding. Open questions get an owner and a date; nothing is left as a silent assumption.
- Rework and re-check. The author updates the story and acceptance criteria; a reviewer confirms each accepted finding is resolved before the story is marked ready.
- Keep the findings. A log of finding types (ambiguity, missing error path, conflicting rule) shows which checklist items and template headings your team needs most.
Try it: AI Requirement Ambiguity Detector Try it: AI Requirement Gap Analyzer
The requirements review checklist
Use the eight criteria as headings for your notes. The questions under each are the ones that most often find defects.
- Ambiguity — Could two readers build or test it differently? Are there vague words (fast, easy, appropriate), undefined terms, pronouns with unclear referents, or “and/or”?
- Completeness — Are error paths, empty states, limits, permissions and roles covered? What happens on timeout, duplicate submission, cancellation, or invalid data? Who can do this, and who cannot?
- Consistency — Does it contradict another story, a business rule, the API contract, the UI design, or itself? Are the same things called by the same names?
- Correctness — Is it what the business and the user actually need? Is it right for the domain, the law and the current policy? Are the numbers (fees, limits, VAT, dates) correct and sourced?
- Testability — Does each acceptance criterion describe an observable result with a clear pass or fail? Could you write the expected result of a test case from it today?
- Feasibility — Can it be built with the available technology, data, third-party services, time and budget? Does it depend on something the team does not control?
- Traceability — Does it have a unique ID, a link up to its epic or business goal and to related rules, and will test cases be able to reference it?
- Non-functional needs — Are performance, security, privacy, accessibility, localisation, reliability and audit needs stated with measurable criteria, or at least marked as decided elsewhere?
Red-flag words and what to ask instead
Certain words almost always hide an undecided requirement. Search the text for them before reading in depth; each one is either a finding or a quick confirmation that the meaning is defined elsewhere.
Word in the requirement Ask instead
fast, quickly, promptly within how many seconds or minutes, at what percentile, under what load?
user-friendly, easy, intuitive which task, for which user, measured how?
appropriate, reasonable, adequate what exactly? list the cases or give the number
etc., and so on, such as what is the complete list?
should, may, might mandatory or optional?
all, always, never, every really all? what are the exceptions?
support, handle, process, manage what is the observable behaviour?
and/or both, or either one?
secure, robust, scalable against what threat, failure or load?Worked example: a user story and its review comments
For example, a fictional online store has this story in its backlog. The team also has a business rule, BR-4 in its account rules document: unverified accounts cannot sign in.
The comments below are written the way they would appear in a review tool or on the ticket: one issue each, located, with a reason and a proposal or question. Note that the reviewer proposes values but does not decide them — decisions belong to the product owner, and to security where security is involved.
US-231 Reset password by email
As a registered customer
I want to reset my password from the login page
so that I can get back into my account when I forget it.
AC1 The customer enters their email and receives a reset link.
AC2 The link expires after a reasonable time.
AC3 The new password must be strong.
AC4 After resetting, the customer is logged in automatically.
AC5 The page should be fast and user-friendly.
AC6 Customers with unverified accounts can also reset their password.
--- Review comments ---
RC-01 [Testability · Major] AC2
"A reasonable time" cannot be tested: two testers will pick two different numbers.
Proposal: "The link expires 30 minutes after it is sent." @PO is 30 minutes right?
RC-02 [Ambiguity · Major] AC3
"Strong" is not defined here. Is this the existing password policy SEC-12?
If so, reference it. Can the new password be the same as the current one?
RC-03 [Completeness · Major] AC1
No behaviour for an email that is not registered. If the message differs, the
form reveals which emails have accounts. Proposal: show the same message in both
cases. @Security please confirm.
RC-04 [Completeness · Minor] AC1, AC2
Is the link single-use? If the customer requests two links, is the first one
still valid?
RC-05 [Consistency · Major] AC4 + AC6
Together they let an unverified account sign in, which contradicts BR-4
("unverified accounts cannot sign in"). One of the three has to change.
RC-06 [Correctness · Question] AC4
Should a password reset sign out existing sessions on other devices? Automatic
sign-in right after a reset needs a security decision.
RC-07 [Non-functional · Major] AC5
"Fast and user-friendly" is two requirements and neither is measurable. Split
into a response-time target and the team accessibility checklist. Also: which
language is the email sent in, Arabic or English?
RC-08 [Feasibility · Question] AC1
Is there a limit on reset requests? Without one, the form can be used to flood
a customer inbox and to run up email-provider costs.
RC-09 [Traceability · Minor] Story
Not linked to its epic or to SEC-12 and BR-4. Add the links so test cases can
trace to the rules they check.Try it: AI Requirement Ambiguity Detector Try it: AI Acceptance Criteria Reviewer
The story after rework
In this fictional example the product owner and the security lead answered the questions, and the author rewrote the criteria. The numbers are the team’s decisions, not recommendations. Every criterion now has an observable result, and the story traces to the rules it depends on.
US-231 Reset password by email (v2, after review)
Links: EPIC-AUTH-3 · SEC-12 password policy · BR-4 verified accounts · PERF-2 response time
AC1 Given the "Forgot password" form, when any email address is submitted,
then the same confirmation message is shown whether or not it is registered.
AC2 Given a registered, verified address, a reset link is sent. The link is
single-use and expires 30 minutes after it is sent. A new request
invalidates all earlier links.
AC3 The new password must satisfy SEC-12 and differ from the current password.
AC4 After a successful reset, all existing sessions are signed out and the
customer is taken to the login page with a success message.
AC5 For an unverified account, the verification email is sent instead of a
reset link (BR-4).
AC6 At most 5 reset requests per account per hour. Further requests show the
same confirmation message and send nothing.
NFR1 The reset email is sent in the account language (Arabic or English).
NFR2 The form passes the team accessibility checklist: labelled fields,
announced error messages, full keyboard operation.
NFR3 Response time: the site-wide target PERF-2 applies (p95 under 2 s for form
submissions at the PERF-2 reference load); the product owner set no
story-specific target.Try it: AI Acceptance Criteria Generator Try it: Acceptance Criteria Generator
Reviewing non-functional requirements
Non-functional needs are the most frequently missing part of a story, because the story template asks only for behaviour. ISO/IEC 25010 describes the product quality characteristics — among them performance efficiency, security, reliability, compatibility and interaction capability (usability) — and it makes a useful prompt list: for each characteristic, ask whether the story affects it and, if so, where the criterion is written.
- Performance — a number, a percentile and a load: “p95 response under 2 s at 200 concurrent users” is testable; “fast” is not.
- Security and privacy — who may see and change what, which data is personal, how long it is kept, what is logged. The OWASP ASVS is a catalogue of verifiable security requirements to draw from.
- Accessibility — keyboard operation, labels, error announcements and contrast, usually by reference to the team’s WCAG-based checklist.
- Localisation — languages, right-to-left layout, date, number and currency formats, and which language messages and emails use.
- Reliability and operations — behaviour when a dependency is down, retries, time limits, and what is monitored and alerted.
How Mutqan’s AI requirement tools help — and where they stop
AI tools are useful as an extra, very fast reviewer in the individual-review step. Paste a story or a set of requirements and they return candidate findings in seconds; you then treat every suggestion as a draft comment that you accept, rewrite or discard. They draft; a person decides.
Their limits are the same as any reviewer without context. They do not know your other documents unless you provide them, the decisions made in last week’s meeting, your regulations or your users; they can raise gaps that are already answered elsewhere, or miss a contradiction with a rule they never saw. Follow your organisation’s policy on what may be shared with an external service, and use anonymised or fictional data in examples.
- AI Requirement Ambiguity Detector — detects ambiguous, vague or contradictory statements and proposes clarifying questions; a quick first pass for RC-01 and RC-02 style findings.
- AI Requirement Gap Analyzer — looks for missing requirements such as error handling, permissions, edge conditions and non-functional needs; the RC-03, RC-04 and RC-08 kind.
- AI Acceptance Criteria Reviewer — reviews acceptance criteria for testability, completeness and ambiguity, and suggests rewrites you can adapt.
- AI Acceptance Criteria Generator — drafts Given/When/Then criteria from a user story, useful when a story arrives with none.
- Requirements → Test Cases and AI Test Coverage Analyzer — the first converts numbered requirements into traceable test cases with a requirement-to-test matrix; the second compares requirements with existing test cases to find untested areas.
Try it: AI Requirement Ambiguity Detector Try it: AI Requirement Gap Analyzer Try it: AI Acceptance Criteria Reviewer
From review to test design
A reviewed story is a better test basis: each acceptance criterion becomes one or more test conditions, the error paths added in review become negative test cases, and the numbers decided in review (30 minutes, 5 requests per hour) become boundary values. Keep the link from each test to the criterion it covers, so a changed criterion shows exactly which tests to update. How to turn criteria into well-formed test cases is covered in the guide on writing test cases.
Try it: Requirements → Test Cases Try it: AI Test Coverage Analyzer Try it: User Story → Test Scenarios
Frequently asked questions
When should requirements be reviewed?
Before development starts on them — typically during backlog refinement, before a story is accepted into a sprint — and again whenever they change. Reviewing early drafts is cheaper than reviewing a finished specification, because less has been built on the wording.
Who should take part in a requirements review?
At minimum the author (product owner or business analyst), a developer and a tester. Add security, UX, operations or a domain expert when the story touches their area. Different perspectives find different defects.
How do I make a requirement testable?
Replace every vague word with an observable result and, where relevant, a number: who does what, under which condition, and what the system visibly does. If you can write the expected result of a test case from the sentence, it is testable.
What if the product owner cannot answer a review question yet?
Record it as an open question with an owner and a date, and do not mark the story ready while it blocks a criterion. If the team must proceed, write the assumption into the story explicitly so it can be tested and revisited.
Can AI review requirements for me?
AI tools can produce a fast first list of ambiguities, gaps and weak acceptance criteria. They lack your domain context, other documents and decisions, so a person must judge every suggestion. Use them as one reviewer among several, not as the review.
Is writing acceptance criteria the same as reviewing requirements?
No. Writing acceptance criteria turns a requirement into checkable statements; reviewing examines the requirement and its criteria for defects. A review often produces better criteria, and new criteria should themselves be reviewed.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsA generic framework for reviewing work products — the review process, roles and review techniques.
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelThe product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
- OWASP Application Security Verification Standard (ASVS)A checklist of verifiable security requirements for web applications, grouped in three assurance levels.
Practice exercise
Review an appointment-booking user story
A fictional municipal services portal is adding online appointments for its service centres. User story US-77 goes to backlog refinement tomorrow, and you are the tester in the three amigos review with the product owner and a developer. Below are the story, the approved appointment policy POL-APPT that it must follow, and a note on where the slot data comes from.
Do the individual review step from the guide: read alone, with the eight-criterion checklist, before any discussion. Write at least six review comments in the format of the guide’s worked example — ID, criterion and severity (Major, Minor or Question), location, what is wrong and why it matters, a proposal or a question, and who must decide — covering at least five of the eight criteria. Then rewrite at least three acceptance criteria that received a Major finding, add the criteria the review shows are missing, list the open questions with an owner, and name the boundary values that the reviewed numbers create. Propose values where you need them, but mark them for confirmation: the reviewer proposes, the product owner decides.
Pen and paper are enough; allow about 30 minutes. If you want a second reviewer afterwards, paste the story and the policy into the AI Requirement Ambiguity Detector from the guide’s tool list (it needs sign-in) and judge each suggestion yourself, only after your own pass.
Fictional municipal services portal. Residents use it signed in to their account.
Slot availability comes from the queue system of the service centres, which another
vendor runs; the portal reads it through the vendor API.
US-77 Book an appointment at a service centre
As a resident
I want to book an appointment at a service centre online
so that I do not have to wait in the queue.
AC1 The resident chooses a service, a centre, a date and a time slot and gets
a confirmation.
AC2 Appointments can be booked up to 60 days in advance.
AC3 The resident can cancel or reschedule the appointment at any time.
AC4 The resident should receive a reminder before the appointment.
AC5 Available slots are updated in real time.
AC6 A resident can also book for family members, etc.
AC7 The booking page must be fast and must handle a large number of users.
POL-APPT Appointment policy (approved; owned by the operations team of the centres)
R1 Appointments are booked 1 to 30 days ahead. Same-day booking is not offered.
R2 Each person has at most one active appointment per service.
R3 An appointment can be cancelled or moved until 24 hours before its start.
After that the slot stays booked and counts as a no-show if missed.
R4 Three no-shows within 90 days block online booking for 30 days.- Scan the story for the red-flag words in the guide’s table and mark each one.
- Read the story side by side with POL-APPT R1 to R4 and the note on slot data. Mark every contradiction, every rule the story ignores and everything that has two names.
- Go through the eight checklist criteria one by one. For each, write a finding, or a short note that you checked it and found nothing.
- Write each finding as one review comment: ID, criterion and severity, location, what is wrong and why, a proposal or question, and who decides.
- Rewrite at least three acceptance criteria that received a Major finding so that each has an observable pass or fail result, add the criteria that the policy requires and the story lacks, and list the open questions, each with an owner and a date.
- List the boundary values that the numbers in the reviewed story create — days ahead (R1), the 24-hour limit (R3) and the no-show rule (R4). For each limit, write the last value that is allowed and the first value that is not, with the expected result of each. The Boundary Value Analysis tool can check your set for R1.
Show the model answer
Red-flag words (step 1): "at any time" in AC3 is an "always" in disguise — what are the exceptions? R3 names one. "Should" in AC4: mandatory or optional? "Before the appointment" in AC4 is a vague quantity: how long before? "Real time" in AC5: within how many seconds? "Etc." in AC6: what is the complete list? In AC7, "fast" (how fast, at what percentile and under what load?), "handle" (what is the observable behaviour?) and "a large number of users" (how many?). None of them is defined elsewhere, so each one leads to a finding below.
The review comments follow, one per paragraph. Your IDs, wording and severities may differ; six or more of them, covering at least five criteria, is a full answer. RC-01 [Consistency · Major] AC2: "up to 60 days" contradicts POL-APPT R1 (1 to 30 days ahead, no same-day booking). The policy is approved, so the proposal is to align AC2 with R1. @PO and the policy owner (operations): which one is current, and are these calendar days or working days?
RC-02 [Consistency · Major] AC3: "at any time" contradicts R3 (only until 24 hours before the start). Proposal: Cancel and Reschedule are available until 24 hours before the start, then disabled with a message that explains the rule. @PO
RC-03 [Correctness · Question] AC2 + AC3 (R1 + R3): a resident who books at 22:00 for an 08:00 slot the next day is already inside the 24-hour window at the moment of booking. They can never cancel or reschedule, and if they miss the visit, the no-show counts towards the R4 block. Is that what the business wants? Options for @PO, for example: count "1 day ahead" as at least 24 hours ahead, or allow cancellation for a short time after booking.
RC-04 [Testability · Major] AC4: "should" and "before the appointment" give no pass or fail. Is the reminder mandatory, how long before, by which channel, and what happens after a cancellation or a reschedule? Proposal: "An SMS reminder is sent 48 hours before the start; none is sent for a cancelled appointment, and a rescheduled one gets its reminder for the new time." 48 hours rather than 24, because a reminder sent 24 hours before the start arrives just as R3 closes cancellation, too late for a resident who now knows they cannot come. @PO: are 48 hours and SMS right?
RC-05 [Feasibility · Question] AC5: the slots come from the vendor’s queue system, which the team does not control, and "real time" is not measurable. Can the vendor API report changes within a stated number of seconds, and can it reserve a slot at the moment of confirmation? What does the resident see when that API does not respond? @Dev lead to confirm with the vendor before the story is marked ready.
RC-06 [Completeness · Major] AC1, AC3, AC5: the story does not say what happens when someone else takes the chosen slot between selection and confirmation, when Confirm is pressed twice, or whether a reschedule releases the old slot before or after the new one is confirmed. Proposal: the slot is reserved only at confirmation; if it is gone, the resident sees "This slot is no longer available" and the updated list; one confirmation creates exactly one appointment; the old slot stays booked until the new one is confirmed. @PO
RC-07 [Ambiguity · Major] AC6: "family members, etc." does not say which relationships count, how the relationship is checked, whose appointment counts under R2, who receives the confirmation and the reminder, or who may cancel. @PO: list the relationships and the rules.
RC-08 [Non-functional · Major] AC6: booking for another person means processing that person’s personal data. Who may see their appointments and details, and is their consent needed? @Privacy must decide before the criterion can be written.
RC-09 [Completeness · Major] Story: R2 and R4 are not reflected. What does a resident see who already holds an active appointment for the service, or who is blocked after three no-shows? Proposal: booking is refused with a message that names the existing appointment (R2) or the date the block ends (R4). Also missing: what is shown when no slot is free in the whole booking window, and whether days on which a centre is closed are offered. @PO
RC-10 [Non-functional · Major] AC7: "fast" and "handle a large number of users" are two requirements and neither is measurable. Proposal: a response-time target with a number, a percentile and a load, such as "p95 under 2 s at the expected peak". @PO and @Ops: what is the expected peak, and when does it occur?
RC-11 [Non-functional · Minor] Story: a public service with no localisation or accessibility criteria, and no note of where they are decided. In which language are the confirmation and the reminder sent (the account language?), how are dates and times shown, and does the slot picker pass the team accessibility checklist (keyboard operation, labelled fields, announced errors)? @PO
RC-12 [Traceability · Minor] Story: not linked to its epic or to POL-APPT R1 to R4. Add the links so that test cases can trace to the rules they check and a policy change shows which story and tests to update.
RC-13 [Consistency · Minor] AC3 and R3: the story says "reschedule" where the policy says "move". One action should have one name in the story, the screens and the policy, or test cases and defect reports will describe it in two ways. Proposal: use "reschedule" and note in the story that it is the "move" of R3. @PO with the policy owner
Rewritten acceptance criteria (step 5; three or more of these is a full answer, and values marked "proposed" wait for the product owner): AC1 Given a signed-in resident, when they choose a service, a centre, a date and a free slot and confirm, then exactly one appointment is created, and a confirmation with a reference number, the centre, the date and the time is shown and sent by SMS (channel proposed). AC2 Only dates from 1 to 30 calendar days after today are offered (R1; calendar days proposed); today and dates more than 30 days ahead are not. AC3 Cancel and Reschedule (R3 calls it "move") are available until 24 hours before the start; after that both are disabled and the page explains the rule. A reschedule keeps the same appointment and its reference number, and releases the old slot only when the new one is confirmed. AC4 An SMS reminder is sent 48 hours before the start, while cancellation is still allowed under R3, in the account language, and for the new time after a reschedule; an appointment booked less than 48 hours ahead gets no separate reminder, and a cancelled one gets none (proposed). AC5 The slot is reserved at confirmation; if it was taken in the meantime, the message "This slot is no longer available" and the updated list are shown and no appointment is created. How soon a change in the queue system appears in the list is the figure the vendor confirms (RC-05).
Criteria the review adds or moves: AC8 A resident who already holds an active appointment for the same service cannot book another one; the message names the existing appointment and offers to reschedule it (R2). AC9 A resident blocked under R4 cannot book and sees the date the block ends. AC10 When the queue system does not respond, the page says that booking is temporarily unavailable and no appointment is created (wording proposed, once RC-05 is answered). AC6 leaves this story: family bookings become a separate story once RC-07 and RC-08 are answered, because "etc." cannot be tested. AC7 becomes NFR1, a response-time target with the figures that the product owner and operations set, and NFR2 covers language (confirmation, reminder, date and time formats) and the team accessibility checklist. Add the links from RC-12.
Open questions, each with an owner and a date. In this answer each is due before the next refinement session, except Q4, which the dev lead dates with the vendor, and Q3, which moves with AC6 to the new family-booking story. Q1 @PO and operations: 30 or 60 days, calendar or working days (RC-01). Q2 @PO: bookings made less than 24 hours ahead (RC-03), and whether a cancellation exactly 24 hours before the start is still allowed (R3). Q3 @PO and @Privacy: family bookings (RC-07, RC-08). Q4 @Dev lead with the vendor: how fresh the slot data is, reservation at confirmation, and behaviour when the vendor API is down (RC-05). Q5 @Ops: the expected peak load (RC-10). Q6 @PO: reminder channel and timing (RC-04). Q7 @PO and operations: are the first and last days included in the 90-day window and in the 30-day block (R4)? Until a question is answered, the criteria that depend on it stay marked "proposed" and the story is not marked ready; if the team must proceed, the assumption is written into the story explicitly.
Boundary values (step 6): days ahead under R1: 0 (today, not offered) and 1 (offered) at the lower limit, 30 (offered) and 31 (not offered) at the upper limit. The lesson on boundary value analysis in the test design module turns this into a full technique. Hours before the start under R3, at minute precision: 24 h 1 min (cancel allowed), 23 h 59 min (refused) and exactly 24 h 0 min, whose expected result is the answer to Q2; testing all three covers both readings until Q2 is answered. Active appointments for the same service under R2: 0 (can book) and 1 (refused); also test one active appointment for a different service (can book) — not a boundary, but the likeliest misreading of R2. No-shows under R4: 2 within 90 days (not blocked) and 3 (blocked). The edges of the 90-day window (the oldest no-show exactly 90 days ago) and of the block (its last day and the day after) are boundaries too; their expected results wait for Q7.
Check your own work: what matters is that you found both contradictions with POL-APPT (AC2 against R1, AC3 against R3) and at least one rule the story ignores (R2 or R4); that each comment holds one finding with its location, reason, proposal or question, and decider; that you proposed numbers without deciding them; and that you can write the expected result of a test case from every criterion you rewrote. If you missed RC-03, read R1 and R3 together again: some defects appear only where two correct-looking rules meet. If you also used an AI tool, check whether it found the contradictions with the policy: it cannot see POL-APPT unless you paste it with the story.
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.
Part of the QA Roadmap
Before this topic
Next topics
Tools mentioned in this guide
Detect ambiguous, vague or contradictory statements in requirements and get clarifying questions from Mutqan AI.
Find missing requirements — error handling, permissions, edge conditions, non-functional needs — with Mutqan AI.
Review acceptance criteria for testability, completeness and ambiguity, with rewritten suggestions from Mutqan AI.
Generate clear Given/When/Then acceptance criteria from a user story with Mutqan AI.
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Compare requirements or a user story against existing test cases to find untested areas, with Mutqan AI.
Generate Given/When/Then acceptance criteria and a definition-of-done checklist from a user story.
Analyze an OpenAPI contract for design risks: inconsistent naming, missing error responses, weak auth, breaking-change hazards, pagination and validation gaps.
Derive end-to-end test scenarios from a user story, including alternate and exception flows.