What is a business requirement? The most 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 directly! It must be!?
Well, no it isn’t. A business requirement is not something a system must do. It is something that the business needs to do in order to stay in business. For example, it is a process they must complete or a piece of data they need to use for that process or a business rule that governs that process. “The system shall do this or that…” is functional. It is the manifestation of the business requirement in a system. It will change with technology. It usually is subjective. 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 or tweet them or whatever the next new, big thing is. Your business requirements change less, typically, than your functional requirements, they are 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….”.
Who cares? Why elicit business requirements? To help you, and even more importantly, the business itself understand what the business really does or needs to do and what information it needs to do it. Many SMEs get caught up in the day-to-day (and sometimes very expensive) “that’s how we’ve always done it” and forget what their business goals and success factors are. Talking through and documenting the business requirements helps bring that out. It creates “aha” moments. It creates innovation. It creates excellence in business.
I see business analysts’ faces fall when I tell them they aren’t writing business requirements, but rather they are writing functional specifications. But then I see the light bulb go on brightly when they start to realize why they need to understand, document, 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, you can come up with the best solution for that business.
More on Requirements
- Validating Requirements – How do I know I’m not missing anything? - August 1, 2016
- 6 Tips to Identify Business Analysis Red Flags - April 6, 2016
- Choose the Right Decision Criteria - June 23, 2015
- An Entrepreneurial Mindset to Teamwork - August 19, 2014
- Business vs Functional Requirements? Who Cares? - February 27, 2014