NETTING IT OUT

This report works through the second half of a case study of transforming Customer Scenarios® to Use Cases. We continue our discussion identifying the Use Cases--the functionality that will be subject to further Use Case requirements analysis. This report will be followed by Part Three, which will wrap up our examination of how to populate metadata 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 simply repackage and deliver existing functionality in more customer-friendly ways, they are useful when Customer Scenarios call for new functionality to be developed or procured. Customer Scenarios represent an ideal state, and they almost 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. Additionally, 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 these reports will bolster your existing Customer Scenario, SOA, and requirements definition practices, and they can help you deliver SOA solutions in organizations that employ Use Case tools for software or business definition and design.

CONTEXT

In Part One of this report, 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. Specifically we addressed the issues and considerations involved in delineating the following:

* System Boundary. The System Boundary is the "box" on the Use Case model that separates external actors from the chunks of system functionality called Use Cases. The box may encompass a software system, a non-software business system, or a combination of software and business functionality.

* Actors. Actors are human, mechanical, or software players with which the system interacts, such as the customer or a credit card verification service.

* Use Cases. Use Cases are the units of functionality that comprise the system. The best practices discussed in this trilogy recommend IT services as the preferred unit of functionality, thus encouraging a modular, plug-and-play perspective on software as well as business functionality.

This report continues to apply our best practices for mapping Customer Scenarios to Use Cases, but the focus herein shifts to the Use Case list and to the metadata and issues associated with individual Use Cases. It is the Use Case itself, as opposed to the overall Use Case model, that becomes the primary subject of further requirements analysis.

This is not to suggest that the system boundary is unimportant or that it will not change as a result of your further analysis work. Rather, when one takes a services perspective on a business or software system, well-defined chunks of functionality can be added or removed with relatively greater ease and freedom than with other design approaches. This, of course, is a major selling point for SOA and portals as functionality and data delivery mechanisms. As customer needs change, opportunities arise, or your business changes, SOA solutions are less tied to the structure of the Use Case model--the whole system--and are more flexible.

Our first task, then, is to refine this list of Use Cases that will be subject to further analysis. Then we can begin analysis on the individual Use Cases.

REFINING THE USE CASE LIST

Recall that Use Cases--the ovals inside the system boundary--represent chunks of business or software functionality. A Use Case model (the diagram with the System Boundary, Actors outside of the boundary, and ovals inside the boundary) usually comprises multiple Use Cases. Part One of this report outlined our recommendations for identifying candidate Use Cases and for arriving at a suitably complete list of Use Cases for requirements analysis.

Let us apply those recommendations to examples from the Elite Linens case study. As we do so, keep in mind that the objectives of the balance of this section are:

* To ensure that we have a complete and correct list of Use Cases within the system boundary

* To identify which Use Cases require further requirements analysis, and remove from the list any Use Cases that do not.

As we shall see shortly, a complete and correct list of Use Cases within any given Use Case model's system boundary differs from the complete and correct list of IT services used to support a given Customer Scenario. Furthermore, not all chunks of functionality inside the system boundary (i.e., Use Cases) are best defined or specified through Use Case analysis. Some functionality, which generally will be IT services, is most efficiently defined through object modeling, data modeling, or simply by application of our service granularity and definition best practices.

This creates a dichotomy that requires up-front clarification: When we add a Use Case to the candidate list, we have identified a new Use Case and are adding it inside the system boundary. When we remove a Use Case from the list, however, we are not removing it from the system boundary. Rather, we are removing it from the list of those selected Use Cases for which further Use Case analysis likely will add value.

You still may be required--by your organization's standards and IT practices--to perform complete Use Case analysis on every Use Case, even if our best practices recommend dropping it from the "for further analysis" list. This is an organizational policy issue that exists to ensure thorough IT practices. Our objective in these reports is to help you differentiate value-adding from non-value-adding situations, so that you can emphasize resources and apply additional requirements techniques with greater certainty and address policy issues (when and where meaningful) from a reasoned basis.

These issues will be illuminated further as they arise in the balance of this section...