| name | jira-requirement-analyzer |
| description | Read a JIRA ticket and judge whether it is actually ready to test. Use when a tester says "analyze this ticket", "is this story ready to test", "find gaps in JIRA-123", or pastes a user story / acceptance criteria and wants it pressure-tested. Fetches the ticket, scores it against a readiness checklist, and returns a gaps / ambiguities / risks report plus clarifying questions to send back to the author. |
| license | MIT |
| metadata | {"author":"Prrammod Dutta | TheTestingAcademy","stlc-phase":"Requirement Analysis","version":"1.0.0"} |
JIRA Requirement Analyzer
When to use
- Someone hands you a JIRA key or story text and asks "is this ready to test?"
- A grooming / refinement session needs the ambiguities surfaced before estimation.
- Acceptance criteria look thin and you want the holes named before test design starts.
Workflow
-
Fetch the ticket.
-
If JIRA MCP or atlassian MCP or ROVO mcp is connected the fetch the ticket via that - https://www.atlassian.com/platform/rovo-mcp
-
If a JIRA key is given, pull it via an available JIRA MCP tool
or REST call. If neither is reachable, ask the user to paste the ticket body —
never invent ticket content. Capture summary, description, ACs, components,
linked issues, attachments, and fix version.
-
Score readiness.
Walk each requirement and mark
✅ clear /
⚠️ ambiguous /
❌ missing.
Check: testable acceptance criteria, defined error/empty/boundary states, roles &
permissions, non-functional needs (perf, security, a11y, i18n), data & dependencies.
-
Classify findings
into three buckets
— Gaps (missing info),
- Ambiguities (two valid readings),
- Risks (what could ship broken). Rate each by impact.
- Draft clarifying questions
addressed to the author — specific, answerable, one topic each
HUMAN REVIEW GATE (mandatory).
Present the report as a draft. State what you
assumed and could not confirm.
Ask the tester to confirm or edit before these
questions go to the author;
do not proceed to scenario design until confirmed.
Output shape
## Requirement Analysis — <JIRA-KEY>: <title>
Readiness verdict: READY / NOT READY (n blockers)
Gaps [ ❌ ... ]
Ambiguities [ ⚠️ ... two readings each ]
Risks [ impact-rated ]
Questions for the author (numbered, one topic each)
--- HUMAN REVIEW GATE ---
Assumptions / What I could not confirm / "Confirm before I send these to the author"
Create a light weight HTML page in the /tmp dir, with name jira-analyzed-<ticket-id>.html for all finding as output
Safety & Guardrails
- Never fabricate an acceptance criterion, field, or requirement — a missing item is a
finding, not a blank to fill.
- Do not rewrite the ticket for the author; surface the gap and ask the question.
- A "READY" verdict is advisory — the author and QA lead own that call.
- Keep every finding traceable to a specific line or absence in the ticket.
Anti Hallucination STRICT RULES (MANDATORY)
DO NOT invent features, APIs, error codes, UI elements, or behavior.
DO NOT assume default or "typical" system behavior.
If information is missing or unclear, respond with: "Insufficient information to determine."
Every assertion must be traceable to provided input.
If a detail is inferred, label it explicitly as: "Inference (low confidence)".
Output must be deterministic and repeatable.
