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.)
Ask: 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 ModernAnalyst.com, 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 http://www.ModernAnalyst.com