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:

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:

FR-001: The system shall display search results within 3 seconds
of the user submitting a search query.

Bad Requirement:

The system should be fast and display results quickly.

Requirement ID Conventions

Functional Requirements

FR-XXX: Core functional requirements
FR-AUTH-XXX: Authentication related
FR-RPT-XXX: Reporting related
FR-INT-XXX: Integration related

Non-Functional Requirements

NFR-PERF-XXX: Performance
NFR-SEC-XXX: Security
NFR-REL-XXX: Reliability
NFR-USA-XXX: Usability
NFR-MAINT-XXX: Maintainability

Constraints

CON-XXX: General constraints
CON-REG-XXX: Regulatory constraints
CON-TECH-XXX: Technical constraints

Priority Levels

MoSCoW Method

Risk-Based Priority

Document Formatting

Section Numbering

1. Introduction
   1.1 Purpose
   1.2 Scope
2. Overall Description
   2.1 Product Perspective

Requirement Tables

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