Use Case Analysis

Purpose and Implementation













Abstract: This document attempts to answer questions concerning the implementation of Use Case Analysis into a project scope. It attempts to answer questions such as what is a Use Case, how is one created, what does it contain, how do you write one, what is a Use Case Model Survey, what does it look like, what does it contain, and what is it used for? Also included are style guidelines on writing Use Cases.





















J. Mark Shacklette















Table of Contents





1. Use Cases

1.1 Pros

1.1.1 They assist in Requirements Capture Activities

1.1.2 They provide a contractual delivery process

1.1.3 They serve as an easily-understood communication mechanism

1.1.4 When done thoroughly, they make it difficult for functional pieces of the system to “fall through the cracks”

1.1.5 They provide a basis for functional requirements tracing

1.1.6 They provide a concise summary of what the system will do at an abstract (low modification cost) level.

1.2 Cons

1.2.1 They introduce functional decomposition into OOA/OOD

1.2.2 Because of the line drawn in the sand between Use Cases and Objects, there is a definite increase in the probability that one Use Case will make unwarranted assumptions about the underlying implementations of another Use Case.

1.2.3 They make it difficult to move to “object discussion”

1.2.4 They can actually hinder reuse at the object level

1.2.5 While good at capturing functional requirements, they are cumbersome in collecting non-functional requirements, such as technical requirements.

1.2.6 There is ambiguity as to what requirements are “outside the scope of” the Use Case Model Survey

1.2.7 Testing from Use Cases is often a vague undertaking

1.3 Solutions

1.3.1 Smooth the road from functions to objects

1.3.2 Establish firm procedures for reuse

1.3.3 Establish firm procedures for both Unit Testing and System Testing

1.3.4 Categorize the objects that participate in a Use Case

2. Use Case Analysis

2.1 Use Case Model Survey

2.1.1 Participants

2.1.2 Inputs

2.1.3 Actor Glossary

2.1.4 Task Description

2.1.5 Finding Use Case Packages

2.1.6 Describing the Use Case Packages

2.1.7 Actor Identification

2.1.8 Use Case Identification

2.1.9 Use Case Relationships

2.1.10 Review Readiness Criteria

2.2 Use Case

2.2.1 Participants

2.2.2 Inputs

2.2.3 Task Description

2.2.4 Review Readiness Criteria

2.2.5 Style Guidelines

  1. Use Cases

    1. Pros

Use Cases have been heralded as the end-all and be-all of modern Object Oriented Analysis. They basically grew out of the scenario diagrams that were often used during functional decomposition in standard structured analysis over the past several decades. In 1994, Ivar Jacobson published a definitive Use Case book called Object-Oriented Software Engineering: A Use Case Driven Approach. Since the publication of that volume, and the subsequent adoption by Rational of Jacobson’s “Objectory” process, Use Case Analysis has come to the forefront of Object Oriented Analysis. Use Cases provide a number of important benefits:

      1. They assist in Requirements Capture Activities

Use Cases are an excellent tool in requirements capture. They allow the customer and the developer to come together and determine the functional requirements of the system.

      1. They provide a contractual delivery process

Since all functional requirements are contained within the Use Case Model Survey, the collection of Use Cases can serve as a contract between the customer and the developer, signifying exactly what will be delivered.

      1. They serve as an easily-understood communication mechanism

Use Case artifacts are written in informal English, and are written to be easily understood by customers, developers, testers, marketing staff, and others.

      1. When done thoroughly, they make it difficult for functional pieces of the system to “fall through the cracks”

If the functional analysis task of Use Case development is done thoroughly, Use Cases will contain all of the functional requirements of the system, making development easier because it is based on a defined set of directions.

      1. They provide a basis for functional requirements tracing

Use Cases provide a means of tracing functionality throughout the development process. A functional requirement that is delivered in code should be able to be traced back to a particular Use Case.

      1. They provide a concise summary of what the system will do at an abstract (low modification cost) level.

Use Cases provide a fairly concise view of what the system will do when it is complete. Since no code nor design exists within a Use Case, modification of the system at this level, i.e., changing what the system will do, is quite easily done and the cost is minimal. This is in contrast to changing design (rose models, class diagrams) and code.









Next, the System Operator Actor’s dog Fifo introduces a design object into

the Analysis Phase.

Figure 5: FIFO Example





    1. Cons

      1. They introduce functional decomposition into OOA/OOD

