skills.rest
jcg-admin
jcg-adminCOMMUNITY
Explore all skills by this author →
GitHub

rm-specification

Formalize analyzed requirements into specification documents with acceptance criteria and traceability.

Updated Mar 14, 2026
Search Tags:#acceptance criteria#user stories#traceability#srs#gherkin#moscow#requirements specification
One-click install
npx skills add https://github.com/jcg-admin/IACT-ui --skill rm-specification-jcg-admin
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rm-specification
Source: https://github.com/jcg-admin/IACT-ui/tree/main/.claude/skills/rm-specification
Command: npx skills add https://github.com/jcg-admin/IACT-ui --skill rm-specification-jcg-admin

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve? Turning analyzed, prioritized requirements into a formal, verifiable specification is error-prone: requirements often lack acceptance criteria, NFRs lack measurable metrics, and there is no baseline for change control. This Skill guides the Specification step of the Requirements Management cycle, producing standard-format documents (IEEE 830 SRS, BRD, or User Stories) with verifiable acceptance criteria and full traceability. ## Core Features & Use Cases - Format Selection Guidance: Decision criteria for choosing between IEEE 830 SRS, BRD, User Stories with Given/When/Then, or hybrid specifications based on project context. - Quality Enforcement: INVEST validation for user stories, quantitative metrics for non-functional requirements (performance, security, availability, usability), and mandatory acceptance criteria per requirement. - Baseline & Traceability: Establishes a versioned requirements baseline with stakeholder sign-off and requirement-to-stakeholder traceability matrices. - Use Case: After completing requirements analysis with MoSCoW prioritization, use this Skill to produce an SRS document where every requirement has a unique ID, Gherkin acceptance criteria, and an approved baseline ready for validation. ## Quick Start Ask the AI to formalize the analyzed requirements in rm-analysis.md into a specification document with acceptance criteria and a traceability matrix.

Frequently Asked Questions about rm-specification

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a requirements specification document?▼

Choose a format based on context: IEEE 830 SRS for formal contracts, BRD for business projects, or User Stories for agile teams. Then define each requirement with a unique ID, description, MoSCoW priority, origin, and verifiable acceptance criteria.

What is the difference between SRS, BRD, and User Stories?▼

IEEE 830 SRS is a formal, exhaustive standard suited to regulated or contractual projects. BRD focuses on business value for sponsors and analysts. User Stories with Given/When/Then are lightweight and testable, fitting agile teams with short iterations.

How do I write acceptance criteria with Gherkin?▼

Use the Given/When/Then structure: Given the initial context, When the actor performs an action, Then state the observable result. Each user story needs at least one happy-path scenario and one error scenario, avoiding UI or implementation details.

What are the INVEST criteria for user stories?▼

INVEST validates story quality: Independent, Negotiable, Valuable, Estimable, Small, and Testable. A story failing any criterion, such as being too large for a sprint or lacking testable acceptance criteria, should be split or refined before specification.

When should I not create a requirements specification?▼

Do not specify before analysis is complete with quality checks passed and conflicts resolved. Specifying unverified requirements propagates defects into design, development, and testing artifacts downstream.

How do I specify non-functional requirements measurably?▼

Attach quantitative metrics and verification methods to each NFR. For example, state p95 response time under a defined load for performance, uptime percentage per month for availability, or task completion time for usability, each with a test method.

Related Skills

Explore More Product & Management Skills→
jcg-adminjcg-admin

rm-analysis

Analyze requirements quality, resolve conflicts, and prioritize with MoSCoW and Kano.

Community
Intermediate
launchapp-devlaunchapp-dev
38

design-review-process

Codify a four-gate design review process with criteria, checklists, and approvals.

Official
Advanced
jdm4pkujdm4pku
23

change-control-advisor

Evaluate requirements change requests through structured impact analysis and CCB decision workflows.

Community
Intermediate
yuyuxinliyuyuxinli
1

user-story-splitting

Split large user stories into smaller deliverable stories using eight patterns.

Official
Intermediate