Forget the Chicken and the Egg, Business Requirements Come First

Dave Coriale, CAE | 10.23.18
Topics: Software Requirements & Selection

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—what they want the system to do. They’re not thinking about how the new system can help their organization achieve its goals—the system’s business requirements.pexels-photo-1020325

What’s the difference between business requirements and system requirements?

Business requirements describe what your organization needs and why these needs must be fulfilled. They’re focused on your organization’s goals for the system being considered, not the solution itself.

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—how well it must function. 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 creating and/or implementing new technology. It provides insight into the new system’s potential value for its users and stakeholders.

Business requirements answer questions like:

  • How will the system further the organization’s mission and business objectives?
  • What organizational problems must the technology help solve?

pexels-photo-908295Business 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 them 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 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 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/feature 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

Do you see the difference between “security” or “connecting dogs and walkers” and actual business requirements? Keeping that difference in mind, let’s look at some possible business requirements for a new association management system (AMS):

  • Increase our understanding of members and stakeholders, including their behavior and preferences, and what they find of value.
  • Reduce member dependency on staff by increasing a member’s ability to access information, for example, transactional history, on their own.
  • Create an environment in which members can acquire new knowledge while interacting with other members.

When partnering with our association and nonprofit clients on AMS selections and other technology implementations, we always want to ensure the business requirements they develop are clearly understood and communicated.

Consequences of not addressing business requirements first

During the requirements gathering process, always discuss and define your business requirements first. Then 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—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 up 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, then get specific.

Are you already in the middle of your requirements process?

Go back and review your business requirements—or develop them if [egads] you haven’t already done so. If you discover they’re not true business requirements, pull your team back together for additional discussion.

draw-1772745_640The business requirements discussion will open up the minds of participants so 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, 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.

Listen to "Getting Worked Up About Business Requirements" on DelCor's Reboot IT Podcast 


Don't Skimp on Requirements Analysis  We answer 9 questions about requirements analysis so you can save your job—and  your sanity. Bonus: Dave's top ten signs your project is in trouble. Download the Whitepaper

Subscribe to receive new DelCor blogs!



Peek into your org's IT Maturity with our self-assessment


Find our best events, white papers, and more.


In a fix, intrigued, or can't find what you're looking for?