Proceedings of IEEE Joint International Requirements Engineering Conference, 9-13 September 2002, Essen, pp 61-68

A Misuse Case is a Use Case [1] from the point of view of an actor hostile to the System under Design. Its goal is not a system function but a threat posed by that hostile actor.

The simplest application of Misuse Cases is to elicit Security requirements. Security Requirements are caused to exist because people and agents that they create (such as computer viruses) pose real threats to systems in the world. Security is thus unlike all other areas in a specification, as someone is consciously and deliberately trying to break the system.

The scenarios in which such 'negative' agents attempt to defeat the system under design can be elicited as Misuse Cases, in the sense proposed by Sindre & Opdahl [2, 3].

Explicitly drawn malign Agents and Misuse Cases (see Figure 1 for a simple example) can help to focus attention on the struggle against such negative agents.

Misuse and Use Cases may be developed recursively, going from higher to lower levels (e.g. from the car/system to the lock/subsystem) as threats are discovered, ideally by analysts and stakeholders working together. Cases and relationships discovered at lower levels may highlight aspects not considered at higher levels, possibly forcing Trade-Off analysis. The approach need not be rigidly top-down; requirements may be explored in any direction. The model grows in richness until it is seen to be sufficiently complete to define the problem.

There is a productive analogy with playing a game like Chess or Go here. The 'White' team's best move consists of thinking ahead to the 'Black' team's best move, and acting to block it.

For example, if a thief's intention is to break into the car and to short the ignition, thus defeating the lock, possible mitigating approaches are to lock the transmission, or to require a digital code from the key. These alternatives can then be traded-off in terms of the financial and practical costs and benefits that they entail.

Karen Allenby and Tim Kelly describe a method for eliciting and analysing safety requirements for aero-engines using what they call 'use cases' [4]. They do not suggest the use of negative agents associated with their use cases. Their method is to tabulate the failures, their causes, types, and effects, and then possible mitigations. They observe that mitigations often involve subsystems, i.e. the procedure implies a recursive decomposition. However, since their 'use cases' describe potentially catastrophic failures and their effects, it seems reasonable to follow Sindre & Opdahl and explicitly call them Misuse Cases.

John McDermott and Chris Fox introduce the term 'Abuse Case' [5] as a way of eliciting security requirements; an abuse case 'defines an interaction between an actor and a system that results in harm to a resource associated with one of the actors, one of the stakeholders, or the system itself'. It might be better to say that 'a misuse case defines a hostile goal, which if carried out would result in harm…', and there need be no restriction to security requirements, but otherwise abuse case is essentially another synonym for misuse case.

Numerous academic approaches exist for exploring goal relationships. Van Lamsweerde and his co-workers on the KAOS approach have proposed goal-obstacle analysis [e.g. 6]; Antón and Potts have used goals and obstacles to surface requirements [7]; while Yu, Mylopoulos and their co-workers have developed the i* approach for non-functional requirements [8]. However none of these provide the simple but accurate visual impact of misuse cases combined with easy-to-understand relationships; methods suited to analysis and model-checking are not necessarily suited to use in workshops.

Misuse Cases with 'threatens' relationships are perhaps closest in spirit to goal-obstacle analysis; one could view this style of Misuse Case diagrams as a concise way of presenting goal-obstacle analysis visually to a workshop audience. However, a threat is not simply a passive obstacle but (at least in extreme cases) an active and purposeful attempt to overcome a system's defences.

Sindre and Opdahl simply use 'includes' and 'extends' for threats, which is not entirely clear – the relationships seem too generic. Similarly, their use of 'prevents' carries the implication of 100% successful mitigation, which seems to exclude partial success. In addition, in domains such as air traffic control, prevention means neutralizing threats in advance by making them unable to occur, while 'mitigates' means reducing effects after they have occurred [9]: this is too narrow a meaning for many purposes.

