8.1 Tracing Back to Use Cases

Use cases are a central traceability artifact in the software lifecycle. What makes them good for traceability is

• They are readable by businesspeople, so they are a credible starting point.

• They are coarse-grained, allowing a large system to be divided up into a digestible number of pieces.

Use case traceability can be extensive , as we've seen on projects we've been a part of. Here are the artifacts use cases can have traceable links:

• Analysis model

• Sequence diagrams

• Class diagrams

• State diagrams

• Design model

• Sequence diagrams

• Class diagrams

• State diagrams

• CRC sessions

• Test model

• Test plans

• Test scenarios

• Test cases

• User interface design

• Storyboards

• Application architecture

• Transaction handling

• Prefetch

• Project management

• Iteration planning

• Documentation and training

• User manual

• User training

• Product marketing

• Security profiles

• Release planning

8.1.1 Analysis Model Traceability

REFERENCE:

RUP (analysis model artifact)

The most obvious traceability for any requirements artifact is into analysis. Use cases trace easily into analysis artifacts, especially when the analysis is done using object-oriented techniques.

Using object-oriented analysis as an example, each step in the use case translates into a set of messages passed between objects in a UML sequence diagram. The initiating actor stands on the left of the sequence diagram (as an object in its own right) and initiates the message into the "internal" objects that comprise the application. Analysts create sequence diagrams for each path in each use case.

NOTE:

In UML, the collaboration diagram is a direct substitute for a sequence diagram. Everything we've said about sequence diagrams applies directly to collaboration diagrams. In our experience, we've seen sequence diagrams applied to business problems more than 80% of the time, but the choice is really the preference of the project team and its stakeholders.

An object-oriented analysis model usually also contains a class diagram. The class names come from mining the nouns in the use case text. All nouns in the use case names, descriptions, paths, preconditions, and postconditions become candidate classes. Once you collect these nouns, a process of removing class names that are redundant, irrelevant, and attributes of other classes can proceed.

State diagrams are normally part of an object-oriented analysis model. Each state diagram takes one of the classes from the class diagram that exhibits "interesting dynamic behavior" and models the states that this class goes through in its lifetime. A state diagram contains states (as you might expect) and transitions . The states can often come from the preconditions and postconditions of use cases (although there may be other sources). The transitions are sometimes the messages that come from the initiating actors in the use cases, and other times are the messages from the sequence diagrams.

8.1.2 Design Model Traceability

REFERENCE:

RUP (design model artifact)

Design models contain the same artifacts as analysis models: sequence diagrams, class diagrams, and state diagrams. Design models differ in that they contain boundary and control classes, whereas the analysis models contain only entity classes. The control classes are often named directly after the use cases they represent. The boundary classes are a result of the user interface design, so they are only indirectly traceable to use cases.

8.1.3 CRC Card Session Traceability

REFERENCE:

CRC card book

CRC (class-responsibility-collaboration) card sessions are an effective tool to determine the operations of classes, also termed responsibility.

In CRC card sessions, the participants hold small recipe cards which have a candidate class name written at the top. In effect, the participants become those objects. Then the group tries to tell the story of a use case with the participants/objects working as a team to supply the necessary information. These sessions are very fun, and they provide tremendous insight into ways the objects can collaborate effectively to achieve the desired results of the use cases. The traceability back to use cases is very clear in CRC card sessions. The stories told are the use case paths, and the results of the CRC card sessions are input into the analysis or design model.

8.1.4 Test Model Traceability

REFERENCE:

RUP (test model artifact)

One of the clearest traceability links is between use cases and test models. After all, it is fairly obvious when you take a step back that use cases are test cases, just moved to the front of the lifecycle and called requirements.

The test plan will likely be organized by use case. The test scenarios will add test data to the use cases to become testable. The test cases will focus on each use case path.

8.1.5 User Interface Design Traceability

User interface design comes from the requirements, including use cases and usability. (For more information about nonfunctional requirement traceability see Section 8.2.) The user interface storyboards use use cases as their "stories," showing how the screen mock-ups progress as a fictional user walks through a use case.

8.1.6 Application Architecture Traceability

REFERENCE:

RUP (software architecture document)

Application architecture provides the foundation for how the components and objects are organized in the target technical environment. As its input, use cases help to identify the control objects or components . Control objects are the objects that manage the other objects into transactions that are useful to users. Those transactions are patterned after use cases.

8.1.7 Project Management Traceability

REFERENCE:

Chapter 7 in this book

Project management in an iterative/incremental project is focused on the production of use cases, meaning that the team works to create working, tested code that automates the stories told in the use cases. We have much more detail on project management in Chapter 7 of this book.

8.1.8 Documentation and Training Traceability

An often-overlooked traceability opportunity on software projects is into documentation and training. The ways the users will want to learn about using the application will be by use case ( assuming the use cases are constructed correctly). They will want to learn one story at a time, stories told from their perspectives. Therefore, it makes sense to organize end user training courses and user documentation by use case. This approach also allows documentation and training professionals to fit in effectively into the iterative/incremental lifecycle. Their documentation and training artifacts can be pieced together one use case at a time as the development team attacks each use case.

8.1.9 Product Marketing Traceability

In software product companies, use cases become an effective marketing tool. As new releases of the software go into general availability, the marketing team has a useful list of the new stories they can tell with the product and subsequently new sections for product demonstration scripts.

8.1.10 Security Traceability

Use cases begin by examining the goals of the actors. The actor definitions provide the basis for creating security profiles. If the actor definitions are defined in the way the users use the application, the actor definitions trace smoothly into security user groups. Similarly, the use cases are the ways the actors use the application, so they effectively become the resources that are assigned to the user groups.

8.1.11 Release Planning

When management of a product is planning a set of releases, it is useful to have a coarse-grained set of features that will go into each release. The most logical pieces to use for this type of planning are use cases. This applies to a software product team or an internal project for an IT shop.