Chapter 6. Preparing for Use Case Modeling and Determining Use Case Approach

This chapter discusses some of the activities that need to be performed when setting up a use case modeling effort, activities in the first major use case activity group, “Prepare for use case modeling and determine use case approach” (Figure 6-1). The activities are identification of stakeholders, selection and customization of a process framework for use case modeling, and selection of standards, templates, and tools to support the effort. Finally, mentoring and formal training need to be planned and put in place.

Figure 6-1. Preparation activities for use case modeling

Perform a Stakeholder Analysis

A number of different “stakeholders” are involved in the use case modeling process. A stakeholder is defined as any individual who has a “stake” or interest in the use case model. The stakeholders must be identified and engaged in the use case modeling effort as early as possible and their feedback must be solicited and incorporated into the use cases. Only with active participation of all the stakeholders can a use case effort—and the system—be successful. Although this task can seem time-consuming and difficult, the payoffs for all the stakeholders are great. For example, the customer that is paying for the information systems development efforts and the project manager responsible for developing the system can use the use cases to agree on system scope and then estimate the schedule and budget. The users will use the system use cases to identify and validate the system requirements, thus reducing the “surprise” factor when the system has been developed (“That’s not what I thought the system would do”). The system developer and architects utilize use cases to help drive the analysis and design of the system.

A stakeholder analysis should be performed as part of the system development process. A stakeholder analysis normally identifies the key stakeholders, what organizations they are with, their overall organizational responsibilities, their relationship to the project, and any issues or concerns that are associated with the individual. Following are categories of stakeholders who are involved in a use case modeling effort.

• Customers

• Users

• Project managers

• System analysts

• System architects

• System developers

• Testers

• System operators and maintainers

Each stakeholder has different needs and perspectives (Table 6-1). The different attributes of a system (such as requirements, schedule, progress, budget) are of concern to different categories of stakeholders.

Table 6-1. Stakeholders and use case modeling

It is critical that each system stakeholder be involved in the use case modeling effort. Without this involvement, it is extremely difficult to get buy-in for the system and the development approach that is being taken. If the stakeholders are not involved early in the system development effort, not only does the project team have a difficult time capturing the system requirements, the stakeholders do not feel a sense of ownership. Then, if things don’t go quite as planned during the development effort (e.g., delays, cost overruns, demands for changing requirements), the stakeholders will be far less likely to understand, support, and champion the effort.

Select and Customize a Use Case Process Framework

Before jumping into use case modeling, you will need to create or select and customize a use case process model.

First, determine the role of use case modeling within the overall system development process context. Define how use cases will fit in and relate to the other analysis models, such as object models, architectural models, formal written requirements, and designs. If you are adapting a preexisting process framework, determine what modifications you will need to make:

• Modifying existing methods or process activities

• Integrating activities or methods from different use case frameworks or approaches

• Adjusting activities for use within the overall system development process

When customizing a framework, consider the size of the project. Smaller projects typically need much less structure than large ones. Some organizations like a lot of structure, while others prefer a less structured approach. Be sure you are tuned in to the culture of your organization. Consensus is critical. A large, established company with thousands of IT professionals in a traditional industry may like and want a significant amount of structure, or what Booch refers to as “ceremony” [Booch 1996]. A small Internet startup will probably want just enough structure to “get it done.” If possible, test the framework on pilot projects and refine it before deploying it to the rest of the organization. Have the participants on the pilot project act as champions and mentors to the rest of the organization. This will help build consensus and provide critical hands-on support.

We recommend starting with an existing object-oriented framework such as the Rational Unified Process and customizing it as needed for your effort.

Select Use Case Standards, Templates, and Tools

When many individuals work on a large project, use case modeling standards must be established that will provide guidelines, such as the appropriate representations for use case text descriptions and use case models. Standards dictate common approaches and representation for development of the use cases—what models will be developed and how they will look—and the level of detail a model will define and how will it fit in with the other models.

To ensure and encourage a common and consistent approach, standards should be supported by common templates, such as use case templates, use case diagram templates, and so on, along with guidelines for using them and checklists to ensure that they are completed and validated correctly.

Not only do standards help to ensure that the use case model is developed consistently, they help to educate developers as to how the process will proceed. If the developers are experienced and have been on previous use case modeling efforts, the proposed standards can generate healthy debate and result in a useful refinement of the approach before the project begins.

The easiest and best approach to creating standards is to select already developed industry standards such as the Unified Modeling Language as your starting point. But be careful: UML is very large and will need to be customized and modified for most project efforts.

Computer Automated Software Engineering (CASE) tools should be selected that will support your models, descriptions, templates, and processes. Although it is highly unlikely that one tool will meet all your project needs, it is critical for large projects, particularly projects with lots of iteration, that tool support is provided. CASE development tools can vary from Rational Rose for large-scale development to Visio for simple projects. Be prepared to supplant a primary tool with other tools and manual processes to support your effort.

