Chapter 7. Performing Initial Use Case Modeling

This chapter outlines the initial activities for creating the use case model, a process we refer to as initial use case modeling. The outcome of this activity group is a use case model that captures a “conceptual” picture of what the system needs to do. During initial use case modeling, the key behaviors of the system are defined, the major actors are identified, and an initial mapping to high-level business objects is performed.

As shown in Figure 7-1, the activities in this group include the development of a context diagram and descriptions of the major actors and primary use cases. Once again, although the activities are presented in a linear order, there will be a large amount of parallelism and iteration among them.

Figure 7-1. Initial use case modeling activities

Develop Context Diagram

Sometimes people develop a traditional context diagram before developing a formal use case diagram. A context diagram is a very quick and focused representation of the system boundaries, entities that interact with the system, and the nature of the interaction. Since the context diagram is a little less formal than a use case diagram, analysis can start very early on without formally defining use cases or actors. It also has a long history in system development analysis [DeMarco 1979] [Yourdon 1989], so users and systems analysts may already be comfortable with it. Although this activity is not traditionally used in use case modeling, it can be a quick and easy way to get started with the analysis when you are dealing with an unclear problem or working very early with a customer or users.

The context diagram (Figure 7-2) represents the system as a big circle with external entities surrounding it. In the traditional context diagram, directed lines (arrow) indicate the flow of information between the external entities and the system. In a use case modeling content diagram, the arrows show interactions that will potentially map to use cases. Under normal circumstances, the external entities will serve as input into the identification of the actors.

Figure 7-2. Context diagram layout

In a context diagram, everything inside the circle is “inside” the system and everything outside the circle is “outside” the system. An external entity can be a person providing information to or receiving information from the system or an external system receiving information from or sending information from the system. Any interaction and/or information shared between the system and external entities should be documented as directed lines, but their descriptions should be kept at a high level. For example, the need for reports can be captured on the context diagram as a general interaction without listing every report. There is no hard and fast rule on the number of external externals and interactions that can be shown in a context diagram, but remember that this is a one-page overview of the system, not a detailed description. As the analysis proceeds, the external entities and arrows will map to more detailed actor and use case descriptions.

When developing a context diagram, review such documents as business use cases, Business Process Reengineering (BPR) results, existing requirements, the stakeholder analysis, enterprise IT architecture descriptions, and strategic planning documents. Start by asking the stakeholders to list the external entities in the system environment that will interact with the system. Place these external entities around the system and describe the interactions between the external entities and the system. There is no need to be formal; more formality will be introduced in the following activities that define actors and the initial use cases.

Drawing a traditional context diagram can be skipped if there is sufficient information or experience to start formally defining the use cases and actors. However, it is a quick way to get started scoping the system.

The context diagram for the loan processing example is shown in Figure 7-3.

Figure 7-3. Context diagram of loan processing system

Now is a good time to start to create a glossary similar to the system glossary of domain object definitions in (Chapter 4) of standard terms and definitions that will be used during the use case modeling. The glossary will continue to be updated as the use case modeling progresses, but the initial glossary should be created before the initial use case models so that all participants agree on a common terminology to use in describing the actors and use cases. A glossary helps to improve the readability of the use case modeling artifacts and can reduce rework.

Identify the Major Actors

During this activity the project team starts to identify and document the actors. (Actors were defined in Chapter 1.) Look for the major or primary actors that interact with the system. As the use case analysis proceeds, more actors will be found, and the level of detail on each actor will be refined. Remember that an actor is a role, not a specific individual. The role should reflect the responsibilities the actors have in the environment within the context of how they interact with the system. For example, in a travel management system, a good role name for the actor who submits a travel voucher would be “Employee.” A bad name would be “User,” since a user could be anyone who uses the system. The more precise the actor name, the better.

When looking for the actors, look for individuals, other systems, or other organizations that will interact with the system. In addition to brainstorming with users and customers, look at these documents and deliverables:

• Draft context diagrams and other models that describe the system within its environment (e.g., BPR results, existing system models, strategic plans, and so on)

• Stakeholder analysis that has identified the stakeholders and their roles

• Written specifications and other project documentation, such as memos about meetings with users, to help find users who may be potential actors

• Individuals who participated in requirements workshops or joint application development (JAD) sessions

• Training guides and user manuals for current processes and systems

• Organization charts

Finally, and most important, elicit from the key users in the use case modeling process the names of people whom they think may interact with the system.

Involving the users and customers does not mean that they should write the use cases unassisted. If a project lets the users write the use cases, then the use case model will almost always be inconsistent, incomplete, and overscoped. In addition, since the users wrote the use cases, they will feel that they “own” them. It can be very difficult to get the users to agree to a major reworking, if needed.

