srs-document

Create a Software Requirements Specification with labeled requirements, data dictionary, and interface sections.

23|1|Updated Mar 19, 2026
One-click install
npx skills add https://github.com/jdm4pku/RE-Skills --skill srs-document-jdm4pku
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: srs-document
Source: https://github.com/jdm4pku/RE-Skills/tree/main/skills/srs-document
Command: npx skills add https://github.com/jdm4pku/RE-Skills --skill srs-document-jdm4pku

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing a formal Software Requirements Specification is error-prone: requirements end up ambiguous, untraceable, mixed with design decisions, or scattered without unique IDs. This Skill guides you through producing a complete, reviewable SRS that organizes functional requirements by system feature and covers data, interfaces, quality attributes, and constraints. ## Core Features & Use Cases - Structured SRS Template: A fill-in template covering introduction, overall description, system features, data requirements, external interfaces, quality attributes, and constraints, aligned with IEEE 830 / ISO/IEC/IEEE 29148. - Requirement Writing Standards: Enforces unique persistent IDs, "shall" phrasing, atomic testable statements, and EARS patterns (ubiquitous, event-driven, state-driven, unwanted behavior, optional). - Worked Example: Includes a ChemTrack chemical inventory SRS excerpt showing labeled requirements with rationale, source, priority, and business rule references. - Use Case: A client requires a formal, baselined requirements document before approving design. Use this Skill to organize 200+ requirements into a coherent, traceable SRS ready for stakeholder sign-off. ## Quick Start Ask the agent to draft an SRS for your project using the srs-document template, organizing functional requirements by system feature with unique IDs and EARS-style shall statements.

Frequently Asked Questions about srs-document

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

FAQPage Schema
How do I write a Software Requirements Specification document?▼

Structure the SRS with sections for introduction, overall description, system features, data requirements, external interfaces, quality attributes, and constraints. Organize functional requirements by system feature, give each a unique persistent ID, and write each as a single testable shall statement.

What is the EARS template for writing requirements?▼

EARS (Easy Approach to Requirements Syntax) provides five patterns: ubiquitous (The system shall...), event-driven (When...), state-driven (While...), unwanted behavior (If...then...), and optional (Where...). Each pattern fits a specific requirement trigger type.

How should requirements be labeled in an SRS?▼

Use unique, persistent identifiers that never change once assigned. Options include sequence numbers (FR-1), hierarchical numbers (3.2.1), or hierarchical textual tags (PRODUCT.FEATURE.FUNCTION.1). Textual tags are recommended for large projects because they are self-documenting.

When should I use a formal SRS instead of user stories?▼

Use a formal SRS when the project demands a reviewable, traceable requirements baseline, such as regulated, contracted, or large-scale systems. For small projects, right-size the document and include only sections that add value to avoid shelfware.

Why should an SRS avoid design details?▼

An SRS specifies what the system shall do, not how it is built. Including design decisions like database schemas or table columns constrains developers unnecessarily. State the requirement, such as storing chemical records with specific fields, and leave implementation to design.