NETTING IT OUT

This report works through the conclusion of a case study of transforming Customer Scenarios® to Use Cases. In this report, we examine how to populate metatdata at the Use Case level from your Customer Scenarios so that you can begin the Use Case analysis process itself.

While Use Cases are not required when you are simply repackaging and delivering existing functionality in a more customer-friendly way, they are useful when the Customer Scenario calls for new functionality to be developed or procured. Customer Scenarios represent an ideal state. The good ones always require new functionality or reengineering of existing business processes and/or the functionality that implements them. Use Cases integrate well with our Service Granularity and Definition Best Practices, giving you additional tools in the requirements definition process. Lastly, Use Cases offer the detailed flow-of-work visibility that is useful for designing and evaluating business procedures and software.

Thus, the techniques discussed in this series of “Scenarios to Solutions” reports will bolster your existing Customer Scenario, SOA, and requirements definition practices, and they can further help you to deliver SOA solutions in organizations that employ Use Case tools for software or business definition and design.

CONTEXT

In Part One of this report1, we undertook a case study and detailed examination of translating Customer Scenarios® into Use Cases. That report focused on creating a high-level mapping to establish scope and context. In Part Two of this report, we examined how one refines the list of candidate Use Cases to ensure that Use Case requirements analysis is performed on appropriate business and IT functionality.

This report continues to apply our best practices for mapping Customer Scenarios to Use Cases, but the focus becomes more detailed as we examine how to populate metadata associated with each of the identified Use Cases.

Make no mistake: this effort to populate metadata does not bring Use Case analysis to closure. Indeed this report will bring you to the point of starting your Use Case analysis work processes. Why, then, should you undertake all of this effort “just to get started?” Because you can be confident that subsequent Use Case requirements analysis work will focus on topical functionality that will support your Customer Scenarios. Without this context and direction-setting effort, you are at risk of performing Use Case analysis on functionality that may or may not end up meeting your customers’ needs. A little “homework” now will pay dividends in streamlining analysis work and delivering better customer experiences later on.

REVIEW OF USE CASE CONCEPTS

Recall that a Use Case is a sequence of transactions in a system, the purpose of which is to produce a result of measurable value to an individual actor of the system. Think of a Use Case as capturing an instance of interactions from among the total capability set that the company and its business partner’s could offer to the customer. If the customer’s desired outcome—or any of the customer’s “I Want to…” statements—is the end result of the Use Case, then analysis on that Use Case will guide us to conclude what specific capabilities the company and its business partners will require to effect that outcome—ergo, business requirements.

A successful transition from Customer Scenarios to Use Cases begins with choices about the following three core elements of a Use Case (See Illustration 1):

• System Boundary. The application or business system boundary, inside of which are Use Cases, business partners, and the company itself; and outside of which is the customer.

• Actors. One or more external actors—humans, software, or machinery that interact with the system—whose interactions we are documenting.

• Use Cases. The functionality or processes that will produce customer-desired outcomes and that will be subject to requirements analysis.

Use Case Example: Custom Linens for the Bedroom

Copyright 2004 Patricia seybold Group, Inc.

Illustration 1. This Use Case model captures some of the Use Cases that will be subject to further analysis by Elite’s team. Note that this model is not complete or comprehensive, intentionally, because the total list of Use Cases as discussed in this report would be several graphical pages long. Rather this is intended as an example of the final Use Case model that Elite’s IT team would develop from their list of candidate Use Cases.

The Use Case diagram comprises just the above three elements. IT vernacular becomes confusing because the Use Case diagram (a.k.a. Use Case model) often is referred to by the shorthand “Use Case”. The units of functionality, also, are called Use Cases. While the diagram presents a quickly digestible overview of the system, the details about the functionality are captured in supporting metadata attached to the actual Use Case (the third element in the list immediately above). To be proper with our terminology, we will refer to these units of functionality by their proper name: Use Case. We will refer to the diagram as a Use Case diagram or a Use Case model.

Let’s take a brief look at the metadata that is populated at the Use Case level during translation from Customer Scenarios...