NETTING IT OUT

This report works through the first half of a case study of transforming Customer Scenarios® to Use Cases as we recommended in the prior report. Herein, we discuss establishing the Use Case system boundary, actors, and Use Case granularity. The next report will address the detailed mapping between Customer Scenario metadata and Use Case metadata. In addition, this report examines in greater detail how Customer Scenario and Use Case experts and practitioners typically make decisions about the transition, thus providing further insight into the differences between Customer Scenarios and Use Cases and how to best leverage the strengths of each.

Ideally, you would begin your requirements gathering with Customer Scenarios and then do your detailed requirements analysis using Use Cases, as appropriate. 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. Additionally, Use Cases integrate well with our Service Granularity and Definition Best Practices.

Thus, the techniques discussed in this trilogy 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.

CONTEXT

Customer Scenario® Mapping yields rich insights into customer-friendly business changes that will deepen your customer relationships. Our customers frequently wish to scope and specify applications--portals, changes to existing Web sites, changes to existing traditional applications, or possibly new applications to be bought or built--to support their Customers’ key Scenarios. Where new functionality must be constructed or procured, Use Cases are a useful tool in the business-requirements gathering process. This report applies the best practices for mapping Customer Scenarios® to Use Cases that were presented in the prior report of this series.

This report demonstrates how to accomplish the transition from Customer Scenario Mapping to Use Case requirements definition--with the caveat that we are not attempting to instruct with respect to basic Use Case methods and practices per se. Most organizations that employ Use Cases have internal methods and practices standards, or follow external recommendations(1). This report continues our examination of how such standard Use Case practices can be adapted to leverage your investment in Customer Scenario Mapping.

SUMMARY OF METADATA

Prior to undertaking our example, let’s review the metadata captured in Customer Scenarios and in Use Cases, and the mapping between these mechanisms. The metadata that we identify herein represents what you will capture or identify through the documentation and analysis processes involved in mapping Customer Scenarios and developing Use Cases. The mapping expresses how you will transition from Customer Scenario Mapping to Use Case requirements analysis.

Customer Scenario Metadata

Customer Scenarios map an ideal scenario based on what the customer wants to do. The focus of a Customer Scenario is “what is the customer’s ideal experience, and how can we (the company and its partners) make that experience the best, most memorable possible?”

Customer Scenarios comprise five core elements. Typically these are captured on poster paper at the beginning of a Customer Scenario Mapping session and updated as the session proceeds:

• Customer--A named individual representing a key customer segment.
• Scenario--Actions that the customer wants to undertake because she perceives those actions as causal to achieving her desired outcome.
• Customer Context--Key assumptions about the customer and the situation the customer is in as she undertakes the scenario. Desired Outcome--The end-state that spells success to the customer.
• Conditions of Satisfaction--The customer conditions that must be met along the way.

The “body” of a Customer Scenario is captured in metadata, as follows ...