Templates
Requirements Templates
Templates for user stories, use cases, and software requirements specifications
Requirements templates help capture and communicate what needs to be built. These templates range from lightweight (user stories) to comprehensive (SRS) depending on project needs and regulatory requirements.
User Story Template
# User Story: US-[ID]
## Story Information
| Field | Value |
|-------|-------|
| ID | US-[ID] |
| Title | [Short descriptive title] |
| Epic | [Parent epic if applicable] |
| Priority | Must Have / Should Have / Could Have / Won't Have |
| Points | [Story points] |
| Sprint | [Sprint number] |
---
## User Story
**As a** [type of user]
**I want** [goal/desire]
**So that** [benefit/value]
---
## Acceptance Criteria
### Scenario 1: [Happy Path]
```gherkin
Given [precondition]
And [additional precondition]
When [action]
Then [expected result]
And [additional result]Scenario 2: [Error Case]
Given [precondition]
When [action that causes error]
Then [error handling behavior]Scenario 3: [Edge Case]
Given [edge case condition]
When [action]
Then [expected behavior]Additional Details
Business Rules
- [Rule 1]
- [Rule 2]
UI/UX Notes
- [Design reference or description]
- [Wireframe link if available]
Technical Notes
- [API endpoint affected]
- [Database changes needed]
- [Third-party integration]
Dependencies
| Dependency | Type | Status |
|---|---|---|
| [Dependency] | Story/API/External | Resolved/Pending |
Definition of Ready Checklist
- Acceptance criteria defined
- Dependencies identified
- Technical approach discussed
- Estimated by team
- UX designs available (if applicable)
Traceability
| Type | Reference |
|---|---|
| Requirement | REQ-[ID] |
| Design | [Design doc link] |
| Test Cases | TC-[IDs] |
---
## Use Case Template
```markdown
# Use Case: UC-[ID]
## Use Case Information
| Field | Value |
|-------|-------|
| Use Case ID | UC-[ID] |
| Name | [Use Case Name] |
| Version | 1.0 |
| Author | [Name] |
| Last Updated | [Date] |
---
## 1. Brief Description
[One paragraph describing the use case]
---
## 2. Actors
### Primary Actor
[Who initiates this use case]
### Secondary Actors
[Other systems or users involved]
---
## 3. Preconditions
[What must be true before the use case can start]
1. [Precondition 1]
2. [Precondition 2]
---
## 4. Postconditions
### Success
[State of the system after successful completion]
### Failure
[State of the system if the use case fails]
---
## 5. Basic Flow
| Step | Actor | System |
|------|-------|--------|
| 1 | [Actor action] | |
| 2 | | [System response] |
| 3 | [Actor action] | |
| 4 | | [System response] |
| 5 | | [System completes action] |
---
## 6. Alternative Flows
### 6a. [Alternative Flow Name]
**Trigger:** [When this flow is triggered]
| Step | Actor | System |
|------|-------|--------|
| 6a.1 | [Action] | |
| 6a.2 | | [Response] |
[Returns to step X of basic flow OR ends use case]
### 6b. [Another Alternative Flow]
**Trigger:** [When this flow is triggered]
[Steps...]
---
## 7. Exception Flows
### 7a. [Exception Name]
**Trigger:** [Error condition]
| Step | System |
|------|--------|
| 7a.1 | [Error handling action] |
| 7a.2 | [User notification] |
---
## 8. Business Rules
| Rule ID | Description |
|---------|-------------|
| BR-001 | [Business rule] |
| BR-002 | [Business rule] |
---
## 9. Non-Functional Requirements
| Requirement | Description |
|-------------|-------------|
| Performance | [Response time, throughput] |
| Security | [Authentication, authorization] |
| Availability | [Uptime requirements] |
---
## 10. User Interface
[Wireframe reference or description]
---
## 11. Related Use Cases
| Use Case | Relationship |
|----------|--------------|
| UC-XXX | [extends/includes/related] |Software Requirements Specification (SRS)
# Software Requirements Specification
## [System Name]
### Document Information
| Field | Value |
|-------|-------|
| Version | 1.0 |
| Date | [Date] |
| Author | [Name] |
| Status | Draft / In Review / Approved |
---
## 1. Introduction
### 1.1 Purpose
[Purpose of this SRS document and intended audience]
### 1.2 Scope
[Scope of the software being specified]
### 1.3 Definitions, Acronyms, and Abbreviations
| Term | Definition |
|------|------------|
| [Term] | [Definition] |
### 1.4 References
| Document | Version |
|----------|---------|
| [Reference] | [Version] |
### 1.5 Overview
[Overview of the rest of the document]
---
## 2. Overall Description
### 2.1 Product Perspective
[How this system fits into the larger environment]
### 2.2 Product Functions
[High-level summary of major functions]
### 2.3 User Classes and Characteristics
| User Class | Description | Frequency of Use |
|------------|-------------|------------------|
| [User type] | [Description] | [Daily/Weekly/etc.] |
### 2.4 Operating Environment
[Hardware, software, network requirements]
### 2.5 Design and Implementation Constraints
[Constraints affecting design choices]
### 2.6 Assumptions and Dependencies
[Assumptions that could affect requirements]
---
## 3. Specific Requirements
### 3.1 Functional Requirements
#### 3.1.1 [Feature Category]
##### REQ-001: [Requirement Title]
| Field | Value |
|-------|-------|
| ID | REQ-001 |
| Priority | Must Have |
| Source | [Stakeholder/Document] |
**Description:**
[Detailed description of the requirement]
**Rationale:**
[Why this requirement exists]
**Acceptance Criteria:**
1. [Criterion 1]
2. [Criterion 2]
**Dependencies:**
- [Dependency]
---
### 3.2 Non-Functional Requirements
#### 3.2.1 Performance Requirements
| ID | Requirement | Target |
|----|-------------|--------|
| NFR-PERF-001 | Response time | < 2 seconds |
| NFR-PERF-002 | Throughput | 1000 req/sec |
#### 3.2.2 Security Requirements
| ID | Requirement |
|----|-------------|
| NFR-SEC-001 | [Requirement] |
| NFR-SEC-002 | [Requirement] |
#### 3.2.3 Reliability Requirements
| ID | Requirement | Target |
|----|-------------|--------|
| NFR-REL-001 | Availability | 99.9% |
| NFR-REL-002 | MTTR | < 1 hour |
#### 3.2.4 Usability Requirements
| ID | Requirement |
|----|-------------|
| NFR-USE-001 | [Requirement] |
---
### 3.3 External Interface Requirements
#### 3.3.1 User Interfaces
[Description of UI requirements]
#### 3.3.2 Hardware Interfaces
[Hardware interface requirements]
#### 3.3.3 Software Interfaces
| System | Interface | Purpose |
|--------|-----------|---------|
| [System] | [API/Protocol] | [Purpose] |
#### 3.3.4 Communications Interfaces
[Network protocols, data formats]
---
## 4. Traceability Matrix
| Requirement | Design | Code | Test |
|-------------|--------|------|------|
| REQ-001 | SDS-001 | [Module] | TC-001 |
| REQ-002 | SDS-002 | [Module] | TC-002 |
---
## 5. Appendices
### Appendix A: Glossary
[Extended definitions]
### Appendix B: Analysis Models
[Diagrams, models]
### Appendix C: Issues List
[Open questions, TBD items]
---
## Approval
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Product Owner | | | |
| Technical Lead | | | |
| QA Lead | | | |Product Requirements Document (PRD)
# Product Requirements Document
## [Product/Feature Name]
### Document Information
| Field | Value |
|-------|-------|
| Author | [Name] |
| Date | [Date] |
| Version | 1.0 |
| Status | Draft / In Review / Approved |
---
## 1. Overview
### 1.1 Problem Statement
[What problem are we solving?]
### 1.2 Objective
[What are we trying to achieve?]
### 1.3 Success Metrics
| Metric | Current | Target | Measurement |
|--------|---------|--------|-------------|
| [Metric] | [Value] | [Value] | [How measured] |
---
## 2. User Research
### 2.1 Target Users
[Who are the primary users?]
### 2.2 User Personas
**Persona 1: [Name]**
- Role: [Description]
- Goals: [What they want to achieve]
- Pain Points: [Current frustrations]
### 2.3 User Journey
[Current user journey and pain points]
---
## 3. Requirements
### 3.1 Must Have (P0)
| Requirement | Description | User Story |
|-------------|-------------|------------|
| [Requirement] | [Details] | US-XXX |
### 3.2 Should Have (P1)
| Requirement | Description | User Story |
|-------------|-------------|------------|
| [Requirement] | [Details] | US-XXX |
### 3.3 Nice to Have (P2)
| Requirement | Description | User Story |
|-------------|-------------|------------|
| [Requirement] | [Details] | US-XXX |
### 3.4 Out of Scope
- [Item explicitly excluded]
---
## 4. User Experience
### 4.1 User Flow
[Diagram or description of user flow]
### 4.2 Wireframes
[Link to wireframes/mockups]
### 4.3 Design Principles
- [Principle 1]
- [Principle 2]
---
## 5. Technical Considerations
### 5.1 Architecture Impact
[How this affects system architecture]
### 5.2 Dependencies
| Dependency | Type | Status |
|------------|------|--------|
| [Dependency] | [Internal/External] | [Status] |
### 5.3 Technical Constraints
- [Constraint 1]
- [Constraint 2]
---
## 6. Launch Plan
### 6.1 Release Strategy
[Phased rollout, feature flags, etc.]
### 6.2 Timeline
| Milestone | Date |
|-----------|------|
| Development Complete | [Date] |
| Beta Launch | [Date] |
| GA Launch | [Date] |
### 6.3 Launch Checklist
- [ ] Documentation complete
- [ ] Support team trained
- [ ] Monitoring in place
- [ ] Rollback plan ready
---
## 7. Open Questions
| Question | Owner | Due Date | Resolution |
|----------|-------|----------|------------|
| [Question] | [Name] | [Date] | [Answer] |
---
## Approval
| Role | Name | Date |
|------|------|------|
| Product Manager | | |
| Engineering Lead | | |
| Design Lead | | |Related Resources
- Requirements Discipline
- Definition of Ready
- FDA QSR Guidelines
- Microsoft Playbook: Agile Development
Compliance
This section fulfills ISO 13485 requirements for design inputs (7.3.3), customer requirements (7.2.1), and traceability (7.5.3), and ISO 27001 requirements for information security requirements (A.5.6), security in supplier agreements (A.5.20), and documented information (7.5).
How is this guide?
Last updated on