Business Requirements vs Functional Requirements? Who Cares?

Ali Cox

Ali Cox

Business Requirements vs Functional Requirements? Who Cares?
Share
Share on facebook
Share on twitter
Share on linkedin

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.

Enhance your elicitation with our Requirements Gathering Techniques Quick Tip.

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.

Get a deep dive into data analysis with our Detailing Business Data Requirements class.

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

Editor’s Note: This blog post was originally published in February 2014. Due to its popularity, Ali has completely revamped and updated its content to be more comprehensive and accurate for the state of today’s environment.

More on Business Analysis

Join our #AlwaysLearning Community

About the Author

Ali Cox

Ali Cox

Alison (Ali) Cox, Netmind Senior Instructor and General Manager, has experience since the mid-1980s in various areas, including business analysis, project methodology development and training, systems development (mainframe, client-server, and web), and telecommunications management. Alison began her career in the financial services area, and then moved into systems development for accounting systems. She has provided consulting and training in business analysis and project management for small companies to Fortune 500 corporations worldwide and speaks Spanish fluently. Alison is also a partner of TEMSS (Telecommunications Efficiency Management Strategies and Services), which provides telecommunications efficiency auditing and billing analysis services to clients in all areas of business across the United States. She completed her Master of Business Administration in MIS and Accounting from the University of Georgia. Connect with Ali on LinkedIn.

14 Responses

  1. Yes, clear difference between what business does and what it might need a system to do in support.

    the next question: is a functional requirement still stating what a system should do, but not how? I would say ‘what, not how’, but in practice it might not always be clear. Take your initial example:,it mentions a ‘how’ in email, but the requirement is to automate its use and does not state how to do it; there could be a few different ways to do it.
    It is a fine line, and requiring a specific solution should be avoided.

    1. Absolutely right.

      I understand (and agree with) the reasoning behind separating Functional and Business Requirements, but we shouldn’t mix Functional and Non-Functional requirements.

      Business Requirements, for me, explain the “why” of Functional Requirements – e.g. we need to get away from a dog
      Functional Requirements describe what a system should do (not why or how) – e.g. run
      Non-functional requirements describe how it should do it – e.g. run (yes, but) fast

      N.

    2. I agree David, when defining the requirements, the BA does not solution the system, they should define the Who, what, when, where but not the how as that is for the development team to determine.

      Additionally, a complete user story includes the value of the need.

      As a Product Owner, I want our customers to receive an automated email each time they purchase a complimentary product, so that the customer receives an acknowledgement of the purchase and sees additional offers.

  2. I think that the functional requirements are the ‘how’ from the user view – and to me, options that the users are aware of (like email communication, twitter, texts, etc.) should be part of those requirements. If they have to interact, they need to be involved in the decision as to the method of interaction. It IS sometimes a fine line, but good communication within the project will usually get you on the right side of it.

  3. I agree with both posts however, for simplicity sake, I have learned to use the two words “What” and “How” when articulating the difference to project team memebers. Business requirements articulate “What” problem must be solved while the Functionional requirements provides “How” the problem may be resolved – often providing options broken out by cost or level of effort to deliver. I had a boss many years ago who introduced me to the idea that these two documents (project artifacts) must be “married” in a stakeholder meeting where Technology Leads are asked to sell to the business stakeholders “How” the various solutions shall solve the “What”.

    As a team, the optimal solution is agreed. It is also during this meeting of minds where you may uncover some “aha” moments, whereby the team may further clarify both the requirements (including both the “What and the How”) and, thus, fine tune the ultimate solution.

  4. That’s great Carl – I agree and do the same thing. I find that the business loves getting to the “What” if you do it efficiently. They learn a lot about themselves. Then they are more participative in the “Hows” and take ownership. It’s a beautiful thing 🙂

  5. Carl its a very good explanation, but in real time most of our projects are having either business requirement or functional requirement due to the project schedule. As mentioned most of the people do not care about the importance of a functional requirement.

  6. Ali I appreciate your article but I agree with David. Fast forward from the date this article was first published, today’s literature supports that when it comes to functional requirements we have to be very careful…Functional requirements state what features the business would need out of system to meet their business objectives. When we start talking about how, we start to design and in many cases, we limit the possibilities the solutions architects can work with because of this explicit how to…I understand the importance of co-designing but not to the extend of limiting where that solution can go, which is a risk the functional requirements start answering how to do it.

    When I read the title of the article I was excited to use as a reference to explain to my customers the importance of the difference between the business and functional requirement, I will refrain from doing so. I have spent many years trying to educate my customers to take the design out of the functional requirements and to keep the focus of what is required to meet the business needs… I tell my customers the functional requirements answers the question of “What” is required of the systems. The technical design, not the functional requirements answers the question of “How” to do it.

    1. Completely agree, I find the wording in the blog post misleading. Functional requirements indeed specify “what the system should do”. The example given (“The system shall facilitate the automation of email to the customer.”) is very badly chosen because it does not contain any true “what”. Both “email” and “automation” are, sadly, solutions. It’s what I like to call “solutions masquerading as requirements”. Without context, at best, the “automation” could be seen as a non-functional requirement because it imposes a constraint on the design (emails should be automated and not manual).
      The “how” stems from the high level design and not from requirements. We need to conduct a thorough interviewing process with the Business in order to get to the true “what”s by working back from what they initially tell you, which is, more often that not, “how”s (solutions).

  7. Miguelina, I see your point. The problem I see that could emerge from that is that the customers end up with something that they don’t want to use. Like I said, a very fine line. None of this is done in a vacuum without communication and coordination, but I think I need to know if a customer will, for example, want an email versus text versus some other new technology. If I leave that totally up to the technical team without the perspective of the customer, I might end up with an unusable product. I use the user centered design concept where the functional and technical requirements, while separate, are closely coupled so that the design ends up being usable to that end user. We can agree to disagree though!

Leave a Reply

Your email address will not be published. Required fields are marked *

Almost done!

Please check your email to confirm your subscription.

Join our #AlwaysLearning Community

Onsite Training Request

Please provide the information below to help us to customize your solution. 

Contact Us

Netmind US
296 South Main Street, Suite 300
Alpharetta, GA 30009-1973
T. +1 (678) 366.1363
F. +1 (678) 366.1983

Office Hours:
Monday – Friday, 8:30-5:00EST

General Inquiries:
info@netmind.net

Sales Inquiries:
sales@netmind.net

Request Information