Gil Regev
Ian Alexander
Alain Wegmann
A version of this paper
appeared in
Business Process Management Journal,
"Goal-oriented business process modelling"
Guest Editors: Ilia Bider and Paul Johannesson
Volume 11 Number 6 2005 pages 695-708
Abstract
An organization's business processes are sequences of activities. Some are intended to create value for customers; others prevent abuse; still others set strategic targets. This paper presents a modelling approach for these three aspects, based on use cases for desired processes and misuse cases to describe hostile processes. The modelling approach is rooted in General Systems Thinking (GST) and Cybernetics, explaining business processes as a regulatory mechanism. Organisations are treated as organisms which homeostatically maintain their internal states and their relationships with their stakeholders in the presence of disturbances from their environment. Business processes both define the desired states and provide the means to reach them.
Introduction
An organization’s business processes are usually thought of as sequences of activities designed to create value for a customer (Hammer and Champy 1993). Not all the activities comprising a business process directly participate in this creation of value. As stated by Hammer and Champy, business processes also contain activities designed to prevent abuse of the process. Thus in order to define a complete business process, an organization needs to understand what value it wants to provide to its customers, what are the potential abuses it may face while providing this value, and what kind of actions it is ready to take to protect itself from these abuses.
In this paper we present a modelling approach that may help to understand these three aspects. The approach is based on a modelling technique inherited from Requirements Engineering (RE). The approach consists of modelling the value creation and protection activities with so called use cases and the potential abuses with so called misuse cases. The modelling approach is rooted in a theoretical viewpoint, based on General Systems Thinking (GST) and Cybernetics, explaining business processes as a mechanism through which an organization regulates its relationships with its stakeholders.
In Section 2 we briefly describe the regulation viewpoint of organizations. In Section 3 we explain the role of business processes in this regulation. In Section 4 we introduce the concepts of use cases and misuse cases. In Section 5 we explain how business processes can be modelled with use cases and misuse cases. In Section 6 we review the relevant related work.
Organizations as regulators of relationships
GST (von Bertalanffy 1968; Weinberg 1975; Weinberg and Weinberg 1988) and Cybernetics (Wiener 1954; Ashby 1956) provide an explanation of organized entities as systems that maintain their identity in a hostile environment by regulating relationships with this environment. This viewpoint takes as a point of departure the second law of thermodynamics that states that a closed system invariably drifts towards disorder. To maintain its internal order, a system needs to have relationships with its environment. It needs to be an open rather than a closed system. An open system uses its relationships with its environment to maintain its internal order. These relationships are therefore necessary for the system but they also constitute a threat to the internal order of the system if not properly controlled. Hence, from a regulation viewpoint, systems regulate (impose order on) their relationships with their environment in order to maintain their internal order. We thus have a circular process where the internal order (the structure) of the system is maintained in a stable state because of the regulation of the relationships between the system and its environment. But this structure is what enables the system to regulate its relationships with its environment (Weinberg and Weinberg 1988, p. 157).
Applying this viewpoint to human organizations, we can identify business processes as one of the mechanisms by which organizations regulate their relationships with their environment. Organizations can thus be seen as open systems that have relationships with other systems in their environment. These relationships must be controlled, as they can both threaten the stability of the organization and support it. The stability of the internal and external relationships of an organization is what defines its identity.
The principles of homeostasis (first enunciated by the physiologist Walter B. Cannon) provide a set of heuristics that explain how the identity of a system is maintained stable in an unstable environment. These principles, restated in a business process vocabulary are:
An example of a homeostatic behaviour can be seen in a financially troubled company. When a change in the company’s finances drives revenues or profit uncomfortably below expectations, several actions will be taken to compensate for this change. These might be to invest in new products or to reduce expenses. If things get better, it means that the effectiveness of the company to face such non-welcome change has probably increased. If, on the other hand, things don’t get better, successive action is to be expected, such as more reduction in expenses. However, this is likely to cause more harm than good, as it may damage investment for the future. Hence, some factors should be in place to safeguard against excessive spending cuts. Moreover, if the company is unable to compensate for this unwelcome change in a given timeframe, external organizations such as investors may intervene to save it.
The process implied by Cannon’s principles can be represented in a diagram such as Figure 1. Whenever a change is detected in a variable, a corrective action is automatically taken. The stable state, maintained by the homeostatic system, is usually called a norm (Vickers 1987; Liu 2002). Hence, Vickers defines a norm as a (1987, p. 14) "governing relation by which the actual course of affairs may be judged." In this context the desired state, the norm, represents the goal of the corrective actions.
Figure 1: Oscillations around a norm
We consider that the state of a variable is pushed away from the norm by the influences exerted on the system by its own subsystems and the systems in its environment. In organizations, these influences are not automatically met by corrective actions (Vickers 1987, p. 16). In an organization, the norms may change with response to influences. Indeed, in human organizations norms change continually. This change in norms can be referred to as learning or adaptation to the environment. Moreover, the use if corrective actions is often supplemented by anticipation of future changes resulting in preventive corrective actions being taken because the organisation fears that some changes may affect its norms.
The different stakeholders of an organization expect it to maintain different norms. These norms are potentially conflicting in nature (Vickers 1987, p. 15). For example, customers may expect an organization to maintain low prices while investors may expect it to turn a higher profit every year. The organization therefore needs to set norms that represent tradeoffs between the conflicting norms requested by its stakeholders. For example, the prices charged to customers may not be as low as those that the customers may expect and the profit may not be as high as what the investors may expect.
The organization also needs to limit the change it allows for its norms when its stakeholders request such change. For example, customers who request a decrease in price may not obtain such a decrease because the organization may feel that this is an unacceptable change to its norm. The norms of the organization can also come under threat from stakeholders that the organization considers non-legitimate such as criminals doing money laundering.
The Regulative functions of business processes
The regulation viewpoint described above gives us a framework with which to understand the behaviour of organizations. In this viewpoint business processes are seen as the norms of behaviour of the organization. We find it convenient to classify these norms of behaviour into three levels:
For example, a first-level business process is 'Sell a Product'. Salesmen are expected to follow the norm, a sequence of activities to achieve a successful sale without excessive risk to the company. This process may be regulated by several second-level business processes, such as 'Control Credit' and 'Enforce Process Compliance'. Credit may be controlled automatically by a financial mechanism triggered by credit level; whereas process compliance may be controlled by human regulators inside or outside the company, e.g. Quality Assurance, Financial Services Authority, Ombudsman. The first-level and second level processes exist to help achieve and maintain zeroth-level non-operational goals such as 'Establish Corporate Image'; such abstract high-level goals are themselves regulative of all lower-level goals, e.g. driving the style of sales efforts and hence the Quality Assurance procedures themselves. These three regulatory levels are shown in the use case diagram in Figure 2: high-level use cases are to the left.
Figure 2: Use & Misuse Cases modelling the three regulatory levels
In the next two sections we explain the concepts of use case and misuse cases as well as how to model business processes with these concepts.
Use Cases and Misuse Cases
Use Cases were proposed by Ivar Jacobson as a way of resolving the confusion of means and ends in object-oriented system specification (Jacobson 1992). The idea was to capture brief narratives describing possible uses of the system under design as distinct cases; these could then be implemented in the design one at a time. Each narrative would be named as a Use Case and diagrammed as an elliptical bubble. The role principally involved with the use case would be diagrammed as a stick-man, linked to the bubble (Figure 3). (Unfortunately Jacobson used the confusing term 'actor' to mean role, apparently based on the Swedish word Aktör, derived from the French Acteur but with a shifted meaning.)
Figure 3: Use Case
Alistair Cockburn extended Jacobson's Use Case concept by identifying the use case's name as a functional goal, and by documenting a suggested structure for use cases, to include a primary or main success scenario, as well as exception (he called them 'extension') scenarios to handle undesired events (Cockburn 2001). This made it clear that use cases documented system behaviour desired by people (or possibly other intelligent agents) playing specific system roles. Cockburn also proposed a range of templates for use cases ranging from sketchy to 'fully-dressed', effectively converting the use case into a complete framework for documenting functional requirements (Figure 4).
Figure 4: Fully-Dressed Cockburn Use Case Template
Meanwhile, practitioners found the use case approach convenient for thinking about business processes as well as system behaviour, and documented processes as scenarios using use case notation for their context diagrams. Cockburn writes:
"A use case is a 'form' of writing, just as is an outline, a table, a FSM, a sonnet, a haiku, etc. As such, it has areas of applicability. It happens to be good at describing branching behaviour (the main path / alternate paths format), and therefore should be considered whenever that shows up… [as] in describing inter-actor behaviour, and so it gets appreciated in process reengineering documents" (Cockburn 2003).
The name 'use case' was clearly intended by Jacobson to apply only to uses of a system, but scenario modelling has long been applied much more widely, e.g. for military planning and film storyboarding (Alexander 2002d), so there is really no a priori reason why use case-type scenarios should not be applied to business process modelling.
Guttorm Sindre and Andreas Opdahl further extended the modelling range by introducing the idea of the Misuse Case to document hostile or negative scenarios (Sindre & Opdahl 2000; 2001). They inverted the colours of the Use Case to indicate the intentions of an opponent (Figure 5).
Figure 5: Sindre & Opdahl Misuse Case
A Misuse Case documents conscious and active opposition in the form of a goal that a hostile agent intends to achieve, but which the organization perceives as detrimental to some of its goals. This is a stronger sort of problem than an 'Obstacle' (van Lamsweerde 1998a) which merely passively gets in the way of a desired goal. In particular, an Obstacle does not react by creatively devising counter-measures when it is surmounted. A Misuse Case and its hostile agent implies a dynamic and intelligent pattern of threats, not just the single threatening goal that is actually named.
This opens the way to a game-playing or MiniMax view of business processes. Both the organization and its opponents (such as criminals and business rivals) act intelligently to discover and play their best move, which is – as in games like Chess and Go – whatever best counters their opponent's best move. To model the resulting zigzagging arms race between the players, Alexander proposed two new relationships, threatens, and mitigates (Alexander 2002b, 2002c). A Misuse Case is relevant only if it threatens the goal of a Use Case in the same model. Analysis may reveal one or more candidate counter-measures to the threat, and these may be documented as lower-level Use Cases that mitigate the threat posed by the Misuse Case (Figure 6).
Figure 6: Documenting Threat & Mitigation with Use & Misuse Cases
The resulting approach is suitable for a wide range of purposes, most obviously security threat mitigation, but also reasoning in design space for trade-off and conflict analysis (Alexander 2002a).
Modelling Business Processes with Use & Misuse Cases
To give an idea of how the suggested modelling approach works, let us examine a simple example (Figure 7).
Figure 7 : Business Processes Modelled as Use & Misuse Cases
The illustration shows a set of business processes modelled as use cases (white bubbles), and a hostile process modelled as a misuse case (black bubble). The business processes are the responsibility of the roles shown on the left; the hostile process is owned by the negative role on the right. High-level processes (large scale, long lifetime) are shown furthest left; successively lower-level processes are shown further towards the right. Relationships between processes are shown as arrows; four types of relationship are visible in the diagram, namely includes, has exception, threatens, and mitigates.
The diagram was constructed by Scenario Plus, a free toolkit created by one of us (Alexander) for use with the commercial requirements tool DOORS (Scenario Plus 2003, DOORS 2003). The toolkit provides a rich set of options for the modeller, including model creation, editing, linking, checking, metrics, and export. Processes are modelled primarily as scenarios (sequences of activities); these are not visible in the diagram, which only names the goal of each process.
A first-level business process has the goal to 'sell a product' – this goal can also serve as the name of the corresponding use case. Salesmen are expected to follow a canonical sequence of activities, constructed to help achieve a successful sale without excessive risk to the company. The 'sell a product' sequence as documented in Scenario Plus is shown along with a few other use cases in Figure 8.
|
Figure 8 : Use Case Contents – Primary and Exception Scenarios
The primary and exception scenarios reveal much more detail than can be shown on a use case diagram, which merely illustrates the context in summary form. Each row of the table in Figure 8 represents one DOORS object, such as a scenario step or a structural heading. Scenario Plus enforces a specific set of meanings on the structure – for instance, underscoring indicates the name of a 'target' use case to be linked to (by the analysis tool). A link from a primary scenario to another use case is assumed by the analysis tool to be an inclusion; one from an exception scenario is similarly assumed to be an exception link; while a reference to a Misuse Case from a Use Case is assumed to be a mitigation. These rules greatly reduce the amount of effort needed to set up a model. Essentially the analyst is freed to think about the structure of the business processes, and in most cases can leave tasks like linking to the toolkit.
The existence of a documented product sales procedure reminds the salesmen that they should be behaving in a certain way, and it sets the norm which they are expected to follow. Setting a norm tells the stakeholders what is expected, but does not in itself ensure that the norm is followed. The norm may include items that are hard to quantify, and that may be qualities rather than activities. For instance, salesmen may be required to be polite and friendly, and to dress soberly. These particular norms are better documented as constraints than as scenario steps. Since they are local to the sales process, we suggest it is best to keep them within the use case. Scenario Plus accordingly provides a 'Constraints' section for this purpose.
A first-level process may be regulated by several second-level business processes. In the product sales example, second-level regulatory processes may include 'control credit' and 'enforce process compliance'. It is clearly a matter of process engineering judgement as to whether a set of regulatory processes is sufficient. The lack of any regulatory process can be detected automatically in a model; but the demonstration that the described processes are sufficient to regulate a given process is another matter.
Credit may be controlled automatically by a financial mechanism triggered by credit level; whereas process compliance may be controlled by human regulators inside or outside the company, e.g. the company's own Quality Assurance department, a Financial Services Authority, the Ombudsman. Normally, one role has the primary responsibility for a given business process – Sales is responsible for selling – though other secondary roles may also be involved. Roles may – as this example demonstrates – be filled by either human or machine agents, as long as these have sufficient intelligence for the tasks involved.
First-level and second level processes exist to help achieve zeroth-level non-operational goals such as 'establish corporate image'; such abstract high-level goals are themselves regulative of all lower-level goals, e.g. driving the style of sales efforts and hence the Quality Assurance procedures themselves.
For example, the 'sell a product' process may currently involve no security checks. However the Misuse Case 'launder money' may in future demand mitigation with a 'check money laundering' process – an additional regulatory step. This might initially be implemented in a workflow system as a stub (which does nothing), allowing for change if security conditions are perceived to worsen: for instance, if the industry regulator imposes tighter rules.
Related Work
Modelling goals and business processes is popular in the RE field. Many current RE methods focus on goals and scenarios as a means of justifying the requirements for an IT system. We call these methods Goal-Directed Requirements Engineering (GDRE) methods. Most of the GDRE methods subscribe to some extent to BPR. Since at the core of BPR lies the belief that IT systems can streamline business processes, GDRE methods are most interested in business processes (as expressed in scenarios) and their goals.
The most prominent among the GDRE methods are KAOS (Dardenne 1993), GBRAM (Anton 1997), i* (Mylopoulos 2001), and Cockburn’s goal-directed use cases (Cockburn 2001). In KAOS goals are refined into sub-goals and eventually into IT system requirements by applying refinement patterns that are collected into a knowledge base. KAOS includes techniques for conflict resolution and overcoming obstacles (van Lamsweerde 1998b; van Lamsweerde 1998a). In KAOS, goals are classified into achieve, cease, maintain, avoid and optimize goals. GBRAM offers tools for the extraction of goals from textual descriptions of the organization such as interview transcripts, policies, scenarios etc. These goals are then classified into maintenance or achievement goals. Maintenance goals may represent both maintain and avoid activities. Obstacles and constraints on the satisfaction of these goals are considered.. Scenarios are constructed to identify goals that do not appear in the original textual descriptions. Finally, the goals are operationalised into IT system requirements. In i* a network of relationships between actors is modelled in order to represent the dependencies between the organization and its stakeholders. Optional goal satisfactions are evaluated by considering how well each option supports a set of so called softgoals (goals that have no clear cut criteria of satisfaction). Softgoals represent the non-functional aspects of the relationships between organization and stakeholders, such as quality of service, security, usability, flexibility etc. (Mylopoulos 1999). While the relationship between business processes and goals remains somewhat implicit in the KAOS and GBRAM literature, this relationship is explicit in the i* related literature (see for example Yu 1994).
Kueng and Kawalek (Kueng 1997) describe a business process modelling approach in which goals such as what to achieve and what to avoid are considered. In this approach they consider that achievement goals define value added activities in the sense described by Hammer and Champy (1993) while avoidance goals are necessary but do not represent value added activities.
In the field of Organizational Semiotics (Liu 2002) business processes are thought of as norms of behaviour of an organization. These norms are extracted from description of the organization’s current business processes. The meaning of the norms for different people within the organization is analyzed. Goal-directed use cases are proposed based on these norms.
Avoidance, goals, goal obstacles, the approximate satisfaction of soft-goals and the adherence to norms all represent drive an organization to define activities that mitigate threats. The methods described in this section do not explicitly model these threats as they are perceived by the organization and that we model as misuse cases.
Conclusions
In this paper we presented a modelling approach for designing business processes by considering the need to create value for customers, to protect the organization from abuse and to set strategic directions for the organization. The approach is based on the use of modelling elements, use cases and misuse cases, which were developed in the field of requirements engineering. This approach has the advantage of explaining the goal of a business process as well as the activities that form the process as arising from the interaction between the organization and its environment.
We have also presented the underlying theory that justifies the modelling approach. This theory views organizations as open systems that resist change in order to maintain their identity. Business processes are understood as the means by which the organization regulates its relationships with its stakeholders in order to maintain its identity. However, the organization’s identity and its business processes constantly change as the threats and opportunities presented by the organization’s stakeholders change as well.
References Anton 1997
Ashby, W., R., 1956: An Introduction to Cybernetics, London, Chapman Hall, 1956.
Alexander 2002a: Ian Alexander, Initial Industrial Experience of Misuse Cases in Trade-Off Analysis, Proceedings of the IEEE Joint International Requirements Engineering Conference (RE'02), 9-13 September 2002, pp 61-68, Essen, Germany
Alexander 2002b: Ian Alexander, Towards Automatic Traceability in Industrial Practice, Proceedings of the First International Workshop on Traceability, Edinburgh, 28th September 2002, pp 26-31, in conjunction with the 17th IEEE International Conference on Automated Software Engineering
Alexander 2002c: Ian Alexander, Modelling the Interplay of Conflicting Goals
with Use and Misuse Cases, Proceedings Eighth International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ'02), Essen, 9th-10th September 2002, pp 145-152
Alexander 2002d: Ian Alexander, On Abstraction In Scenarios, Viewpoints Article, Requirements Engineering (2002) 6:252-255
Cockburn 2001: Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001
Cockburn 2003: Alistair Cockburn, Suggestion to "Definition of Scenario technique", submission to RE-online mailing list, 9 March 2003, archived at http://research.it.uts.edu.au/re/re-archive/
Dardenne 1993
DOORS 2003: http://www.telelogic.com (Telelogic's website)
Hammer M., Champy, J., 1993: Reengineering the Corporation: A manifest for Business Revolution, London, Nicholas Brealey, 1993.
Hammer M., 1996: Beyond Reengineering, New York HarperCollins, 1996.
Jacobson, Ivar, et al: Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992
Kueng 1997: Kueng, P., Kawalek, P., Goal-based business process models Goal-based business process models: creation and evaluation. Business Process Management Journal, Vol. 3 No. 1, 1997, pp. 17-38.
Liu 2002: Liu, K., Clarke, R.J., Anderson, P.B., and Stamper, R.K. "Coordination and Communication Using Signs: Studies in Organizational Semiotics." Kluwer 2002
Mylopoulos 1999: Mylopoulos, J., Chung, L. and Yu, E., "From Object-Oriented to Goal-Oriented." Communications of the ACM, vol. 42. No. 1. January 1999.
Mylopoulos 2001: Mylopoulos, J., Kolp, M., and Castro, J. "UML for Agent-Oriented Software Development: The Tropos Proposal," Proc. UML 2001.
Scenario Plus 2003: Shishkov 2002: Shishkov, B., Xie, Z., Liu, K., Dietz, J.L.G., "Using Norm Analysis to Derive Use Cases from Business Processes." In the proceedings of the 5th Workshop On Organizational Semiotics OS 2002, Delft, The Netherlands, pp. 187-195, June 14-15, 2002,
Sindre & Opdahl 2000: Sindre, Guttorm and Andreas L. Opdahl, Eliciting Security Requirements by Misuse Cases, Proc. TOOLS Pacific 2000, pp 120-131, 20-23 November 2000
Sindre & Opdahl 2001: Sindre, Guttorm and Andreas L. Opdahl, Templates for Misuse Case Description, Proc. 7th Intl Workshop on Requirements Engineering, Foundation for Software Quality (REFSQ'01), Interlaken, Switzerland, 4-5 June 2001
van Lamsweerde 1998a: Axel van Lamsweerde, E. Letier, Integrating Obstacles in Goal-Driven Requirements Engineering, Proceedings ICSE'98 - 20th International Conference on Software Engineering, IEEE-ACM, Kyoto, 19-25 April 1998.
van Lamsweerde 1998b: van Lamsweerde, A., Darimont, R., and Letier, E. "Managing Conflicts in Goal-Driven Requirements Engineering," IEEE Trans. Software Eng. Special Issue on Managing inconsistency in Software Development, Nov. 1998.
Vickers, Sir G. 1968: Value Systems and Social Process, London: Tavistock Publications 1968.
Vickers, Sir G. 1987: Policymaking, Communication, and Social Learning, New Brunswick NJ: Transaction Books, 1987.
von Bertalanffy, L. General System Theory. New York: George Braziller, 1968.
Weinberg, G. M 1975: An Introduction to General Systems Thinking. New York: Wiley & Sons, 1975.
Weinberg, D. and Weinberg, G. M. 1988: General Principles of Systems Design. New York: Dorset House, 1988.
Wiener N., 1954: The Human Use of Human Beings: Cybernetics and Society, Boston, Houghton Mifflin 1954.
Yu 1994: Yu, E., and Mylopoulos, J. "Using Goals, Rules and Methods to Support Reasoning in Business Process Reengineering," Proc. 27th Hawaii Int. Conf. System Sciences, Maui, Hawaii, vol. 4, pp. 234–243, Jan. 1994.
More Papers, Consultancy and Training on
Ian Alexander's Home Page