-
Notifications
You must be signed in to change notification settings - Fork 1
Design Doc Template
status of design doc:
Authors: [Names of who Authored this Design Doc]
Reviewers: [Name of who reviewed this Design Doc and when]
High level summary describing what this design doc entails. Should inform the reader whether its useful for them or not... 3 paragraphs max
A description of the problem trying to be solved. This is a good place to include the related user story and explain why this solution is necessary
- describe the desired user impacts of the solution and what you want it to achieve from different user perspectives
- describe how you will measure success
- describe what this solution is not trying to achieve and what will not be fixed or implemented by this solution
What are the high level checkpoints and when do we want to achieve them
Start Date: [ some date ]
Milestone 1 - [ goal ] [date]
Milestone 2 - [ goal ] [date]
.
.
.
End Date: [ some date ]
If there is an existing solution what is it, why does it need to be changed ( maybe illustrate problems through a diagram ) ... link to the old design doc if necessary
Technical Architecture section... describe in technical details the new solution and how it will solve the outline problems. Be detailed here... diagrams are always an asset. A developer should be able to read this section and understand what they need to do while you not being there
How will this solution be tested, once in production how will things be supported and how alerts will be sent out when things go wrong
examples:
- Will this require an increase resources ( Devs, DevOps ect )
- Any security implications ?
- Does this need to be communicated in any way to effected stakeholders ?
Any open questions that can't be currently addressed