56 lines
1.7 KiB
Markdown
56 lines
1.7 KiB
Markdown
# Spec Format
|
|
|
|
## Template
|
|
|
|
```md
|
|
## Problem Statement
|
|
|
|
The problem that the user is facing, from the user's perspective.
|
|
|
|
## Solution
|
|
|
|
The solution to the problem, from the user's perspective.
|
|
|
|
## User Stories
|
|
|
|
An extensive, numbered list of user stories, covering all aspects of the feature. Each user story should be in the format of:
|
|
|
|
1. As an <actor>, I want a <feature>, so that <benefit>
|
|
|
|
<user-story-example>
|
|
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
|
|
</user-story-example>
|
|
|
|
## Implementation Decisions
|
|
|
|
A list of implementation decisions that were made. This can include:
|
|
|
|
- The modules that will be built/modified
|
|
- The interfaces of those modules that will be modified
|
|
- Technical clarifications from the developer
|
|
- Architectural decisions
|
|
- Schema changes
|
|
- API contracts
|
|
- Specific interactions
|
|
|
|
## Testing Decisions
|
|
|
|
A list of testing decisions that were made. Include:
|
|
|
|
- A description of what makes a good test (only test external behavior, not implementation details)
|
|
- Which modules will be tested
|
|
- Prior art for the tests (i.e. similar types of tests in the codebase)
|
|
|
|
## Out of Scope
|
|
|
|
A description of the things that are out of scope for this spec.
|
|
|
|
## Further Notes
|
|
|
|
Any further notes about the feature.
|
|
```
|
|
|
|
## Rules
|
|
|
|
- **Don't include specific file paths or code snippets.** They may end up being outdated very quickly. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision in Implementation Decisions and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
|