New Feature, Resume. Requirements Document


undefined

We started with a template that I really enjoy here. It's all markdown and very easy to build into any project wether you use notion, GitHub, Jira, or just markdown documents locally.

# Feature Requirements Document

## Overview - **Feature Name:** [Feature Name] - **Project:** [Project Name] - **Date:** [Date] - **Status:** Draft/In Progress/Complete

## 1. Feature Description Brief description of the feature and its purpose.

## 2. User Stories ### Primary User - As a [user type], I want [goal] so that [benefit]

### Secondary Users - As a [user type], I want [goal] so that [benefit]

## 3. Functional Requirements ### Core Functionality - [ ] Requirement 1 - [ ] Requirement 2 - [ ] Requirement 3

### Edge Cases - [ ] Edge case 1 - [ ] Edge case 2

## 4. Non-Functional Requirements ### Performance - [ ] Response time requirements - [ ] Load handling requirements

### Security - [ ] Authentication requirements - [ ] Authorization requirements - [ ] Data protection requirements

### Usability - [ ] UI/UX requirements - [ ] Accessibility requirements

## 5. Technical Requirements ### Dependencies - Required software versions - Required libraries- Required APIs

### Integration Points - [ ] Integration 1 - [ ] Integration 2

## 6. Acceptance Criteria - [ ] Criteria 1 - [ ] Criteria 2 - [ ] Criteria 3

## 7. Assumptions - Assumption 1 - Assumption 2

## 8. Dependencies - Internal dependencies - External dependencies

## 9. Risks - Risk 1 - Risk 2

## 10. Timeline - Start date: [date] - Estimated completion: [date] - Milestones: - Milestone 1: [date] - Milestone 2: [date]

## 11. Additional Notes - Any additional important information - Design considerations - Implementation notes

It looks a lot better in practice then it does in a blog format. I should really make a code option for my blogs since I do this a lot.

I used this format to make the ticket for the resume feature. Adding all the information as a ticket means the developer||engineer has less places they need to chase to work and less reasons for distractions. It's important to give the engineer as much information as possible up front to limit the amount of assumptions, guesses, and questions they may have.

I am a little looser on my own documents considering I'm writing them for myself. as the features become more complicated, or the ones for the upcoming game(s), they will contain a lot more details and design documents.