Purpose (also referred to as the “Rationale”):
A generic description of what you are proposing? This should not go into a lot of technical depth. It should be a description a producer can understand enough to get the jest of the work. You will go into more technical depth later.
Terminology:
Define words that may not be commonly used in the doc. If you are writing an “unwrap” tool, leadership or naive readers may not understand what that is so spend time to define edge case words.
Problem:
Why are you proposing this work? What problems are you solving?
Solution:
What is your proposed solution?
Risks:
What could go wrong?
Fallback Plan (Mitigation Strategy):
If the solution does not work (this should be called out in the “Risks” section) what alternate solution exists to mitigate the problem. How can you leverage your work into another successful solution
Proof of Success (Conditions of Success):
How will we know if the “Solution” was successful?
Implementation steps:
Algorithm for implementation. This will be very technical and probably just read by other TAs and engineers. However it is an important part of the doc because you can use it to test yous implementation plans as well as use it as pseudocode.