A Trade-Off Analysis is a systematic examination of the advantages and disadvantages of each proposed requirement and/or design approach for a system. This is a task for an analyst, in consultation with stakeholders. Trade-Offs usually have both engineering and economic implications. Approaches therefore need to involve a full range of stakeholders to be successful.

The basic Misuse Case technique as described above employs ordinary Actors, with their goals as Use Cases, supplemented by hostile Actors whose goals are Misuse Cases. To analyse a Trade-Off, these are inter-related with 'threatens' and 'mitigates' relationships, as well as ordinary UML 'includes' and 'has exception' relationships [10]. Use/Misuse Case models are developed by analysts and corrected by stakeholders in an iterative Trade-Off process (such as an inquiry cycle – see below).

Let us define relationships as follows, broadly in line with the intentions of Sindre and Opdahl:

• Misuse Case A 'threatens' Use Case B if achieving the goal of A reduces the system's ability to achieve the goal of B;

• Use Case A 'mitigates' Misuse Case B if it reduces B's effects on the Use Cases that it 'threatens'.

These are general, domain-independent relationships which allow for both complete and partial effects to be analysed. Indeed, Trade-Offs in industry are generally studied with at least an informal cost-benefit analysis that attempts to quantify the effects of candidate approaches.

However, when we move from more-or-less pure user needs to System Requirements and Trade-Offs, it becomes necessary to consider possible conflicts between desired goals as well as how to handle possible threats.

To achieve this, the basic Misuse Case technique needs to be extended with additional types of relationship to describe Trade-Offs accurately. It seems desirable to minimize the number of types of relationship, so that non-technical stakeholders can readily understand the results.

Two classes of interaction between Use and Misuse Case seem to be needed in practice (beyond the threat/mitigation cycle already mentioned). These are where one Use or Misuse Case risks aggravating another Misuse Case; and where two Use Case goals can not both be satisfied, because they conflict. Conflicts are commonly discovered in the transition from requirements to design, as different goals are seen to lead to incompatible design approaches. Especially when requirements are written as lists of 'shall' statements, the implications of different requirements on design may not be apparent. When a design approach is identified and checked against the requirements, the conflicts start to appear, and alternative design approaches may then be considered and traded off. It may be a goal of requirements modelling to help to discover possible design conflicts.

The aggravation of existing risks is often discovered even later, especially when limited effort has been expended in risk analysis. Two new relationship types, 'aggravates' and 'conflicts with', are therefore introduced.

• Use or Misuse Case A 'aggravates' Misuse Case B if it increases either the probability of success or the seriousness of the damage that B threatens.

• Use Case A 'conflicts with' Use Case B if achieving A's goal makes achieving B's goal more difficult (or impossible), and vice versa for B's effect on A.

The target of 'aggravates' is always a Misuse Case, as the relationship inherently implies that something negative is being reinforced. Where the source of 'aggravates' is a Use Case, the meaning is that a desired goal unintentionally causes an undesired side-effect. Where the source of 'aggravates' is a Misuse Case, the meaning is that one undesirable action unintentionally reinforces the undesirable effects of another. If the reinforcement is intentional, it seems preferable to use the arguably more explicit 'includes' relationship to show shared hostile intent between the two Misuse Cases, as in the Car example illustrated above.

Both ends of a 'conflicts with' relationship are always Use Cases, as the relationship inherently implies that something desirable is being contradicted. In fact, 'conflicts with' is a mutual, bi-directional relationship. It would perhaps be appropriate to think of it as a stereotype representing two conventional unidirectional UML relationships [2] with opposite directionality.

The set of four relationships ('threatens', 'mitigates', 'aggravates', 'conflicts with'), together with the usual 'includes' and 'has exception', form a compact but sufficient conceptual toolkit for handling Trade-Offs. The set enables the analyst to describe threats, to discover both functional and non-functional requirements, and to show the areas where costs and benefits can be expected. For example, a Trade-Off analysis can show where a design fails to mitigate a threat; that negative benefit can then be evaluated, and compared with the benefits and costs of that design and its rivals.

