SKILL DETAIL
Requirements Analysis
需求分析
Use this skill when you need to analyze requirements, identify test points, boundaries, dependencies, and risks before test design; triggers include requirements analysis and test point analysis.
StatusStable
TypeAtomic Skill
DomainRequirement Quality
SDLCRequirement
Good forQA / BA / PM / DEV
LanguageChinese / English
EvalsEvals ✓
Synced2026-09-15
Why this Skill
Use this skill when you need to analyze requirements, identify test points, boundaries, dependencies, and risks before test design; triggers include requirements analysis and test point analysis.
It turns pre-test-design requirement understanding into a quality input that can be reviewed, tracked, and acted on.
- Business rules are incomplete: the happy path is clear but exception flows are missing.
- State changes, boundaries, and external dependencies are not defined clearly.
- Acceptance criteria cannot be verified directly, so gaps leak into test design.
- API, UI, and business rules can diverge while quality risks remain unprioritized.
When to use
Use this Skill
- A new requirement enters refinement.
- A user story is drafted and needs a testability check.
- A PRD review or test analysis is about to start.
- A major requirement change needs its scope and risks re-mapped.
When not to use
- The task is already limited to generating test cases.
- The task is only PR diff analysis.
- The task is only production incident triage.
- The task is only API automation or regression execution.
Input
Minimum Input
- Requirement / User Story
- Current change objective
Recommended Input
- PRD
- Acceptance Criteria
- UI / Prototype
- API Specification
- Business Rules
- Architecture
- Existing Test Cases
- Historical Defects
Optional Context
- Source Code
- PR Diff
- Production Logs
- Metrics
- Previous Requirement
Output
The output is not a generic summary. It is a structured analysis report that can move directly into review, test design, and follow-up.
Judge the output value before installing
- 01Scope Summary
- 02Business Objective
- 03Actors
- 04Business Rules
View full output structure
- 05Main Flow
- 06Alternative Flow
- 07Exception Flow
- 08State Changes
- 09Dependencies
- 10Boundary Conditions
- 11Missing Information
- 12Ambiguities
- 13Quality Risks
- 14Questions to Confirm
- 15Recommended Next Actions
Output preview
PriorityFindingEvidenceImpactAction
P0Membership state after a failed upgrade is undefinedAC-03State may become inconsistentPM defines the failure rule
P1Timeout behavior for the external benefits API is unknownAPI SpecRecovery scenarios cannot be designedDev adds a timeout strategy
P1The 10,000 boundary is not definedPRDBoundary tests cannot be determinedClarify >= / >
Real example
Before
Add automatic membership upgrades. A Gold user becomes Platinum after cumulative spending reaches 10,000, with Platinum benefits granted immediately.
Run Skill
@skill requirements-analysis
Analyze this membership upgrade requirement. Identify business rules, boundaries, dependencies, gaps, and quality risks.After
- Business ruleGold → Platinum when cumulative spend reaches 10,000
- Missing informationShould refunds reverse spend? Should upgrade failures retry?
- Boundary9,999.99 / 10,000.00 / 10,000.01
- DependenciesMembership Service / Order Service / Benefit Service
- Quality riskP0: membership upgrades but benefits are not granted.
How It Works
- 01Understand context
- 02Extract business rules
- 03Identify flow and state
- 04Identify boundaries and dependencies
- 05Discover missing information
- 06Identify quality risks
- 07Produce structured analysis
Install & Quick Start
Install command / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirements-analysis
-grequirements-analysis.prompt
@skill requirements-analysis
Analyze this requirement. Identify business rules, boundaries, dependencies, information gaps, and quality risks.
Requirement:
[Paste requirement here]---
name: requirements-analysis
description: Use this skill when you need to analyze requirements, identify test points, boundaries, dependencies, and risks before test design; triggers include requirements analysis and test point analysis.
---
# Requirements Analysis (English)
**Chinese version：** See the corresponding Chinese skill.
## When to Use
- Need help with requirements analysis in a real project context.
- Need an output that can be used directly for execution, review, or follow-up.
## Workflow
1. Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
2. Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
3. If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
4. Default to Markdown; switch formats only when the user asks.
## Core Constraints
- Prioritize by risk / business impact — do not treat everything equally.
- Separate confirmed facts from current assumptions.
- Do not invent endpoints, fields, environments, or root causes the user did not provide.
- Keep output executable: concrete scenarios, clear priority, clear next steps.
## Progressive Disclosure
- Before producing output, read and follow `prompts/requirements-analysis.md` (minimum coverage, output structure, quality bar).
- When Excel/CSV/JSON/Word is requested: read `output-formats.md` and honor the format.
- When a ready-made template fits: use matching files under `output-templates/`.
- For deep framework/troubleshoot/schema notes: read only the relevant file(s) under `references/`, do not load the whole directory.
- For format conversion or helper checks: prefer existing `scripts/` over reinventing.
- For evaluating/regressing this skill: use `evals/` with skill-up.
## Pre-delivery Checklist
- [ ] Followed the main prompt's output structure
- [ ] Minimum coverage focus: scope summary, business objective, clear and unclear requirements, missing rules, edge or exception conditions, testability gaps, dependencies and impacts, risk priority, ... (details in main prompt)
- [ ] Covered the minimum checklist, or explained omissions
- [ ] High-risk items have explicit priority
- [ ] Did not invent details the user did not provide
- [ ] Assumptions and gaps are marked
## Common Pitfalls
- Do not pretend completeness when scope/context is missing.
- Do not treat every item as equally important.
- Do not skip assumptions and information gaps.
- Do not dump generic theory unrelated to the current toolchain.