Chapter 1

Introduction to Elicitation

In This Chapter:

Business requirements are elicited by conducting interviews, workshops, note-taking sessions and feedback loops, and quality reviews with various sources to capture business requirements, user and stakeholder expectations, and system constraints and assumptions. Typical elicitation techniques, which are discussed in detail in Part III of this book, include:

Workshop sessions. Formal working sessions with users, business and technical subject matter experts, and project team members and led by a facilitator. The goal of workshop sessions is to gather as much information as possible from a diverse group of subject matter experts to begin to drive consensus on the functions and features of the solution.

Brainstorming. A process that is used extensively in requirements workshops to generate creative and innovative ideas.

Interviewing. Systematic attempt to collect information from a person or group of people in an informal or formal setting by asking scripted questions.

Surveys. Administration of a written set of questions to multiple stakeholders to determine information on customers, work practices, and attitudes.

Documentation reviews. The review of existing system, business policy, and contractual documentation.

Interfaces reviews. The review of system, people, and process linkages external to the proposed business solution. System interfaces define system interactions—which systems provide input, which ones require output, and what medium is used.

What Elicitation Is Not

The elicitation process occurs at the beginning of the requirements phase, as described in the business solution life cycle depicted in Figure 1-1, which is our common framework for developing new business solutions.

Elicitation does not typically produce models—although it sometimes does.

Elicitation does not specify the requirements attributes—although some attributes, such as requirement source and owner, may be identified during elicitation sessions.

Elicitation does not deliver full documentation—it is only the beginning.

Figure 1-1—Business Solution Life Cycle

Business requirements expressly state the needs that a new/changed business solution must meet for the solution to successfully take advantage of a business opportunity or solve a business problem. Business requirements, then, are driven by and derived from the specific business value needed to achieve organizational goals. All too often, project teams begin by focusing on the solution before truly understanding the business requirement. Requirements elicitation activities are designed to give the project team an understanding of the business environment and to gather the customer and user needs that the project outcome is expected to satisfy. Good requirements elicitation practices provide the foundation to effectively analyze, specify, document, and validate the requirements.

Terminology

Prior to discussing the processes for planning requirements activities and eliciting requirements, it is prudent to establish a common lexicon.

Business System

A business system, also referred to as a business solution, is comprised of all the elements that are necessary to make an organization operate, including: (1) business rules, policies, and procedures, (2) business processes that flow value through the organization to the customer, (3) organizational entities who own and operate the business system, (4) geographic locations of the organizational entities, (5) data that flows through the business processes, (6) application systems that support the operation of the business processes, and (7) technology infrastructure supporting the applications. The development of a new or reengineered business solution may involve changes to some or all of these business system components.

Requirements Types: Functional versus Supplemental

Business requirements are defined as those activities that must be performed to flow value through the organization to the customer. Business requirements are expressed first in terms of business objectives, and are then defined as a set of functional and nonfunctional requirements. Functional requirements define the behavior that is required within the business solution to deliver business value to the organization. Functional requirements are the features, services, tasks, and functions supported by the solution.

Functional requirements describe what needs to be performed, not how the solution will meet the requirements. As an example, a functional requirement may state that a user needs to withdraw cash from an ATM. The what is “withdraw cash.” A functional requirement does not describe how the function will be provided in terms of hardware, software, and documentation components. Elements of the solution will be designed and constructed to support the functional requirement later in the project life cycle.

Nonfunctional, or supplemental, requirements provide additional information that imposes constraints that may modify the business solution behavior. They describe the appropriate levels of supportability, maintainability, security, or usability needed to satisfy a specific requirement. All too often, the nonfunctional requirements are overlooked early in the project. This often results in business systems that are costly to maintain and difficult to operate, thus eroding the business value of the solution.

When discussing requirements, it is helpful to clarify whether the requirement is a functional requirement or supplemental requirement. Table 1-1 shows the differences between these two types of requirements.

