I hear more people talking about requirements for their technology selection process, which makes me happy because I’ve been writing about requirements and teaching classes about requirements for the past 10 years. But one thing still bothers me:
People aren’t talking enough about business requirements.
Unfortunately, project teams usually want to start with functional requirements, which is what they want the system to do. They’re not thinking about the system's business requirements, which is how the new system can help their organization achieve its goals. 
What’s the difference between business requirements and system requirements?
Business requirements describe what your organization needs from your systems and why these needs are important. They’re focused on your organization’s goals for the system, rather than on what specifically the solution can do.
User or functional system requirements define what the system must do to meet user needs.
Non-functional system requirements describe how the system must perform and how well it needs to fulfill certain needs. Examples of non-functional requirements include criteria related to system integration, security, usability, user interface, design, reliability, and so on.
Digging deeper into business requirements
A business requirement is a high-level statement explaining why the organization is bringing in new technology. It provides insight into the new system’s potential value for its users and stakeholders.
Business requirements answer questions like the following:
- How will the system further the organization’s mission and business objectives?
- What organizational problems must the technology help solve?
Business requirements explain how the system can help the organization achieve its goals and improve its operations. They’re not about the solution itself. They’re about strategic organizational goals; in fact, they’re solution-agnostic. You can’t build a system based on business requirements, but you do need business requirements to develop system requirements.
Examples of business requirements
We can illustrate business requirements with an example from outside the association world: Wag. What do you think the business requirements might be for this Uber-like app for dog walking?
You might start thinking about something important for all organizations like data security. However, even though you better have data security, it’s not a business requirement. You don’t develop a system like Wag without data security in mind, but you’re not developing the system for the sake of providing security—that’s not the overall goal here.
What about “connecting dog owners and walkers”? This seems to make sense as a business requirement because it describes what the system will do. However, is that the reason driving the system to be created, or is it really a function orfeature of the system?
Here are some possible reasons (business requirements) to create Wag:
- Improve canine health
- Employ the underemployed
- Elevate the dog-walking profession
- Aggregate a community
- Increase our understanding regarding the behaviors and preferences of members and stakeholders and learn what they find valuable.
- Reduce member dependency on staff by increasing a member’s ability to access information (for example, transactional history) on their own.
- Create an environment where members can acquire new knowledge while interacting with other members.
Consequences of not addressing business requirements first
During the requirements gathering process, you should always discuss and define your business requirements first. Then, you can move on to functional and non-functional system requirements. If you start with system requirements, your project may suffer these consequences:
- User classes and stakeholder groups are overlooked. Business requirements help identify groups that should be part of the requirements gathering process. If they’re not involved, you won’t have the benefit of their insight and know about their needs until it’s too late.
- You have to deal with change requests and changes in project scope. These last-minute changes waste time and money. By including stakeholders in requirements discussions, you know about their needs from the beginning. By having this information up front, you can keep your timeline and budget in check.
- The system doesn’t meet expectations because it doesn’t help the organization and staff achieve goals and solve problems.
Rethink your approach to requirements
By discussing business requirements first, you open minds and expand system potential. Think big. If you start with narrow business requirements, you’ll end up with a narrow system, like a dog-walking app that connects dog owners and walkers but adds no other value. You don’t want to get boxed in by your requirements from the beginning. Think high-level and then get specific.
Are you already in the middle of your requirements process?
Go back and review your business requirements—or develop them if you haven’t already done so. If you discover they’re not true business requirements, pull your team back together for additional discussion.
The business requirements discussion will open up the minds of participants so that they define different but better requirements. When you start with business requirements, you end up with a richer pool of issues to consider and a larger opportunity to deliver value.
Defining business requirements isn’t overwhelming.
Come up with as many requirements as you can and then prioritize them. Beware the danger of accepting everything you come up with as a requirement instead of items as needs and nice-to-haves. Analyze your system requirements to make sure everything you want the system to do maps back to a business requirement.
Discussions about business requirements are illuminating because they help you uncover opportunities while learning about the business goals and concerns of your colleagues. More importantly, these discussions are necessary because they force your team to think about your association’s goals—and position you to achieve them.
This blog was originally published on 10.23.18 and edited on 3.6.23.
Listen to "Getting Worked Up About Business Requirements" on DelCor's Reboot IT Podcast
