Deliverable 1: Standard Use Case Format

Up one level to Project Process

Next section to: 2008 Digital Energy Conference Workshop Results

A use case documents the typical interaction between a user and a system. It captures some user-visible functions and achieves a discrete goal for the user . Use case templates are composed of a list of all actors used in the model, the business purpose of the use case, description of the process, list of pre-existing significant conditions, and flows/alternate flows. A use case clearly shows the order of events and the responsibilities of the actor(s) and the system in a single use case scenario, without committing to technical design decisions. There are three key components to describe a use case:

  1. The actor or actors involved. (An actor is a type of user who interacts with the system.)
  2. The system being used.
  3. The functional goal that the actor achieves using the system.

TYPES OF USE CASES

Continuous, Free-Form Narrative: The original style of use cases has been a continuous, free-form narrative style. The disadvantages of such an approach are that (i) there is no clear separation between the user of the interchange and the system side, (ii) lack of structure, and (iii) no distinction between internal and external requirements.

Scenario: Composition of one or more enacted use cases expressed as an extended narrative.

UML Use Case Diagram: Unified modeling language (UML) is intended to help design effective object oriented software. UML is used to describe objects, their attributes, and the relationships between objects at some point in time. This description fits perfectly with what can be achieved by the three key components of a use case. Actors – objects with attributes, relationships as the functional goals, and the overall system with all objects, attributes, and relationships.

Numbered Sequence: A narrative is written as a series of numbered steps. The advantage of such an approach is that the separation into distinct steps makes it easier to skim the use case. The disadvantage of such an approach is that systems and user actions are intermixed.
Partitioned Narrative: A more detailed narrative, compared with the numbered sequence approach, is achieved by taking the scenario approach and partitioning it with more steps involved in the process.

PROGRESS OF STANDARD USE CASE DEVELOPMENT

A standard use case format surfaced through the evolution of this project. The tools discussed in this section are largely techniques utilized within the field of quality management. More information about these tools can be found in Juran’s Quality Handbook by Juran and Godfrey, The Six Sigma Handbook by Pyzdek, The Six Sigma Memory Jogger II by Brassard et al., and The Quality Toolbox by Tague.

This project involved in-depth interviews with subject matter experts (SMEs) to define and document the processes and interactions within the JVR and JVPR processes. Information gathered from SMEs was documented using affinity diagrams. An affinity diagram is a hierarchal display of information obtained from different sources. The structure of this diagram groups information within the themes or categories represented by the information obtained, as shown in Figure 20.

figure20.JPG
Figure 20. Standard configuration of an affinity diagram.

Affinity diagrams are typically created by completing the following steps, which are demonstrated pictorially through the creation of an affinity diagram to investigate the problem of sub-standard customer service.

  1. Collect or brainstorm ideas related to the issue under consideration.
  2. Lay out the ideas on note cards (one idea per note card) (see Figure 21a).
  3. Arrange note cards into groups that represent common themes (see Figure 21b).
  4. Create a label for each group that captures the main theme of that group (see Figure 21c).
figure21a.JPG

Figure 21a. Affinity diagram – Step 1: Listing ideas on note cards.


figure21b.JPG

Figure 21b. Affinity diagram – Step 2: Arranging ideas onto natural groupings.


figure21c.JPG

Figure 21c. Affinity diagram – Step 3: Labeling groups with themes.


This section has outlined the general process of creating an affinity diagram. The organization of the information obtained through SME meetings in the form of an affinity diagram is provided in Section 4 of this report. More about what was learned from SMEs can be gleaned from the detailed exhibits shown in that section.

To understand the subject area under investigation, initially a tree diagram was created to document the elements within JVR. A tree diagram is a tool that helps to break down broad categories into finer and finer levels of detail. The tree diagram starts with one item that branches into two or more, each of which branch into two or more, and so on, as shown in Figure 22. Tree diagrams are primarily used to as a tool to help break down or stratify content areas in progressively greater detail. The objective is to partition a complex system into its components. This helps to focus on the overall goals and better understand the system under investigation. Tree diagrams can either be drawn horizontally or vertically. Figure 23 provides an example of a tree diagram for the system of managing blood sugar level for diabetes patients. Notice the various components associated with this process.

figure22.JPG

Figure 22. Standard configuration of a tree diagram.


figure23.JPG

Figure 23. Example of a tree diagram regarding a system to manage blood sugar levels in diabetes patients.


Next, flowcharts were utilized in the project to capture the steps within the JVR process. A flowchart is a picture of the separate steps of a process in sequential order, including materials or services entering or leaving the process (inputs and outputs), decisions that must be made, people who become involved, time involved at each step and/or process measurements. Flowcharts are also known as process maps or flow maps. First, a high-level flowchart was created. This diagram utilized the basic flow chart symbols as shown in Figure 24. Flowcharts are typically created by completing the following steps:

  1. Determine the boundaries of the process
    • Define the starting point (What happens first?)
    • Determine the ending point (What happens last?)
  2. List all the major steps in the process
    • Use established flowchart symbols
  3. Sequence the steps from the first activity to the last
    • If possible, physically walk through the process
    • List what “is”, not what “should be”
  4. Draw the appropriate symbols and show flow using arrows
    • Keep it simple, yet detailed
  5. Test for completeness by reviewing all the steps in the process
    • Make sure the flowchart is at the depth of detail necessary for your purposes

An example of a flowchart for a loan application/approval process typical for a bank is shown in Figure 25.

figure24.JPG

Figure 24. Standard flowchart symbols.


figure25.JPG

Figure 25. Flowchart depicting a loan application/approval process.

Then, a more detailed flowchart, specifically a swim-lane diagram, was constructed to show the actors within the process. In this project, the swim-lane diagram is accompanied by a written description of each task. A swim-lane diagram is a specific type of flowchart that depict what or who is working on a particular process. Again, these diagrams can be arranged either horizontally or vertically and are used for grouping the sub-processes according to the responsibilities of the actors in the process. The swim-lane diagram differs from other flowcharts in that processes and decisions are grouped visually by placing them in parallel lanes that divide the chart—one lane for each actor. An example of an expense reporting process depicted using the swim-lane format is shown in Figure 26.

figure26.JPG

Figure 26. Swim-lane diagram depicting an expense reporting process.


This section has outlined the general process followed in this project. A standard use case format will be drafted in the next phase of documenting the JVPR workflow in the form of a sequence diagram. This will incorporate some information already shown in the swim-lane diagram (but not all) after it is approved by SMEs and the SPE community. The final form of a use case that evolves from this project will be adopted to present the final results of this project.

Up one level to Project Process

Next section to: 2008 Digital Energy Conference Workshop Results

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License