The relationship names are chosen to be immediately intelligible to non-specialists. These relationships may not be absolutely necessary, or the only possible choices, but the set has a natural feel to it, and it works on real problems.

The goal of Trade-Off Analysis is to enable stakeholders to make an informed and correctly-based judgement in a possibly-complex situation. Employing a Use/Misuse Case representation may make such a judgement more likely if it helps people to visualize the structure of the situation accurately, and in a way that emphasizes the essential points of conflict that create the need for a Trade-Off.

The key to Trade-Off Analysis is therefore similar to that of much practical Requirements Engineering consultancy, namely to elicit the issues carefully, to present the elicited results comprehensibly, and to allow the stakeholders to decide objectively what they want to do. The special feature of the technique is the attention given to relationships between 'positive' and 'negative' goals, rather than simply to the goals themselves.

The analysis was conducted using the Scenario Plus toolkit [11] which is designed to handle Use and Misuse Cases in the DOORS environment [12]. It automatically links underlined references to cases to create 'includes', 'has exception', 'threatens' or 'mitigates' relationships as appropriate. The linking tool uses simple fuzzy matching, so that a readable phrase like 'avoid causing injury' results in a link to the Misuse Case 'Cause Injury' (see object S-167 in Figure 2). The link in that instance is of relationship type 'mitigates' by default, because it runs from a Use Case to a Misuse Case. A link in the opposite direction would automatically be created with relationship type 'threatens', while links between Use Cases or between Misuse Cases are simply 'includes'.

The Scenario Plus toolkit was extended to create these relationship links automatically, and to display them graphically (as in Figures 1 and 3). The analyst creates text objects containing the underlined names of the Use/Misuse Cases related to the current case (in the second (main) column of Figure 2); the tool translates these references into actual links (illustrated in the right-hand (dynamic) column in . For example, Object S-283 specifies that a 'conflicts with' link is to be created to Use Case 'Strengthen Armrest'; the trace on the right shows that such a link has successfully been created).

These facilities make it easy to model, analyse and display Trade-Offs, alongside more traditional applications of scenarios in requirements engineering.

The analysis of desired behaviour with scenarios applies to software, computer and network hardware, and to many apparently simple systems that lack software altogether. I was recently consulted by a railway company about the safety and comfort of the seats in their trains. What looked at first like a trivial problem turned out to be remarkably complex. Here is a part of the analysis of the requirements and design issues on the seats. It was a contribution to a participative workshop approach for a whole-day meeting of about 20 stakeholders from the railway company, including project management, design engineers, maintenance engineers, and quality assurance representatives.

The engineers on the seats project felt stuck as discussions had reached deadlock. They were aware that there was a problem but had not progressed beyond recording that different people in the company held differing views on the situation.

The workshop's starting point was the passenger's top-level goal for his or her seat, namely to sit comfortably and safely. This was threatened by numerous hostile agents, who adopted a variety of strategies (shown as Misuse Cases in Figure 3, with threat arrows directed at the top-level goal). Some of the agents were literally hostile: Vandals armed with knives slashed the seat covers; 'Pests' seated themselves next to women, especially in seats which lacked dividing 'armrests'. Other metaphorically hostile agents included natural causes such as Fire and Wear-and-Tear; engineers need not limit their thinking to literally hostile human agents.

Even apparently simple Misuse Cases like the wearing out of seats through normal Wear-and-Tear could be aggravated by design-related issues. The seat was locked into the normal position after maintenance by an upward-pointing locking pin that was supposed to engage with a downward-opening bush on the underside of the seat. Unfortunately, this pin could be misaligned by maintenance staff, especially once it had started to wear and had some play in its mounting, and then protruded into the foam of the seat. This aggravated the wear and tear on the seat caused by normal passenger movements.

The design engineers in the railway had considered various stratagems to mitigate these threats. They had become bogged down because they had found no clear way ahead: some of the proposed (and actually implemented) solutions aggravated some of the threats or conflicted with each other (Figure 3).