Functional decomposition and object-oriented analysis are somewhat unhappy partners. Functional decomposition defines what the system will do, while OOA functions around defining the abstract “objects” or “entities” that interact within the system. In fact, because you want to achieve an economy of modification (see 1.1.6 above), Use Cases tend to talk about objects very little. This antagonism makes the marriage of OOA and Use Case Analysis often difficult. In short, functional decomposition approaches tend to localize information around functions, not objects. Objects and functions simply do not map to each other on a one-to-one basis.

      1. Because of the line drawn in the sand between Use Cases and Objects, there is a definite increase in the probability that one Use Case will make unwarranted assumptions about the underlying implementations of another Use Case.

The problem here is that the OOA goal of “loosely coupled” objects is broken. When one object depends too much on the internals of another object (as opposed to the other object’s interface), thus breaking another cardinal rule about information hiding, the system becomes brittle and vulnerable when changes are introduced.

      1. They make it difficult to move to “object discussion”

At some point, you need to move from Use Cases to actual object identification and design. Use Cases do not provide a simple path of migration from their functional analysis approach to the object decomposition approach of OOA. This shift in focus (which must take place at some time during the lifecycle) often results in the introduction of significant errors.

      1. They can actually hinder reuse at the object level

Most egregious, since Use Cases are discrete and non-overlapping (usage and extension notwithstanding), reuse at the class and object level can be hindered by each developer “taking a Use Case and running with it”. Since Use Cases by definition do not talk about “objects”, developers often wind up in a vacuum during object analysis, and can often wind up reinventing the wheel several times.

      1. While good at capturing functional requirements, they are cumbersome in collecting non-functional requirements, such as technical requirements.

Technical requirements, such as performance measurements, fit awkwardly into a Use Case Flow of Events.

      1. There is ambiguity as to what requirements are “outside the scope of” the Use Case Model Survey

Because of the above, non-functional requirements left out of the Use Case Model Survey are often forgotten if there is not a rigid procedure in place to maintain them.

      1. Testing from Use Cases is often a vague undertaking

It is a commonplace to hear discussion about “testing from Use Cases”. However, when you query a testing group about regular, systematic, and effective testing, you often get blank stares. This is because the Use Case only provides information on what to test, not who, when, where, how, and why to test it. Again, testing the functionality is fairly straightforward, but unit testing the particular implementations, as well as testing the non-functional requirements, is not as obvious.

    1. Solutions

      1. Smooth the road from functions to objects

It is imperative that the move from the functional decomposition activities of Use Case Analysis flow seamlessly into the Object identification activities of OOA.

      1. Establish firm procedures for reuse

Procedures for reuse must be firmly in place, or the lack of reuse will infiltrate the project at a variety of levels. Coding standards and design procedures must be firmly in place and understood by everyone involved in the development process.

      1. Establish firm procedures for both Unit Testing and System Testing

Strict testing procedures must be in place to avoid blank stares at the end of the development cycle.

      1. Categorize the objects that participate in a Use Case

Split the functionality of each use case into interface objects, entity (persistence) objects, and control (system) objects. Here, the more modular, the better. Isolation of interface is the key.



REMEMBER, THE PRIMARY GOAL OF USE CASE ANALYSIS IS COMMUNICATION. Specifically, communication of:



  1. system requirements

  2. how the system is to be used

  3. the roles the user plays in the system

  4. what the system does in response to the user’s stimulus

  5. what the user receives from the system

  6. what value the customer will receive from the system

  1. Use Case Analysis

    1. Use Case Model Survey

The Use Case Model Survey lists all the actors and use cases in the system.

      1. Participants

Use Case Model Surveys involve the following participants:

  1. Business Domain Expert

  2. Application Developer

  3. Analyst/Designer (Use Case author)

  4. Architect (Use Case Survey Author)

  5. Testing Engineer

      1. Inputs

        Artifact

        Use

        Non-Functional Line Item Requirements Document

        Allocation to each of the Use Cases to ensure coverage.

      2. Actor Glossary

One of the first outputs of the Use Case Process is a Glossary of Actors. The Actor Glossary contains a list of all the participating Actors (external users and systems) in the system. It is a non-necessary artifact, because the same information must be included in the Use Case Model Survey. To find actors in the system, you look for all types of external stimuli which interact with the system. This includes human beings, as well as external systems, external APIs, and hardware. You name and briefly describe each actor. If there are any inheritance relationships between the actors, they should be mentioned here. You provide each Actor discovered with a very clear unique name which delineates the ROLE the Actor is playing when interacting with the system in this particular context. Describe each named Actor such that it is obvious what the Actor’s responsibilities are with respect to the system.

      1. Task Description

The purpose of the Use Case Model Survey is to illustrate the universe of functionality that the system is to deliver, at the highest level. The Use Case Model Survey consists of a diagram-based document that contains a list of Use Cases with a summary (brief description) and list of participating Actors associated with individual Use Cases. The Use Case Model Survey is used at a very high level to ensure that system responsibilities and LIRs have been covered and allocated to manageable units of work.

