A business requirement states a high-level business objective of the organization that builds a product or an objective of the customer who procures it. Business requirements describe how the world will be better for certain communities of people if this new product is available. Business requirements generally come from the funding sponsor for a project, the acquiring customer, the manager of the actual end users, the marketing department, or a product visionary. These requirements answer an essential question: "Why are we devoting resources to this project?"

Table 21-1 presents some examples of financial and nonfinancial business objectives (Wiegers 2002b). Business objectives fit into the following categories:

Write your business objectives in a precise, quantitative, and verifiable fashion. Vague objectives such as "world class" or "killer app" are meaningless because you can’t measure whether you’ve achieved them.

In addition to stating business objectives, business requirements could include a concise product vision statement, stakeholder profiles, high-level feature descriptions, project priorities, and a statement of product limitations. Well-defined business requirements are not sufficient to let developers know what to build. However, they set the stage for all the project work that follows. The subsequent levels of requirements details—user requirements and functional requirements—must align with achieving the business objectives. I recommend capturing business requirements in a vision and scope document. A template for such a document is available from http://www.processimpact.com/goodies.shtml and is described in Chapter 5 of Software Requirements, Second Edition.

A business rule is a company policy, an industry standard, or a law or government regulation that defines, constrains, or governs some aspect of the business. Most business rules exist independently from a specific software system. For this reason, I recommend that you document your business rules separately from the requirements specification for a particular product. Treat your business rules as an enterprise-level asset, not a project-level asset. This facilitates reusing the rules, as they’re likely to apply to multiple projects and products. A business rules catalog is a convenient place to collect the rules that affect your applications if they aren’t already documented somewhere else, such as in a body of laws. Several comprehensive books on business rules have been published in recent years (Ross 2003; Morgan 2002; von Halle 2002). See Chapter 9 of Software Requirements, Second Edition for more about business rules.

Business rules would apply even if the business processes were being performed manually instead of with the help of software. This is one way to distinguish a rule from a software requirement. As an illustration, I borrow a lot of movies on DVD from my local library. If a movie I want to see isn’t available immediately, I put my name on the waiting list and eventually I reach the top of the list. Once when I tried to request a movie, the library’s Web site displayed an error message: "Sorry, your library only allows you to have 10 items on reserve at one time. Your reserve list already has 10 items, so you can’t reserve this item now." The software was enforcing a library policy—a business rule. That same policy applied long before the library used computers, when librarians kept track of reserve lists manually. The business rule thus has an existence outside the scope of any particular library software application.

Even if you aren’t building business applications, your products could be subject to business rules in the form of government regulations and industry standards. Electrical products that contain embedded software might require Underwriters Laboratories certification. To obtain this certification, the products must comply with specific safety standards, which constitute a set of business rules. Products that require certification by government bodies such as the U.S. Food and Drug Administration are subject to business rules in the form of laws and regulations. If your product doesn’t conform to the pertinent rules, the federal government won’t approve it for sale in the United States.

I do not regard business rules as being software requirements. Instead, I think of them as the origin of requirements that we need to implement to comply with or enforce the rule. Here’s an illustration. Because of recent concerns about privacy of medical records in the United States, healthcare providers are subject to a business rule (in this case, a government regulation) along these lines:

Again, this rule would apply even if no software were involved. The healthcare provider’s office staff would have to hand the patient a copy of the privacy policy before the patient could receive any care and would have to keep records of who has received the privacy policies.

But suppose your team was developing or enhancing the appointment-management software used in doctors’ offices and you needed to enforce this new business rule. The requirements analyst for the appointment system could derive a variety of functional requirements to comply with the rule, depending on the situation. Following are some possibilities:^[1]

As this example illustrates, the business rule can lead to various sets of functional requirements—and manual operations—depending on the situation. It’s usually not a simple matter of just reiterating the rule and calling it a "requirement." I have seen situations, though, in which the way a functional requirement was written simply restated the business rule, so this can indeed happen. Nevertheless, the business rule is the origin or rationale for the functionality that is generated to comply with the rule. Traceability data is valuable for identifying the origin of functional requirements that the analyst derived from business rules.

Another possibility is that the rule influences exactly how the analyst writes a particular requirement. Suppose you have some requirements that control access to certain functions of your company’s information systems through password controls and user privilege levels. Descriptions of which privilege levels are permitted to perform certain operations will be found in your business rules. So the functional requirements for those operations will be included in the specification, and the rules will govern just how the requirements are written to allow only authorized users to perform those operations.

Business rules could also lead to nonfunctional requirements. Figure 21-1 illustrates how this might work. (This example is incomplete; it merely illustrates the point.) A corporate security policy—a business rule—implies the need for certain integrity requirements, a type of quality attribute. The fundamental underlying integrity requirement, or course, is that the system shall validate that a user is who he claims to be within some small probability of error. The integrity requirements given as examples in Figure 21-1 are intended to help achieve this objective from a practical point of view. (Remember, one person’s "what" is another person’s "how.") The security policy and the integrity requirements lead the analyst to derive functional requirements that will enforce that policy and satisfy those integrity requirements.

Figure 21-1. Links between business rules, quality attributes, and functional requirements.

Note the reuse opportunities provided by broadly applicable business rules and the other requirements derived from them. Reuse at a high level of abstraction—the requirements level—provides greater opportunities for increasing productivity than does code-level reuse. Reuse also facilitates commonality and consistency across applications.

Another category of business rules has to do with how computations are performed. Some computational formulas are dictated by corporate policies, such as:

Other types of computational rules are established by government regulations. Examples include income and sales tax calculations, overtime pay, and Social Security benefits. It’s often clearer to represent computations in the form of mathematical formulas or tables, rather than using natural language text.

Some projects use computational algorithms that reflect the professional judgment of the developers but are not really obligatory. Algorithms chosen for the purpose of implementing some specific product functionality, such as searching data or solving mathematical equations, are not business rules. They aren’t requirements, either. Instead, they’re an aspect of design, in that the developer has selected a particular numerical technique to address a set of requirements, such as calculating a spacecraft trajectory to a certain accuracy level and within a specified length of time. Computations based on laws of nature or physics are neither business rules nor requirements, just design choices. However, if the algorithm to use is dictated rather than left to the developer’s discretion, this constitutes an imposed design constraint, which is a type of requirement.

An easy way to distinguish a business rule from a requirement is to ask whether the statement in question would still apply if the process it addresses were being performed manually. If so, that statement is most likely a business rule. But if not, the statement probably is a software requirement.