System Use

Team-Fly

---

 

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents
	Chapter 5.  Column Four: People and Organizations

---

System Use

So, how do we go about designing systems that mitigate variety correctly? More significant to this book, how do we describe the particular requirements for mitigated variety?

This opens the door for a new technique called use cases.

The use case is a kind of diagram showing "actors" interacting with a hypothetical system.

According to Paul Harmon and Mike Watson in their 1988 book, Understanding UML: The Developer's Guide , "A use case diagram provides a functional description of a system and its major processes. It also provides a graphic description of who will use the system and what kinds of interactions they can expect to have with the system" [Harmon and Watson, 1998, p. 112].

The decision as to what systems should be built doesn't come until the end of the requirements project, but once the general idea has been established that a particular part of the business should be automated, it is possible to imagine a system that would do it. Given such an imagined system, it is possible to imagine also the kinds of interactions that a person might have with such a system.

But previously we recognized that an enterprise is itself a system, however, so this definition can be extended to describe a piece of the business and the interactions with that piece. To the extent that this approach is taken, it is much like a context or a level one data flow diagram. The "actors" are "external entities" in a data flow diagram, but the idea of how they interact is the same. Ivar Jacobson explores this idea in his 1994 book, The Object Advantage: Business Process Reengineering with Object Technology . This approach can make use cases effective in capturing a business owner's view of interactions with the enterprise.

The technique differs from data flow diagramming, however, in that less attention is paid to the data content of each flow, and the process of "exploding" higher level processes to component processes is less well articulated .

But the use case can be helpful, however, for its focus on the nature of the interaction itself. To the extent that this is in terms of the mechanical details of the user interface, it is firmly in Row Four, the "Designer's View", but if it simply discusses the content of the interaction without describing the technology involved, it is a legitimate Row Three technique for the people and organization column.

The technique originated as a graphic one, with ellipses for "systems", and stick figures for the "actors". (See Figure 5.14.)

Figure 5.14. A Use Case

The problem with this approach is that, as we've said, it doesn't describe the data, nor does it really describe the nature of the interaction at all. In recent years , it has become evident that the use case is not as significant for its graphics, as it is a vehicle for organizing text descriptions. An excellent description of this more verbal approach is Alistair Cockburn's 2000 book, Writing Effective Use Cases . His view of the use case puts it squarely in Column Four: it is inherently a contract between an actor and a system. It is all about the nature of the interaction.

To Cockburn, a use case description must have the following parts :

• Name A description of the goal of the use case.

• Scope The boundaries of the use case. The nature of this depends on whether the use case is for analysis or design.

  • Analysis: Functional Scope This is described in terms of the actors involved and their goals. A use case brief summarizes the scope.

  • Design: Design Scope The set of hardware and software systems to be addressed.

  Each use case must be clearly identified as to whether it is for analysis or design. In this book, we are only concerned with those used for analysis.

• Level What is the level of detail for the use case? This may be very high summary, summary, user-goal, sub-function, or too low.

  Level, here, is described more subjectively than for data flow diagrams. The reference point is the "user-goal"the level where a person would be expected to complete a single task. This is similar to the "essential activity" level described for essential data flow diagrams in Chapter 4, but the criteria for determining it are different. A user-goal could be at a lower level than an essential activity that is the complete response to an external event, but it may not be. For example, a user goal could be the cataloging of a book received by the library, when the essential activity is the entire receiving process.

• Stakeholders and Interests A list of the actors and each actor's goal. An actor is typically a role, such as "inventory manager" or "data entry clerk", not a named individual. A stakeholder is someone who has a vested interest in the behavior of a system, but who may or may not interact with it directly. A primary actor is an actor that calls on the system to deliver one of its services. The primary actor is often, but not always, the one who triggers the use case.

• Preconditions What the use case must determine to be true before it can start. For example, before calculating charges associated with a sale, the customer must be known.

• Success Guarantee What interests of the stakeholders will be satisfied when the use case is complete, whether through a normal path or one of the alternate paths. For example, if the use case describes a depositor's withdrawal from a bank, success consists of the depositor's actually receiving funds.

• Minimal Guarantee What the use case must deliver, even if the "Success Guarantee" is not met. In the bank withdrawal example, even if the transaction cannot be completed (if there are insufficient funds, for example) the depositor must at least be notified as to the reason.

• Trigger The external event that causes the use case to happen. This is the same external event described for essential data flow diagrams. To the extent that the trigger only causes the steps described here, the use case is for an essential activity.

• Main Success Scenario The sequences of steps that take place if all goes well. While one or more of these steps may be described in lower level use cases, they don't have to be. Describing them simply as components of this use case may be sufficient.

• Extensions Attached to steps in the main success scenario, an extension is a list of steps to be followed if the condition for the main step is not fulfilled. For example, if a step in use case "Get paid for car accident " is "1. Claimant submits claim with substantiating data", an extension could be "1a. Submitted data is incomplete", followed by the steps to be taken under these circumstances.

So, to summarize, in describing the roles people and organizations play in interacting with components of the enterprise, a use case can be an effective tool. Care must be taken, however, to ensure that what are being represented are truly interactions with a business function, and not interactions with a system that hasn't been defined yet.

---

Team-Fly

Top