The tasks for developing the Use Case Model Survey include:

  1. Actor analysis

  2. creating (optionally) Use Case packages

  3. Creating Use Case Model Diagrams

  4. identifying candidate Use Cases

  5. briefly describing each of the Use Cases.



Figure 5: Sample Use Case Model Survey (condensed)

An Actor is anything that interacts with the system. Actors may be the roles that human users, external hardware, and other systems (which may not necessarily be legacy systems) play while interacting with the system. The main difference between a user of the system and an Actor is that an Actor represents the role the user plays in interacting with the system, rather than an actual physical user.

You should refrain from equating Actors with job titles, types of users, or something traceable to an organization chart. Keep an open mind and try not to artificially inhibit the Use Case driven approach.

If you find that you need to use packages, the package-level context shows the system as a “black box” and all the Actors that interact with it. With the UML notation, this “black box” is first represented with a package named “System.” Within that package there should be (recursively) one package for each Use Case Package of the system, if applicable.

Figure 5 Use Case Package Diagram for System

Figure 5 Use Case Package Diagram for Business Application

A Use Case Package is a grouping of similar uses of the system.

The Use Case Model Survey illustrates all the Use Cases that compose each of the Use Case Packages using a Use Case Diagram per Use Case Package (see Figure 5 Use Case Diagram), the Actors associated with each of the Use Cases within a Use Case Package, a brief description of each Use Case, and (optionally) the LIRs allocated to each Use Case.

Figure 5 Use Case Diagram

The use case model survey is not complete until all the system behavior has been assigned to use cases. All requirements in the Line Item Requirements document must have been accounted for in the use cases. Each concrete use case must interact with at least one actor. Each use case must have a manager associated with it. The customer must agree and understand the names and descriptions of each use case. The end product is a first draft of the use case model survey.

      1. Finding Use Case Packages

To find Use Cases:

  1. Find the tasks that each Actor performs when interacting with the system.

  2. Find the CRUD activities: Create, Read, Update, and Delete

  3. Find if any Actors informs the system of any external changes

  4. Find if any actor requires notification of any system occurrence

  5. Look for patterns of common uses of the system; e.g., Core Business Functionality, Technical Architecture. These patterns yield candidate Use Case Packages.

  6. Identify Central Subsystems.

      1. Describing the Use Case Packages

  1. Create hierarchies of packages to account for all the Use Case Packages.

  2. Allocate Actors to each of the Use Case Packages at the appropriate level of detail.

  3. Create a package diagram for Use Case Packages that further specialize into additional Use Case Packages and illustrate any associations (i.e., communication, uses, or extends) and/or dependencies that exist among the co-operating Use Case Packages.

  4. Illustrate the Use Cases, Actors, and any of their associations using a Use Case Diagram per Use Case Package.

  5. Describe the responsibilities of each Use Case Package.

      1. Actor Identification

        1. Finding the Actors of the system

The purpose of finding the Actors is to:

  1. Determine who and what communicate with the system.

  2. Define the limits of the system. What is contained within the system, and what is outside the system.

  3. Provide a basis for discovering the Use Cases.

To find the actors in the system:

  1. Look for all types of external stimuli which interact with the system.

  2. Name and briefly describe the Actors.

  3. Establish any generalization (inheritance) associations between Actors, if necessary. These associations are typically not utilized until the Analysis Activity.

        1. Name and describe each Actor

  1. Provide each Actor with a very clear unique name which delineates the role the Actor is playing when interacting with the system.

  2. Describe each named Actor such that it is obvious what the Actor’s responsibilities are with respect to the system.

  3. Do not overburden any given Actor with too much responsibility.

  4. Place both the Actors’ names and descriptions in the Glossary of Actors, if using one. Otherwise, they belong in the Use Case Model Survey.

      1. Use Case Identification

        1. To find the Use Cases of the system, determine

  1. The tasks that each Actor requires the system to perform. This may influence both the description of the Actor and the Use Case.

  2. Whether each Actor needs to create, read, update, and/or delete any data to/from the system which commonly referred to as “CRUD”; Create, Read, Update, and Delete.

  3. If any of the Actors informs the system of any external changes.

  4. If any Actor requires notification of any system occurrences.

        1. Name and describe each Use Case:

Each use case needs to have a unique name, which should be made up of both a noun and a verb. Good examples are Log Information, Manage Configuration, Present Data, Accept Input, Handle Error, Provide Security, etc. Each use case should have a description that describes the interaction between the associated actor(s) and the system. If the use case is an extends use case, you should specify which use case is being extended and under what conditions the extension occurs. The same case applies with uses use cases. Designate whether each use case is an abstract or concrete use case.

