CHAPTER 8
The XCellR8™ Approach: The Big Picture

End-to-End Business Scenarios

To comprehend the “big picture”—how multiple systems support an organization’s business processes—analysts must define and document all core and support processes and identify the roles and responsibilities of those involved in each of the business processes.

Illustrating end-to-end business scenarios, one process at a time, shows this “big picture” and is particularly useful for the business group. You can use the swim lane diagram, explained below, or a flow chart to visually represent a process. This is also a good tool to use for peer review.

Using a Swim Lane Diagram

A swim lane diagram (Figure 8-1) strings business events together in sequence and shows who is responsible for each activity associated with the illustrated process. Just to put it in perspective: An event is the situation or condition that the company needs to respond to. A process is the defined response to the event. A process is made up of tasks or activities. Because swim lane diagrams clearly illustrate each involved employee’s role, they can also be used to personalize employee training or to develop a user’s manual customized for a specific role.

FIGURE 8-1: Example Swim Lane Diagram for Asset Management Process

Using a Context Diagram

A context diagram shows interfaces between the target system and external entities. Because it shows how the target system will affect and be affected by the outside world, a context diagram is a good tool for higher-level presentations to the executive or the steering committee of your organization.

The external entities shown in the context diagram might be other systems. The diagram shows the systems’ interaction requirements. It can also show potential dependencies.

All the information needed to build a context diagram can be extracted from the data flow diagrams already developed for each of the events, so it should not take much additional time to create one if you decide to include a context diagram in your requirements document.

Sometimes, a context diagram is all you have to begin your requirements analysis. If so, follow the same approach we have already outlined. You still must identify all the business events, and for each, develop the event process model, build the event entity relationship diagram, and define the objects and data attributes. The bottom line is that regardless of how you begin to gather requirements, you must work with business events as the basic unit of analysis.

Take it one step at a time by extracting a business event from the interaction between one external entity and the target system. For example, look at the interface between the VENDOR and the target system (the Order Processing System) in Figure 8-2 and ask, “Under what circumstance is the purchase order information sent to the VENDOR?” The answer to that question is a business event. Then look at the interface between the CREDIT CARD BUREAU and the target system and ask, “Under what circumstance is the request for credit card authorization issued by the target system to the CREDIT CARD BUREAU?” The answer is, of course, another business event.

FIGURE 8-2: Example Context Diagram

Once you have identified a business event, follow the usual steps.

1. Develop the event process model for the event.

2. Build the event entity relationship diagram.

3. Define the objects and data attributes.

Logical Data Modeling

We can use data modeling to visually depict what kinds of access to data a system requires. When we create an event entity relationship diagram, we are using data modeling. We consider data modeling in general an optional part of the business requirements document because it is part of the design of the system. It’s particularly useful for designers, but it is often irrelevant to the business end users.

A logical data model is a road map that allows us to find the data associated with another piece of data (Figure 8-3). For example, would we ever need to get information about an account if the only information we have is about a customer? If so, under what circumstance (business event) would we need to do that? Is there a way of accessing the account information via customer data or customer identifier?

FIGURE 8-3: Example Logical Data Model

Nonfunctional Requirements

Nonfunctional requirements define the quality of a system, not its behavior. When gathering the requirements from a business user, he or she might indicate a need for a system that will display all the claims made by an insured customer over a certain period. This is a functional requirement. How far back in the claims history the system will search is a nonfunctional requirement.

Nonfunctional requirements are typically documented by the systems architect. They may be included in the business requirements document or in the design document or another document. Below are some common nonfunctional requirements. This list is not comprehensive; new system qualities are continually discovered as technology advances.

• Scalability indicates a system’s ability to gracefully handle growth in volume of transactions or users or the size of its configuration. Scalability is typically difficult to define, and unless a known measure of growth is anticipated within a certain period, numbers are usually speculative. For example, nonfunctional requirements for scalability might read: The system must be capable of handling 300,000 work orders by the year 2020, compared with the current capability of 10,000.
  
  A system that does not suffer any downtime due to this additional load is said to be a scalable system.

