INFO 153B/253B: Backend Web Architecture
Kay Ashaolu
"A technical design doc describes a solution to a given technical problem. It is a specification, or “design blueprint”, for a software program or feature.
The primary function of a TDD is to communicate the technical details of the work to be done to members of the team. However, there is a second purpose which is just as important: the process of writing the TDD forces you to organize your thoughts and consider every aspect of the design, ensuring that you haven’t left anything out." (from medium article)
Just because we have written our PRD and TDD doesn't mean it's set in stone
Those two documents should be living documents
As implementation occurs, and life continues, requirements and technical issues can arise and change
We then modify the PRD and TDD accordingly
Changing PRD and TDD has implications, and those should be called out, including
Increase in scope = increase length of time takes to implement
Change in requirements = increase length and complexity of solution
Technical understanding increases = gives more insight in what is possible and how long it will take, can modify timeline
Technical limitations discovered = can impact whether requirements can be implemented as described
Once all parties are good with the feature set implemented we go to launch
Very rarely does this include everything in the PRD
Many times there are high priority or must have items that are implemented that go in the first version
Subsequent features can go in next versions