“Use cases,” a term coined by Ivar Jacobson early in the evolution of object-oriented thinking, have been widely accepted as a helpful way to understand and document the functionality that is important in all kinds of software or business systems. Anyone within miles of object-oriented design will be familiar with the typical application of use cases.

Six Sigma can provoke useful extensions to familiar methodologies. One such extension is the coupling and Six Sigma processing of measures with key use cases. As the functionality described by many use cases begs measurability, creating an early clear link with measures facilitates better understanding of requirements, measurement and test system planning, Y-to-x flowdown and performance prediction and verification.

Use Cases Describe Requirements in Action and Customer Language

Use cases look at a system at its edges – where “actors” (individuals or other systems) interact with it for some benefit. They describe what each actor “should be able to do” in the simple language of positive, active-voice verbs – making them equally understandable by non-technical customers and sophisticated engineers. That alone is a powerful thing. They provide a quick and simple mechanism for reaching shared understanding between customers and suppliers about what’s important to address.

Most often use cases are developed from high level requirements, converting them into the more detailed, actor-centered verb form. For example, a requirement like “users must be able to enter and manage their own shipments online” might be broken down into a series of functional steps. Use cases naturally organize into a hierarchy, making it easy to create views of requirements set at the high abstraction level. For example, a main use case like build shipment may be broken down into daughter use cases like “open account,” “locate items,” “compare options,” “verify availability,” “create order” and “schedule delivery.” Of course, each of these could be further broken down, if necessary. Figure 1 shows a few of these use cases in a form that resembles graphical use case diagrams popularized as part of the Unified Modeling Language (UML).

Exception Cases Inform Robust Design

In addition to the main use case, one or more exception scenarios are often outlined. These document special situations, like “items unavailable,” “payment method declined,” etc. The exceptions should be considered along with the routine functional “promises” that the system may make with each relevant actor. From a Six Sigma perspective, this helps inform robust design, as the extreme and less-expected conditions can be anticipated early in the design process. This allows designers to make provisions for the system to handle or be less-sensitive to those conditions.

Use case discipline around the use of verbs is important. It enforces a solution-free description of “pure functionality.” The first payback, of course, is the object-oriented notion of encapsulation. By focusing on the promises that a system makes at its interfaces, the underlying details about how that functionality is developed and managed can be encapsulated – hidden from the concern of others, retaining important design and code flexibility.

Another benefit, particularly important in Design for Six Sigma (DFSS), is the way use cases clarify understanding within a development team and between that team and customers, starting at the earliest development steps. By looking for just the right verbs to describe what is important, reviewing and refining the list back and forth with customers, a development team focuses on what is important without getting prematurely drawn into discussions about solutions. While jumping to solutions is tempting, and common, experience shows it can create dangerous blinds spots when requirements are fully understood. Getting the use cases right builds a base for fresh and thorough solution ideas at the right stage in development.

Measures Can Enrich the Use Case View

Six Sigma practitioners know that as they figure out how to measure something, they often come to better understand it and are better able to manage it. That seems to be the way it is in use cases. While use cases, as a language for functionality are great, they gain power when coupled with measures. When a team and its customers think about how to appropriately verify and track the performance of key use cases they can gain even more shared understanding than the use case alone might provide. Initially, thinking about the approach to measuring how well a use case is working is enough – no need to detail or build the measurement systems at that point. Not all measures are engineering floating point numbers, of course. The approach to verifying a use case can range from simple presence/absence checks to continuous performance measures. Some examples include:

• Yes/no (checkbox)
• Presence/absence of multiple items (checklist)
• Error rate (false alarm and escape rate)
• Cycle time (execution speed)
• Percent of cases in some class of outcomes
• Availability
• Reliability
• Performance measure

The table to the left shows some simple examples of measurement approaches that might be connected with the functionality in a few use cases. While the use case describes what is important, the added information in the measure extends the detail about what is essential. This can improve the dialog that marketing and sales have with engineering. A goal like “verify availability” becomes clearer when coupled with the approach to quantifying the desired outcome(s).

Key Measures Lead the Way to Further Six Sigma Analysis

With prioritization, some measures will emerge as the most important few. As an illustration, suppose that the “Percent of the top 1,000 items in stock” is found to be one such critical to quality (CTQ) metric (as indicated in the table above). That opens the way to Six Sigma rigor around understanding the current baseline performance, setting improvement targets, and the drilling down (or flowdown) to lower level factors that may be influential in driving that CTQ. Figure 2 illustrates a part of the flowdown for this CTQ. Targets and acceptable ranges should be placed around appropriate measures before the design concept selection commences. The measures then provide a quantitative, fact-based way to compare alternative solution choices and select the best.

In summary, Figure 3 illustrates the life cycle of a use case – beginning with its inception, based on understanding of information about what actors wish to be able to do. Starting in the actor’s process, the team listens to what the actors express to be important (“needs data”) while gathering some backdrop information about what it’s like in the “problem space” (who, what, where, when, how much, in what way, etc). Functional use cases take shape and become understood and agreed upon. In the Six Sigma processing, measures further clarify what’s important and provide the right Six Sigma “handle” for target-setting and flowdown. Measurable use cases guide solution selection and provide a big head start on the identification of test cases. A work product, delivered back to the actor’s process, that lives up to the functionality and measured success criteria runs a pretty good chance of meeting or exceeding real customer expectations. That kind of success can be documented and agreed upon – one of the basic Six Sigma bottom-line goals.