It is the job of the project’s use case modelers to work with the users and customers to elicit and gather the appropriate requirements information, transform this information into a quality use case model, and have the users review and validate the use case model. Most of the time we like to discover the actors first, and then define the use cases (see the Interesting Issue box on page 86).

The initial primary actors who were identified for the loan processing use model are shown in Figure 7-4.

Figure 7-4. Several actors identified for the loan processing system

Once the primary actors have been identified, it is useful to select and talk to representative members of each actor role. During these interviews, try to determine what interactions the actors will need to have with the system to meet the system objective and goals. Consider the level of computer experience that may span an actor role. Normally, we like to speak with at least three individuals for each human actor role:

• one who is very experienced with the role

• one who is a novice at the role

• one who is considered to be representative of the role

Also, if the role is played in different geographical locations, including different countries, talk to a representative in each location. Sometimes system behaviors will need to be different in other locations or cultures.

If the actor is another system, try to contact someone knowledgeable about that system’s functionality, such as a user or system maintainer, to discuss the other system’s capability to carry out the behaviors expected of it.

We document actors with the actor specification forms shown in Chapter 1, and we record the actor description in what we call an actor glossary. The glossary is the list of actors and their descriptions. At this time, document the actor’s name and include a short description of what the actor does. The rest of the actor templates will be filled in as more is discovered about the use cases. Sample actor specifications follow for the applicant, customer, loan officer, and accounts management system.

Discover the Conceptual System Use Cases

Obviously, one of the most important activities in use case modeling is identifying the use cases! In this activity, the initial set of high-level use cases is identified and documented. The initial use case descriptions document the major interactions that actors will have with the system; they model the primary requirements that will drive the system developments.

The set of initial use case descriptions, along with the use case diagram discussed in the next activity and the major business objects, should give the stakeholder a conceptual picture of what the system will look like. This level of detail is commonly referred to as a concept of operation or system concept.

One way to start to identify the initial system use cases is to examine the list of actors and ask the following questions:

• What measurable value is needed by the actor?

• What business event might this actor initiate based on the actor’s role?

• What services does the actor need from the system?

• Does the actor need to receive information from the system?

• What type of service does the actor provide?

When performing this step it is important to keep the actor’s perspective in mind. Each use case discovered should represent some responsibility of the system that supports an actor’s business needs. As you conduct this process, you will discover many possible interactions that users can have with the system. It is important to make sure that the use cases are driven by system objectives and goals, and when the use cases have been defined, make sure that they trace to at least one system objective and goal; for large systems, it is easy to overidentify use cases. Cockburn [1997a, 1997b] describes the use of goals to try to help identify use cases.

Naming Conceptual Use Cases

Name the use cases to reflect, as precisely as possible, the reason for the primary actor’s interaction with the system.

• The use case name should provide a short description of the actor’s interaction with the system.

• The use case name should reflect the actor’s goal in interacting with the system.

• The use case name should be stated from the perspective of the actor.

• The use case name should be an active verb–noun phrase. The verb should be in the imperative mood to denote an action that the actor should perform; a use case is an event, not a process or information flow. For example, a good use case name for submitting a travel voucher is “Submit travel voucher.” A not-so-good use case name is “Travel voucher submission.” “Submit travel voucher” implies an event and is much more specific; “Travel voucher submission” implies a process and could involve far greater functionality than the event of submitting the voucher. (See the Interesting Issue box below for another approach to naming use cases.)

In naming the use cases in the loan processing system example, the following questions might be asked. The answers suggest good names.

• For the loan applicant, what value is needed from the system? The ability to submit a request, receive notification, and so on.

• For the loan officer, what support is needed from the system? Loan request information captured in a form that is ready to evaluate.

• For the customer, what services are needed? The receipt of timely billing.

Example use case names might be “Submit request,” “Evaluate loan request information,” and “Receive timely billing.”

Don’t be afraid to move quickly when brainstorming the use cases. Use case modeling is very iterative. You will have plenty of opportunity throughout the process to find new use cases, merge use cases, and throw out irrelevant use cases.

Documenting Conceptual Use Cases

An initial use case description documents an individual use case at a high level of abstraction. This normally involves a couple of sentences or a free-form paragraph outlining the purpose of the use case and the activities in the use case. This level of use case description allows for a quick understanding of the interactions between the actors and the system and the system responsibilities and behaviors in response to the interactions. Figure 7-5 shows a sample template for capturing a high-level use case.

Figure 7-5. Initial use case template

Conceptual use case descriptions can be developed quickly and provide a focused overview of the major behaviors of a system. They are intended as a starting point for understanding and modeling the final use cases. They are also an excellent means for presenting the system to high-level decision makers in a compact and understandable fashion. Furthermore, they must be done in order to locate an initial use case diagram. Even short use case descriptions ensure that all the stakeholders have the same broad behavior in mind when referring to a specific use case.

