Why Build a Decomposition Diagram?

A decomposition diagram is a simple graphic display of a business area. It is easy to review and revise. A decomposition diagram can be created at a high level or detailed level. It can be used to design any type of solution: software, hardware, procedural, or manual. When it includes true, essential business processes, it is a lasting model of the business that can be refined and reused on future projects. A decomposition diagram can be used to organize many things—data, goals, problems, etc.

Use Case Diagram

A use case is a goal of a software system. It comes from the Swedish word anvendningstall, which means situation of usage or usage case. A use case diagram shows the main use cases along with the actors who are involved with them. The use case diagramming technique was developed to show functional requirements—how a software system interacts with its users (actors). It is typically used to present a future view of a system. The technique was developed in the mid-1980s and has become a very popular technique for documenting requirements (Jacobson, 1992). This diagram is useful for showing the scope of a project or a software product (see the discussion on scoping in Chapter 3).

Figure 6.5 shows an example of a use case diagram. Use cases are depicted as ovals and actors as stick people. Actors are people, organizations, or systems with which the software interfaces. In addition to use cases and actors, the use case diagram includes an automation boundary. This boundary delineates what the software includes and shows the interfaces to the software with the association lines. Associations to people actors represent user interfaces like screens and reports. Associations to system or organization actors represent automated or electronic interfaces.

Figure 6.5: Sample Use Case Diagram

Although the use case diagram was developed as a software design technique, it can be used at the business requirements (non-technical) level. Use cases may be named and defined as independent of technology (referred to as business use cases). The automation boundary can be used to represent the business or project boundary. This allows the use case diagram to show the scope of the requirements or analysis work.

Use Case Descriptions

Each use case on a use case diagram is described in a use case description. The use case technique is popular because each use case description is a functional requirement deliverable that contains all of the requirements components for a particular software function. A use case description also includes a sequential set of steps that describe how the software and actors should interact to achieve a business goal. This dialogue presents a clear picture to business stakeholders of how they will use the new software before it is built. The dialogue also provides developers with detailed instructions about how to build the software.

Within the steps of a use case, analysts typically include a primary path (the happy path) along with alternate paths. These alternate paths show exception processing and error conditions. For each step, the analyst describes the action that the actor will take and the way the system should respond. This description may include detailed data requirements along with the business rules that apply (Cockburn, 2000). See Figure 6.6 for an example of a use case template.

As with all analysis techniques, developing the deliverable is more complex than it would initially appear. Organizations that have started using use cases as a standard requirement deliverable sometimes find analysts struggling with consistency and level of detail. There are stories of use cases that have grown to 100 pages. Is this a useful deliverable? To successfully use this technique, analysts must be well trained and the organization must have some guidelines about how it is used. When used in combination with other requirements deliverables (i.e., ERD, prototypes), use case descriptions can be created in manageable sizes and can be very useful.

One of the major weaknesses of the use case approach is that a use case description may contain several requirements components (data, process, business rules, external agents) instead of documenting them separately. Documenting components together makes it very easy to miss requirements and makes reusability of components very difficult. Most data elements in information systems are used by more than one process. When a data element is documented inside a use case, it must be redundantly defined in every use case that needs it. This leads to wasted time writing requirements and the possibility for a lot of errors. If a characteristic of a data element changes, you need to go to every use case that uses it to make the same change. If you miss one, your requirements are inconsistent and there will be errors in the software—guaranteed!

Figure 6.6: Sample Use Case Description Template

To make your use case descriptions more concise and consistent, define the individual requirements components separately (with unique names) and simply refer to them in the use case descriptions. This alleviates the need to change every use case description when a data or business rule requirement is changed.