Chapter 11. Add Supplemental Information to the Use Case Model

This chapter discusses the capture of nonbehavioral requirements and other information associated with an individual use case through the use of supplemental or additional use case details. Some of these supplemental categories have already been considered, but during a development effort they should be revisited, refined, and reworked to ensure that the use cases capture a complete and updated picture of the system requirements. We focus on two specific types of supplemental use case information in this chapter:

• Use case priorities

• Nonbehavioral requirements

• The capture of detailed business rules and procedures

Use Case Priorities

In a large development effort, when there is iterative system development or scope that needs to be controlled and monitored, the establishment of priority relationships between the use cases is essential [Jacobson 1999]. The functionality in some use cases may be more important or critical to the user than that in other use cases. Also, other use cases may depend on a specific use case, so it will need to be developed sooner rather then later.

Use case priorities document for each use case its development priority in relationship to the other use cases. Priorities can be assigned during initial use case definition, but as the use case model is expanded through extend relationships, include relationships, instance scenarios, and elaborated use case descriptions, priorities may need to be revised to guide the development effort. Priorities are normally assigned based on criteria such as risk, architectural coverage, and business priorities.

When assigning priorities, consider the priorities of the extend and include relationships within the larger individual use case family. For example, an individual base use case may have the same priority as other base use cases; however, its extend and include relationships may have varying priorities. If the base use case has, for example, a high priority, but one of its extend relationships is of low priority, the extend relationship can be developed later in iterative development cycle.

The development priority of an alternative flow or an extend relationship is a combination of the priority of its base use case priority and its own priority in the base use case’s family. Assigning a priority to the overall use case can be too “large grain” in an iterative development effort. Some pieces of a use case may be developed in one development increment, other pieces in later increments. When assigning priorities to extend relationships consider the flow or relationship in the context of the overall base use case. For example, in the case of evaluating a loan request, the base use case, “Evaluate loan request,” is considered high priority, but not all its alternative and extend relationships are considered high priority (Figure 11-1). The bank may feel it is critical to have a basic loan evaluation system in place quickly that automates the approval and disapproval of a loan request. For less frequent alternatives, such as approving a loan request conditionally or referring the loan request to the loan committee for approval, the bank can continue to perform them manually, with their automation waiting for implementation until the next increment of the system.

Figure 11-1. Example of prioritized use case and its extend relationships

The priority of an include relationship is evaluated based on the priority of the other use cases that invoke it. An included use case that is invoked by high priority use cases will obviously have a higher development priority than one invoked only by low-priority use cases.

Priority can be described using such techniques as numerical ranking or categories such as high, medium, and low. Priorities are needed especially if an incremental or iterative development of the system is planned. Of course, the focus is on first elaborating the use cases that are of the highest development priority based on the customer’s business need or to minimize development risk.

As a rule of thumb, an included use case should have as high or higher priority than the use cases that include it, since the including use cases depend on the included use case. In situations where the include use case has a lower development priority than the behaviors in the including use case, the included use case will have to be “stubbed in” during development. Extends usually have a lower priority because a project effort tries to get the base functionality in the hands of customers as soon as possible, then it goes back and adds alternative processes.

Nonbehavioral Requirements

Although use cases provide a good mechanism for describing system behavior and functionality, many nonbehavioral aspects associated with an event are not easily captured in the flow of events. Nonbehavioral requirements are not the functions or the behaviors themselves; they are attributes or characteristics of the system behaviors, such as security, reliability, and performance.

Many nonbehavioral requirements specify the global system characteristics, such as portability, overall reliability, maintainability, overall system performance, security, and so on. These requirements should be documented in a global section in the requirements specification. But there can also be nonbehavioral requirements that are specific to an individual use case. They too should be captured and represented as part of the use case description. Like other requirements, nonbehavioral requirements should be business driven and important to the system development effort.

The IEEE [IEEE 1993a] has defined a set of categories for nonbehavioral requirements.