Normally, it is a good idea to define and tailor your processes, models, and templates first, and then look for a CASE tool that supports them. The CASE tool tail should not be permitted to wag the process dog.

Tailoring your use case modeling approach can complicate CASE tool support. Since the tool may not be able to “adjust” to customization, some revisions to templates and approaches can be made to facilitate the integration of a good CASE tool into the project. Remember that any changes or tools should support your final objectives.

It is easy to oversell the benefits of a CASE tool to upper management and the development team. No CASE tool will meet all your documentation and communication needs. A CASE tool supports the analysts; it does not do the thinking for them. An inexperienced analyst with a CASE tool is still an inexperienced analyst: “A fool with a tool is still a fool.”

It is imperative that the organization evaluate any tool in-house. While this can be time-consuming, it is virtually impossible to plumb the depth and abilities of CASE tools without an extensive review.

Determine Training and Mentoring Needs

There cannot be enough said about the role of formal training and mentoring in the success of a use case modeling effort. Everyone who works on the project should be expert in what they’re doing.

Formal Training

When providing training for individuals involved in the use case modeling effort, it is important to focus on more than simply how to “do” good use cases. Elicitation techniques (e.g., requirements analysis, interviewing skills), interpersonal skills, overall requirements management, and an understanding of systems development are also important, as use cases do not stand alone. Keep in mind the following points:

• Use case training should be synchronized with the process framework.

• Provide formal training courses on use case modeling.

• Have team members participate in training programs that involve a workshop setting and simulated or real-life examples. This gives the team members some hands-on experience before attempting the project.

• Use immersion courses or boot camps that provide intense, long-term (several weeks to several months) instruction.

• Make sure the training is available “just in time.”

Also consider whether training will be provided by an in-house or an outside vendor. If an outside vendor is being considered, they will need to know whether the training will help drive the process (i.e., you are looking for process support guidance as well) or whether it will need to map to a development approach that has already been selected.

Mentoring

Formal classroom training and written documentation are great tools for providing the basics of the technology. However, experienced individuals can analyze the specific needs of the project and customize the training approach. Experience needs to be shared and shared quickly across the organization. Build a network within the company of people with similar experiences who can draw on each other for guidance and advice. Cross-pollination of experience across multiple projects can go far to supplement documentation and formal training that may be limited by rapid change and busy instructors.

What makes a good use case mentor? What are the characteristics for an ideal mentor? When we select individuals to act as mentors, we look for the following characteristics.

Knowledge and Information Technology Skills

Obviously, good mentors must have experience in the areas they are mentoring. For example, a use case mentor must have both the practical experience and the theoretical knowledge to guide the team effectively through difficult analysis decisions. Mentors are able to take lessons learned on one use case modeling effort and make them available to the next project team(s) across the organization.

In addition, the mentor should be able to keep up with the latest and greatest the industry has to offer, distill all that information, and filter from it what is important for the project. Many times, due to project deadlines, members of project teams will not have time to explore the latest ideas and industry experiences and then determine how to integrate them into the industry effort.

Ability to Instill Confidence

Mentors need the respect, trust, and confidence of the team and the team needs to feel comfortable asking questions and accepting advice. Not only should a mentor have knowledge of the specific use case approach, but the team should feel that the mentor has experienced firsthand some of the issues with which they may be struggling.

Mentoring Personality

A mentoring personality includes the following traits:

• Teaching and coaching skills

• Communications and facilitation skills

• Approachability

• Ability to deal with difficult personalities

• Ability to juggle priorities. Mentors are pulled in many directions.

• Ability to work under stress and pressure. Mentors generally find themselves putting out brush fires and working with people who are struggling to make deadlines.

• Ability to recognize their limitations with regard to time and skills.

Ability to Adjust to the Context of the Project

Mentors must have the ability to adjust to a specific project context. They are not always injected into the project at the same stage. Therefore, they must be able to assess the environment and the needs of the project quickly and then act accordingly. Mentors need to have enough experience to generalize use case modeling techniques and methods and apply them to new situations. They must also be open to new approaches and be willing to adjust and modify the approaches they have taken on a particular project in the past.

Ability to Analyze Team Member Experience and Abilities

Good mentors need to be able to evaluate the different talents and capabilities of the team and capitalize on the strengths. The job of mentor is to try to find a role for everyone.

Commitment to Project Objectives and Goals

Mentors need to view their success as the success of team. They must be aligned with project objectives and goals and be effective in establishing buy-in from the team to achieve the goals.

Mentors can be selected from in-house staff or they can be external consultants. An external mentor may bring a new perspective, knowledge, and experience from outside development efforts to the effort; an internal mentor may feel more commitment to the project and understand the internal culture much better.

Conclusion

Preparation is a key for successful use case modeling on a large project. A stakeholder analysis should be performed to identify all interested parties. A framework for applying use cases is developed and put in place. The standards, approaches, and techniques to be used are chosen and planned. Finally, to ensure a knowledgeable project team, training and mentoring are put in place.