Software Requirements Specification
Formal requirements spec (IEEE-style, testable FRs)
Як використовувати: Formal contracts, regulated work, or fixed-bid projects. Every `FR-N` must be testable – if you can't test it, rewrite it.
Перегляд
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:
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.