What are Business Requirements?

What is...B Oct 18, 2018 4 mins 87054 Views 0 Comments 2 Likes

The purpose of business requirements is to define a project’s business need, as well as the criteria of its success. Business requirements describe why a project is needed, whom it will benefit, when and where it will take place, and what standards will be used to evaluate it. Business requirement generally do not define how a project is to be implemented; the requirements of the business need do not encompass a project’s implementation details.

To illustrate this, one wiki defines business requirements as being “expressed in terms of broad outcomes the business requires, rather than specific functions the system may perform. Specific design elements are usually outside the scope of this document.”¹ Another notes that business requirements “describe in business terms what must be delivered or accomplished to provide value [emphasis theirs].”² BABOK 2.0 (A Guide to the Business Analysis Body of Knowledge, the definitive guide to all things related to business analysis³) states simply that “Business requirements are higher-level statements of the goals, objectives, or needs of the enterprise.” Higher-level is the key term here. Business requirements are what an analyst might show an executive to help him understand the need for the project, not what she would show an engineer to help him build the project. BABOK goes on to state, “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 short, business requirements chart where a project is going, not how it’s going to get there.

To compile business requirements, an analyst must first identify key stakeholders, which will always include the business owners or project sponsors. Very often, they will also include subject matter experts and the end user/customer. BABOK 2.0 describes other stakeholders from whom an analyst may elicit requirements as including regulators (who may impose new regulatory requirements as a result of the project) and implementation subject matter experts (who may be aware of capabilities currently present in or easily added to existing systems). These stakeholders must be thoroughly vetted and interviewed in order to complete a detailed discovery of business requirements. Any existing documentation related to the project must be thoroughly reviewed as well.

To better show what business requirements look like, we will use a project example with which everyone is familiar—buying movie theater tickets. Suppose that a chain of 400 movie theaters noticed a decline in ticket sales. After surveying numerous customers, they found that long lines at their ticket booths were causing customers to choose more convenient means of entertainment. Customers stated that rather than go through the hassle of waiting in line for 10 minutes, they would rather rent a movie or subscribe to a movie rental service. After significant discovery in conjunction with selected colleagues, the chain’s business analyst recommends a solution to let customers buy their tickets online and print them ahead of time, thereby saving time for customers and costs for the company.

The business requirements the analyst creates for this project would include (but not be limited to):

Identification of the business problem (key objectives of the project), i.e., “Declining ticket sales require a strategy to increase the number of customers at our theaters.”
Why the solution has been proposed (its benefits; why it will produce the desired outcome of returning ticket sales to higher levels), i.e., “Customers have overwhelmingly cited the inconvenience of standing in line as the primary reason they no longer attend our theater. We will remove this impediment by enabling customers to buy and print their theater tickets at home with just a few clicks.”
The scope of the project. A few examples might be: “1. While the plan is to bring this project to all 400 theaters eventually, we will start with 50 theaters in the most populated metropolitan areas.”
Rules, policies, and regulations. For example, “We will design our web site and commerce so that all FCC, SEC and other relevant governmental regulations are properly adhered to.”
Key features of the service (without details as to how they will be implemented). A few examples might include: “1. We will provide a secure site for the user to select the number of tickets and showing they wish, and to enter their payment information. 2. We will give the user the option to store his or her card information in our system so that they do not have to re-enter it in a later session. 3. The system will accommodate credit, debit, or PayPal payment methods only.”
Key performance features (without details as to how they will be implemented), i.e., “1. The system will be designed so that it can recover within 30 seconds of any downtime. 2. Because our peak audience has been 25,000 customers in all of our theaters on one night, the system will accommodate at least 10 times that many users at any given time without any impact on system performance.”
Key security features (again without details), i.e., “We will devise a unique identifier for each ticket that will prohibit photocopies or counterfeits.”
Criteria to measure the project’s success, such as: “This project will be deemed successful if ticket sales return to 2008 levels within 12 months of its launch.”

This project’s resulting business requirements would not include:

A description of how to adhere to governmental or regulatory requirements.
A description of how performance requirements will be implemented, such as: “The XYZ server on which customer information is stored will be backed up every five minutes using XYZ program.”
Any description of how the unique ticket identifier would be implemented.
Any details or specifics related to the service’s features, such as: “1. The credit card number text box will be 20 characters long and accommodate simple text. 2. If the user selects Yes (01), the information will be loaded to our XYZ storage server called.”

While the above examples accompanying selected bullet points are textual, business requirements may include graphs, models, or any combination of these that best serves the project. Effective business requirements require strong strategic thinking, significant input from a project’s business owners, and the ability to clearly state the needs of a project at a high level.

As with all requirements, business requirements should be:

Verifiable. Just because business requirements state business needs rather than technical specifications doesn’t mean they mustn’t be demonstrable. Verifiable requirements are specific and objective. A quality control expert must be able to check, for example, that the system accommodates the debit, credit, and PayPal methods specified in the business requirements. (S)he could not do so if the requirements were more vague, i.e., “The system will accommodate appropriate payment methods.” (Appropriate is subject to interpretation.)
Unambiguous, stating precisely what problem is being solved. For example, “This project will be deemed successful if ticket sales increase sufficiently,” is probably too vague for all stakeholders to agree on its meaning at the project’s end.
Comprehensive, covering every aspect of the business need. Business requirements are indeed big picture, but they are very thorough big picture. In the aforementioned example, if the analyst assumed that the developers would know to design a system that could accommodate many times the number of customers the theater chain had seen at one time in the past, but did not explicitly state so in the requirements, the developers might design a system that could accommodate only 10,000 patrons at any one time without performance issues.

Remember that business requirements answer the what’s, not the how’s, but they are meticulously thorough in describing those what’s. No business point is overlooked. At a project’s end, the business requirements should serve as a methodical record of the initial business problem and the scope of its solution.