This is your tech spec’s abstract: the who/what/when/where/why of your entire proposal, made succinct. One or two sentences, keep it brief.
Contextualize your project:
- why build it?
- What is the motivation?
- What user problems are you attempting to solve?
- What previous efforts, if any, have been made to solve this problem?
Highlight all the outcomes that you predict will result from your work, both purposeful and inadvertent.
A non-goal is something you are intentionally not doing or solving with your project, even if it could be related. Defining non-goals helps limit the scope of your project and prevents feature creep.
The bulk of the technical aspects goes here.
- Description
- Input Parameters
var name | required/optional | data type | description |
---|---|---|---|
- Pseudo Code / Behavior Tests (It should/should not...)
- Responses
response code | response json | description of when this occurs |
---|---|---|
How do you measure success? Comparitive response times? Conversions in mixpanel?
If the project is external-facing, list the ways in which malicious users could exploit your change.
It’s important to solicit these critiques so that reviewers can pose questions and solutions that will ultimately make your feature more robust.