| In the late 1990s much was made of the use case approach to defining system requirements. According to Paul Harmon and Mike Watson, "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]. A use case consists of a graphic showing a system as an oval, and one or more actors interacting with it. An actor is the person, organization, or computer system that is interacting with a system. In addition, supporting documentation describes the triggers of the use case, the steps taken, and alternative steps that are taken under specific circumstances. As normally used, then, a use case is not a description of the business. It is a description of a hypothetical system. Therefore it does not belong in Row Two of the "Activities" column (Column Two) of the Architecture Framework, as it does not describe the business user 's view of an enterprise's activities. Neither does it belong in Row Three, according to that definition since it does not represent the architecture of an enterprise's activities. As will be shown in Chapter 5, the definition of "system" can be extended to mean a piece of the business itself, however, and a use case can describe the business owner's view of the interactions with that piece. Ivar Jacobson explores this idea in his 1994 book The Object Advantage: Business Process Re-engineering with Object Technology . 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. The difference is that it does not describe the nature of the communications data, and it is not as rigorously defined. The rules for exploding a process, for example, are not well documented in any of the literature currently available. A use case, then, presupposes that a boundary has been drawn around a future system and it describes the nature of the interactions with that system. Because it focuses on interactions more than the actual activities performed, it more appropriately belongs in Column Four ("People and Organizations"), either in Row Three (describing the nature of interactions with a part of the enterprise's functions) or Row Four (describing a user interface). For that reason, use cases are described more fully in Chapter 5. |
