NETTING IT OUT

This report begins a new methodology series. Our focus shifts from Service-Oriented Architecture to the methods and mechanisms that move you from Customer Scenarios® to IT solutions that support those scenarios. This series will culminate in a discussion of our reference architecture to pull together all of the methods and mechanisms discussed along the way. This first report examines the relationship between Customer Scenarios and Use Cases.

Patricia Seybold Group’s Customer Scenarios® are well established as the preferred way to understand your organization from your customers’ viewpoints and to drive changes that make your organization easier for your customers to do business with.

Use Cases are commonly used to capture requirements for IT projects and to design IT systems. Some practitioners employ Use Cases to express interaction between business processes and external actors--customers and suppliers--and/or to re-engineer business processes. The goal is to make applications--and the organization itself--easier to work with.

Ideally, you would begin your requirements gathering with Customer Scenarios and then do your detailed analysis using Use Cases, as appropriate. Use Cases are useful when the scenario calls for new functionality to be developed. Use Cases are not required when you are simply repackaging and delivering existing functionality in a more customer-friendly way.

Given common goals, one might expect a direct translation from Customer Scenarios to Use Cases. In our experience, this is not entirely so. We find our customers struggling with “How do I map my Customer Scenarios into Use Cases so I can define requirements for this application, portal, etc.?” Customer Scenarios and Business Use Cases are both compatible and at odds with one another. This report will show you how to resolve the differences and to achieve your desired results.

CONTEXT

We frequently encounter customers struggling with the relationship between Customer Scenarios and Use Cases. They have successfully engaged their customers in our Customer Scenario Mapping process and have a rich set of Customer Scenarios that offer specific insights into customer-friendly business changes that will deepen their customer relationships. Our customers then set about scoping and specifying applications--portals, changes to existing Web sites, changes to existing traditional applications, or possibly new applications to be bought or built--to support the key Customer Scenarios.

Situation: many organizations employ Use Cases to capture application requirements, using tools such as IBM’s Rational RequisitePro or using document templates in Microsoft Word. Those requirements feed subsequent analysis and application design processes in tools like Popkin’s System Architect and Rational Rose. Thus, with Customer Scenarios in hand, the apparent next step for business analysts and IT architects would be Use Case analysis based on input provided by the Customer Scenarios.

Our conclusion, based on customer experience and our own research, is that this can work if approached correctly. The mapping is not 1:1, and attempts to drive Customer Scenarios directly into Use Cases generally fizzle. Your results--and the relative usefulness of such a translation--will depend on how you apply Use Cases, how you map the respective metadata, and on what you actually need to accomplish to deliver IT support for your key Customer Scenarios.

Furthermore, we conclude that this translation is not always necessary, depending largely on what kind of IT solution or functionality you seek to deliver. Be very cautious here. At issue is not a “problem” with Use Case analysis. Rather, you may have sufficient requirements information from your Customer Scenarios and subsequent services granularity and definition processes(1) to proceed directly to services and portal design--provided that you do not have to substantially develop the functionality within the services that you plan to deploy. Thus, organizations that plan to deploy existing functionality wrapped as Web services are likely to find that a detailed Use Case requirements analysis is not necessary for successful support of key Customer Scenarios.

This report examines the metadata captured by Customer Scenarios and Use Cases, compares and maps the two, and assesses how to make the mapping productive in your application requirements definition process. We conclude this report with recommendations for successful translation from Customer Scenarios to Use Cases and advice as to where that may be appropriate and useful.

A WORD ABOUT TERMINOLOGY

Much of this report is devoted to a discussion of metadata. The common general usage of this term means “data that describes data”--the data that modelers and designers capture to describe the characteristics and structure of other data.

Among our clients, we also hear two major variations on this theme:

• Metadata describes the characteristics of business data. Examples would include the color, sizes, fabric selection, designs and textures of customer linens offered by a retail store. The data, in this case, might be “red” and “royal blue” for color, “king” and “queen “for size, “fitted” and “flat” for designs, etc.
• Metadata also describes the characteristics of modeling constructs. Examples include “entity” and “attribute” on an entity-relationship diagram, “actor” and “system boundary” on a Use Case diagram and “moments of truth” and “business roles” on a Customer Scenario. The data, in this case, might be “customer” and “product” as entities, “customer” and “catalog campaign manager” as business roles on a Customer Scenario or Use Case.

The difference between these two usages, of course, is the subject matter being discussed...