In short:

  1. Provide each Use Case with a unique name which describes (in a few words) the main theme of the Use Case. Good names typically have both a verb and noun.

  2. Briefly describe each Use Case. The description should be consistent with the Domain Object Model and the Glossary of Terms.

  3. If the Use Case extends another Use Case, specify which Use Case it is extending and under what conditions the extension is to occur.

  4. If a Use Case uses another Use Case, specify which Use Case is to be used.

  5. Designate each Use Case as being either concrete or abstract.

      1. Use Case Relationships

There are two special types of Use Cases: extends and uses. The Unified Modeling Language (UML) 1.1 defines each as follows.

        1. Uses Association

If TWO OR MORE Use Cases contain the exact same behavior, that common behavior can be extracted into a separate use case. The new Use Case that contains the common behavior is said to be a uses Use Case. A uses Use Case is not aware that it is being used by other Use Cases and does not necessarily represent a complete, standalone flow of events. This is the only Use Case type which is free of that requirement. An extends Use Case and a uses Use Case are said to be abstract Use Cases, and all other Use Cases that are self-contained and complete are said to be concrete use cases, in that they are actually instantiated by a particular actor(s).

The base Use Cases from which the common behavior was extracted are said to use the other uses Use Case. It is therefore the combination of the base Use Cases and all the Use Cases they use which form a complete Flow of Events. A uses Use Case is not aware that it is being used by another Use Case and does not necessarily represent a complete, standalone Flow of Events.

        1. Extends Association

A flow of events in a Use Case must be sufficient and complete. If you find a major alternative flow of events within a particular flow of events, and this alternative flow can be extracted from the containing flow of events, so that after the extraction, the original flow of events is still consistent and self-contained, the extracted flow of events forms a new Use Case that is said to extend the original Use Case’s flow of events. The extends relationship is analogous to inheritance. The extends use case “inherits” from the extended use case. In this case, the extends use case need only describe how it is different form the “base” use case. The extends use case hierarchy can facilitate reuse of use case descriptions by keeping details out of the more abstract representations. A use case called “dispense value” could further by defined (be extended by, inherited from) further use cases called “dispense cash”, “dispense gas”, “dispense copy page credit”, “dispense ticket”, etc. In this case, “dispense value” is an abstract use case, while the derived use cases are all concrete use cases. This allows you to keep the integrity of the abstract vision. Remember: extends == “inherits from” == “is derived from”.

If a part of a Use Case’s behavior is somehow separate from the remainder of the Use Case and not required to complete the Use Case, that behavior (or Flow of Events) can be extracted into its own Use Case. The new Use Case is said to extend the original (or base) Use Case. It is, however, paramount that the base Use Case retain a complete Flow of Events. An extends Use Case contains some additional part of the base Use Case while the base Use Case remains complete and unaware of the extension.

The key for determining whether an association is an extends or a uses is centered around the concept of which Use Case “knows” about the other Use Case; i.e.,

  1. A base Use Case knows "who" it uses while the uses Use Case does not know who, what, and/or when it is being used.

  2. A base Use Case does not know it is being extended while the extends Use Case knows who, what, and when it is being used.

For additional information on the purpose and a brief outline of Use Case Model Survey, see Objectory 4.1; online/ory/art/art229.htm; Rational Corporation; 1997.

For further information on the description of Use Case Model Survey tasks, see “Task: Describe the Use Case Model”, Objectory 4.1; online/ory/ph/ph251.htm; Rational Corporation; 1997.

See also, “Task: Structure the Use Case Model”, see Objectory 4.1; online/ory/ph/ph269.htm; Rational Corporation; 1997.

These Objectory 4.1 references have further hyper-links to descriptions of how to identify candidate Use Cases and Actors.

      1. Review Readiness Criteria

You will know when you are ready to make the transition from Use Case Analysis to Object Analysis and Design when:.

  1. All system behavior has been assigned to Use Cases

  2. Each Use case is involved with at least one concrete Actor

  3. Each Use Case has a unique, descriptive noun-verb name

  4. Each Use Case has at least one LIR assigned to it.



For “Checkpoints for Actors”, see Objectory 4.1; online/ory/ph/ph277.htm; Rational Corporation; 1997.

For “Checkpoints for Use Case Model”, see Objectory 4.1; online/ory/ph/ph276.htm; Rational Corporation; 1997

    1. Use Case

      1. Participants

For Business Use Cases, participants include:

  1. Business Domain Expert

  2. Analyst/Designer

  3. Application Developer (optional)

  4. For Technical Use Cases, participants include:

  5. Application Developer

  6. Analyst/Designer (optional)

  7. Architect

      1. Inputs

        Artifact

        Use

        Domain Object Model

        Inclusion in the View of Participating Objects (VOPO).

        Use Case Model Survey

        Tracing LIRs and extracting/maintaining integrity of the brief description/summary of the Use Case.

      2. Task Description