• Performance. Once an instance of a use case is initiated, how long will it take to respond to the actor with results? For example, once a loan application is entered into the system, within what time period is a credit analysis expected to be completed? What is the number of transactions performed in the use case? Within what time frame will the transactions occur? What amount of information is to be processed within certain periods for both normal and peak workload conditions?

The performance requirements may need to be partitioned across the multiple activities and interactions with actors in the use case. Be particularly careful if the use case flow of events contains manual activities, as there may be little control over how fast they execute. Also, the overall performance of a use case depends on how fast automated actors, such as external systems, outside the system responsibility react to requests by the system.

• Capacity. How many instances of an actor will need to be supported in the business environment? For example, how many applicants should be able to apply for a loan concurrently? Is there a business need to grow in capacity? This requirement type can also include the number of terminals to be supported and the number of simultaneous users that are expected to be supported.

• Reliability and Availability. How reliable does the business need the use case to be? Will the use case be expected to execute correctly 99% of the time? How available will the behaviors in this use case be? Will the use case be expected to execute 24 × 7? Will regular downtime be needed for system maintenance?

• Security. Are there any security requirements unique to this use case? For example, is there a need to log specific events, implement an audit trail, or use certain cryptographic techniques?

• Design constraints. Although it is important to avoid premature design during an analysis, sometimes design constraints are unavoidable. For example, the customer may have an existing database or mainframe computer that they require the proposed system to use, or they may have a strong desire to use a Web interface. Only record design constraints that are specific to the use case within an individual use case description. If design constraints are systemwide (i.e., cross multiple use cases), list them in a global section of the software requirements specification (SRS).

While the nonbehavioral requirements are captured in the use cases, their design and realization should be done in the systems architecture. And, as the architecture is defined, more details on the nonbehavioral requirements will emerge. For a good discussion of use cases and system architecture, see Kruchten [1995]. For a great overall work on system architecture, see Rechtin [1991].

See [IEEE 1998a], Leffingwell [2000], Robertson [1999], and Davis [1993] for more information on nonbehavioral requirements. Some nonbehavioral requirements will obviously not be known early in the use case modeling effort. However, be prepared to document them as they become available. A requirements analysis is not complete until both the behavioral and nonbehavioral requirements are known.

Nonbehavioral requirements that apply to multiple use cases—for example, overall loan process performance or capacity—will need to be partitioned across use cases. While the actual partitioning is a system architecture task, this partitioning may impact specific actor needs and other requirements contained in the use case. Dependency streams, discussed in Chapter 15, help to diagram the relationships between the use cases that may point out these cross use case requirements.

Interface Analysis

One of the most critical requirements to capture in system development is the system interface, also referred to as input and output requirements. It is in interfaces that requirements such as capacity and performance are exposed. Interface analysis is an activity that ensures the accuracy and consistency of the interfaces.

In our experience, the lack of well-defined interfaces is one of the major reasons for disappointment down the development road. Without a clear understanding of the interfaces, the successful development of a system architecture is severely handicapped. For each interaction between an actor and the system, consider filling out an interface template (Figure 11-2). These templates will also provide a start in identifying the GUI screens, Web pages, and the system test scripts.

Figure 11-2. Simple interface specification

For each interaction between the actor and the system, determine the system’s responsibilities and document them as steps in the use case. During requirements capture, key issues to address with the external interfaces include the following:

• Are all the restrictions and constraints defined?

• Are all the performance and other nonbehavioral requirements specified and the limits understood?

• What is the criticality of the interface?

• Are the interfaces testable?

• Have all appropriate standards for the interface been defined (e.g., the use of EDI, XML, and so on)?

A sample template for capturing this supplemental on each use case is presented in Figure 11-3, and an example for evaluating a loan request is presented in Figure 11-4.

Figure 11-3. Detailed supplemental use case information

Figure 11-4. Example of detailed use case information for “Evaluate loan request”

Focusing on Behavioral Details of Individual Use Case Activities

Sometimes a use case’s flow of events becomes very long or complex. Rather than have a lengthy use case flow of events, it may be useful to document the details of a particular activity in the flow of events as a separate description. Separating the detailed behaviors from the main flow of events also allows the details of the behavior to be modified, independent of having to change the base use case’s flow of events.