For example, the armrest had some years earlier been intentionally weakened so that in the event of a passenger's being thrown against an armrest during an emergency stop, the armrest would snap off cleanly ('be frangible') at its base rather than cause injury to the passenger's abdomen. The railway company was aware of several problems that had been aggravated by this design change.

Firstly, Vandals found it easier to break off the armrest intentionally, and the broken-off armrest formed an all-too-convenient weapon in the hands of such people. Secondly, the absence of an armrest – whether because it had been removed for safety or broken off – made female passengers uncomfortable as it increased the nuisance from 'pests'. The armrest was thus revealed to have numerous functions and to be safety-related; its function was not just to provide a place for passengers to rest their arms.

The simplest solution perceived by the railway engineers was to strengthen the armrest, accepting the risk of injury this might cause. However there was no agreement on this approach: there was evidently a conflict between the design goals of strengthening and weakening the armrest. For example, some engineers felt that a strengthened armrest could lead to structural damage to the seat frame itself in the event of a determined Vandal attack, given a strong armrest firmly attached to the seat frame, and offering plenty of leverage. This would greatly increase the cost of an episode of armrest vandalism. The undesired effects of weakening the armrest had not been considered when the decision to make the armrest frangible had been taken. It appears therefore that vandalism Misuse Cases had not been taken into account in the decision-making process, despite the familiarity of vandalism to train maintenance staff who daily make good damage done deliberately. This suggests that stakeholders such as train maintainers had not been adequately involved in earlier decisions. In fact one of the 'aha!' moments in the workshop occurred when the project managers and systems engineers present realized that maintainers had an important voice; the meeting tangibly relaxed as soon as the maintenance chief had explained his viewpoint.

These and similar arguments were readily expressed in diagrammatic form with Misuse Cases, using the additional relationships 'aggravates' and 'conflicts with' already mentioned. The diagram was introduced in stages, presenting first the top-level goal and actors, then the Use Cases for the subsidiary goals, then the hostile actors and the seven Misuse Cases threatening the goals, and finally (with differently-coloured arrows) the analysis of mitigations, aggravations and conflicts.

None of the stakeholders in the workshop challenged the analysis thus presented; however, it was pointed out to them that the diagram was incomplete. Evidently, once the conflicts, threats, and aggravations were explicitly stated, much of the heat and confusion was taken out of the analysis. Further, the simple act of inviting the different stakeholders to a workshop itself made clear that different viewpoints could rightfully exist.

Faced with the challenge of resolving the problem with the armrest, the design engineers quickly pointed out that they could rethink the design of the armrest: it could be made strong, low, and curved, reducing the effects of vandalism, protecting passengers and frustrating pests.

They sketched a rough outline of a new "armrest" – it had in effect become something new, something like a "non-frangible vandal-resistant armrest/separator" – and promised full drawings for a week later.

As another example, the design engineers had previously considered that the seat locking pin had to face upwards for two reasons. Firstly, there was no room for a locking mechanism below the seat: electrical equipment was housed in the boxes under the passenger seats. Secondly, since the equipment was electrical, it was important that the box lids should be watertight, so that a spilt drink could not cause a short-circuit. However, the stakeholders in the workshop quickly ascertained by discussion amongst themselves that these fears were groundless; a simple blind-ended metal bush could be mounted in the box lid, requiring only a few millimetres of extra space, and offering no path for liquids to penetrate.

The Trade-Off Analysis had brought together the relevant facts for several inter-related issues, enabling the design to be reconsidered objectively in the light of the system requirements. Misuse Cases thus have a definite role in clarifying the interplay of system requirements and design, and indeed in addressing design issues and Trade-Offs during in-service operations and maintenance.

In the examples discussed in detail – the armrest and the locking pin Trade-Offs – the problems were resolved by the combined domain knowledge and skill of the stakeholders, once the interactions (threats, mitigations, conflicts, aggravations) had been brought to their attention. The contribution made by consultancy, facilitation, and analysis techniques was purely to enable this resource of skill to be brought to bear on the problems.

