CHAPTER 7
The XCellR8™ Approach: Completeness Tests

You have learned so far that the business event is the basic unit of analysis to start with when eliciting business requirements. For the documentation of the business event to be complete, it should include the following information:

1. Event name

2. Process name associated with the business event

3. Trigger(s) to the process

4. Process description, written in business terms

5. Information required to support the business event

6. Rules governing the response to the event

7. Relationships among the data participating in the event

8. Actor(s) in the process.

Completeness of a Business Event

To help assess the completeness of a business event, you can use the business requirements assessment chart (BRAC; Table 7-1) in combination with the checklist above.

TABLE 7-1: Business Requirements Assessment Chart

Is Your Event Process Description Complete?

To assess the completeness of an event process description, ask the following questions:

• Does the business logic work? Do you see holes in the logic? Does the process have a start and an end, or does it go in an endless loop?
  
  For example:
  
  1. The legacy system downloads the item data into the outbound directory.
  
  2. The middleware picks up the file from the outbound directory and loads it into the new system.
  
  3. Go back to 1.
  
  This endless loop states the intent of the process is to keep downloading the file, but should the process really be endless? Instead, the system should send a signal indicating that the file has been received successfully to end the process.

• Is the business process documentation easy to read and understand? Remember who your audience is.

• Can the process description stand on its own? A process description should work as an independent unit.

• Is it detailed enough? The correct level of detail depends on what the business requirements document will be used for. If it is going to be used in support of a request for proposal, it may need to be just detailed enough to validate the vendor’s proof of concept. A proof of concept is a way of demonstrating an idea. In systems development, a proof of concept demonstrates that a system performs as claimed, usually against business requirements. If the BRD will be used as a development document by an outside organization, the more details, the better.

Completeness of Business Requirements¹

Once you’ve completed each of the following steps, your business requirements should be complete.

1. An initial list of events has been compiled.

   An initial list of events should be drawn up early on, when you are scoping the project. This will help define the project charter,² determine how many potential events are within its scope and the complexity of each event, and identify the different lines of business or areas that will be affected, who the stakeholders will be, and who should be invited to the requirements session. Most important, it will help establish the business case by identifying which of the events will help you realize business goals, as well as which ones might pose a greater risk to undertaking the project.

   Scoping a project is not a trivial exercise, but it should not take longer than two or three days, depending on the complexity of the project itself. Scoping may substitute for a requirements session if the project is small with few events to analyze.

2. Opposing and complementary events have been found.

   When you identify one business event during scoping, the opposing event is often ignored. Sometimes this is because the opposing event is not allowed as part of the daily business operation or it is deemed impossible. Sometimes it is just forgotten.

   As the analyst gathering the business requirements, it is your responsibility to look for complementary events to known events and determine whether they are in scope.

3. All the object relationships in the EERD are complete.

   An event entity relationship diagram may reveal object relationships that will lead to additional, as yet undocumented business events. These events tend to be ignored because users say they do not or cannot happen. But it’s essential to analyze all possible events involving the objects we’ve discovered. For example, in our simple purchase order system, we discovered the objects Supplier and Product. According to the event entity relationship diagram (EERD) in Figure 7-1, a Product may be provided by one or many Suppliers. What if we need to order the product from a Supplier? If the product can be ordered from more than one Supplier, how do we know which Supplier should be used for this order? Are there any business conditions (events) that dictate the use of a particular Supplier, such as the supplier’s ranking based on its previous year’s performance? If so, we are missing the supplier ranking as a data attribute, as well as a business event that allows us to rank the Suppliers. Our business requirements will not be complete until we capture and analyze this information.

   

   FIGURE 7-1: Entity Relationship between Supplier and Product

4. All the in-scope “zero” situations in the EERD have been accounted for and analyzed.

   If you were to review the relationships in Figure 7-1, would you find a Supplier who will never supply a Product? If the answer to this question is yes, the relationship from Supplier to Product will be represented as 1, N, 0 (zero). A “zero” situation in any EERD relationship represents at least one potential business event. There could be many circumstances under which a “zero” situation applies. You must identify which situations are in scope. In what situation (business event) would you have a record of a certified supplier who has never provided your company a single product? How did that supplier become a supplier? Perhaps there are suppliers who became certified but were never used because they went out of business before they could be used. Determine whether this business event, A certified supplier is out of business, is in scope. It could lead to the de-certification of the supplier.

5. CRUD analysis of the objects is done.

   Determine where each object is created, read (used), updated, and deleted. Remember that each object must participate in more than one event. If you have an object that is created but is not used or updated in another event, it may not be required at all. (Note that the other event does not necessarily have to be in the same system.) So why bother creating it? Similarly, if you have an object that is being read or updated but is not created anywhere else, you must have missed an event. If you determine that the creation of this object is out of scope, so be it. The object could be the responsibility of another project or business area, or perhaps it is part of another system. But it’s important to know where it is created.

6. CRUD analysis of the data attributes is complete.

   Whenever I mention this task to business analysts, I hear a collective groan. Analysts think it is a tedious exercise because a large amount of data must be reviewed. Why should we bother with this analysis? Because it allows you to determine which event creates, reads, updates, and deletes each data attribute. If a project you are working on requires a certain piece of data that is not yet available, you will have to define a business event that will create this data attribute. If you have not defined events corresponding to all data attributes, your requirements are not complete.

   Similarly, if you must enhance a system by changing a data attribute or an object, a CRUD analysis of the data attributes shows clearly which events require the data attribute and thus may need to be reviewed and changed.

7. An event for each possible object status has been identified and analyzed.

   The status of an object tells us a lot about the processes that the business requires. For example, an object called Claim, with possible statuses that include “approved,” “rejected,” “paid,” “returned to sender,” “closed,” and “reopened,” corresponds with seven business events:

   • It is time to review a Claim.

   • A Claim is approved.

   • A Claim is rejected.

   • A Claim is paid.

   • A Claim is returned to sender.

   • A Claim is closed.

   • A Claim is reopened.

These must be analyzed if they are within the scope of the project. If they are out of scope, determine where and when they are performed so that you know who is responsible for them.

NOTES

1. Completeness tests apply only to the business requirements and not necessarily to the derived requirements—those requirements called for by the chosen solution.

2. The project charter defines the scope of the project, its business objectives, and project stakeholders, and it authorizes undertaking and funding the project.