Table 1-1—Functional versus Supplemental Requirements

Functional Requirements Characteristics	Supplemental Requirements Characteristics
Are things the solution must do	Are things the solution must have
Describe user-required behavior	Constrain or modify the solution behavior
Are also called behavioral requirements and are often represented in “the solution or system shall” statements	Are also called nonfunctional, and often constrain the behavior of the functional requirement
Can be documented in text, graphical, or matrix formats	Can be in text or matrix formats
Are free from system specifications, constraints, or design assumptions	Constrain the solution design

In addition, it is helpful to use industry-wide conventions when describing requirements:

Business requirements use the word must. For example, “The accounts payable cycle time must decrease by 20% as measured from the preproject metrics.” Note that business requirements cannot be coded.

Functional requirements use the word shall. For example, “The accounts payable system shall allow users to make modifications to the payment terms.” Note that functional requirements can be coded.

Assumptions use the word will. For example, “Only internal users will use the accounts payable system during the first release.” Note that assumptions cannot be coded, but add clarifying detail to functional requirements.

In addition to eliciting functional and nonfunctional requirements, the business analyst elicits information on business rules, which are the policies, guidelines, regulations, and procedures that govern how a system must respond to perform a function. As an example, in an insurance reimbursement system, business rules describe the formal criteria used to determine whether payments should be made for services and the level of reimbursement, depending on the insurance agreement.

Requirements assumptions and constraints are also documented by the business analyst.

Together the sum of requirements documents and models define the characteristics of the required solution, but do not say how the solution will implement those requirements.

Project versus Product Requirements

People tend to use the terms requirements and scope interchangeably. They are related, but they differ in important ways. Project scope is defined by The PMBOK^® Guide² as the work that must be performed to deliver a product, service, or result with the specified features and functions. It is the sum total of the work breakdown structure (WBS) activities. A WBS is a graphically oriented representation of project scope. Activities are identified and organized hierarchically to show the sum of the project work to be performed.

When a WBS is used by a project team to identify the scope of the project, it effectively depicts the breadth and depth of the project work by presenting a deliverable-oriented grouping of activities. Senior management and customers can quickly review a WBS to see ifthe project team caught the vision for which the project was initiated. Corrections to scope in the early stages of the project are inexpensive, since the solution is not yet designed or constructed. Since project scope represents all the activities needed to plan, execute, control, and close a project, the project manager is responsible for managing the full scope of the project within quality, cost, and time constraints.

Business analysts, on the other hand, are responsible for product scope, meaning the features and functions that will be included in the new business solution. Product scope is defined by the PMBOK^® Guide⁴ as the features and functions that characterize a product, service, or result. The product scope combined with the project management deliverables (e.g., project plans, reports, schedules) and solution development deliverables (e.g., design documents, test plans) together comprise the full project scope. Table 1-2 shows the difference between project scope and product scope.

The Business Requirements Document

The elicitation deliverables are the notes and various models developed during elicitation sessions and typically captured in an early draft of the business requirements document (BRD). The BRD contains the information that clarifies the functions of the solution for both the business and technical stakeholders. Ideally, organizations create a methodology providing a step-by-step approach to creating business requirements that are captured in a predefined BRD template (see Appendixes A and B for sample BRD templates). Customers review and validate the BRD to confirm that it accurately represents their needs, subsequently agreeing to fund solution design and construction. IT architects, design analysts, developers, and testers use the requirements documentation to begin their solution design and development activities. The requirements in the BRD are expressed in natural language to describe the needs, wants, and behavioral requirements of the solution. A BRD:

Table 1-2—Project versus Product Scope

	Project Scope	Product Scope
Lead Roles	Project manager	Business analyst
Deliverables	Project plans Project monitoring and control Project reporting Replanning	Requirements management plan Business requirements User acceptance

Translates business objectives and needs into requirements statements

States needs in a manner that is solution independent

Contains text, graphical, and matrix documentation