The description should provide a reader with a complete, high-level understanding of the use case. Guidelines for writing a conceptual use case description follow.

• Summarize the business goal motivating the use case.

• Describe the purpose of the use case.

• Summarize the major behaviors that occur in the use case (the use case’s scope).

• Write no more than several sentences or a paragraph.

• Use the present tense and the active voice.

• Include a final sentence that describes the result of the action.

Figures 7-6 through 7-9 are a set of initial use case descriptions and graphics for the loan management system that provides a high-level understanding of the basic functionality of the loan processing system.

Figure 7-6. Sample initial use case description “Submit loan request”

Figure 7-7. Sample initial use case description “Enter validated credit references”

Figure 7-8. Sample initial use case description “Evaluate loan request”

Figure 7-9. Sample initial use case description “Book new loan”

Finally, when identifying and documenting the initial use cases, remember the following:

• Focus on the actor’s perspectives by asking what the actor expects from the interaction.

• Make sure the use case is initiated by a business event and is expected to provide value to some actor. If a use case does not provide value to any actor, challenge its existence.

• The user should be able to identify the use case as a business event that will occur within the user’s role.

• Capture each use case at the same level of granularity.

• When an actor is another system (e.g., a credit reporting or payment gateway), it can be valuable to consider a number of systems so that you can generalize the interactions using abstract actors. This can add to the flexibility of the model.

• Try to keep design decisions out of the conceptual use case model. A common problem with use case modeling is the baggage associated with preconceived notions of how the system should work. Always ask, “Is this functionality really required, or am I assuming a solution?”

• Don’t get bogged down in details, but do validate the use cases and their descriptions with actors and other stakeholders after completing this activity and creating the use case diagram.

Developing Conceptual and Base Use Case Descriptions as One Deliverable

Some organizations combine the modeling of conceptual descriptions with the base use case descriptions, discussed in the next chapter, into one deliverable that they present to the stakeholders. In many cases, it is an easy step to a “basic” base use case description once the conceptual descriptions are complete. A lot depends on the users’ involvement and their expectations of the use cases. If users are intimately involved in the project and want regular deliverables to review, conceptual descriptions are the first set of use case descriptions to present to them. Also, if the system is very large, both sets of use cases for the entire system may be impractical to do in one step. However, if the system is smaller, consider combining the conceptual step with base use case description.

Using Workshops to Identify Conceptual Use Case Descriptions

When developing conceptual descriptions, we prefer to generate them in use case modeling workshops involving key users, customers, and analysts. The high-level nature of conceptual use cases facilitates brainstorming and discussion among the team. If the system is very large, consider breaking use cases down into known functional groups and holding individual workshops on each area.

A workshop group should brainstorm and reach consensus on the conceptual use cases, which may be as simple as the use case name and a short sentence or phrase representing its goal. Then, in small teams or as individuals, the group can write the formal conceptual use case descriptions. The group should then come back together as a whole to review and, if needed, rework and regularize the conceptual use cases. If several use case workshops are occurring simultaneously, they should all follow this process.

It is important to have a skilled use case facilitator running the sessions and to have written guidelines that everyone observes. It is also important to provide at least minimum use case training to all participants. We find that beginning the session with an hour or two of formal use case training is a good way to get everyone on the same page and to provide the training at just the right time. For a good generic resource on facilitation, see Schwarz [1994]. It is important that everyone agree on whether the current “what is” situation or the desired “what will be” is being modeled. See the Interesting Issue box below for further discussion on this topic.

Initial use case modeling provides a conceptual understanding of the system, its major behaviors, and its primary actors. Use the conceptual use cases to validate with the customer and user that the system analysis is on the right track. A good way to proceed through the development of initial use case modeling is to schedule several days of off-site workshops that include the different stakeholders. Use these workshops to develop drafts of the use case model and object model. The project team can then more formally document the results and validate this information with the stakeholders. After this validation occurs, the project will be ready to proceed with the next set of activities.

Initial Use Case Descriptions and Extreme Programming

Extreme programming is a new approach to developing software that stresses small teams of paired programmers working closely with the customers to develop software quickly and to be able to respond to changing customer requirements during development. Extreme programming utilizes the concept of user stories to start to capture user requirements. User stories are somewhat similar to initial use case descriptions; they are typically short (about three to four sentences), informal, and written using the customer’s terminology. In an extreme programming approach, each user story should be able to be implemented within one to three weeks. When the story is ready to be implemented, the developers work directly with the customer to gather a more detailed description of the requirements. While there is some similarity between the initial use case descriptions and user stories, there are some critical differences as well. If the reader is interested in the extreme programming see Beck [1999] and Jeffries [2000].

