# Software Requirements Specification

> IEEE-inspired structure for a software system. Fill every section;
> a requirement is good when it is testable.

| Field | Value |
|-------|-------|
| Product | Name |
| Version | X.Y |
| Author | @name |
| Date | YYYY-MM-DD |
| Status | Draft / Baselined |

## 1. Introduction

### 1.1 Purpose

What this document specifies and for whom.

### 1.2 Scope

Product name, what it does, what it does not do.

### 1.3 Definitions

| Term | Meaning |
|------|---------|
| Term | Definition |

### 1.4 References

- Related documents, standards

## 2. Overall description

### 2.1 Product perspective

How this fits with other systems:

```mermaid
flowchart LR
    U[Users] --> S[System]
    S --> E[External service]
    S --> D[(Database)]
```

### 2.2 User classes and characteristics

| Class | Description | Key needs |
|-------|-------------|-----------|
| Admin | ... | ... |
| End user | ... | ... |

### 2.3 Operating environment

Platforms, browsers, constraints.

### 2.4 Assumptions and dependencies

- Assumption / dependency

## 3. Functional requirements

| ID | Requirement | Priority |
|----|-------------|----------|
| FR-1 | The system shall ... | Must |
| FR-2 | The system shall ... | Should |
| FR-3 | The system shall ... | Could |

## 4. Non-functional requirements

| ID | Category | Requirement |
|----|----------|-------------|
| NFR-1 | Performance | p95 response < 300ms |
| NFR-2 | Security | All data encrypted at rest |
| NFR-3 | Availability | 99.9% uptime |
| NFR-4 | Usability | Core flow completable without docs |

## 5. Interface requirements

- UI: ...
- API: ...
- Hardware/external: ...

## 6. Acceptance criteria

How each requirement is verified – test, demo, inspection.

## Appendix

Glossary extension, diagrams, data dictionary.