Better Use Case Diagrams by Using Work System Snapshots

Introduction

Identifying specific processes and activities to be supported by an information system is often a daunting task in requirements determination. Too frequently, important information system functionalities are omitted or misstated (e.g., Rubinstein, 2007). According to system theorists such as Ackoff (1971, 1973), Checkland (1999), and Churchman (1970), understanding any system requires understanding of the larger system that it serves. Information systems are computerized artifacts that are used by participants in work systems. Therefore, understanding of the work system that is supported is a good starting point for understanding an information system and its significance. An understanding of the relationship between the information system and the work system needs to consider different types of activities to be supported or automated by the information system as part of the work system.

Use case diagrams are used widely for defining and depicting the scope of an information system in terms of a set of use cases corresponding to activities supported or automated by the information system. Although there is no totally standard definition of use case, there are several working definitions such as the following (OMG, 2010 – p 628):

At the beginning of an attempt to identify use cases within a particular work system, it is often unclear what the boundaries of the information system will be, i.e., which activities will be automated or supported by the information system, and which activities are part of the work system but will not be automated or supported directly by the information system. Consequently, the specification of use cases within a use case diagram created at the beginning of an object-oriented analysis should start with identification of the work system and then should identify different types of activities.

A good approach for doing this is to summarize the (“as is” or “to be”) work system using a work system snapshot (a basic analytical tool from the work system method (Alter, 2006; 2008; 2013), and then to delve more deeply into each of the activities within the work system snapshot, to identify use cases to be automated or supported by the information system, and then to look at them in more depth to clarify specific functionality required in the information system (see Appendix 1 for a brief introduction to the work system framework and work system snapshots). Thus, our proposed approach recommends summarizing the business situation using a work system snapshot before developing use case diagrams. For this purpose, we propose enhancements to use case diagramming constructs to distinguish between work system and information boundaries, and to differentiate various types of use cases. Evidence from the current research implies that producing a work system snapshot before developing use case diagrams may help analysts identify more use cases that are also of higher quality, thereby help in better determination of the scope and function of the information system to be developed.