Conforms to enterprise standards

Is consistent with the product development methodology of the organization

Is sometimes referred to as a product vision document

A BRD is not:

A system specification, which comes later, in the design phase

A business case, which comes earlier, in the preproject enterprise analysis phase

A project plan, which is often created at the same time the requirements are being documented, because it is difficult, if not impossible, to prepare a complete project plan without an understanding of the requirements and a high-level concept of the solution that is to be constructed. Figure 1-2 depicts the two primary consumers of the BRD.

Statement of Work

The initial draft of the statement of work (SOW) is often first crafted by the business analyst during the elicitation process and finalized during requirements analysis, specification, and validation. The SOW is defined as a contractual document that outlines the expectations (requirements) of the customer and authorizes the performing organization to begin work. The SOW is often used as a component of a contract when the design and development of the solution is outsourced to a third party. There are several common issues with the SOW that the business analyst seeks to resolve:

Figure 1-2—Primary Consumers of the BRD

The requirements are often ambiguous, inaccurate, and incomplete.

The customer does not participate in reviews to validate and further define the requirements stated in the SOW.

The performing organization wants to begin immediate work against the SOW without validation of the requirements.

When Is Elicitation Complete?

At the conclusion of the elicitation activities, the business analyst leads efforts to review and refine the draft requirements statements and models before commencing the requirements analysis activities. The business analyst often conducts reviews with both the customer and technical subject matter experts to verify that the requirements are complete and ready for rigorous analysis. The reviews are designed to validate that the initial set of requirements are:

Clear. All stakeholders agree on what the requirements mean and terms are understood and documented.

Consistent. The requirements do not conflict with any other stated requirements or formal project documentation.

Complete. The breadth of the functions and features to be provided is fully understood and captured (the depth will be progressively elaborated during analysis, specification, and final documentation activities).

Validated. The requirements can be linked to an upstream customer or sponsor document that initiated the project; the business and technical teams have reviewed and approved the breadth of the requirements.

After requirements are elicited and initially documented, they drive all downstream analysis, design, development, and testing activities. Often, once a team of users, customers, and managers has drafted requirements, organizations expect development teams to immediately begin designing and developing the solution. However, requirements must still be analyzed, decomposed, documented in multiple forms, and further elaborated to ensure they are accurate, complete, and unambiguous before being released to downstream phases (refer to Getting It Right: Business Requirement Analysis Tools and Techniques, another volume in this series, for more information). During requirements elicitation, an iterative approach is recommended. Note taking and numerous feedback loops are performed often to determine if the requirements are fully understood.

Summary

Business requirements document the capabilities a new business solution must provide to achieve business objectives.

Functional requirements describe what a solution must do or how it must behave.

Supplemental requirements, also called nonfunctional requirements, are performance characteristics that the solution must have; supplemental requirements may constrain how the system behaves or modify how the user interacts with the system.

Requirements can be captured through text, graphically, or in matrixes.

Requirements describe what the solution must do, not how it will do it; in other words, requirements are solution independent.

The elicitation effort can be considered finished when the breadth of requirements is complete, consistent, correct, and unambiguous.

Requirements are accompanied by assumptions and constraints.

Project scope includes both the product and project deliverables to be provided by the project.

Product scope is defined as the solution components that are built to satisfy the features and functions outlined in the BRD.

The initial draft of requirements documentation is the outcome of the elicitation process.

The BRD summarizes the functional and supplemental requirements that must be satisfied to meet the business objectives.

A statement of work (SOW) is often used as a requirements document when outsourcing the design and/or development of the solution.

Action Plan for the Business Analyst

Separate the categories of requirements in requirements templates.

Include assumptions and constraints in requirements documents.

Have peers check to determine if the requirements are high quality and complete in breadth.

Create a defect checklist for all templates that lists common requirements errors.

Document all requirements-related terms, enterprise acronyms, and business domain language in an appendix to the requirements document or in a separate glossary.