SRS Generation Skill

What Is a Software Requirements Specification?

A 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.

Generation Workflow

The SRS generation process follows a six-step workflow designed to produce a complete, high-quality document:

Step 1: Scan Context

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.

Step 2: Find the Upstream PRD

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.