What Are the Requirements Needed for a Software Development Quote?
Requirements are an important part of the information you must gather when assembling a quote for a software project. After all, how can you know how much something will cost to build if you don’t understand what it will do.
But, there’s a dilemma:
- How do you justify building requirements before you see a quote?
- How do you get a quote without requirements?
So, when you want a quote and you need requirements, how do you bridge the impasse? It comes down to knowing which requirements you absolutely need to create a good quote.
How Do You Create Good Requirements?
In custom software development, requirements are essential. That’s why we’ve covered them in several past posts:
- How Should I Document My Software Requirements?
- Software Design vs. Software Requirements
- Why Business Objectives Are Not The Same as Software Requirements
- Top 5 Problems When Writing Software Requirements
Beyond how to document requirements, avoiding common pitfalls, and differentiating your software requirements from business objectives, it’s also important to pull the right team together to assemble and draft them.
The best team to draft requirements includes your solution architects, key stakeholders, and project/product managers. But, you also need a business analyst to analyze what users will do, pull those requirements together, and bridge their business needs to what’s technologically possible.
Why Are Requirements Important?
Building a house is a lot like building custom software. Sure, houses have been built before, but that doesn’t mean you can use someone else’s blueprints to build your house, assuming that they will work for you too.
Hire a builder and give them vague requirements, and you could end up with a house with no closets, or three bedrooms shotgun-style with no hallway, or both bathrooms upstairs. Maybe any of those configurations could work for you, but without requirements, you leave the project (and its details) in the hands of the builder. The builder builds and the designer designs. Each role puts its respective skills and expertise to work in completing the project. Would you like the person who poured your concrete to be your interior designer?
Software Requirement Specification: Different Users Want Different Things
Ask ten homebuyers to describe their dream home, and you’ll get ten answers. The same goes for software development.
When you set out to develop your requirements, consider:
- Users who will be served by the software
- What users think the software will do
- What the user intends to do
- What you are trying to accomplish
Think of the user roles and personas who will use the system after go-live. For example, in a call center environment, this would include the call center reps, whose primary requirements might reflect their wish for autodetected phone numbers or auto-filled records. Contrast this with their managers who want reports and data to monitor employee, team, and departmental performance.
But, if you only consider the call center rep and manager, you could miss an equally important and influential group: call center callers. They might prioritize not needing to repeatedly identify themselves when they call the hotline.
Creating Software Requirements
Writing software requirements means getting into the heads of the people who will use the software. Whether you are creating a ride-share app or a system to support a customer service operation, you develop requirements that suit all the parties who might find their way into the software.
After you’ve got your requirements, take them to a solution architect who will work with you to develop any requirements that you might have missed. Maybe the call center callers want to know their anticipated wait time on hold. Maybe a call center manager wants to know the average time between calls for each rep. Maybe the company’s IT group needs the app to connect to a third-party SSO solution.
When Requirements Go Bad
The worst requirement is the one you don’t capture, some of these include; thinking about what kind of users will be using the software? What are the security requirements? What kind of payment processing or data storage do you need? What third-party systems need to get data in or out of this software? Those can significantly impact your ability to stay on budget and within your estimates.
When you build an app and apps, there are so many decisions that it can cost between $200,000 and $1 million to build. For example, whether you build two native apps for iOS and Android or build one on React Native can mean a 2x cost differential.
One common pitfall we see is when companies request bids for custom apps through poorly defined RFPs. RFPs force bidders to focus on the lowest cost. When you leave too many decisions up to someone motivated to cut costs, you may be agreeing to tradeoffs before you even know what those are.
The Bottom Line: Drafting Requirements
When you’re drafting requirements for your custom software project, you want the right people at the table, representing the right users with the right expertise. You want someone who asks the questions and represents the interests of users and stakeholders who aren’t there in the room. You want the requirements you need to get an accurate quote without losing time on a project that may not get the green light.
It’s okay to ask for help. In our downloadable eBook, The Ultimate Guide to Software Requirements, we show you how to identify and document the key requirements of your custom software project. When we develop requirements, we aim to make the entire development process easy for our clients by helping them determine the most important information upfront.