How Should I Document My Software Requirements?
By Thayer Tate
Starting the process of developing customized software can add a lot of stress and pressure when you’re uncertain about the best approach to follow and your responsibilities in the requirements definition process. It’s common to have a myriad of questions run through your head. Where do I start? How detailed do I need to be? How do I communicate my vision? Do I need to determine the technical requirements? What if I am not very technical?
You are right to think hard about specifying your requirements well, as this is one of the most critical aspects of the development process and starting a successful project. Most of our clients are not technically savvy and are commonly business executives with good ideas on how to streamline their operations internally or provide new services to their customers through a mobile app or software application. You may have noticed from some of our other articles, that we place a great deal of importance on upfront Solution Design. It saves time and money and helps you avoid mistakes, overruns, and unnecessary time delays. Proper upfront requirements documentation and solution design are the key to setting up the project for success and ensuring the resulting solution will fulfill all of your key business objectives.
At SOLTECH, we provide our clients with a carefully crafted requirement checklist that was developed to bypass typical pitfalls that many software development projects experience. We ask questions that prompt thoughtful responses about the end-users and their goals when using the application, and details around needed software features. Below, we have provided some guidelines to help you start documenting requirements for your software application.
Where do I start? Do I start with an outline or list of features?
The very best place to start, when thinking about creating the most optimal and functional application, is to define each type of user that will be using the software. Because the most important aspect, once the software has been completed, is to have developed solutions for each user group. Therefore, once the user categories are rigorously defined, the software team will be able to construct an efficient and effective roadmap.
Questions will arise, such as:
- Is there more than one type of user group?
- Does each user group have completely different requirements?
- Are there accessibility and security requirements for each user group?
- Will any of the users be using payment processing or data storage?
- Are any of the user groups going to use the software to interact with other user groups?
Let’s take a look at an example that will give you a better idea of how this is achieved. Let’s say you recently founded a company similar to Uber. While it may appear that the software requirements would be fairly basic, they are actually quite complex. Since the software application will be used by the drivers, the rideshare customers, and the company, there are three primary user groups. Delving into each group’s interactions with the software, will uncover specific requirements, such as:
Driver Requirements: The driver will need the software to profile features such as login, profile editing, add/edit customer ratings, track the car’s location, receive payments/tips for services, and more.
Rideshare Customer Requirements: The customer is looking for a quick and simple experience and will expect the system to accept ride requests, display the drivers’ exact location, provide trip pricing, allow online payments, and a profile that includes ride history, account history, driver ratings, and more.
Company Requirements (the back end): An internal company admin user will expect the application to provide user management, ride management, payment management, geographic tracking, driver/contractor agreements, driver payments, and the ability to handle any support request that might come up.
By evaluating each user type and their needs separately, you are likely to be more thorough and also think more like the end-user, which is always a good thing when designing software. Additionally, user-driven requirements will be easier for your software developer to follow and will more easily translate to technical design concerns like user roles and security.
Your Take-away: Define the various personas of the groups that will be using the application.
How do I communicate my vision?
Once you have taken the time to understand and define each user’s requirements clearly, the next step will be to consult with a Solution Architect. This is an architect level technical resource who will take the User Personas and individual needs step further. The Solution Architect will typically ask a myriad of additional questions that you didn’t know to ask and uncover issues that need to be addressed before the Software Design is expanded with the details required by the software engineers.
A highly experienced Solution Architect should be able to converse with you in business terms and help translate business requirements into a more precise and detailed set of software specifications to guide future implementation efforts. It’s also very common for the input of Solution Architect to help you identify requirements or features that you might have missed otherwise.
No matter how detailed your business requirements may be, we always recommend engaging a Solution Architect to help you translate requirements into Software Specifications before you engage a software development team. Remember that Software Design should be a collaborative process and that your input and involvement are equally important to the process. Avoid working with architects or developers that seem to minimize your input in the development process.
Do I need to determine the technical requirements? What if I am not very technical?
When working with a reputable software development company, you will not be asked to make technical decisions without the options being described in business terms. In fact, if your software development contractor regularly speaks to you in technical terms, we would suggest working with someone else. Just as you would not be expected to tell the home builder how to engineer a foundation or build to government building codes, your development contractor should not expect you to provide technical level details and requirements.
In our downloadable eBook, The Ultimate Guide to Software Requirements, we walk through the process of identifying and documenting the most important aspects of software development. Our objective is to make the entire development process easy for our clients by gleaning the most important information upfront.
Thayer TateChief Technology Officer
Thayer is the Chief Technology Officer at SOLTECH, bringing over 20 years of experience in technology and consulting to his role. Throughout his career, Thayer has focused on successfully implementing and delivering projects of all sizes. He began his journey in the technology industry with renowned consulting firms like PricewaterhouseCoopers and IBM, where he gained valuable insights into handling complex challenges faced by large enterprises and developed detailed implementation methodologies.
Thayer’s expertise expanded as he obtained his Project Management Professional (PMP) certification and joined SOLTECH, an Atlanta-based technology firm specializing in custom software development, Technology Consulting and IT staffing. During his tenure at SOLTECH, Thayer honed his skills by managing the design and development of numerous projects, eventually assuming executive responsibility for leading the technical direction of SOLTECH’s software solutions.
As a thought leader and industry expert, Thayer writes articles on technology strategy and planning, software development, project implementation, and technology integration. Thayer’s aim is to empower readers with practical insights and actionable advice based on his extensive experience.