Generates professional Software Requirements Specification (SRS) documents based on IEEE 830, ISO/IEC/IEEE 29148, and Amazon technical specification standards. This skill activates when the user needs a requirements document, requirements specification, SRS, functional requirements, non-functional requirements, software requirements, requirements analysis, or requirements engineering. It formalizes product needs into structured, testable, and traceable requirements with unique IDs, acceptance criteria, use cases, a CRUD matrix, and a full traceability matrix linking back to the upstream PRD.
Generates structured Software Requirements Specification documents following IEEE and ISO standards based on project context and PRDs.
npx claudepluginhub tercel/spec-forgeThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/checklist.mdreferences/generation-instructions.mdreferences/template.mdA Software Requirements Specification (SRS) is a formal document that describes exactly what a software system must do and the constraints under which it must operate. It serves as the contractual bridge between stakeholders who define the product vision (captured in a PRD) and the engineering team that designs, builds, and tests the system. A well-written SRS eliminates ambiguity, reduces rework, and provides a single source of truth for every requirement the system must satisfy.
The two foundational standards for SRS documents are IEEE 830 (IEEE Recommended Practice for Software Requirements Specifications) and ISO/IEC/IEEE 29148 (Systems and Software Engineering -- Life Cycle Processes -- Requirements Engineering). IEEE 830 established the canonical section structure -- introduction, overall description, specific requirements -- and defined the quality attributes every requirement must exhibit: correctness, unambiguity, completeness, consistency, ranking for importance, verifiability, modifiability, and traceability. ISO/IEC/IEEE 29148 modernized this foundation by integrating requirements engineering into the full systems and software lifecycle, emphasizing stakeholder needs analysis, requirements analysis, and requirements validation as continuous activities rather than one-time documentation events. This skill combines the structural rigor of both standards with the pragmatic, metric-driven approach found in Amazon technical specifications, where every requirement must be tied to a measurable outcome.
The SRS generation process follows a six-step workflow designed to produce a complete, high-quality document:
Before writing a single requirement, the skill scans the current project to build context. It examines the project directory structure (top three levels), reads the project README if available, and surveys the docs/ directory for existing documentation. This scanning phase establishes the technical landscape -- programming languages, frameworks, existing APIs, data stores -- so that requirements are grounded in the real project environment rather than written in a vacuum.
The most critical input to any SRS is the Product Requirements Document. The skill automatically searches for a matching PRD file (following the docs/<feature-name>/prd.md naming convention) and reads it thoroughly when found. The PRD provides the product vision, user stories, feature definitions, success metrics, and scope boundaries that the SRS must formalize into precise, testable requirements. If no PRD is found, the skill proceeds but flags that traceability to product-level requirements will be limited.
The skill asks the user targeted clarification questions covering functional scope, performance targets, security needs, data requirements, integration points, availability and reliability expectations, compatibility constraints, and regulatory or compliance obligations. These questions fill gaps that the PRD may not address at the level of detail an SRS demands -- for example, specific response-time thresholds, concurrent-user targets, or data-retention policies.
Using the template at references/template.md, the skill generates the full SRS document. Every section of the IEEE 830 structure is populated: introduction, overall description, functional requirements, non-functional requirements, data requirements, external interface requirements, and the requirements traceability matrix. Requirements are written following the conventions and quality standards described in the sections below.
If an upstream PRD was found, the skill builds a requirements traceability matrix (RTM) that maps every PRD feature or user story to one or more SRS requirements. This matrix ensures complete coverage -- no PRD item should be left without a corresponding SRS requirement -- and provides downstream documents (Technical Design, Test Plan) with a clear chain of custody for every requirement.
Before finalizing, the skill loads the checklist at references/checklist.md and evaluates the generated document against every item. Any failed check triggers revision. The document is only written to disk once all checklist items pass.
Every requirement receives a unique identifier that encodes its type and module or category:
FR-<MODULE>-<NNN> where <MODULE> is a short uppercase label for the feature module (e.g., AUTH, CART, SEARCH, NOTIFY) and <NNN> is a zero-padded sequential number. Examples: FR-AUTH-001, FR-CART-012, FR-SEARCH-003.NFR-<CATEGORY>-<NNN> where <CATEGORY> identifies the quality attribute (e.g., PERF, SEC, REL, AVL, MNT, PRT, USB) and <NNN> is a zero-padded sequential number. Examples: NFR-PERF-001, NFR-SEC-003, NFR-REL-002.These IDs are used throughout the document -- in the requirements traceability matrix, in cross-references between related requirements, and in downstream documents such as technical designs and test plans. Consistent ID formatting is essential for automated traceability and search.
Each functional requirement is structured as a complete use case specification with the following elements:
In addition to individual requirement specifications, the SRS includes a CRUD matrix -- a table that maps data entities (rows) against Create, Read, Update, and Delete operations (columns), with each cell indicating which functional requirement governs that operation. The CRUD matrix provides a rapid completeness check: if an entity has no "Delete" operation defined, that may be intentional (soft-delete policy) or an oversight that needs resolution.
Non-functional requirements define the quality attributes and constraints of the system. Each NFR must include a specific, measurable metric, a target value, and a measurement method. The SRS organizes NFRs into the following categories:
The requirements traceability matrix (RTM) is a table that establishes bidirectional links between PRD items and SRS requirements. Each row maps a PRD identifier to one or more SRS functional or non-functional requirement IDs, along with a coverage status (Fully Covered, Partially Covered, or Not Covered). The RTM serves three purposes: it confirms that every product need has been addressed, it enables impact analysis when requirements change, and it provides the foundation for downstream traceability into technical design and test planning.
The SRS uses precise modal verbs to convey obligation levels, following IEEE 830 and RFC 2119 conventions:
Avoiding ambiguous language is critical. Terms like "fast," "user-friendly," "efficient," or "robust" are never used in isolation. Every qualitative claim must be paired with a quantitative target (e.g., "The system shall return search results within 200ms at the 95th percentile" rather than "The system shall be fast").
Every requirement in the SRS -- functional or non-functional -- must satisfy four quality attributes:
The SRS generation skill relies on two reference files:
references/template.md: The complete SRS document template following IEEE 830 structure. This template defines every section, provides placeholder guidance, and establishes the formatting conventions for requirements, tables, and diagrams.references/checklist.md: The quality checklist used during the final validation step. It contains items organized into four categories -- completeness, quality, consistency, and format -- that the generated document must satisfy before it is written to disk.The final SRS document is written to docs/<feature-name>/srs.md in the project root, where <feature-name> is a sanitized, lowercase, hyphen-separated slug derived from the user's input. The docs/<feature-name>/ directory is created if it does not already exist. If a file with the same name already exists, confirm with the user before overwriting. This naming convention places all documents for a feature in a single docs/<feature-name>/ directory (prd.md, srs.md, tech-design.md, test-plan.md) and enables automatic upstream document discovery by downstream skills.