Introduction

How many times have your business partners told you that their project is of the highest priority and that they needed it “yesterday”? And how many times have you been told that there is no need to define requirements because the project is “very simple”? Figure I-1 depicts why clearly defined requirements are necessary: All project stakeholders and team members must have a clear understanding of client needs to be successful.

Why do businesses tend to ignore the gathering of business requirements? Frequently, they do not know what business requirements are. They may also claim that they do not have enough time. They firmly believe that in the time it takes to analyze the requirements of the business, they can design and develop an automated system. While this might have been true in the past, when a business needed six months to a year to complete business requirements, this kind of thinking is no longer acceptable.

XCellR8™ helps you gather business requirements in an average of ten days, depending on the complexity and size of the project—hence the name XCellR8™ (accelerate). The approach you’re about to learn also facilitates consistent results and offers a standardized method for “interviewing” users.

FIGURE I-1: Why Complete Business Requirements Are Essential

Today, it is not enough to ask users what they want or need. To be successful, one must know:

What further questions to ask

What to listen for when answers are given

When to ask questions

Where and how to document the answers

What to do with a requirements document moving forward.

The resulting business requirements document—which should be comprehensive, accurate, and independent of any particular technology—may likely be the only “stable” document you’ll ever have for your project. It does not need to change, unless the business itself or the business objective changes.

What Are Business Requirements?

So many definitions of business requirements have been proposed that it is obvious that business analysts often struggle to differentiate requirements and design specifications. A business requirement is something a business requires a manual or automated system to do to satisfy a driver, such as the business’s operation, vision, principle, or mission. Requirements do not mandate the use of a particular kind of technology; good business requirements must be independent of any technology bias.

The following characteristics of requirements are universally recognized:

Requirements are not obvious.

Requirements can come from many sources.

Requirements may not always be easy to express clearly in words.

Requirements are hard to elicit.

Requirements gathering (also called requirements elicitation) can be tedious and time-consuming because business users:

• May not always know what they want

• Do not always clearly express their needs

• Aren’t always available

• May have a hard time communicating with a requirements analyst, especially if the analyst tends to use a lot of technobabble.

Most importantly, requirements can change over time for a number of reasons, including new business objectives or changes to the project scope or business case. Requirements should not change to align with a chosen solution, however; rather, differences between requirements and a chosen solution should be identified as gaps or workarounds, or they should be considered when drafting future standard operating procedures (SOP). In these cases businesses sometimes must accept a chosen solution even if it doesn’t align directly with requirements (e.g., a generic software package is purchased to automate existing business processes, but to save costs and time, no modifications are made to align the new software to specific aspects of the system).

What Makes a Business Requirement Good?

A successful business requirement should be verifiable, traceable, unambiguous, correct, complete, and implementation-free.

Verifiable. A requirement is verifiable if there is a finite, cost-effective process with which a person or machine can check that the product meets the requirement.

Traceable. Traceability allows the business to track the development of a requirement all the way to a specific implemented part of a system. When a system feature or functionality cannot be traced back to a business requirement, it is likely that the business requirement was misunderstood initially during elicitation. The reverse is true, too, when a business requirement is not satisfied by a system feature or functionality. Traceability also allows for a more efficient testing because the requirement is linked to appropriate test scenarios and test cases.

Unambiguous. A requirement is said to be unambiguous if it has only one interpretation. This means the requirement must be described in a definitive way that includes the data required, the business rules surrounding the process, the roles required to perform the process, and the conditions under which the process is to be performed.

For example, a process description of how a product is ordered from a supplier may simply state, “The system must be capable of generating a purchase order.” This capability statement might seem very simple and succinct, but when analyzed further, a number of questions arise: When does this need to happen? Who is authorized to do this? What business rules apply to this process? What data are required at the start of the process? What data need to be recorded at the end of the process?

Instead, the requirements should begin by specifying that the company should order a product from a supplier under the following conditions:

• The product has reached an inventory level lower than the allowed threshold.

The buyer responsible for a specified product issues a requisition for the product.

These conditions serve as triggers to the business event, Order a product. Each trigger may require a specific process. Each process must be defined in a precise, unambiguous manner. For example, for the first trigger, reaching a lower inventory level than is allowed, the process description may read something like this:

For each product whose quantity on hand has reached a level lower than the allowed threshold (for example, 100 units), determine the following about the product to be ordered:

Name

Description

Effective product price

Effective date of the product price.

Find the following information about the certified supplier of the product:

Name

Address

ontact information.

Determine the quantity of product to be ordered.

Create a purchase order (PO) for the product, identifying the following:

Date the PO is created

Who created the PO

Product ordered

Quantity ordered

Unit price of the product ordered

Supplier of the product

Date by which the product must arrive

Terms of payment.

Send the purchase order for review to the buyer responsible for purchasing the product. This review may result in a confirmation or revision of the PO.

This process description does not leave anything to the imagination. The second trigger, the buyer issuing a requisition for the product, may require a different process altogether, but you can detail the process just as the example above shows.

Correct. A requirement is only as correct as the project stakeholders and subject matter experts say it is. A requirement may be correct for one stakeholder and incorrect for another. When this happens, further investigation is warranted to determine what requirements will satisfy the company’s vision, goals, and project charter.

For example, in a supply chain project, the goal might be to standardize the ordering processes across all the distribution centers. A requirement might state, “The system must order products from any warehouse for distribution to a store.” Upon analysis, this system may appear inefficient and uneconomical because stores might end up getting the product from a warehouse that is 100 miles away when the same product is available in a warehouse that is only 20 miles away. The requirement should then be reevaluated.

Complete. Chapter 7 includes a series of tests you can use to verify the completeness of requirements and processes.

Implementation-free. Good business requirements do not specify solutions. Business requirements are not system requirements. They should be business-driven, not system-driven. Solutions that drive requirements are called derived requirements, and they are not considered business requirements because the business doesn’t necessarily need the particular capability or product to function. For example, a company selects a software package to replace its legacy warehouse management system. The new software can accept only one unit of measure, either imperial or metric. A derived requirement of the replacement initiative, therefore, is the capability to convert all measurements into one unit of measure—which is not something the business had in mind initially. This derived requirement indicates that the initial requirements-gathering process and subsequent software evaluation did not uncover this gap until much later on in the development cycle.

The Requirements Phase

Typically, the requirements phase starts when a problem is discovered and someone recognizes that it requires a solution. It can also start when a new idea for a product is proposed. The problem may be as simple as a system that is not user-friendly; you then need to determine what will make it so. Or it can be as challenging and complex as completely revolutionizing the business.

The Requirements-Gathering Process

Many analysts begin the requirements-gathering process by populating business requirements templates in documentation software before they even have a process for gathering the information the templates call for! As a result, they end up with documents that are likely full of assumptions and unverified requirements—or worse, speculative requirements, requirements that the analyst speculates should be included in the scope of the project based on his or her own knowledge of the project.

Filling out a requirements template is relatively easy if you have the information you need and understand what the information will be used for. But if you don’t, you still need a process to gather the business requirements—one that you can use over and over again no matter what the application is and no matter what industry you’re working in.

The primary reason for gathering business requirements is the occurrence of a business event, which is when something happens in the business to which the business needs to respond. A business event triggers a process, which is the business’s response to the event. A process must have a result, an outcome related to the event.

Processes may vary from one company to the next. The requirements analyst should document whatever process will allow the organization to achieve its goals.

Each business event requires an event process model (EPM) to support it. The EPM is composed of a data flow diagram (DFD) and a process description, the accompanying descriptive text. The DFD shows the sequence of tasks and activities the organization must perform to support the business event. It also shows the objects or information that the process requires, as well as the information that the organization needs to retain when the process is complete. An object is a person, place, thing, or concept. It is something that participates in a business event and contains essential information required by a process.

The entity relationship diagram (ERD), also known as the logical data model (LDM), complements the EPM. The ERD illustrates how different objects that support a business event or meet a business objective are related to each other. The relationships between objects are articulated as one (1)—a single, one-to-one relationship—many (N), or none (0). These object relationships are shown on the ERD. For each business event, a mini-ERD, which we call the event entity relationship diagram (EERD), is created.

The EERD is considered a working tool, so it does not have to be included in the final requirements documentation. The EERD helps the requirements analyst determine when the business requirements have been fully documented; understanding and documenting relationships between objects can reveal new business events that might not have been apparent at the beginning of the analysis.

Finally, the context diagram shows the external interfaces with the target system. The context diagram shows the “big picture,” so it’s often presented to the organization’s executives to show how the target system affects the whole enterprise.

A Good Requirements-Gathering Process

A client wanted to determine why none of his team’s project implementations had been successful. We reviewed the most recent documentation for each project and interviewed representatives from each of the project teams. What we discovered was not surprising. Every one of the unsuccessful projects had undefined requirements, missing requirements, or misinterpreted requirements, or the requirements were still being developed while the system was being constructed.

For every failed project, the team did not know how to gather the requirements and did not know when the requirements gathering process was complete.

How can you avoid this situation? By following a good business requirements elicitation process. Your process is more likely to succeed if:

It has structure and discipline. The process should provide steps to follow when eliciting requirements, as well as procedures that will help maintain control.

It is predictable and repeatable, regardless of the application or project.

It can forecast the requirements phase. The process should have a mechanism that can accurately estimate the length of time it will take to complete the elicitation.

It has process transparency. Everything done during the elicitation process and delivered at its end should be visible to every participant.

The participants agree to use the process. The requirements elicitation process itself should not be controversial. It should be focused on the project at hand.

It has a set agenda. This goes hand-in-hand with structure and discipline. A good requirements elicitation session should not degenerate into a free-for-all discussion. Participants should follow the agenda, complete the discussion, and deliver results.

The participants are fully engaged. Everyone attending the requirements elicitation session should think that he or she has something to contribute and should feel free to speak up.

The expected deliverables are completed. The participants’ expectations must be established at the very beginning of the session.

It provides a mechanism for verifying the quality of the documentation. Participants can use this mechanism to review the resulting business requirements documentation for accuracy. This mechanism can also be used to check updates to the documentation after the review process.

It is measurable. After defining benchmarks, such as the participants’ satisfaction with the requirements process and its results, you should be able to measure the success or failure of the requirements elicitation process.

The resulting documentation is organized, at least according to the organization’s standards.

The analysis of business requirements adheres to a reasonable standard of quality.

It is led by one facilitator. Multiple facilitators tend to distract participants, who then become confused about whom to listen to or get guidance from.

Improving the Efficiency of the
Requirements Elicitation Process

The process of eliciting and documenting business requirements must be explained to those participating in the requirements elicitation session. Each participant needs to understand his or her role in the meeting, what must be delivered at the end of the session, session logistics, how detailed the discussion will be, and what he or she should do to prepare for the session.

Stakeholders who participated in the process should agree that the process was worthwhile and their time was well spent.

Every analyst assigned to the project needs to recognize what is expected of him or her before, during, and after the session and must optimize time spent on the requirements-gathering session.

The project team and any other interested party should be able to go back to the requirements document if any enhancement or update is necessary.

During the requirements-gathering process, all expected deliverables should be identified so that stakeholders and project team members are not blindsided with a document that doesn’t really reflect the client’s needs. For example, a client decided to purchase a software package and the project team relied on the functional flow document produced by the software vendor as their requirements document. Instead of eliciting requirements and writing a business requirements document (BRD), they used the vendor’s functional flow document to determine what the client wanted. The result was a system that required nearly a $5 million modification; this could have been avoided if the project team had taken the time to elicit requirements and use the BRD as their benchmark.

The requirements-gathering process is just the beginning of discovering everything that you should know about a project. A positive, efficient requirements process will help smooth the transition to the next phase of system development.

Determining What the Client Needs

The following are some of the most common approaches to determining clients’ needs. They can be used in any industry.

A requirements discovery session (RDS), also known as joint application development and joint requirements planning session (JRPS). RDS (or JRPS) is a forum in which all project stakeholders and subject matter experts (SMEs) meet to discuss the project’s goals and what must be done to achieve them. RDS is the most effective approach for getting consensus, discovering various options for performing the business processes, and understanding what other people in the organization are trying to accomplish.

This approach, however, does not work without good—or even excellent—facilitation. If the meeting devolves into a free-for-all, nothing will be accomplished or resolved. Brainstorming is a good way to get a variety of ideas, but without appropriate control, the results may not be useful.

Interviewing. The interview approach is one of the most widely used. The requirements analyst (the interviewer) meets with the user or SME (the interviewee) for a one-on-one interview. This approach works well if the interviewer knows what questions to ask to glean the requirements and how to document the answers. Later, the interviewer and interviewee can review the information documented and revise it as necessary.

Problems can arise, however, if there is more than one interviewee or interviewer for the project. Different interviewees may provide conflicting answers; different interviewers may have differing questioning styles. Also, the interview process can be time consuming, lengthening the requirements-gathering process.

Surveying. Requirements analysts should formulate appropriate survey questions that are based on the needs of those who will complete the survey. This is where the challenge begins. Questions should be simple and easily understood by everyone receiving the questionnaire but specific and detailed enough that good requirements can be extracted from the responses.

Frequently, respondents do not return surveys within the allotted time or do not answer questions they do not understand. Sometimes, responses necessitate follow-up questions, drawing out the process—the requirements analyst will have to devise even more questions, which still may not yield the needed answers.

Prototyping. In this context, prototyping refers to designing a user interface that the client can use to help articulate his or her data and process requirements. This approach is often used by requirements analysts who come from a development background. It is also very popular among business users who prefer visual rather than written processes.

Remember that user expectations are very difficult to manage. Users tend to believe that if a prototype exists, the system should be able to work now—not tomorrow or a year from now. Also, whenever you use prototyping to elicit business requirements, you will spend a lot of time talking about how the system should work rather than about what the system should do, resulting in analysts designing rather than defining the business needs.

Shadowing. Job shadowing, in which the analyst follows a user around as he or she does his or her day-to-day activities, works well if your intent is to document the current environment. But if you are trying to gather requirements for a system that will be implemented in the future, job shadowing will narrow your vision to what is happening and how things are done today, especially if the automated system already in place doesn’t align with longterm business strategies and goals.

In Brief

For as long as I can remember, there has been a debate as to whether the top-down approach to system analysis is better than the bottom-up. Do you want to see the big picture first and then decompose that into smaller pieces, or do you want to see the pieces, then put them together to make a big picture?

I don’t suggest a resolution to this debate in this book. I suggest instead that we approach the problem with whatever information is available to us at the time. People tend to complete tasks in a manner that makes sense and is easy to follow. As we gather information, however, we gain insight from different situations, conditions, and events that crop up along the way, leading us to more questions and an improved analysis of the system at hand.

In terms of functionality, data storage, and desired results, computerized systems are similar to the human brain. Computerized systems must store data to support various conditions and circumstances. These circumstances and conditions are called business events. In the XCellR8™ approach to gathering business requirements, each business event (or business condition) stands alone and is treated independently from other events.

We learn important information incrementally and not necessarily sequentially, and we don’t always learn everything we need to know about a business event or an object at once. An event-based approach to requirements analysis like XCellR8™ employs incremental data attribution for objects, allowing each event and all of its components to be specified and documented incrementally as new, needed knowledge becomes available.