• Security indicates that a system is protected against damage or loss. Security may refer to protection from external sources of danger. The system may restrict access to sensitive data to specially authorized personnel only, hence the use of passwords for authentication and authorization. Some security factors to consider include:

  • • Security for sensitive data

  • • Data encryption

  • • Security for corporate confidential data

  • • Security for user access

  • • Security for system administration

  • • Security for public internet.

• Performance, which may be included in the functional requirements, refers to the behavior of the system and its speed. A performance requirement might be stated: “The system shall have a response time to user requests of less than 1,000 milliseconds in all cases.”
  
  Depending on the nature of the desired state, the metrics used to describe performance requirements could differ. For example, if the solution is user-driven, a metric for performance could describe response times. If the solution represents system-to-system interactions, the number of transactions per hour may be a more appropriate metric.
  
  Documenting all performance requirements is quite important because service level agreements tend to be driven by these requirements. For example, if an off-the-shelf software package is supposed to provide a fast response to all system functionalities, that claim should be tested—as part of the proof of concept or system test—against the performance required by the business. One of the factors considered when developing a service level agreement is the level of support the software vendor must provide to ensure performance requirements.
  
  It is also important to identify performance data for both peak and off-peak use of the system. It is possible that the target system will not meet business expectations because of its architecture. For example, the current system may have a local database that enables a relatively fast response time; the new system may require a centralized database that will extend response time.

• Reliability is defined by electrical and electronics engineers as the ability of a system or component to perform its required functions under stated conditions for a specified period of time. This may also refer to the ability of a system to operate under unexpected conditions.

• Serviceability refers to the system’s ability to, where possible, be maintained, upgraded, or replaced without requiring the system to cease operating at any point. This also refers to the system’s disaster-recovery capability, such as in the event of data corruption or total loss of a data processing center. In such cases, what recovery point objective (RPO) and recovery time objective (RTO) should the infrastructure support? RPO defines how much data is lost during the disaster; RTO establishes the number of hours until the system is up and running again.

• Usability refers to user interaction standards to which the system must conform. A usability requirement might be written: “The system user interface shall conform to the ABC Machines GUI standards.”

• Stability refers to the level at which a system can continue to run over a specific period without failing.

• Availability refers to the amount (or ratio) of time that a system is operational. For example, “The system must be available to users 99 hours out of every 100 hours of operation.”

• Capacity refers to a system’s ability to hold and process data and applications.

• System integrity is the condition of a system wherein its mandated operational and technical parameters are within prescribed limits.

• Exception handling refers to system processes that address a condition that might cause the system to stop its normal flow of operation.

• Logging is the ability of a system to give the user a means of identifying, authenticating, and authorizing himself or herself before accessing any function.

• Interoperability is the ability of the target system to interface with other systems within the enterprise.

• Extensibility is the ability of a system to handle additional functionalities or changes to existing ones while minimizing their impact.

• Maintainability is defined in ISO 9126 as the ease with which a software product can be modified to:

  • • Correct defects

  • • Meet new requirements

  • • Make future maintenance easier

  • • Cope with a changed environment.

• Upgradeability refers to the ease with which the system’s configuration can be replaced with newer or more up-to-date technology.

• Deployability is the ability to implement or install a system in different locations without additional constraints or requirements.

• Data retention is the ability of a system to hold a prescribed volume of data within a specified period of time, for example:

  • • On-line data is used in real time.

  • • Near-line data is accessible within an hour.

  • • Off-line data cannot be accessed within an hour.

• Recoverability is the ability to restore your system to the point at which it failed or malfunctioned.

• Internationalization refers to the ability to adapt a system to various languages without making software changes. The opposite of internationalization is localization, which refers to incorporating locale-specific components, such as business rules that apply to only one location, in the system.

• Legal and regulatory compliance refers to the system’s functions that must comply with any existing federal or local laws and regulations (e.g., Sarbannes-Oxley or the Canadian equivalent, Bill 198). The business owner could acknowledge the noncompliance of the system without wanting to make changes, but he or she should be made to sign off on taking that risk.

In Brief

The big picture is not just a nice thing to have. It is critical in ensuring that all the pieces fit together to achieve the vision and the desired goal of the project.

NOTE

1. Kurt Koffka, Principles of Gestalt Psychology (New York: Harcourt-Brace, 1935), 176.