Business Requirements: Foundation for Success   

By Joy Beatty, Vice President, Seilevel and Karl Wiegers, Principal Consultant, Process Impact   
imageProject teams sometimes gloss over a project’s business requirements in their haste to begin developing the product. They do so at their peril. The term “business requirements” refers to a set of information that, in the aggregate, describes a need that leads to one or more projects to deliver a solution and the desired business outcomes. Business opportunities, business objectives, success metrics, and a vision statement are key elements of the business requirements. Without a shared understanding of the business motivations for undertaking the project, it’s impossible to clearly decide what is and is not in scope as you go along.
Business requirements issues must be resolved before the functional and nonfunctional requirements can be fully specified. The business requirements provide a reference for making decisions about proposed requirement changes and enhancements. We recommend displaying the business objectives, vision, and scope highlights in every requirements elicitation session so the team can quickly judge whether a proposed requirement is in or out of scope for a given release or development iteration.
Identifying Desired Business Benefits
The business requirements set the context for—and enable the measurement of—the benefits the business hopes to achieve from undertaking a project. Organizations should not initiate any project without a clear understanding of the value it will add to the business. Set measurable targets with business objectives, and then define success metrics that allow you to measure whether you are on track to meet those objectives.
Business requirements might come from funding sponsors, corporate executives, marketing managers, or product visionaries. However, it can be challenging to identify and communicate the business benefits. Project teams sometimes don’t have access to those who set them, so the team members aren’t exactly sure what the project is intended to accomplish. There could be multiple important project stakeholders who don’t agree on what the objectives should be. The business analyst can help ensure that the right stakeholders are setting the business requirements and facilitate their elicitation, prioritization, and resolution of conflicts.
The business benefit has to represent a true value for the project’s sponsors and to the product’s customers. For example, simply merging two systems into one is not a reasonable business objective. Customers don’t care if they are using an application that involves 1, 5, or even 10 systems. They care about issues like increasing revenue and decreasing costs. Merging two systems might be part of the solution, but it is rarely the true business objective. Regulatory and legal compliance projects also have clear business objectives. Often, the objectives are phrased as risk avoidance, possibly to avoid getting sued or being put out of business.
Product Vision and Project Scope
Two core elements of the business requirements are the product vision and the project Software software requirementsRequirementsscope. The product vision succinctly describes the ultimate product that will achieve the business objectives. This product could serve as the complete solution for the business requirements or as just a portion of the solution. The vision describes what the product is about and what it ultimately could become. It provides the context for making decisions throughout the product’s life, and it aligns all stakeholders in a common direction. Chapter 5 of Software Requirements, 3rd Edition suggests a keyword template for writing a concise, focused vision statement. The project scope identifies what portion of the ultimate product vision the current project or iteration will address. The statement of scope draws the boundary between what’s in and what’s out for this project or iteration.
The vision applies to the product as a whole. The vision should change relatively slowly as a product’s strategic positioning or a company’s business objectives evolve over time. The scope pertains to a specific project or iteration that will implement the next increment of the product’s functionality, as shown in Figure 1. Scope is more dynamic than vision because the stakeholders adjust the contents of each release within its schedule, budget, resource, and quality constraints. Scope for the current release should be clear, but the scope of future releases will be fuzzier the farther out you look. The team’s goal is to manage the scope of a specific development or enhancement project as a defined subset of the strategic vision for the product.
fig 1
Figure 1. The product vision encompasses the scope for each planned release, which is less well defined the farther out you look.
Vision and Scope Document
The vision and scope document collects the business requirements into a single deliverable that sets the stage for the subsequent development work. Some organizations create a project charter, a business case, or market requirements document that serves a similar purpose. This deliverable does not have to be in the form of a traditional document. You can think of it simply as a container that holds the business requirements for the project, in whatever form you choose to store them. We’ll say “document” just for convenience.
The owner of the vision and scope document is the project’s executive sponsor, funding authority, or someone in a similar role. A business analyst can work with this individual to articulate the business requirements and write the vision and scope document. Input to the business requirements should come from people who have a clear sense of why they are undertaking the project. These individuals might include the customer or development organization’s senior management, a product visionary, a product manager, a subject matter expert, or members of the marketing department.
Figure 2 suggests a template for a vision and scope document. As with any template, adapt this to meet the specific needs of your own projects. If you already have recorded some of this information elsewhere, do not duplicate it in the vision and scope document. Some elements of the vision and scope document might be reusable from project to project, such as business objectives, business risks, and stakeholder profiles. An annotated version of this template, with embedded guidance, is available at
fig 2
Figure 2. Suggested template for a vision and scope document.
The time you spend developing a clear set of business requirements is a small investment in setting the direction for a successful project that delivers the desired business value. It will be worth every minute.
Author Bios: Joy Beatty is a Vice President at Seilevel, Karl Wiegers is Principal Consultant at Process Impact, Karl and Joy are co-authors of the new book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.