Use Cases are written during the elaboration phase, as part of Requirements Capture. Requirements Capture includes the following deliverables:

  1. Line Item Requirements Specification

  2. Use Case descriptions

  3. Use Case Model Survey

  4. Domain Model Survey

One of the nice things about writing Use Cases is that they bring into relief vagueness in previous requirements analysis. You can’t tell what the system is doing if you don’t know what the system is to do. Vagueness in the requirements specification thus becomes obvious at an early stage, during the drafting of the Use Cases.

Generally, it is better to have longer and more extensive use cases than several smaller ones. We want a single contained complete course of activity rather than several amalgamated sub-courses of activity. From the user’s perspective, it is a logically cohesive flow of events in the system.

The analysis model (which includes Use Case Analysis) is developed using what is often called an ideal condition, or perfect technology model. What this means is that you are not going to be concerned with whether a given technology will work with another, only that in the best case, it should. In the construction phase, reality again enters the picture, and you have to adapt the analysis to the real world. The reason you don’t concern yourself too much in analysis with the details of implementation are:

  1. You’re in analysis, and implementation details are out of your scope

  2. The implementation and platform are probably going to change over the life of the project anyway, so why worry about it until down the road when you have a better chance of pegging it right

  3. We don’t want to have our vision blurred by technical details too early.

The idea as you move into analysis is to model the system with no regard to the actual implementation environment, as much as is possible, and within reason. The goal is to postpone the details until you are ready to implement them. This allows you to clearly see the structure and to have to modify that structure less frequently. If you have a red house, and later find that the house needs to be green, you’ve got a real change to make. If when you need it, you find that you need a green house, and your analysis is only a house, no change needs to be made to the analysis model. It keeps its integrity.

Some important items to note:

  1. Each Use Case is a complete course of events in the system, seen from a user’s perspective.

  2. Primary Actors are central actors for whom the system exists

  3. Secondary Actors are actors who exist for the Primary Actors

  4. Actors are outside the system. Use Cases are inside the system.

  5. Finding actors is often a great way to go about describing a use case.

  6. You can think of a Use Case as a class which is instantiated at some time during the runtime life of the system.

  7. The describing of Use Cases during the elaboration phase is highly iterative. We go through several versions and drafts, each time pruning and elaborating on the contents arrived at earlier.

  8. The tasks of Use Case development include developing the Local View, Flow of Events, Pre-/Post-conditions, Assumptions, Special Requirements, and the View of Participating Objects (VOPO.)

  9. All actors must interact with at least one Use Case. One Use Case may interact with more than one Actor. The arrowhead points away from the entity initiating the interaction, generally, from the actor to the Use Case. A uses association is drawn with a directed SOLID line with the <<uses>> type description and a hollow arrowhead pointing to the use case being used. An extends association is drawn with a directed SOLID line with the <<extends>> type description and a hollow arrowhead pointing to the use case being used.

  10. Each use case must have one Manager who is responsible for directing the life cycle of the use case. This is often the use case writer or a domain expert.

For a description of Use Cases and an explanation of their use, see Objectory 4.1; online/ory/mod/mod74.htm; Rational Corporation; 1997.

For more information on the purpose, properties, and timing of Use Cases, see Objectory 4.1; online/ory/art/art208.htm; Rational Corporation; 1997.

For a description of Use Case tasks, see “Task: Describe a Use Case”, Objectory 4.1; online/ory/ph/ph260.htm; Rational Corporation; 1997.

        1. Local View

The local view is the portion of the Use Case Diagram pertinent only to the understanding of the Use Case Description ( Objectory 4.1; online/ory/mod/mod76.htm; Rational Corporation; 1997.) This graphical local view would show at a minimum the oval representation (UML) of the Use Case and all the Actors with which it communicates. If the Use Case Description uses any uses Use Cases, they would also be shown on the diagram along with any additional Actor that may communicate with the uses Use Case. If there are no Actors directly associated with a uses Use Case, it is assumed to inherit the Actors from the base Use Case using it.

If the Use Case Description extends any other Use Cases, those Use Cases are also included in the diagram—but the inverse does not hold. Any base Use Case that is extended has no awareness of the extension and is logically excluded it in its own local view. Extends Use Cases are most frequently utilized to express functionality that is truly optional; e.g., extensions to an existing production system. If their representation was included in the Use Cases they extend, then all those related artifacts would have to be updated to handle the inclusion, which subsequently short-circuits the benefits of using an extends association. This suggests that the extension never truly existed and should have been written directly accounted for in the base Use Case.

        1. Summary