The separate descriptions can occur without a specific motivation to reuse (i.e., the description is not an included use case, referenced across multiple use cases). We refer to these descriptions as activity behavior descriptions. They are not use cases that are invoked from the base use case, nor are they subordinate use cases (discussed in Chapter 15). No actor needs to be involved. Rather, they provide more details (or focus) about an activity in the flow of events. They are not necessary for every activity—only for those that are not yet clearly defined in the use case and require further explanation. The activity behavior can be used only once. If that is determined as reuse, change to a standard include.

We don’t recommend blindly “decomposing” use cases in this manner in an endless fashion, we do recommend limiting the use of this technique to very large and complex use cases that need further detailing.

Activity behavior descriptions are referenced in the base use case’s flow of events by annotations showing where activity behavior descriptions are provided.

We think of activity behavior descriptions as supplemental documentation for representing detailed requirements without cluttering up the use case model. Activity behaviors can have preconditions and postconditions. A sample activity behavior template is outlined in Figure 11-5. For a sample activity behavior description for the “Validate loan application” use case activity, see Figure 11-6.

Figure 11-5. Activity behavior description

Figure 11-6. Activity behavior for validate loan application

Documenting Details of Business Procedures and Rules

An area of some debate within the use case community is how to document detailed business procedures and rules that are within the system’s scope and will occur as part of the execution of a use case’s flow of events.

First, what is a business rule? Business rules are defined as detailed procedures, relationships, and guidelines that drive what the business will do in a particular situation. A system will need to implement these rules if it is to automate the aspects of the business to which they apply. These procedures and rules pinpoint requirements that will need to be captured.

For example, when applying for a loan, what are the rules for determining the interest rate? When evaluating a loan, what are the guidelines governing debt-to-income ratio? Including these rules in the use case can clutter the flow, resulting in an overly long flow of events that is hard to read and has lost focus.

However, rather then lose the business rules as they are discovered, document them in activity behavior descriptions or place them in an SRS or other documentation and provide traceability to and from the use case. For a large system with many rules, it can be most efficient to specify them outside the use cases, as these types of requirements can be very detailed and can be used in multiple use cases.

There may be some rules that come from artifacts other than the use case model. For example, the analysis object model and textual requirements not chosen to be modeled in the use cases are possible sources of rules. Although outside the scope of this book, as the rules become associated with domain objects, document this relationship as well. Traceability is then maintained between the use cases, business rules, and domain objects.

When considering whether to break out an activity behavior, consider the following:

• Are there some aspects of the use case that need to be documented at a greater level of detail than others? If so, use activity behavior descriptions to capture the details of the activities.

• Is the use case getting so large and complex with details that it is difficult to follow at one reading?

• Are there requirements within a use case activity that are highly volatile or changeable? To help maintain the use case model, consider placing them into their own activity descriptions.

• Are there detailed business rules associated with the activity that would be better represented outside the use case flow of events?

When using an activity behavior description, leave enough description of the activity in the use case flow of events so that a user can understand what the activity involves. This helps keep the flow understandable. If readers want more specific details about the activity, they can refer to the activity behavior description.

Another interesting approach for documenting behavioral detail in a use case model is described by Mark Collins-Cope [Collins-Cope 1999]. In this paper, an approach referred to as RSI is used to partition the use case model into three different types of use cases: requirements use cases, service use cases, and interface use cases (RSI), This approach helps organize and structure the detailed information typically contained in a use case model. Requirements use cases describe business processes (but not detailed functionality), interface use cases describe what is presented to the users, and service use cases provide the detailed description of the underlying functionality of the system (very similar to collaboration cases, discussed in Chapter 9).

Conclusion

Information associated with use cases, such as priorities and nonbehavioral requirements, addresses critical requirements associated with a use case but not easily represented in a use case’s flow of events. This information should be captured and documented in associated fields on the detailed supplemental use case information templates. Additional detailed business rules and behaviors can be captured in activity behavior descriptions.