Software Design Documents are the foundation of any good run, from concept to release. In this two part post, we will cover what this document is, how to make one, and why it’s so important to have one ready from the start. We will then dive into the difference of planning a project with and without one of these documents with a team.
What is a Software Design Document?
ASoftware Design Document is the bible of the software you plan to develop. It is meant to cover everything about the software before you even lift a finger. It describes what the software does, what it’s meant for, and who it is meant for. It can contain anything from early concepts to late patch information. It could even have a plan for the life cycle, which can even cover what happens after the software releases. If you have a question about your software design, an answer should be found in the document. These documents are very flexible and can be used to facilitate the production of all kinds of software, from applications you can use on your mobile device to video games and professional programs.
How to get Started with a Design Document
Making a Software Design Document depends on what type of software you are designing, the scope of the design, if you have a team or it is just a personal reference document, and many other factors. For example, a Game Design Document that is for your eyes only would include the game’s name, the high concept (which is the main summary of what the game is and how it plays), the target platforms that will run the game, what mechanics the game will use (which will be translated into code later in development), and what assets you will need to build a working prototype.
When first starting out and dealing with a personal scope for the game, you’ll want to think as small as possible to create the Minimal Viable Product. Once the game is fully fleshed out and developed so it matches the document, you would then go on to update the document to include newer content for the release build. A design document doesn’t always have to be rigid.
With that example in mind, we get a basic understanding to adapt it to any kind of software. Ask the following questions as needed and put what is necessary into your document:
- What is the project called?
- Who is working on the software and who will review the document against it?
- When has the document last been updated?
- Who is your target demographic for the software?
- What will the software run on?
- Who is/will fund the project?
- What is the high concept? (Be brief with this – if it can’t fit in a single Tweet, it isn’t brief enough.)
- What problem does the software fix and how?
- What does the software not do? (To keep your team on the same page)
- Are there any design goals?
- Are there any risks or roadblocks?
In order to make the best design document you can to ensure your development begins with maximum potential, use the A.S.S.E.S.S. method – Always Start Simple, Especially in Short Situations. You can always make your software bigger and better in the future. You can add every bell and whistle under the sun in time, but there is probably a deadline you have to meet that is creeping up. Starting simple and assessing what your team can get done in time will increase your chances that you have something to show for come the deadline.
In the next part of this post we will answer one very important question.