From Scenarios to Solutions: Use Case Techniques Applied, Part 1

Transforming Customer Scenarios to Use Cases

December 24, 2003

This report works through an example of translating Customer Scenarios into Use Case models and provides guidelines for successful identification of the Use Case model system boundary, actors and Use Cases. This is the first of a two-part report. The second report will address detailed metadata translation, which translation occurs within the context and boundaries established by the best practices demonstrated in this report.


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.


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.


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 ...

Sign in to download the full article


Be the first one to comment.

You must be a member to comment. Sign in or create a free account.