Software Requirements Specification (SRS) Manager

Create, validate, and maintain professional Software Requirements Specifications (SRS) following a standardized template.

This skill guides you through the process of authoring and auditing Software Requirements Specifications. It ensures all requirements are verifiable, uniquely identified, and cover essential areas including functional behavior, quality of service, security, and AI/ML considerations.

Install Software Requirements Specification (SRS) Manager

Download the skill as a ZIP file, then unzip it into your Claude Code skills folder.

Download manage-srs.zip

Unzip to:

~/.claude/skills/manage-srs/

Core Principles

1. Verifiability: Every requirement must be testable. Avoid vague terms like "user-friendly," "fast," or "reliable" without specific metrics.
2. Atomicity: Each requirement should cover a single, discrete function or constraint.
3. Consistency: Use the standardized ID schema and keyword conventions (shall, should, may).
4. Traceability: Ensure every requirement has a clear ID and a planned verification method.

Requirement Structure

All requirements MUST follow this markdown structure:

- ID: REQ-[AREA]-[NNN]-[VER]
- Title: [Short descriptive title]
- Statement: The system shall [action/constraint]...
- Rationale: [Why this requirement exists]
- Acceptance Criteria: [Specific conditions for success]
- Verification Method: Test | Analysis | Inspection | Demonstration
- More Information: [Links or additional context]

ID Schema

• AREA: Use one of: FUNC (Functional), SEC (Security), PERF (Performance), ML (Machine Learning), INT (Interface), REL (Reliability), AVAIL (Availability), COMP (Compliance), MAINT (Maintainability).
• NNN: A three-digit sequential number (e.g., 001).
• VER: Optional version number (e.g., 1.0).

Step-by-Step Instructions

1. Initialize a New SRS

If the user wants to start a new document:

• Create a file named SRS.md using the provided template structure.
• Ask the user for the Project Name, Author, and Organization.
• Draft the high-level "Product Perspective" and "Product Functions" based on the user's initial project description.

2. Adding Requirements

When adding requirements:

• Categorize the requirement into the correct section (Functional, QoS, AI/ML, etc.).
• Ensure the "Statement" uses the imperative "shall" for mandatory items.
• Define at least one clear Acceptance Criterion.
• Assign a unique ID following the schema.

3. Reviewing and Auditing

When asked to review an SRS:

• Check for duplicate or non-sequential IDs.
• Identify "hidden requirements"—sentences that sound like requirements but lack an ID or clear statement.
• Flag vague language (e.g., "minimize latency") and suggest specific metrics (e.g., "latency shall be < 200ms").
• Verify that every requirement has a corresponding entry in the Verification Matrix (Section 4).

4. Specialized Sections

• AI/ML (Section 3.6): If the project involves AI, ensure you define Model Specifications, Data Management, Guardrails (input/output filtering), and Human-in-the-Loop requirements.
• Observability (Section 3.3.5): Ensure requirements cover logging, metrics, and tracing standards.

Verification Matrix

Ensure the Verification table in Section 4 is kept in sync with Section 3. Use the following format:

Rules and Constraints

• Never delete a requirement ID. If a requirement is removed, mark it as "DEPRECATED" or "DELETED" in the statement but keep the ID to maintain traceability.
• Do not include design or implementation details (the "how") unless they are strictly binding constraints (e.g., "Must use Postgres 15").