Software Design vs. Software Requirements
If you are new to creating software, you have probably heard the words design and requirements thrown around. Are they the same thing? Are they different? And which one do you need?
In this article, I will describe software requirements and software design, the purpose each plays in creating a software app, and why you should consider both prior to developing your web or mobile app idea.
Software requirements clearly define “what” your system needs to do. They are, in effect, a checklist that your designers, developers, and testers will use to make sure you get the system you want.
Defining solid requirements is the first stage of a successful software project. During this stage, you are defining the problem, the future vision and goal, and the details of the solution.
Software requirements cover things like:
- Who are the users of your system
- What is every task that your user needs to perform using the system
- What are the key steps of each process
- What happens when a task doesn’t go as planned
- How many users does the system need to support
- How many transactions per day/minute/second does the system need to handle
- What kinds of processing takes place behind the scenes
- What security and compliance requirements need to be met
- What hardware/infrastructure preferences should the solution work with
- What technology preferences should the solution consider
- What third party systems need to get data in or out of this software
It is better that software requirements be detailed rather than vague. At this point, you are not focused on “how” the system will achieve all the items on the checklist. You are still focused on “what’ the system needs to do to be successful.
With solid requirements in hand, the next step is software design. This is when we figure out how the application will function to meet both the needs of the business and the needs of its users.
Software design can take on many forms. There may be wireframes that sketch out the web or mobile app screens. There may be a higher fidelity design or prototype where you get to see or use a mock-up of the system complete with great graphics, fonts, and images. There may even be very technical specifications that detail logic, workflow, or the data of the system.
All of these documents help describe on paper how the system should look and work so that:
- You can feel confident the right system is going to be built
- Your development team knows exactly how to build it
The Discipline Of Requirements And Design
It is a natural human instinct to start solving problems as soon as we hear about them. If you have a software idea, you most likely started sketching out screens and were looking for a developer to code your system even before you fully defined everything that it should do. Although this instinct is natural, it has its limitations.
Before you start solving a problem, you have to get your arms around the entire puzzle. Once you understand the problem at a wider and deeper level, you will often see that your initial designs wouldn’t have worked or are incomplete because you didn’t have the complete picture in your head.
Requirements are a way of being disciplined about what your software will do. They force you to think about the needs of all of your users and how your system should behave in a wide variety of situations. They also allow you to see and fill in the gaps, and describe the system clearly, without ambiguity.
Although you can code off of requirements, and many people do, a design phase allows you to create a web or mobile app that is easy to use, intuitive, efficient, and in line with your brand.
In many software projects, more than one developer will be doing the work. Without a consistent design, each developer may implement his portion of the application in his own style, resulting in a system that is inconsistent with an identity crisis.
Software can be written in a wide variety of ways using a wide variety of methodologies. You get to choose if you define the requirements and create the design upfront or figure it out while you develop your software.
Figuring it out upfront takes discipline and a concerted effort of thought and analysis. It isn’t as fun as jumping into the code and seeing a system straight away. But having requirements and design is having a roadmap to your desired app. Without a road map, you are forced to drive in the general direction and hope you get there. You may wander, drift, and have a hard time knowing if you are truly on course.
Why not take the time to define your requirements and design up front? Why not give your team a clear picture of what it is you want them to build? Why not empower yourself to know if your team is staying on target and delivering the software you want and need by comparing their work to the design?
For more information about requirements, read our blog post Why Business Objectives Are Not The Same as Software Requirements.
The Checklist For Sharing Your Software Vision
Before you get started in developing your software app, your thoughts and ideas should be clarified and written down so they can be consistently and easily shared and understood. To help you get started on the right foot, we have created a checklist.
You can grab a copy of that checklist below and share it with your team!