Member-only story
PRD is not enough! We need SDD!
A missing link between requirement and code
Intro
Imagine you are leaving on a road trip, but instead of using a map, you are told where to go. You recall a series of places to go through and start driving by relying on road signs. Sure, you may get there, but there’s a lot of room for failure. You may have wrong memory about one of those step, a road sign may have altered, or the path may be blocked for construction and you need to take detour and you don’t know where the hell you are anymore. You might be lost, all because you don’t have a map.
That is less true nowadays since we all have phones with GPS with us all the time, but you get the point.
Similar to coding, if you are told of a destination (a product requirement document, or PRD) and you jump into coding right away, you may fail in a similar manner. You need a map — in this case, a software design document, or SDD. Much like a map, an SDD can help keep you and your team on track from the start of a project to the last lines of code.
If PRD is a destination, SDD is a map.
Once in a while, some feature is too complex that a PRD alone is not enough to produce good code. One idea I have is to create an SDD (software design document). I will cover the who, what, when, and how we should create one.
Vocabulary
Let’s refresh some abbreviations in case this is new to you:
PRD (product requirements document) is an artifact used in the product development process to communicate what capabilities must be included in a product release to the development and testing teams. It often consists of:
- Elevator Pitch
- Overview
- Success Criteria
- Product Requirements — user stories, applicable clients, design links, etc.
SDD (software design document) is a detailed plan for developing a piece of software. It should break down nearly every aspect and outline the finished software’s functionality (specs) and your team’s plans to build it (timeline, goals, etc.). It often contains:
- Owners / Reviewers
