SRS Documentation Skill
Overview
This skill provides guidance for creating formal Software Requirements Specification (SRS) documents following the IEEE 830 standard structure.
IEEE 830 Standard Structure
1. Introduction
1.1 Purpose
- •State the purpose of the SRS document
- •Identify the intended audience
- •Specify the scope of coverage
1.2 Scope
- •Identify the software product by name
- •Explain what the software will do
- •Describe application benefits, objectives, goals
- •Be consistent with related higher-level specs
1.3 Definitions, Acronyms, and Abbreviations
- •Define all terms used in the document
- •Include technical terms, acronyms, abbreviations
- •Reference glossary or appendix if extensive
1.4 References
- •List all referenced documents
- •Include document titles, numbers, dates, sources
- •Identify version or revision information
1.5 Overview
- •Describe document organization
- •Explain the structure of remaining sections
2. Overall Description
2.1 Product Perspective
- •System Context: How the product fits into the larger ecosystem
- •System Interfaces: Connections to other systems
- •User Interfaces: UI considerations and constraints
- •Hardware Interfaces: Required hardware connections
- •Software Interfaces: Required software connections
- •Communications Interfaces: Network and protocol requirements
- •Memory Constraints: Memory and storage limitations
- •Operations: Normal and special operations modes
- •Site Adaptation Requirements: Installation and deployment needs
2.2 Product Functions
- •Summary of major functions
- •High-level feature overview
- •Organized by user or business function
2.3 User Characteristics
- •General characteristics of intended users
- •Educational level, experience, technical expertise
- •Accessibility considerations
2.4 Constraints
- •Regulatory requirements
- •Hardware limitations
- •Interface requirements
- •Standards compliance
- •Security considerations
2.5 Assumptions and Dependencies
- •Factors assumed to be true
- •Dependencies on other systems or components
- •Conditions that if changed would affect requirements
3. Specific Requirements
3.1 External Interface Requirements
- •User Interfaces: Detailed UI specifications
- •Hardware Interfaces: Hardware interaction details
- •Software Interfaces: API and integration details
- •Communications Interfaces: Protocol specifications
3.2 Functional Requirements
Organized by:
- •Feature or function
- •User class
- •Business object
- •Mode of operation
- •Stimulus/response sequence
Each requirement should include:
- •Unique identifier (FR-XXX)
- •Description of functionality
- •Inputs and outputs
- •Processing logic
- •Error handling
3.3 Performance Requirements
- •Response time requirements
- •Throughput requirements
- •Capacity requirements
- •Resource utilization limits
3.4 Design Constraints
- •Standards compliance
- •Hardware limitations
- •Software constraints
- •Architectural requirements
3.5 Software System Attributes
- •Reliability: Mean time between failures, recovery
- •Availability: Uptime requirements
- •Security: Access control, data protection
- •Maintainability: Modification ease, documentation
- •Portability: Platform requirements
3.6 Other Requirements
- •Database requirements
- •Operations requirements
- •Internationalization requirements
4. Appendices
A. Glossary
Complete list of defined terms
B. Analysis Models
- •Data flow diagrams
- •Entity-relationship diagrams
- •State diagrams
- •Use case diagrams
C. Requirements Traceability Matrix
- •Maps requirements to business objectives
- •Maps requirements to test cases
- •Shows requirement dependencies
Writing Guidelines
Requirement Characteristics
Each requirement should be:
| Characteristic | Description | Example |
|---|---|---|
| Necessary | Needed for system success | Not nice-to-have |
| Unambiguous | Single interpretation | "User" defined specifically |
| Complete | All information included | Includes error scenarios |
| Consistent | No conflicts | Aligns with other requirements |
| Verifiable | Can be tested | Measurable criteria |
| Traceable | Has clear origin | Links to business need |
| Modifiable | Can be changed easily | Unique ID, no redundancy |
| Prioritized | Ranked by importance | MoSCoW classification |
Requirement Writing Style
DO:
- •Use "shall" for mandatory requirements
- •Use "should" for desirable requirements
- •Use "may" for optional requirements
- •Be specific and quantitative
- •Use consistent terminology
- •Write in active voice
- •One requirement per statement
DON'T:
- •Use vague terms (fast, user-friendly, flexible)
- •Use negative requirements when possible
- •Combine multiple requirements
- •Include design/implementation details
- •Use inconsistent terminology
Examples
Good Requirement:
code
FR-001: The system shall display search results within 3 seconds of the user submitting a search query.
Bad Requirement:
code
The system should be fast and display results quickly.
Requirement ID Conventions
Functional Requirements
code
FR-XXX: Core functional requirements FR-AUTH-XXX: Authentication related FR-RPT-XXX: Reporting related FR-INT-XXX: Integration related
Non-Functional Requirements
code
NFR-PERF-XXX: Performance NFR-SEC-XXX: Security NFR-REL-XXX: Reliability NFR-USA-XXX: Usability NFR-MAINT-XXX: Maintainability
Constraints
code
CON-XXX: General constraints CON-REG-XXX: Regulatory constraints CON-TECH-XXX: Technical constraints
Priority Levels
MoSCoW Method
| Priority | Code | Description |
|---|---|---|
| Must Have | M | Critical for success |
| Should Have | S | Important but not critical |
| Could Have | C | Nice to have |
| Won't Have | W | Out of scope for this release |
Risk-Based Priority
| Priority | Level | Description |
|---|---|---|
| Critical | P1 | System cannot function without |
| High | P2 | Major feature impacted |
| Medium | P3 | Minor feature impacted |
| Low | P4 | Enhancement or convenience |
Document Formatting
Section Numbering
code
1. Introduction 1.1 Purpose 1.2 Scope 2. Overall Description 2.1 Product Perspective
Requirement Tables
markdown
| ID | Description | Priority | Status | Source | |----|-------------|----------|--------|--------| | FR-001 | User login | M | Approved | Stakeholder Meeting 2024-01-15 |
Cross-References
- •Use hyperlinks within document
- •Reference by ID: "See FR-001"
- •Include traceability: "Implements BR-003"
Validation Checklist
Before finalizing SRS, verify:
- • All sections of IEEE 830 template completed
- • All requirements have unique identifiers
- • All requirements are verifiable
- • No conflicting requirements
- • All terms defined in glossary
- • Traceability matrix complete
- • Stakeholder sign-off obtained
- • Version control and change history included
See template.md for the complete SRS template. See checklists.md for validation checklists.