Develop Initial Use Case Diagram

A use case diagram provides a visual representation of the participation of the actors in the use case. On a system of any size, there will be multiple use case diagrams. Some may show the relationship between the actors and the system, while others may show the base use cases and their extends, includes, and generalization relations (discussed in Chapter 11). A use case diagram also may focus on clusters of related use cases and show all the relationships the use cases have—includes, extends, generalizations, and actor. Initial use case diagrams are developed concurrently with conceptual use cases and continue to be detailed as the use case modeling evolves. Sample use case diagrams for the loan processing system are presented in Figures 7-10 and 7-11.

Figure 7-10. Partial use case diagram for loan submission use cases in the loan processing system

Figure 7-11. Use case diagram for ongoing loan management use cases in the loan processing system

Determine/Refine the Conceptual Business Objects

The purpose of the “Determine conceptual business objects” activity is to further refine the glossary and to start defining the conceptual relationships between the objects. As discussed in Chapter 4, the system glossary contains objects representing major business entities or events. The glossary includes a description of each object and its conceptual relationships with other objects. Defining entities in the glossary and the relationships between these entities is often called domain object modeling.

Object modeling is an activity that continues throughout the development process. As development proceeds, objects that will be realized in the system are discovered and refined. That is, the object model is at different levels of abstraction and completion at various stages of development. Three well-defined levels of object modeling are domain, analysis, and design. The glossary looks at an object model at the domain level. In other words, the glossary contains definitions of objects that make sense to a business (e.g., loan, application, terms, and so on).

Relationship of Use Cases and the Object Model

The relationship between use cases and object modeling is a strong one. A discussion of use case modeling without including its relationship to corresponding object models would present only a partial picture of the role use cases play during requirements analysis.

Use cases can serve as a validation vehicle for the domain object model by ensuring that all the necessary abstractions have been found. In this capacity, use cases can help identify additional objects and validate existing ones. Use cases can also help control the scope of the object model by clearly identifying the interactions between the system and its environment. When objects are modeled via use cases, they are associated with the event described by the use cases and are therefore traceable to higher-level objectives, functions, and work flows. Modifications to objects can be validated by determining whether the modifications are within the scope of the use cases. Use case and object modeling complement one another and are usually performed as parallel activities.

When discovering the objects at this level of analysis it is effective to apply the following guidelines to each system use case.

• Walk through the use case to identify the objects that participate in it.

• Look for nouns. Many times nouns represent objects, but nouns can be “verbed” and verbs can be “nouned.” Also, many nouns in a large document may not be objects or be interesting from a system perspective.

• Ask what products are “produced” by the use case and what the inputs are.

• Ask which actor initiates a event and which other actors participate in the use case.

• Group candidate objects into categories. Categorization techniques can be found in Booch [1994] and Coad [1991].

• Try to brainstorm for “candidate” objects; don’t try to eliminate objects too early.

• Look for objects that have different names but are really synonyms and choose a common name for them.

• If an object is ambiguous (does not map cleanly to a business concept), try to map it more cleanly or else eliminate it.

• If the object appears to be atomic—that is, it represents a single simple value—it may be an attribute of another object (e.g., first name or birthdate).

The following is an example set of known categories that typically represent objects, based on several categorization techniques.

Start to document each object with its high-level characteristics and create a business or high-level object model with relationships such as associations, generalization, and aggregation. Although some people like to perform very detailed use case modeling before attempting object modeling, we have found that the object model provides perspective on the system requirements that is difficult to represent in the use case, such as the number of accounts a customer can have. An object model can elegantly represent this fact as an association (with multiplicity) between a bank account object and a customer object. Defining use cases and objects tends to go back and forth; that is, use cases are defined to a level of detail and then objects are found. Next, more details are added to the use case model, and additional objects and details are discovered.

Consistently mapping the use case model to objects as the use case model is being developed helps reduce the risk of functional composition. Object modeling and use case modeling each bring unique strengths and weaknesses to the analysis effort. We like to think of the two as “dancing” with each other throughout the requirements analysis.

Following are three example use case descriptions with candidate objects in boldface type.

The following selected objects are found in these use cases.

Packaging and Validating the Use Case Conceptual Model

Following is a sample table of contents for the conceptual use case model.

1. Textual introduction
2. Use case and/or context diagram
3. Actor glossary
4. Conceptual use case descriptions
5. Glossary

Conclusion

The outcome of initial use modeling is the creation of a use case model that captured a high-level conceptual picture of what a system will need to do. During this effort, key or primary behaviors of the system are defined, the major actors are identified, and an initial mapping to high-level business objects is performed.