Analysis techniques like those involved in creating Misuse Case diagrams are therefore helpful only as part of an integrated approach. Straightforward participative workshop methods include Ian Graham's or Linda Macaulay's [13, 14]. Integrated inquiry cycle methods include John Heron and Peter Reason's proven Co-operative Inquiry [15, 16] which can be applied to requirements [17, 18], or Colin Potts' independently devised Scenic [19].

Tool support is not essential for documenting and presenting such analyses, but it can be helpful. The Scenario Plus toolkit's Misuse Case and Trade-Off facilities proved to be effective in the railway case: the filters allow different types of relationship to be presented separately or together, so the presentation of threats, mitigations and conflicts could be built up visually in stages, in a way that the stakeholders could understand.

Using any suitable tool encourages people to record the reasons for a design decision. A Trade-Off Analysis diagram automatically records much of the thinking embodied in a Trade-Off workshop. Scenario Plus also makes it easier to keep diagrams up to date. But more importantly, integration with an industrial-strength requirements engine, as with Scenario Plus' DOORS platform, enables design elements and tests to be traced back to (Use Case) requirements and (Misuse Case) justifications and Trade-Off arguments.

There are clear advantages in recording the justification for design decisions made in the presence of possibly-conflicting viewpoints. If the reasons for a decision are not adequately documented and agreed, there is a danger of continual disputes in line with the shifting political fortunes of different stakeholder groups within an organization. This can cause indefinite oscillation between conflicting outcomes ('paralysis by analysis'). Alternatively, if decisions are not discussed openly, they may be made excessively autocratically without adequate consideration. This can lead to shock discoveries of problems after decisions have been implemented. Trade-Off analysis, in contrast, provides a thorough cycle of stakeholder involvement, and leads to a shared and lasting decision. Simple graphics such as those illustrated here, which help people share their understanding of Trade-Offs, can contribute to this success.

To use a Misuse Case model in a workshop, it is obviously easiest if you can prepare a reasonably good model in advance using interview notes from one or two key stakeholders, – this is what was done for the seats workshop. The facilitator then introduces the modelling approach and the model itself, explaining that the model is incomplete, and that participants are welcome to suggest additional items.

Scenario Plus makes it possible to edit quickly enough for an analyst to update a model while a facilitator obtains inputs from workshop participants using a whiteboard or flipcharts. This means that you can acknowledge a stakeholder's contribution by modifying the model, provided you don't divert stakeholders' attention from the workshop's business – analysing Trade-Offs – to optimising the model visually.

If you intend to create a model during a workshop, you certainly need a team of two people to manage simultaneous facilitation and modelling (much as described by Graham [13]).

Whenever you build your model, you should allow opportunities for stakeholders to comment on the model, so that you can refine it with them. The essential thing is that the stakeholders should feel that the model describes their situation adequately.

Was the approach the right one? Without Misuse Cases, the seats workshop might still have been successful, but participants would have been less focussed on the nature of the conflicting forces. The workshop would probably have spent longer trying to analyse the existing situation. This might have put pressure on participants to reach a solution quickly. That is always unwise in a workshop as different participants work at different speeds, and people need time to express themselves, even if it is only to agree with what others are suggesting.

What benefit did identifying threats (as Misuse Cases) bring? It helped participants acknowledge that there were explicit choices confronting the design engineers, and that the approaches that had been thought of before the workshop were all problematic. Indeed, the temporary solution that had in fact been adopted, namely removal of the armrests, was actually illegal. The Misuse Case model helped to get the whole workshop to acknowledge that no pre-existing solution was acceptable and unproblematic. At that point, the workshop rapidly moved into a free space in which it could think creatively. It isn't easy to think of ways of measuring this effect, though with hindsight participants could have been asked to fill in feedback forms on the advantages and problems posed by the conflict analysis approach.