The Use Case summary explains the benefit(s) and overall functionality the system provides to its Actor(s). This section should identify and describe all Actors that interact (either actively, passively, or inherited) with the Use Case.

        1. Assumptions

Assumptions are typically a delineated list of items that are not handled within the Use Case as pre-conditions, post-conditions, or exceptional flows of events. Therefore, assumptions are items that are not tested in any way. An example of an assumption might be that all Actors communicate in English.

        1. Pre-/Post-Conditions

Every Use Case should have both a Pre- and Post-Condition. The purpose of Pre- and Post-Conditions ( Objectory 4.1; online/ory/mod/mod76.htm; Rational Corporation; 1997) is to describe the observable and testable states of the system before the Flow of Events executes and after the Flow of Events has executed.

        1. Flow of Events

The primary component of Use Case’s Description is its Flow of Events (FOE) ( Objectory 4.1; online/ory/mod/mod76.htm; Rational Corporation; 1997.) The FOE is made in narrative form utilizing complete sentences solely from the viewpoint(s) of the Actor(s) interacting with this Use Case. This approach is used to maximize the readability and applicability of the artifacts to the largest possible audience. There are three major variations within the Flow of Events: Normal, Alternate, and Exceptional.

The Alternate Flow of Events (Objectory 4.1; online/ory/mod/mod75.htm; Rational Corporation; 1997), which is seldom required, may be used to slightly modify certain parts of the Normal Flow of Events, while leveraging a varying degree of reuse. For example, a Use Case named Check Out Items within a supermarket system might allow a Cashier Actor to enter the prices and quantities of products into the system at a check out counter, calculate the total sale, accept payment, and return change (if any) to the customer. An Alternate Flow of Events might allow customers to check out their own items at a “self-service” counter. The Alternate Flow could then reuse events directly from the Normal flow as applicable and redefine or add additional events (probably with respect to. security, integrity, and honesty) pertinent only to the self-service counter.

Alternate Flows of Events are particularly useful when requirements fluctuate or are incrementally defined.

In both the Normal and Alternate Flow of Events, it is important to state precisely when a Use Case begins and ends. A good method is to start each Use Case with the key phrase, “This Use Case begins when <some Actor provides some stimulus.>” If the Use Case being developed is an extends Use Case, then the key phrase should be modified slightly: “This Use Case extends the <some base Use Case> when <some condition> is met.” Furthermore, if the extends Use Case extends more than one base Use Case, there should be one sentence (as illustrated above) for each base Use Case it extends. Likewise each Use Case should terminate with the key phrase, “This Use Case ends when <some major theme of the Use Case has been completed and some value has been returned to the initiating Actor.>”

To reduce the complexity of the Flow of Events (whether Normal or Alternative), and possibly to promote reuse within a Use Case (reuse among Use Cases is achieved using uses Use Cases) developers may use sub-flows ( Objectory 4.1; online/ory/mod/mod75.htm; Rational Corporation; 1997.) A sub-flow is an optional grouping of Flows of Events, each with its own Pre-Condition(s), Post-Condition(s), and Description. Sub-flows are optionally used as a structuring technique only. Each Use Case is different (or should be) and applicability of sub-flows should be made on a Use Case-by-Use Case basis.

When developers optionally use sub-flows and/or Alternate Flow(s) of Events, it is very important that they describe (briefly) all the sub-flows and how they fit together in the main Flow of Events (both Normal and Alternative) before using the sub-flows. This part of the Flow of Events is commonly referred to as the “glue” that holds the Use Case and any of its optional sub-flows and Alternative Flow(s) of Events.

The combination of sub-flows and pre-/post-conditions also lends itself readily to describing concurrent processing if desired. It is also possible to have sub-flows with their own sub-flows and so on. Be extremely careful in doing this (as with all sub-flows), so as not to inhibit the readability of the artifact.

Try to resist the urge to create Alternate Flows of Events because they could potentially have the effect of reducing the readability of the Use Case if not structured properly. The correct use of sub-flows should satisfy reflex reactions to creating Alternate Flows of Events in most cases. When an Alternate Flow of Events is utilized, it is possible to use and reuse sub-flows from within the Normal Flow of Events.

