A Work System Front End for Object-Oriented Analysis and Design

An Alternative Starting Point For Analysis And Design

This paper explores the possibility of using work system concepts as the front end of an object-oriented analysis and design (OOAD) process, thereby addressing a widely recognized problem related to difficulties in communication and collaboration between business and IT professionals. The problem is that many concepts and methods designed for IT professionals simply do not satisfy the needs of business professionals. The fact that some highly talented IT professionals may do fine with the existing toolset and approaches does not minimize the confusion and blank stares encountered by many others when trying to apply technically-oriented representations with end users.

This paper shows how the problem may be addressed by linking ideas from an analysis and design approach for business professionals with established analysis and design concepts and methods for IT professionals. The first group of concepts comes from work system theory (WST) and the work system method (WSM). WST is a theoretical basis that emerged from an effort to develop a systems analysis method for business professionals that was eventually called WSM. Various versions of WSM – based on WST - were developed and tried out with MBA and Executive MBA students over many years (Alter, 1995, 2003, 2006, 2013; Truex et al., 2010). WST and WSM are explained in the following section. The second set of concepts consists of use case diagrams and other UML artifacts associated with OOAD, which was developed as a method for IT professionals attempting to produce software that meets requirements produced in collaboration with managers and other business professionals. The creators of UML asserted that any modern object-oriented approach to developing information systems must be (1) use case driven, (2) architecture-centric, and (3) iterative and incremental (Dennis et al, 2009, p. 18). OOAD produces formal specifications that help IT professionals produce well-designed software.

Establishing links between WST/WSM and OOAD addresses important problems in requirements determination, a process that is problematic and error-prone due to difficulties in communicating between business-oriented and IT-oriented worldviews. With a business-oriented worldview, the system of concern is a work system in which human participants perform work using information, technologies, and other resources to produce product/services for internal or external customers. This work system focus is directly related to topics that managers and business professionals care about greatly, i.e., how well their work systems perform and how to improve performance. In contrast, specifications for IT-based tools are more distant from both their understanding and their concerns. With an IT-oriented worldview, the system is an IT artifact that is used by users while performing work. Thus, without diminishing the importance of UML specifications for architecture-based software development and maintenance processes, there is no reason to assume that initial collaborations between business and IT professionals should be framed around concepts that drive object-oriented specifications for IT professionals. It is possible that interacting around use case terminology introduces an unnecessary bias because it focuses on uses of technology rather than work system improvement. Ideally, collaboration with business professionals should occur around concepts they understand fully. Subsequent efforts should generate the technical specifications that programmers need.

This paper is organized as follows. A background section summarizes the limitations of use case diagrams. The next section presents an overview of WST and WSM, including the definition of work system, the work system framework, work system life cycle model, work system method, and work system metamodel. A hiring system example illustrates two ways to summarize a work system: a work system snapshot based on the work system framework and a more detailed summary based on the work system metamodel. The more detailed summary is called an Activities, Resources, Triggers and Products (ARTP) table as it includes resources used by each activity along with relevant triggers, preconditions, and post-conditions including product/services that are produced. The final sections explain how information in the work system snapshot and ARTP summaries can be converted into use case diagrams and can lead to other UML artifacts such as use case descriptions, domain class diagrams, and activity diagrams.