Requirements Analysis Plus: Trace requirement sources, differences, and changes across documents
Requirements Analysis Plus is easiest to understand with imperfect project material. The working task is simple: Analyze membership rules across requirements, prototypes, and API definitions with source traceability.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with Requirements Analysis Plus.
Read the source Skill first
The main prompt covers Diff vs baseline (requirements-analysis), Input processing order (default), Optional Role Report Inputs, Structured conclusion fields (use on each high-priority item), Quality Bar. Those headings are navigation; the project artifacts still provide the facts.
The source directory contains 3 example files, 1 references, 7 script entries. Start with Requirements analysis example, requirements-analysis-plus (EN) supporting references.
Start multiple inputs with a source ledger
Analyze membership rules across requirements, prototypes, and API definitions with source traceability
The plus Skills often read requirements, analysis, and planning files together. Record their authority first.
| source_id | File | Purpose | Conflict rule |
|---|---|---|---|
| RQ-01 | requirements.md | Business rules | Highest authority |
| AN-02 | analysis.xlsx | Risks and boundaries | Flag conflicts with requirements |
| PL-03 | release-plan.md | Dates and owners | Cannot override business rules |
Each strategy item or case should carry a source ID. Mark unsupported conclusions as assumptions.
Resolve version conflicts before combining files
The task is Analyze membership rules across requirements, prototypes, and API definitions with source traceability. Parsing is the easy part; the same fact may appear in three incompatible versions.
| Conflict | Treatment | Output status |
|---|---|---|
| Requirement supports refunds, plan has no work | Keep the rule and expose the delivery gap | blocked |
| Analysis and interface use different fields | Use the current interface version and request review | needs-review |
| Test data predates the requirement | Do not use it as evidence for new behavior | stale-source |
Store a source ID and version or update time. After generation, sample three strategy items or cases and trace them back. One unsupported item is enough to repair the source chain before handoff.
The deliverable includes a source ledger, conflict list, source-linked primary artifact, and a visible list of unparsed items.
A prompt you can adapt
Replace the bracketed fields with project facts. Specific material leaves less room for guessing.
Use the requirements-analysis-plus Skill.
Task: Analyze membership rules across requirements, prototypes, and API definitions with source traceability
Version and environment: [requirement / build / environment]
Inputs: [file paths or links]
Scope: [included and excluded journeys]
Constraints: [accounts, data, time, compliance]
Build a source ledger and conflict order first. Add source_id to material outputs and label anything unsupported as an assumption.
Finish with open questions. Do not invent missing facts.Use the first pass to inspect structure and gaps. Supply missing material before asking for the handoff-ready artifact.
Advanced use, from one call to a maintained flow
Add a checksum or version to the source ledger. Recompute affected conclusions and emit changed, unchanged, and needs-review states.
A three-Skill chain
requirements-analysis-plus → test-strategy-plus → testcase-writer-plus
| Handoff | Payload | Receiver check |
|---|---|---|
| Upstream to requirements-analysis-plus | Source versions, scope, risks, open questions | Requirements Analysis Plus staleness and conflicts |
| requirements-analysis-plus to downstream | Primary artifact, evidence index, unfinished work | Requirements Analysis Plus executability and owners |
| Feedback to requirements-analysis-plus | Runs, defects, new risks | Requirements Analysis Plus baseline and regression update |
Do not paste three complete outputs into one large prompt. Give Requirements Analysis Plus a structured summary and accessible source artifacts. It saves context and makes defects traceable.
Team gates
| Gate | Check | Failure action |
|---|---|---|
| requirements-analysis-plus input | Version, environment, owner, accessible sources | Stop Requirements Analysis Plus and list gaps |
| requirements-analysis-plus artifact | Material claims carry basis and status | Return Requirements Analysis Plus for evidence |
| requirements-analysis-plus execution | Command, exit status, report are reproducible | Classify infrastructure or test failure |
| requirements-analysis-plus decision | Residual risks have accepter and date | Do not enter the next stage |
Review Requirements Analysis Plus adoption, human edit rate, unsupported claims, and failure-to-diagnosis time each sprint. Record a baseline for several cycles before setting targets.
“Plus” does not mean “load every file”
Multi-format parsing expands context and creates version conflicts. Establish authoritative sources first. Every conclusion related to Diff vs baseline (requirements-analysis) should resolve to a source ID.
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirements-analysis-plus -g -a codex -yInvoke it with “Use the requirements-analysis-plus Skill,” then attach the real artifacts.
Two practical questions
When should I choose the plus version?
Use the basic Skill for one clear input. Choose plus when multiple files need parsing and traceability.
What if sources conflict?
Preserve the conflict, apply source authority, and mark affected conclusions.
When is human review mandatory?
Require an accountable person for scope trade-offs, risk acceptance, release decisions, and source conflicts.
What should be archived?
Keep the input version, Skill output, human edits, and final evidence so the conclusion can be reconstructed.
Run Requirements Analysis Plus against one real artifact and keep the input, output, and review notes. The fragments here establish structure; project evidence must still come from the project.