Streamlining Business Requirements

The XCellR8 Approach

Gerrie Caudle

• Publisher: Berrett-Koehler Publishers
• Year: 2009
• Print ISBN:
  9781567262407
• Edition: 1
• eBook ISBN:
  9781567262780
• Topic: Business
• Subtopic: Business Strategy
• Index: Business

Effectively Define and Gather Your Business Requirements Today!
Many programming systems today are designed and constructed before business requirements are completed and finalized. Without a proper foundation, these systems will eventually crumble. Streamlining Business Requirements: The XCellR8™ Approach provides project managers and business analysts with the foundation, principles, and steps needed to document business requirements in an accurate and efficient manner. Author Gerrie Caudle introduces the XCellR8™ approach, an analysis method used to gather business requirements in a structured, well-defined set of steps.
This book offers comprehensive framework needed to:
• Effectively analyze business requirements
• Properly identify business events
• Prepare for a requirements session
• Better understand the "big picture"

CHAPTER 1
What Is the XCellR8™
Approach?

The basic principle of the XCellR8™ approach is reducing a complex project into small, easy-to-understand units. This means taking one small step at a time rather than tackling the whole project in one go. Our analysis will be done on an event-by-event basis, no matter how simple or how complex each event is. A rule of thumb: If an event looks very complicated, it probably consists of many smaller events.

I’ve been accused of making complex things very simple. Clients will say: “Our process seems more complicated than that!” But when all is said and done, it really isn’t. I was asked to present my approach to a potential client one day. I asked questions about the client’s requirements, and after half an hour of Q&A, he argued that I should have written some 20 bullet points on the board; I had written only 5. But he acknowledged at the end of the session that what I had written down were the real requirements.

What Is XCellR8™?

XCellR8™ is an approach that allows you to gather and document your user requirements in a structured, well-defined set of steps. It helps you know what questions to ask every step of the way, identify when information might be missing, and recognize when the requirements analysis is complete.

XCellR8™ is made up of the following steps:

1. Identify all business events. This may be done at a scoping session¹ before the actual requirements session, or during the first hour of the requirements session itself.
2. Choose an event.
3. Develop the event process model (EPM).
4. Build the event entity relationship diagram (EERD) for the objects required by each event, eventually developing a data dictionary.
5. Repeat steps 2 through 4 until each event has been analyzed.

These steps sound daunting and tedious. But once you understand them and begin to put them into practice, you will find that eliciting business requirements has never been easier.

Why Does XCellR8™ Work?

The XCellR8™ approach has eight primary benefits:

1. Starting a project is easy. When you understand the basic unit of analysis used in this approach—the business event—you will find that jump-starting a project is simple.
2. The focus is on the requirements rather than on the solution. The emphasis is on what needs to be done rather than how it will be done. The “hows” are dealt with in the later stages of the system development life cycle.
3. Scope creep—functionality not previously mentioned or recognized by the client—is easily identified. Scope creep can stop a project in its tracks, so it is essential to ask specific, relevant questions during the requirements-gathering process about the scope of the project. Identify what should or should not be considered within scope.
4. XCellR8™ saves time for analysts and users. The approach is focused, disciplined, and streamlined. It allows no time for getting sidetracked or going off on tangents. Such an approach results in a very intense, brain-draining requirements-gathering session. But using XCellR8™, subject matter experts and analysts will likely spend just one-third of the time they usually do on their responsibilities.
5. It facilitates getting users’ consensus. Users’ involvement reduces resistance to change. If the requirements elicitation process is driven by the business side, the business tends to take ownership of the business processes and any changes that must be introduced to the current ones.
6. It results in a complete requirements document. The approach offers completeness tests along the way—not just a simple checklist, but a method that will allow you to determine when all the in-scope processes have been analyzed and documented.
   The resulting business requirements document (BRD) contains all the information the development team needs for the next stage of systems development—functional design. The format of your BRD may differ from the one outlined in Chapter 5, depending on your organization’s standard templates, but the contents should be the same.
7. The translation of business requirements into functional specifications is relatively easy. The content and organization of the BRD allows the business requirements to be easily translated into a design document.
8. Critical mass in requirements definition is achieved quickly. The process-modeling technique used in the XCellR8™ approach is easy to use and understand. The approach allows for the completion of requirements elicitation in a fraction of the time other approaches require. The use-case methodology advocates having more than 80 percent of requirements documented before entering the development phase.² The XCellR8™ approach will allow you to document nearly 100 percent of the requirements.

When gathering business requirements, it is important not to get bogged down by the “hows.” Business requirements are all about the “whats,” not the “hows”: What does your clients’ business require? What problem is the business trying to solve? What does the business need? What information does the business have to get? What do we need to do with the information that we have? What rules does the business have to comply with? What constraints exist?

No analyst wants to be accused of requirements analysis paralysis. To prove that they are making progress, analysts tend to go through this exercise at a very high level, oftentimes designing a system instead of simply defining requirements for it.

To determine the “whats,” you must first define the conditions, situations, or requirements that your client faces day to day. These conditions are called business events, and they are the subject of Chapter 2.

In Brief

In systems development, an approach or strategy is critical in ensuring the success of your project. XCellR8™ is an approach that allows practitioners to conduct the front-end analysis of their project, gather and document user requirements in a structured, well-defined set of steps, and define business needs. XCellR8™ is not a silver bullet that will solve everything, but it will help practitioners elicit and document business requirements in a manner that their business clients can easily understand.

NOTES

1. Scoping sessions are discussed in more detail in Chapter 5.

2. IBM, Rational Unified Process: Best Practices for Software Development Teams (white paper, 1998).

CHAPTER 2
The XCellR8™ Approach:
Identifying Business Events

A business event is, very simply, something that happens in a business. It is a condition or situation to which the business must respond or an activity that the business needs to perform in order for it to reach its goal, accomplish its mission, or achieve its vision.

There are two categories of events: time-driven and external.

Time-driven events happen within the organization and are based on when the enterprise needs to perform them. A time-driven event is an activity that the business needs to accomplish when a certain situation occurs or when the result of another event is in a specific state. It is phrased beginning with “It is time to”; for example, It is time to review a purchase requisition, It is time to cancel a reservation, or It is time to rent a truck. Such events, however, are rarely triggered by time as dictated by the clock. For instance, It is time to open a bank account is really initiated at the moment a request to open a bank account is received from a customer, either when the customer walks into a bank branch or when he or she visits the bank’s website and makes the request.

An externally driven event is triggered by an entity outside the business department or organization. The timing of externally driven events is not necessarily controlled by the business. For example, a product shipment arriving from a supplier is an externally driven event. The shipment may arrive at any time. The organization does have control, however, of the process defined to respond to the event.

Events sometimes occur because a system is implemented, placing new constraints on the organization or necessitating additional requirements. For instance, when a client company implemented a warehouse management system...

Table of contents

• Cover
• Title Page
• Copyright
• About the Author
• Dedication
• Contents
• Preface
• Acknowledgments
• Introduction
• Chapter 1: What Is the XCellR8™: Approach?
• Chapter 2: The XCellR8™ Approach: Identifying Business Events
• Chapter 3: The XCellR8™ Approach: The Event Process Model
• Chapter 4: The XCellR8™ Approach: The Event Entity Relationship Diagram and Data Attribution
• Chapter 5: Putting It All Together
• Chapter 6: The Life Cycle of an Object
• Chapter 7: The XCellR8™ Approach: Completeness Tests
• Chapter 8: The XCellR8™ Approach: The Big Picture
• Chapter 9: Using Use Cases
• Chapter 10: Test Scenarios
• Chapter 11: Business Requirements Traceability
• Chapter 12: Applying the XCellR8™ Approach
• Appendix: Example Business Requirements Document
• Glossary