You don't need to know code to write specifications developers will love
What Makes a Good Specification
| element | purpose | priority |
|---|---|---|
| User Stories | Define who does what and why | Must Have |
| Feature List | What the app does | Must Have |
| User Flows | How users navigate | Should Have |
| Data Requirements | What information is stored | Should Have |
| Integrations | External services needed | Nice to Have |
User Story Template
## User Story Format
As a [type of user]
I want to [perform an action]
So that [I achieve a benefit]
## Example
As a customer
I want to save my payment method
So that I can checkout faster next time
## Acceptance Criteria
- User can add credit/debit card
- Card number is masked (show last 4 digits)
- User can have multiple saved cards
- User can delete saved cards
- User can set a default card
Feature Specification Example
## Feature: User Registration
### Overview
Allow new users to create an account to access the platform.
### User Flow
1. User clicks "Sign Up"
2. User enters email address
3. System validates email format
4. User creates password (8+ characters)
5. System sends verification email
6. User clicks verification link
7. Account is activated
### Requirements
- Email must be unique in system
- Password: minimum 8 characters, 1 number, 1 special character
- Verification link expires in 24 hours
- User can resend verification email
### Edge Cases
- What if email already exists? Show "email already registered" with login link
- What if verification link expires? Allow resend
- What if user never verifies? Account remains inactive
Data Requirements Template
## User Profile Data
### Required Fields
- Email (unique, used for login)
- Password (hashed, never stored in plain text)
- Full Name
- Account Created Date
### Optional Fields
- Phone Number
- Profile Photo
- Address (for shipping)
### Business Rules
- Email cannot be changed after registration
- Password can be reset via email
- Account can be deactivated but not deleted (for records)
Common Mistakes to Avoid
Avoid
- • Vague requirements ("make it fast")
- • Assuming developers know your business
- • Skipping edge cases
- • No prioritization
Do Instead
- • Specific metrics ("load in under 3 seconds")
- • Include business context
- • Document what happens when things go wrong
- • Mark features as Must/Should/Nice to have
Need help with your specification?
We help non-technical founders create clear technical requirements.
Get Specification Help