What are business requirements? A common answer I get when asking for an example of a business requirement is a sentence like: “The system shall facilitate the automation of email to the customer.” Is that a business requirement? Well of course it must be. The business told me that specifically, and in those words! It must be a business requirement since it came from the business, right!?
Well, no it isn’t. It may end up being a requirement, but it is not a business requirement. Let’s explore the difference between that “system shall” sentence and what I believe is a true business requirement. Like a lot of requirement types, there will be a fine line between one type to another, but in general, I think there are guidelines on which requirements fall into which types. It is important to understand the difference so that we provide the business with a solution that will actually solve the problem, not just what somebody thought would be a good idea (or a ‘pretty, shiny thing’).
What a Business Requirement is NOT: A Functional Requirement
The answer above, “The system shall facilitate the automation of email to the customer,” is not a business requirement, it is a functional requirement. A functional requirement describes how we perform our business processes (or their functionality). It usually is subjective and it may not be the right answer! You can technically solve your business needs in many different ways. For example, you can choose to email a customer, tweet them or whatever the next new, big thing is.
Our functional requirements should describe how the business would like a software system to work or the steps they take to perform a manual process. Here are some examples of how we might represent functional requirements:
- A statement like: “The system shall display a welcome message to the user on the Home page.”
- A prototype
- A workflow diagram
- A use case description (textual description of the steps to complete a function)
- A story map
So, What is a Business Requirement?
A business requirement is not something a system must do. It is something that the business needs to do or have in order to stay in business. For example, a business requirement can be:
- a process they must complete
- a piece of data they need to use for that process
- a business rule that governs that process and that data
Your business requirements change less (in most businesses) than your functional requirements, and are typically more objective. “If we don’t find the best way to reach our customer, we could be out of business!” So, the business requirement would read something like: “We need to contact the customer with xyz information”, not “the system will….”.
Remember, “The system shall do this or that…” describes the how (or the functionality). It is the manifestation of the business requirement in a system.
Let’s consider if this had been stated as a user story.
As a Product Owner, I want to communicate product incentives to our customers each time they purchase a complimentary product.
In this instance, the user story is written independent of the how or functionality and is a business or stakeholder requirement. (Although, I might argue that it really doesn’t state the true benefit however and should be rewritten.) Too often, though, a user story will be written like this:
As a Product Owner, I want our customers to receive an automated email each time they purchase a complimentary product.
This is definitely a functional requirement and makes some huge assumptions regarding the purchase of products. Are they always made in an automated fashion, if not, how does the system know to send an automated email at the time of purchase and to what email address? What is the Product Owner is really trying to achieve? Is sending an automated email the best way to accomplish the ultimate goal?
Understanding the true problem or business need (Business Requirement) will ensure that you are delivering the highest value to your customer. Once we understand the true business needs, we can start determining the best way to approach building a solution (whether automation is involved or not) and how to implement that solution.
Why Elicit Business Requirements?
The reason is simply to help you, and even more importantly, the business itself understand what needs to be done. Many SMEs get caught up in the day-to-day (and sometimes very expensive) “that’s how we’ve always done it” and forget their business goals and success factors. Talking through, communicating and getting agreement on the business requirements helps bring these goals and success factors to the surface.
For example, discussing why you want to communicate with your customers when they purchase particular products focuses on the solution and direction. Is it for brand awareness or maybe to sell add-on products or service items? The answers to these questions and brainstorming on how you might achieve those goals creates “aha” moments. It creates innovation. It creates excellence in business. When everyone understands the business well it’s easier to know what new directions to take to create success.
How Do We Get to the True Business Requirements?
Like anything we do, if we are in the business analysis role, there is not one right way. The wrong way, though, is to go straight to a solution without understanding the business.
When I am not teaching, I run IT for a telecommunications expense management company, so I live and breathe data. Without correct and complete data, my business would lose customers fast! That means I am somewhat partial to the data side and typically start there. If you are more ‘process-oriented’, you might start there. It doesn’t matter where you start, as long as you reach a good understanding of the business.
To clarify, when I say start, I mean I research. I comb through any documentation and information about the business that I can find. I come up with many questions that I then need to get answered by the right people. The answers raise more questions. I watch people work, I analyze how they do what they do and pull out what their true goal is. I dig deeper when someone says, “I’m not sure why I have to do that, it’s how we’ve always done it” or “I don’t know why we need that information or what we do with it”. I help them figure out their pain points.
I analyze the relationships between the data. For example, in my business I need to know what accounts our clients have with their telecom vendors. I dig into the detailed data to ensure we have what we need for the business processes to perform correctly. For example, I need account number and contract data to ensure that the telecom vendors are charging our clients the correct rates. I dig further into the data to discover how we make decisions and why sometimes we make bad decisions or processes fail.
In my business, we recently added a new service offering. Something we had never done before. I had to build processes from the ground up to handle what we needed to succeed. I explored data and business rules to identify our new processes. I needed to make informed decisions about what to automate and what we needed to perform manually. If I had jumped right to building the new application screens we need to support the new business, I would certainly have missed crucial data, had a lot of rework, been frustrated, and disappointed my business partner. None of those would be good, would they?
I usually see puzzled faces when I tell people that the “system shall” statements are not business requirements, but rather they are functional. But then, I get an aha! moment when they start to realize why they need to understand and communicate true business requirements. That’s when the innovation, real change, creativity, out of the box thinking comes in! If you really understand WHAT a business does, then you can come up with the best solution for that business.
I hope we in the IT industry do not fall prey to the old ‘just start building and it will be great’ way of thinking. I have done that before; it’s not great. It leads to expensive redesign and rework, and even that is not done well because now we are behind and the business is frustrated. How about we get it right the first time? I say yes!
Thank you,
– Ali
Want more AHA moments?
Editor’s Note: This blog post was has been previously published by B2T on our previous website. Due to its popularity, Ali has updated its content to be more comprehensive and accurate for the state of today’s environment.
Ali Cox
LEAD EXPERT
Alison (Ali) Cox has experience since the mid-1980s in various areas, including business agility, business analysis, project methodology development and training, systems development (mainframe, client-server, and web), and telecommunication expense management. She began her career in the financial services area, and then moved into systems development for accounting systems.
Ali has lived through IT and operational initiatives from waterfall to implementing agile in her own small business, then helping other companies do the same through training and mentoring. She believes that having the small business mentality (everyone has to pitch in on everything) is the right kind of mindset for all organizations, no matter the size or industry.
Ali is the author of Business Analysis for Dummies, 2nd Edition.