Engineers are starting to look at Use and Misuse Cases for a range of purposes within the systems engineering life-cycle [20, 21]. The most obvious applications of Misuse Cases are for eliciting security requirements; safety requirements and other '-ilities' are also promising domains, provided one accepts that the actors (as with 'Wear and Tear' in the seats workshop) are only metaphorically hostile. Colin Potts has indeed argued for the power of metaphor [22].

I and colleagues at DaimlerChrysler are investigating the appropriate forms of use cases for 'recycling' requirements in the automobile systems engineering life cycle [23]. Systems Engineering covers the development not only of software, which is the domain addressed by popular accounts of use cases such as Alistair Cockburn's and Kulak & Guiney's [24, 25], but also of hardware and interfaces of all kinds. One of the critical problems in reusing requirements when systems are to be upgraded is feature interaction, as described by Pamela Zave [26], where a proposed new feature conflicts with an existing feature. This leads to an asymmetric Trade-Off Analysis in which existing features have priority, as it is costly to disturb existing functionality.

In mixed hardware-software systems, non-functional requirements are often as important as system functions. A large system composed of many subsystems, such as a passenger car, must be analysed at both system and subsystem levels to cope with the necessary complexity. Trade-Offs can arise anywhere within such a system, both during initial specification and design, and as feature interaction during upgrades such as the creation of a new series of cars. Many stakeholders are involved in this process. Use/Misuse Case models can be helpful in communicating the purpose of system and subsystem features to different audiences.

Trade-Off Analysis represents an extension of this application of Use Case thinking, helping stakeholders to understand the consequences of the choices open to them, and forming a useful bridge between requirements and design. Sindre and Opdahl suggested that Misuse Cases could be applied to eliciting security requirements. The described Case Study used them to surface not only requirements but design conflicts, and not only for security but for threats of other kinds including safety and passenger comfort. There is scope for further work applying Misuse Cases to elicit Usability requirements.

Misuse Case models are a promising approach for

• Eliciting various non-functional requirements, such as for security, safety, and perhaps usability;

• Identifying threats to system operation, and hence

• Identifying ways of neutralizing those threats;

• Identifying conflicts between requirements and design approaches, whether direct goal conflicts, or indirect through aggravation of Misuse Cases;

• Analysing and presenting Trade-Offs in participative workshops.

These purposes appear to be fulfilled in a preliminary way through the use of Use and Misuse Cases related by a proposed set of 'threatens', 'mitigates', 'aggravates', and 'conflicts with' types of links in a workshop.

The paper described a practical application of these techniques, supported by a modelling and traceability tool (Scenario Plus on a DOORS platform), in a one-day participative workshop investigating a set of railway trade-offs. The apparent success of the workshop suggests that the techniques may be worth more detailed exploration, and application in other domains.

Trade-Off analysis can benefit from Misuse Cases and specially-chosen relationship types. These simplify confusing situations in an appropriate way, and help design engineers to focus their attention on compromises and novel design approaches that can resolve problems.

Even an incomplete Trade-Off analysis can be effective in directing stakeholders' attention to the nature of a Trade-Off situation, seeding discussion and encouraging stakeholders to describe further Trade-Offs before searching for solutions.

Trade-Off analysis shows stakeholders that what they may simply have called 'requirements' consist of a blend of user goals for performance and safety, threats from hostile agents, mitigations, aggravations and conflicts in design goals, and candidate design approaches.

Trade-Off analysis with Misuse Cases allows stakeholders to see design approaches as options with costs and benefits, rather than as fixed decisions.

Visualizing an option as one of several bubbles on a diagram frees up people's thinking, allowing them to search creatively for a practical resolution.

The approach makes explicit that design engineers are valid stakeholders in a railway (and by implication in other application domains also). Similarly, maintenance staff are seen to be stakeholders, just as much as the passengers and the funding authorities.

Successful resolution of Trade-Off situations requires that the stakeholders, including both operations & maintenance staff and the design team, come to grips with the complexity of the situation. This means recognizing that there are many valid viewpoints as well as their own, and potentially many design solutions.