CHAPTER 12
Applying the XCellR8™ Approach

Chapter 12 outlines basic applications of the XCellR8™ approach for various projects, including:

• New development projects

• Reverse engineering projects

• Process reengineering projects

• Business process mapping projects

• Enhancement projects.

New Development

When faced with a completely new project, in which the only information you might have is the name of the project, and perhaps its objective, where do you begin your analysis? Use the steps you have learned.

• Identify a business event from the only information that you know: the business objective or project name. For example, if the business objective is to improve the logging of customer complaints, the business event that you can extract from this objective is A customer files a complaint or It is time to log a customer complaint.

• Develop the event process model for this event.

• Build the event entity relationship diagram for the objects you discover.

• Define the objects and data attributes.

If you have the event A customer files a complaint, what is the opposing event? It is A customer cancels a filed complaint. You now have two events. As you continue your analysis, you will surely find other events. Your responsibility is to identify which ones are in or out of scope. Do not worry if an event sounds trivial. It is possible that nobody has analyzed this event because it sounds “dumb,” but you might be surprised by the important data that trivial event reveals.

If the name of your project is “Asset Management Project,” you can extract the business event It is time to manage an asset. If your event contains the words “manage” or “process,” dig deeper; you will discover more specific events. For instance, to manage an asset, you must first procure it, then receive it, assign it, and probably configure it.

Reverse Engineering

Reverse engineering (RE) is the process of analyzing the details of a current system by identifying its capabilities, by using the system itself or by extracting the capabilities from existing documentation. RE is often done if subject matter experts are not available or there are no subject matter experts, or if documentation has not been updated, is lost, or was never written.

This can be a tedious and difficult process if you don’t know anything about the system. You must navigate the system yourself. Where do you start? The same way you would normally begin requirements analysis of any project: Identify a business event from an existing software screen, if any, or from the documentation. For that event:

• Develop the event process model for the event.

• Build the event entity relationship diagram for the objects you discover.

• Define the objects and data attributes.

From the original event, discover the others, beginning by finding opposing events.

Process Reengineering

This approach is aimed at reviewing current processes and introducing improvements that will lead to greater efficiency and effectiveness. Business process reengineering is also known as business process redesign (BPR), business transformation, or business process change management.

You cannot improve a business process unless you articulate it first to determine what you are dealing with. The simple exercise of reviewing processes usually leads to discussion of immediate improvements that can be made to the manual process, as well as changes that can be effected by automation.

When reviewing current processes, you go through the same steps you would follow for new development and reverse engineering:

• Identify the event the process is responding to.

• Develop the event process model for the event.

• Build the event entity relationship diagram for the objects you discover.

• Define the objects and data attributes.

Business Process Mapping

This method is used to define exactly what a business entity does and when, who is responsible and accountable for its processes, and how the success of a business process is measured. Mapping may be done for one business area or the entire enterprise. Business process mapping is the same thing as documenting the current environment. To define exactly what a business entity does, you must identify which business events the business area needs to respond to. Once you identify these events, you follow the same steps:

• Develop event process models for the events.

• Build event entity relationship diagrams for the objects you discover.

• Define the objects and data attributes.

Enhancement

When you begin an enhancement project, you will probably already know what the system does, why the enhancement is being made, and to what part of the system the enhancement should apply. Accordingly, the business events may be a little easier to identify for this kind of project.

So do you need to use the XCellR8™ approach to analyze requirements for such a small initiative? For example, if you are being asked to change the characteristics of a specific data attribute, do you need to go through the process of identifying the event, developing the event process model, building the event entity relationship diagram, and defining objects and data attributes? Maybe. This might be a good opportunity to discover the gaps in your knowledge of the system and any system defects. Changing the characteristics of a specific data attribute may not be a huge task, but identifying the impact of this change on the rest of the system could be. You must determine whether changing this data attribute will affect any other part of the system. You can do this by looking at every event the data attribute participates in.

This is why traceability is very important. If documentation has been produced showing traceability of the requirements by objects (hence, by data attributes), it will be easy to tell which other events and processes might need to be reviewed and changed as a result. If you do not conduct such a review, you are very likely to encounter some huge errors at implementation time.

In Brief

Whether your project is small or a multimillion-dollar initiative, you need a process that is repeatable and predictable (no matter what the application is) and that will allow you to define your project’s business requirements in a structured, disciplined manner. The XCellR8™ approach allows you to do that. The extent to which you use it will depend on your own personal level of comfort with the process and your own soft skills (e.g., your ability to interact with higher-ranking professionals, your willingness to ask questions) and the complexity of your project.