The Exceptional Flow(s) of Events ( Objectory 4.1; online/ory/mod/mod76.htm; Rational Corporation; 1997 are an extremely valuable part of the Use Case. The Exceptional Flow(s) of Events describe what the system does when an exception (which may or may not be an error state) to the Flow of Events occurs. An example of an Exceptional Flow might be “Printer out of Paper.” In the Normal Flow of Events, it may not be useful to account for this with a conditional since the overwhelming majority of time, the Actors expect the printer to have sufficient paper. But instead of causing the system to “crash," an Exceptional Flow can be utilized to account for and handle that not-necessarily- error state.

Consider the following points when describing the Flow of Events:

  1. Explicitly state how and when the Use Case begins and ends.

  2. Describe the Flow of Events not just the functional requirements or purpose of the Use Case.

  3. Do not describe the Flow of Events of another Use Case—ever. That is the responsibility of the other Use Case(s.)

  4. Do not mention Actors that do not communicate with the Use Case being described.

        1. Special Requirements

The Special Requirements ( Objectory 4.1; online/ory/mod/mod76.htm; Rational Corporation; 1997) allows for the documenting of such things as design considerations, future considerations, and performance requirements. As a Use Case Description is being developed, design considerations are often identified and if they are not captured will most likely have to be rethought or lost. So, place these items in a Design Considerations subsection of Special Requirements. Examples of design considerations may be database related, GUI navigation aspects, expert system support for business rules, etc.

There may be certain ideas uncovered during the Requirements Activity that are not consistent with the current scope of the system but may merit further consideration during the next iteration of the system development. Document those considerations in the Future Considerations subsection of the Special Requirements section. This subsection may additionally prove useful when the process control deployed on the overall system is iterative in nature with designated incremental builds. In this case, this section could be utilized to identify which parts of the Use Case Description are to be developed in certain iterations and any potential dependencies between iterations. Iteration does not only apply to design and implementation; Use Case Descriptions may have incremental deliveries as well.

With a robust Special Requirements section, there is no justification why the Use Case Model cannot entirely replace what has been traditionally referred to as a Requirements Specification.

        1. View of Participating Objects

The Use Case View Of Participating Objects (VOPO) (Objectory Process Documentation; V3.3.1; 1993; section 2.1.11) is a graphical subset of the Domain Object Model which illustrates the objects which participate in the Use Case, their associations, attributes, and behaviors.

As Use Case Descriptions are being developed, so too should the Domain Objects in the Domain Object Model. The primary source for these Domain Objects is the Use Case Descriptions. This is not to suggest that development of the Domain Object Model should begin once the Use Case Descriptions are baselined; just the opposite. Both the development of the Domain Object Model and Usage Scenarios support the development of the Use Case Descriptions, and each will provide feedback into each other.

As the Use Case Description and Domain Object Model near a baseline, a view of participating objects (VOPO) should be included in the Use Case Description itself. This is analogous to the Local View (see, page 1) with respect to. the Use Case Model Diagram. The VOPO has substantial benefit when the Analysis Activity commences which includes the development of Sequence Diagrams and Collaboration Diagrams since those are directly dependent on a particular Use Case Description.

A Use Case is a narrative description of the interactions between the Actor(s) and the system ( Objectory 4.1; online/ory/mod/mod76.htm; Rational Corporation; 1997.)

Each Use Case has a main theme and must provide some quantifiable value (positive or negative) to its Actor(s.) Use Cases consist of the following core elements: local view, summary, Actors, assumptions, pre-/post-conditions, flow(s) of events, special requirements, and view of participating objects (VOPO.)

      1. Review Readiness Criteria

You know you’re done when:

  1. all the roles played in the system’s environment have been accounted for and described in the Glossary of Actors or Use Case Model Survey.

  2. Every actor interacts with at least ONE use case

  3. No actor is playing more than one role at a given time. If a particular actor can interact with the system in completely different manners, you have not delineated that actor well enough. There are two different actors playing two different roles

  4. The names of each actor specific enough to describe the actor as well as the role.

  5. The Actor descriptions are comprehensible by the customers, testing staff, Business Domain Experts, and developers alike.

  6. The Use Case represents a complete flow of events.

  7. The Use Case has a clearly defined beginning and end.

  8. Every concept in the Use Case is defined in the Glossary.

  9. The summary section of the Use Case contains a clear and concise compendium of the flow of events of the Use Case.

For “Checkpoints for Use Cases”, see Objectory 4.1; online/ory/ph/ph278.htm; Rational Corporation; 1997.

For “Checkpoints for Use Case Descriptions”, see Objectory 4.1; online/ory/ph/ph279.htm; Rational Corporation; 1997.

      1. Style Guidelines

        1. The term “actor” is generally never used by itself. The author needs to name the actor specifically. The only exception to this is when the actor is referred to in the immediately preceding sentence, and is mentioned alone (no other actors are mentioned in that sentence), and the reference is clear. There can NEVER be any confusion as to “which” actor you are talking about.

        2. The words “information” and “data” are generally proscribed in business use cases. The reason for this is that the use of these words tends to obscure what lies behind them. However, when writing architecture use cases, the word data is appropriate, but still avoid the use of the word information, as it is simply too vague. If you do use the word “data”, try and predicate it with some descriptive adjective or clause, such as “database data”, “data on the wire”, etc.

        3. Avoid the use of the word “subsystem” in requirements capture. Use the word “service” instead.

        4. Preconditions are specific activities or conditions that MUST BE MET by actual effort prior to beginning a flow of events.

        5. Assumptions in the Flow of Events section of a use case are precisely that, assumptions that are made that are outside the scope of preconditions and the flow of events. They are also outside the scope of any particular requirement.

        6. Generally, the word “Actor” is never used by itself. It always needs to be qualified (which actor?), unless the context is unmistakable.

        7. Pre and post conditions are not optional. Every Flow of Events has a pre and post condition.

        8. Do not use future tense verbs in your Use Cases. Avoid sentences like “The Actor will then do something.” Instead, like Sergeant Joe Friday, simply state the facts in the preset tense: “The Actor does something. After doing that, the Actor does this.”

        9. Avoid the passive tense. Don’t say “The system is queried by the So-And-So Actor as to what ....” Say instead, “The So-And-So Actor queries the system to find out ...”.

        10. All output devices not being developed as a deliverable of the system are Actors, and should be noted and treated as such.

        11. Be specific when writing a Use Case. Specify which actor you are talking about, describe the details of information that is being passed around. Note that this is not to define the structure of the information (don’t say “a struct so-and-so is then passed to”), but do say WHAT the details of the information are, i.e., “a name, address, social security number, etc.”

        12. The Flow of Events must clearly state precisely WHEN the Use Case begins and precisely WHEN the Use Case ends.

        13. A Use Case does not know about GUIs. You cannot say something like “then the User presses the Save Button and then the system ....”. Don’t define the User Interface in your Use Case. Doing so would violate the encapsulation of the Use Case as well as introduce design concepts (“how” discussions) into what should be a “what” description.

        14. Don’t be afraid to include business algorithms, or other rules that are implicated in a given Use Case. These are appropriate for inclusion.

        15. Use Cases are oriented around a specific goal. Make sure, in your title, that it is the goal that is described, NOT the process of achieving the goal. Say “Log Information,” not “Information saved vi Logger”.

        16. Use Case titles are in the present tense, active voice, and will consist of a noun and a verb, at a minimum.

        17. Explicitly state when the Use Case begins. “This Use Case begins when <some actor> <does something which provides a stimulus>“. Likewise, explicitly state when the Use Case ends: “<Something finally happens and> this Use Case ends.”

        18. Capitalize the words Use Case, since the two words never appear in a vacuum, but are always associated with a Use Case title.

        19. Capitalize the name of the Actor and then append the word “Actor” to that name. For example, the System Operator Actor.

        20. The description of the flow of events should be in present tense, active voice narrative. Use bulletized lists wherever applicable.

        21. Never fail to describe the details of the information being exchanged between Actors and the system. If the system presents the user with information, detail (via bulletized lists, etc.) WHAT that information consists of.

        22. Do not mention details of the (proposed) user interface (GUI). Don’t mention buttons, icons, scrolling, an iconbar, dropdown boxes, listboxes, etc. These are design issues and do not belong in Requirements Analysis.

        23. GUI mockups can be referred to, but ONLY as a heuristic aid to understanding WHAT is happening in the Use Case, not as a description of HOW the user is going to do something.

        24. Use adverbs sparingly, but feel free to use adjectives where appropriate.

        25. It is common for business domain experts to use several words to describe a single entity or activity. When writing Use Cases, settle on a single word to describe the entity or activity, and stick with it. Eschew obfuscation by limiting the redundancy of synonyms. Also, the term chosen should certainly exist in the Glossary.

        26. Avoid personal pronouns. Don’t refer to the Actor as “he” or “she”. Just restate the name of the Actor. Be careful with reflexive pronouns such as “it”. Make very sure the reflexive pronoun is not ambiguous as to what the referent is.

        27. When using Sub Flows, use the Primary Flow of Events to summarize each of the Sub Flows. There is no need to specifically state when a Sub Flow begins and ends, as there is in the case of a Primary Flow of Events. It is assumed that the Flow of Events details WHEN the Sub Flow begins, and it is assumed that the thread of execution will continue after the Sub Flow ends with where it left off in the Primary Flow of Events.

        28. The Exceptional Flow of Events should be just that: exceptional. Errors should be handled within the Flow if Events itself, and Exceptional Flows reserved for truly exceptional situations (system crash, component disappearance/failure, etc.).

        29. A Use Case is not an object, and when we say that it “executes”, what we really mean is when an Actor starts it’s activity, begins to go through the sequence of steps defined within the Use Case.