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:
Identify all business events. This may be done at a scoping session1 before the actual requirements session, or during the first hour of the requirements session itself.
Choose an event.
Develop the event process model (EPM).
Build the event entity relationship diagram (EERD) for the objects required by each event, eventually developing a data dictionary.
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:
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.
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.
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.
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.
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.
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.
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.
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.2 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).