Why Software Design Documentation? How to Write a Good Software Design Documentation (Part 1)IDOWU OLAIDE RIDWAN
As a software developer, We spend much time on reading design documents for software developed or about to be developed. We will also spend time writing our own design documents as well since we are about to develop any application.
I have read over hundreds of software design documents and I can today tell you that the strong differences between good design docs and the ultimate success of the project are correlated like “x and y”.
What makes a design document great? This article will describe what I have gathered over the years.
For a software design to be successful, the following four (4) sections are needed to be known:
- Why do we write design document?
- What do we include in a design document?
- How do we write a design document?
- The process needed around it?
WHY DO WE WRITE DESIGN DOCUMENT?
A design document is a full description of how you want to solve a problem. It is also known as “technical specification”.
Many developers has already written the importance of writing design doc before even going into coding.
The only tool that makes software development easier for any developer is to write design document.
Design document main goal is to make it easier for developers to think through the design and now get feedback from the information gathered.
Many developers thinks that it is the work of software documents to teach about the system we are developing or serves as a documentation for the growth.
I believed that they are also the side benefits of software doc but it doesn’t finish up there.
As an acceptable rules of documenting what you developing, we believed that the only project that needs documentation is for only big projects but mini projects also require documentation since beginners can have inspiration from them.
Many software documentation always has different designs and so, I will take you through the content, style and processes that any software documentation must have.
WHAT DO WE INCLUDE IN A DESIGN DOCUMENT
The following is the list of sections that will be needed to include in your next design doc:
Title and People
- Title of the design doc
- The author(s) names
- The reviewer(s) of the doc
- The date of the documentation being last updated
Always write a catchy summary of what the company can understand and use it to explain what the documentation is about and useful for. It should be up to three (3) paragraphs maximum but not more than it.
This is the part to explain the problem at hand, reasons why the project is highly suitable for the problem.
What the users needed to have to assess the project and how it fits into technical strategy, product strategy and the team’s goals per mile.
Goals and Non-goals
This is the part that details all the goals and non-goals needed for the success of the project
- The doc should explain the goals of the projects
- The doc should list all the goals achievable
- The doc should list all the goals that is “not achievable” by citing the reasons
It is advisable to list all the achievable milestones for the project stages so that all the managers in the project completion can skim through them and measure the progress of the project.
It is always advisable to use “calendar format” so that all project managers can keep track of the progress by calendar based
Start Date: July 24, 2018
Milestone 1 — New system MVP running in dark-mode: July 31, 2018
Milestone 2 – Retire old system: August 12th, 2018
End Date: Add feature X, Y, Z to new system: August 30th, 2018
Add [update] if possible should in case there are update after the end date
Give details about the current solution in use provided that there was a solution in usage
To full explain the current solution, a “USER STORY” should be used to frame your writings.
It is also regarded as “Technical Architecture” among software development. It can also be detailed using user story.
Explain using pictures and real life examples on how the solution will solve the project problem in hand.
Options for open source solution can also be put into consideration here to prevent building from scratch.
It is useful in this part to talk about any other side solutions that comes up when proposing the solutions that you later arrived at.
Monitoring and Alerting
Always provide a check on how to monitor the situation and the alert system for the monitoring incase if anything breaks.
Costs and Expenses
- How many engineers do you need?
- Cost per each engineers
- Doesn’t it after the latency of the current solution?
- Does it after the security of the current solution?
- What are the negative and positive consequences?
- How can the team communicate?
- How can the support team communicate with the users?
Any open issues and talks can be discussed over in this part.
Select other sources of discussion channel e.g slack or skype
This is the part where the project engineers, managers and all the decision makers will be referencing to when looking at the rate of executing the project
It is essentially the part where you will give detailed explanation of how the project will be executed over time and the outcomes of each timelines
It is always good to scope into external factors should that the timeline will be accurate
It is good to use project tracker to track your timelines
This is where we will stop for today on how to write a good detailed software development documentation (part 1)
Thanks for reading and do you plan to enroll for website design and development: