An Overview of Business Requirements


With business analysis projects, as with all endeavors, you have to know where you are going before you can chart your course to get there. In other words, before you can decide whether to take a train, bus, or plane, what time of day you will travel, and what you will carry, you have to decide where you are going.

So it is with requirements. Before you can chart how you are going to implement a solution, everyone involved in the development effort must agree on why you need it to start with and that it is the very best solution available. Business requirements are fundamental to any development effort because they define where you are going by articulating the business problem and its solution—why it is needed and how to measure its success.

Requirements Do Matter

An official definition of business requirements is available in BABOK 2.0 (Business Analyst’s Body of Knowledge), the definitive guide to business analysis. BABOK defines business requirements as “higher-level statements of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success.” In other words, business requirements describe where you are going. The B2T blog specifies that business requirements “recognize what is critical to the business, and why it is critical, before trying to develop solutions.”

Business requirements are traditionally developed early in a project because they are fundamental to everything that will follow in the development process. To quote BABOK: “The way the business need is defined determines which al¬ternative solutions will be considered, which stakeholders will be consulted, and which solution approaches will be evaluated.”

To illustrate this, let’s suppose that you work for an organization that handles national disaster relief efforts. Your manager informs you that your organization is expanding its focus from national disasters to also include international events around the globe. Your job is to define the business requirements that will enable this new international division to function efficiently. You determine that the core business requirement is to provide relief for those affected by disaster around the globe in a timely manner. Accordingly, the business requirements would explain the reason for the expansion; i.e., people are increasingly affected by disasters from numerous sources, the needs are just as great, your organization already has many of the resources needed to fulfill them, and so on.

The criteria to measure the new division’s success might be that your medics are on site within 24 hours, and that people receive help within 30 minutes of their arrival, etc. Conventionally, the business requirements would not include such details as the maintenance steps for fueling the helicopters or recruiting and testing medics and other volunteers. You would only state that you need them, effectively including them in the scope of the solution.

Undertand the Business Need

To move forward with charting a solution without adequately exploring a business need through strong business requirements can lead to unfortunate errors and expensive corrections. Yet many organizations (without strong business analysis principles) fall into such a pattern. From BABOK: “An issue encountered in the organization, such as a customer complaint, a loss of rev¬enue, or a new market opportunity, usually triggers the evaluation of a business need. It is common for organizations to act to resolve the issue without investigating the underlying business need. The business analyst should question the assumptions and constraints that are generally buried in the statement of the issue to ensure that the correct problem is being solved and the widest possible range of alternative solutions are considered.”

By way of illustration, imagine that your manager told you to write requirements for installing an ATM in your organization because people need cash to buy lunch in the cafeteria. If you wrote the requirements accordingly and they were implemented at a cost of $10,000, it would be unfortunate for someone to say later, “Couldn’t this also have been accomplished through a simple payroll deduction system? That would have been practically free.” The real business need was not to enable employees to use an ATM on site. It was to find a convenient way for people to pay for food in the cafeteria. If that real business need had been unearthed, all succeeding requirements and development would have gone in a more effective direction.

Using our disaster relief scenario, similar business needs must be examined in order for the project to be most effective. Does the organization automatically assume that medics should be flown in at great distances? Can they be recruited and deployed from local hospitals? Is it possible to set up a global network that can be deployed more cheaply and quickly? What are the quickest, most efficient, most cost-effective solutions to provide the help that people need?

Unearthing the Real Business Needs

So how does an analyst go about unearthing the real business needs that underlie a project?

By exploring your business, its successes and failures, and eliciting as much data as you can from your stakeholders and existing documentation. BABOK refers to this process as enterprise analysis, which it defines as “how business analysts identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business.” You must elicit the why’s of the project from relevant project stakeholders. (BABOK lists possible stakeholders as subject matter experts, customers, end users, project sponsors, and regulators—those who monitor regulatory or government requirements.)

Overview of Business RequirementsAsk: Why are we undertaking this endeavor? What problem is this solution solving? How will we know if we have succeeded? and so on. When you start to hear the same answers repeated, you will know that you have done a thorough discovery. Once you are satisfied with the completeness of your discovery, you are safe to move forward with composing your business requirements and communicating them to your stakeholders for review. (Bear in mind that even the most thorough analyst cannot uncover every eventuality. There are many scenarios that you will not be able to think of, nor will your stakeholders. These are called unknown scenarios. Your job is not to uncover every unknown scenario, but to thoroughly uncover all of the information that is available to you.)

Risks, constraints, assumptions, and success criteria should also be included in your business requirements. (Examples: “A risk that we face is security conditions. If a host country will not let us enter, we will be hindered in meeting the needs of disaster victims,” or “We assume that our existing life support systems will suffice for our international missions and will not need to be re-outfitted,” etc.) Take some time to objectively think through what assumptions, constraints, risks and success criteria. If you think you may be too close to the project to see them, ask an objective peer to review your document.

Having said all of this, be aware that each organization defines business requirements differently. One organization might have its business requirements include not only the direction of the solution, but every detail regarding how to get there. Another organization’s definition might also include technical specifications. Regardless of your corporate culture and its processes, the principle behind business requirements is the same: Do your investigative homework to unearth the real business need, and be sure that all stakeholders have agreed on the business need and proposed direction before proceeding in greater detail. Solid business requirements will make each part of the development process—including succeeding requirements—much smoother.

Author: Morgan Masters is Business Analyst and Staff Writer at, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at

Like this article:
  19 members liked this article


Adrian M. posted on Wednesday, December 16, 2009 11:35 AM
Posted by Moya Bawden on LinkedIn:

Absolutely True. However the concept of overarching knowledge for a project is nearly as old as the holy grail, and pretty much as unattainable.

One way of dealing with reducing the chaos of uncertainty is to define first who and what is out of scope, and inform these groups/processes of the general project and the fact that they are deemed out of scope. That will usually raise a howl if there is an oversight.

I like the six sigma approach of properly defining the problem before determining the solution, and the lean approach of using various kinds of waste as markers to the problem works well. Without facts based assessment we often develop solutions to the wrong problem.

The 'Best' solution is likely to be a compromise between price, time and technical fit, with variable emphasis on usability depending on the voice of the users. It depends on the balance of power in the team where the lines are drawn. And then the business changes mid-project!

It seems that the Agile approach, which provides a disciplined trial, may be a faster route to delivery and satisfaction than the more ponderous SDLC?
Adrian M. posted on Wednesday, December 16, 2009 11:35 AM
Posted by Leslie Munday on LinkedIn:

I did not read anywhere that the author was proposing adopting an approach that required an overarching knowledge of the project. Just, proposing that you know your requirements before you delve into design.

The other consideration, is to prioritise your requirements in order to maximize your ROI early on (makes you look good to the customer). In order to prioritise requirements, one must know what the requirements are, therefore to a certain extent it IS necessary to form an overarching knowledge of the project within its scope, prior to proceeding.

Tony Markos posted on Thursday, December 17, 2009 7:43 PM
Very informative article. Morgan, you state that: "..... be aware that each organization defines business requirements differently." On a requirements listserv fairly recently the question was asked: "What is the difference between business requirements and functional requirements?". Some very experienced people gave some sound answers. Sound but conflicting. A couple of weeks later the debate was still going on. No concensous was ever reached.

Business requirements, functional requirements, business systems requirements, systems requirements, and on and on. A question that needs to be asked: Is is there a need for more than one type of business/functional requirement?

A good data flow diagrammer will answer no. In dfding, all requirements, whether for a completely manual process, a very techo specific process deep inside a computer, the highest level goal by top management - anything that can be stated in a verb phrase - is a functional requirement. Such a convention is critical for larger scale integration efforts.

Tony Markos
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC