|Product dimensions:||6.00(w) x 9.00(h) x 0.51(d)|
About the Author
Read an Excerpt
Streamlining Business Requirements
The XCellR8? Approach
By Gerrie Caudle
Management Concepts PressCopyright © 2009 Management Concepts, Inc.
All rights reserved.
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 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.CHAPTER 2
The XCellR8 Approach: Identifying Business Events
Abusiness 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 a few years ago, the company had to introduce controls and procedures they previously did not have. These new procedures became new processes. These processes were not prompted by the business, but rather by the system implementation.
When naming an event, do not begin with a verb. That's because an event is not a process — it's a condition or state that must be supported by a process. The process that you eventually define to support the event will be named starting with a verb to indicate action.
Examples of events include:
* A customer makes a bank deposit.
* It is time to open a bank account.
* A delivery truck arrives at the in-gate.
* It is time to enable supplier payment.
* A customer cancels his or her order.
* A department manager launches a project.
If you have identified only one business event in the early stages of a project and can't seem to find others to include in the project, think about whether there are events that oppose the one you've identified. For example, if you have an event called A customer makes a bank deposit, the opposing event is A customer makes a withdrawal. If the event is A delivery truck arrives at the in-gate, the opposing event is A delivery truck leaves the facility through the out-gate. If it is possible for the truck driver to drive out of the in-gate, which would require a different response, then this is a different event from A delivery truck leaves the facility through the out-gate. When identifying events, remember that details matter.
Using Business Rules to Find Events
Business rules are the guidelines that direct the operation of the business requirements. A rule is made up of conditions and actions. It defines what actions need to be taken under certain conditions. These actions can be the start of a new event, an alert, the issuance of a report, a corrective action, or a directive to ignore a condition.
There are different categories of business rules:
* Organizational rules that govern the company from the top, such as bylaws
* Financial rules, such as Sarbanes-Oxley
* Process rules that govern the day-to-day operation of a business, such as hiring procedures
* Production rules that govern product quality, such as product composition
* Commerce rules that govern transactions between the organization and its external partners, such as payment procedures for vendor invoices or procedures for customer returns.
Let's say that the chief financial officer of Sterling Corporation wants to implement some new business rules:
* For contract work estimated at more than $50,000, a business approval request form must be submitted.
* For contract work estimated to take more than 50 hours, a work order must be created.
What are the business events we can extract from these rules?
* It is time to estimate contract work.
* Contract work will cost more than $50,000; it is time to submit a business approval form (BAF).
* Contract work will cost $50,000 or less.
* Contract work will take more than 50 hours; it is time to create a work order.
* Contract work will take 50 hours or less.
You can extract at least five business events from these business rules alone. There may be still more events, depending on what other rules apply when a BAF is submitted or when a work order is created. Once you have identified the business events, develop the event process model for the event, build the event entity relationship diagram, and define the objects and data attributes.
For example, if contract work will cost more than $50,000, ask these questions:
* How do you know that the contract work is more than $50,000?
Answer: There must be a data attribute indicating the contract work value. The value of the contract work is the trigger to the process.
* What information should be included in the BAF?
* Who should submit the BAF?
* To whom should you submit the BAF?
* What will happen if the BAF is not approved? What will the state of the contract work be?
* What will happen if it is approved?
* How many approvers are there? If there's more than one, is there a hierarchy? What rule should be followed to decide on the outcome of the approval process? e.g., If there are two approvers and one disapproves, is the BAF rejected? Should the rule be unanimous approvals only?
* Is the selection of the approver based on the type of contract work? What business rules apply to the selection of the approver?
Case Study: Business Events for a Portfolio Management Project
Identify as many possible business events as you can from the project description below. Compare your answers to the list of business events appearing in Table 2-1. The list identifies only the events that can be extracted from this brief description and could change dramatically during the requirements discovery session.
Kumot Global Services is launching a portfolio management project that will allow the company to keep track of all of its projects. The following conditions — business rules — apply to all of the company's projects:
* A project may be cancelled for a number of reasons: if the budget is not approved, resources are not available, costs are greater than benefits, or the project is deemed high-risk.
* When a project is initiated, the project manager prepares a project plan. This plan must go through an approval process.
* Both internal and external resources may be assigned to a project. Vendors, for example, are external resources. Kumot's current portfolio management project will include vendor invoice processing.
* When an internal resource (a staff member) is assigned to a project, the project manager must make sure the staff person is available to devote time to the project and has the appropriate skills and knowledge to fulfill the assigned role.
* A project's schedule, internal resources, budget, and vendors may change at any time.
* A project is prioritized based on several factors determined by the IT portfolio management department.
* Once complete, the project will be evaluated against the original project plan.
When taking on a new project, it is easy to become overwhelmed and bogged down by details, especially if you cannot determine which ones are relevant and important. The best way to approach any project is to minimize its complexity. This can be done by following the XCellR8 principle of breaking the project down into manageable chunks of work, each based on a single business event. Events are conditions or situations to which a business must respond to achieve some goal. They can be triggered by entities inside or outside the business. They may be based on business rules.CHAPTER 3
The XCellR8 Approach: The Event Process Model
The event process model (EPM), which gives essential details about a business event and the process that supports it, is the most important part of the system documentation for your business partners and users. Business partners and users think in terms of what the system does; system developers consider what data the system must have access to in order to support the business. Business requirements gathering is thus focused on defining processes and identifying objects and their relationships. Your users, however, will naturally want to focus on understanding the process. You can gain their support by creating event process models that demonstrate your understanding of what their systems must do. We'll begin by explaining the components of an event process model.
Excerpted from Streamlining Business Requirements by Gerrie Caudle. Copyright © 2009 Management Concepts, Inc.. Excerpted by permission of Management Concepts Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
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,