Ian Alexander

Abstract

1. Introduction

Systems Engineers are starting to look at Use Cases for a range of purposes within the systems engineering life-cycle [Hruschka & Rupp 2001, Alexander 2001].

The SE life-cycle is larger than that of software engineering (software typically forming a subsystem), which is the domain addressed by most current literature on use cases [e.g. Cockburn 2001, Kulak & Guiney 2000]. These authors, even if they recommend iteration to make Use Case Models more accurate and more detailed, appear to consider that a single model is sufficient for a software project. But a large system composed of many 'systems', such as a passenger aircraft or a warship, must be analysed in successively greater detail in subsystem models to cope with the complexity of the functionality [Simon 1996, Stevens 1998].

The greater range and the fact that embedded and real-time systems are often complex and safety-related means that systems engineers are often skeptical [e.g. Jorgensen 2001, Mills 2001]. This skepticism is unfortunately not unjustified as some software engineers have apparently rushed to apply Use Case methods informally, hoping to avoid the burden of documenting traditional requirements. Others have proposed 'light' methods [e.g. Beck 2000] that may be unsuitable for large systems.

However, a disciplined use of scenarios should help with the elicitation, validation, and reuse of systems requirements, as well as for guiding design and generating test cases. Operational scenarios have indeed long been used for some of these purposes. Scenarios are known to be effective in elicitation and design [e.g. Carroll 1995].

Background: Use & Misuse Cases Ivar Jacobson introduced Use Cases in the context of his work on large telecommunication systems [Jacobson 1992]. He had the idea of describing a system's desired behaviour by telling a story at just one level of detail, from the point of view of a user or interfacing system (an 'Actor'). Such a story (a 'Scenario'), when supported by subsidiary scenarios (for Alternatives and Exceptions) and associated information, he called a Use Case. Guttorm Sindre and Andreas Opdahl took the traditional concept of a 'Negative Scenario', i.e. a situation desired not to occur by a system's users, and applied it in a Use Case context to create the idea of a Misuse Case [Sindre & Opdahl 2000]. This is a goal (possibly supported by one or more scenarios, though unlikely to be worked out in full detail) desired by an agent (not necessarily human) hostile to the system. Business and military planners and game-players are familiar with working out their opponents' best moves as identifiable threats, and countering these when the threats are considered to be sufficiently likely to be worth neutralizing. The Misuse Case and its hostile Actor neatly encapsulate the idea of evaluating 'Black's Best Move'. From this perspective, it seems natural to consider how to represent threats, mitigations and similar relationships between Use and Misuse Cases, in a form suitable for Systems Engineering.

A negative form of Use Cases, Misuse Cases [Sindre & Opdahl 2000, 2001] also look promising for systems requirements elicitation. Negative scenarios have also long been applied, e.g. in military and commercial operations planning, but they may be less familiar in systems engineering.

In principle an approach combining Use and Misuse Cases can be applied at any level from whole systems down through subsystems to individual equipments and components. This approach is inherently stepwise, so it should dovetail well with both the stepwise decomposition of the SE life-cycle, and with participative inquiry cycle approaches [e.g. Potts 1994, Heron 1996, Alexander 1999].

Functional and Non-Functional Requirements NFR is simply a blanket term for all requirements that are not explicitly Functional. While the concept of a system Function is quite sharply-defined – a piece of behaviour exhibited by the system – the same cannot be said for NFRs. Many classifications have been attempted. One widely-used group of NFRs consists of Reliability, Availability, and Maintainability (RAM), sometimes combined with Safety. RAM requirements are typically applied in real-time automotive, railway and aerospace systems where the continued correct functioning of the system is important. Some engineers refer familiarly to NFRs as '-ilities', since many NFRs effectively name desirable qualities such as reliability, verifiability, and so on. The term 'Constraints' is also widely used, perhaps most effectively to describe definite limitations on how the system can be built, such as the need to interface to existing systems, to provide certain standard interfaces, or simply on the size, shape, paint finish, weight and similar required properties of systems. Clearly, non-technical aspects such as budget and timescale can also constrain development projects. Given this diversity, the term NFR, while not especially informative, is at least unambiguous.

One interesting feature is that Misuse Cases seem naturally to lead to Non-Functional Requirements (NFRs] such as for safety and security, whereas Use Cases essentially describe system behaviour in Functional terms (i.e. first you do this, then you do that), possibly with some closely-associated NFRs such as performance targets for specific transactions.

NFRs at high (e.g. whole System) level typically lead to Functions at lower (e.g. Subsystem) levels. For example, a security requirement may lead to security subsystems to protect the system as a whole. Indeed, all security 'systems' can be viewed as subsystems responding to overall system security requirements – nobody wants an alarm unless they have something to protect.

There thus appears to be an important interplay between Use and Misuse cases that could greatly improve the efficiency of eliciting and organizing Functional and Non-Functional Requirements – which themselves are involved in an interplay during system design – in the systems engineering life-cycle. Let us look in turn at how a Use/Misuse Case analysis can derive Security, Safety, Reliability and other Non-Functional Requirements.

2. Use/Misuse Case Analysis – 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 a method proposed by Sindre & Opdahl. The explicitly drawn malign Agents and Misuse Cases (see diagram below) can help to focus attention on the battle against such negative agents and hence can improve system security [Sindre & Opdahl 2000].

Misuse and Use Cases may be developed in stages, going from system to subsystem levels and lower as necessary (as illustrated by the zigzag pattern in the diagram). Lower-level cases may highlight aspects not considered at higher levels, possibly forcing re-analysis. The approach is not rigidly top-down but offers rich possibilities for exploring, understanding, and validating the requirements in any direction.



Use/Misuse Case Diagram to elicit Security Requirements. High level is to the left.
Use Cases are drawn in white. Misuse Cases are drawn in black.

There is a productive analogy with game-playing 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 the misuse being threatened is the theft of a car, the White player is the lawful Driver and the Black player is the Car Thief. The driver's freedom to drive the car is at risk if the thief can steal the car. So, the driver needs to be able to lock the car – a derived requirement, which mitigates the threat. This is at the top level of the analysis. The next level is started by considering the thief's response. If this is to break into the car and to short the ignition, thus defeating the lock, a mitigating approach, as for instance locking the transmission or requiring a digital code from the key, is required.

It can be seen informally from the diagram that threat and mitigation form a balanced zigzag pattern of play and counter-play. This 'game' can be reflected in an Inquiry Cycle style of development [Potts 1994, Alexander 1999]. Both Use and Misuse Cases may include subsidiary cases of their own kind, but their relationships to cases of the opposite kind are never simple inclusion. Instead, Misuse Cases threaten Use Cases with failure, and appropriate Use Cases can mitigate known Misuse Cases.

Where such mitigation approaches are already known, development may proceed by selecting which possible design features can be afforded – transmission locks cost money and cannot necessarily be provided on all models of car. So, there is a trade-off between the user requirements (countering misuse) and the design constraints (e.g. cost, weight, size, development schedule). Such trade-offs are possibly more familiar to systems engineers than to software developers.

Where suitable mitigation approaches are not yet known, development and Use/Misuse Case analysis can proceed together, initially but not exclusively top-down. Possible mitigation approaches can be identified, studied, prototyped, evaluated and then selected if suitable. Mitigations may demand new subsystems or components; the existence of these new devices may in turn engender new types of threat. These threats can be analysed in their turn to evaluate the need for further counter-measures. In this situation, analysis and design are intertwined [Swartout & Balzer, 1982] as the design choices crystallize and the system requirements can be stated more specifically.

Security threats are rarely neutralized completely by mitigation measures. Thieves pick locks and break into systems through unsuspected access paths. Partial mitigations are still useful as long as they afford a realistic increase in protection at reasonable cost. The goal of neutralizing all possible threats is of course wishful thinking and cannot be stated as a requirement.

3. Tool Support for Use/Misuse Case Analysis

Considering the automatic handling of Use Cases [Alexander 2001, Scenario Plus 2002] and their interplay with misuse cases, there are thus four situations to consider, namely relationships to and from each kind of case:

		Source Case
		Use	Misuse
Target Case	Use	includes	threatens
	Misuse	mitigates	includes

Rule governing creation of relationships between Use and Misuse Cases

This table can be interpreted as a four-part rule governing the automatic creation of relationship types according to the sources and targets of relationships between Use and Misuse Cases. The Scenario Plus toolkit has been extended to implement this mechanism to construct links. The requirements engineer names the Use or Misuse Case within a scenario step in either the Primary Scenario or an Alternative Path [Cockburn 2001] and underlines the name. The analysis tool then scans for underlined phrases, and attempts to match them with existing Use or Misuse Cases. For example, the tool fuzzily matches the phrase 'Stealing the Car' with the Misuse Case goal 'Steal the Car' (see screenshot below). If no match is found, the tool asks the user if a new case should be created. The tool then links the including to the included Use or Misuse Case according to the table.



Automatic Creation of links between Misuse and Use Cases,
by searching for underlined use case names with simple fuzzy matching

This mechanism permits engineers to write use case steps simply and readably in natural languages (such as English). The created links are displayed, drawn on the summary diagram as relationships between Use/Misuse Cases (see above), and can be navigated as usual in the requirements database.

Misuse Cases are identified by a simple flag; users can choose to show or hide Misuse Cases (with their actors and relationships) as desired. Misuse Case Actors are automatically drawn on the right of the diagram; the Misuse Cases themselves are drawn (as Sindre & Opdahl suggest) on the right with inverted colours.

A refinement on Sindre & Opdahl is to permit Misuse Cases to exist at different levels relative to the current context (e.g. the system). Following Cockburn, the levels provided are {Overview, High, Surface, Low, Too Detailed}. For instance, in a system context, a business-wide case would appear as an Overview and might well be considered inappropriate given the setting; the same business case might appear appropriately at surface level in a business model. Accordingly, both Use and Misuse Case levels are shown on scales with high to the left, low to the right. To keep the Misuse Cases apart and on the right of the diagram, Use and Misuse Cases need separate X-axis scales for level, as can be seen on the diagram above.

Mitigation can itself be subclassed into prevention, detection, and remedy [Sindre & Opdahl 2000, 2001]. It is possible to use the names of these subclasses as relationship labels on use case diagrams, but there is a danger of making the diagrams excessively complex [Cockburn 2001]. It may be better therefore to document the precise relationships within the use cases themselves.

4. Safety Requirements from Failure Cases

Allenby & Kelly describe a method for eliciting and analysing safety requirements for aero-engines using what they call 'use cases' [Allenby & Kelly 2001]. 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 stepwise decomposition. However, since their 'use cases' describe potentially catastrophic failures and their effects, it would seem reasonable to follow Sindre & Opdahl and explicitly call Allenby & Kelly's structures Misuse Cases. 'Failure Cases' is another suitable name.

In the case of safety requirements, there is not generally a human agent posing a threat (though this is possible through sabotage, terrorism, and so on). The agent threatening a negative scenario is typically either the failure of a safety-related device, such as a car's brake, or an inanimate external force such as dangerous weather. For example, a car may become uncontrollable by most drivers if the road is covered in ice or wet leaves. It may be advantageous to anthropomorphise the weather as an agent 'intending' to make the car skid (see diagram below). This uses the force of an easily-understood metaphor [Potts 2001] to emphasize the requirement for control in different weather conditions. Some authors believe that people effectively always operate through metaphor [Byron & Nass 1996, Lakoff & Johnson 1980], in which case it is wise to express requirements in that familiar form.



Use/Misuse Case Summary Diagram for elicitation and analysis of Safety Requirements
'Weather' is anthropomorphized as a malign agent

The use of metaphor and anthropomorphism may appear colourful and even frivolous. However, human reasoning has evolved in a social context to permit sophisticated judgements about possibly hostile intentions of other intelligent agents [Pinker 1997]. Use/Misuse Case analysis deliberately exploits this faculty in the service of systems engineering.

Misuse Cases may help to elicit appropriate solutions in the form of subsystem functions, such as for traction control and automatic braking control. These handle exception events (such as skidding) by carefully programmed responses. These satisfy requirements that may be written as exception-handling scenarios. Such scenarios can either form the Exception subsections of larger use cases (such as 'Control the Car') or may be pulled out into Exception-Handling Use Cases in their own right, as illustrated in the diagram below, where the 'pulling out' is indicated by explicit 'has exception' links.

Once such exception-handling use cases have been identified, the Misuse Cases are not needed except as justification for design decisions. Justifications remain useful to protect design elements and requirements from being struck down at reviews, especially when time and money are scarce. The misuse cases can readily be displayed or hidden as desired by use case tools such as my Scenario Plus toolkit for DOORS [Scenario Plus 2001, DOORS 2001].

As with Security Requirements, Misuse and Use Cases may be developed in stages, going from system to subsystem levels and lower as necessary [Allenby & Kelly 2001]. Again, bottom-up and middle-out working remain possible. The explicit presence of Misuse Cases should make validation of requirements by domain experts easier and more accurate.

5. Other Non-Functional Requirements

It is evident that other NFRs may be handled in a similar way with Use/Misuse Case elicitation and analysis.

Reliability requirements may be elicited and analysed as threats caused by agents of several kinds, including human error, storms, design errors (e.g. software bugs), and metal fatigue. These can cause hardware breakdowns, software crashes and so on. There is a clear relationship between such 'agents' and Exception Classes, which can be used to generate candidate scenarios and hence elicit requirements [Maiden 1998].

Maintainability and Portability requirements may also benefit from the Use/Misuse Case treatment. Here the 'malign agents' could be inflexible design or wired-in device dependence.

It is not difficult to think of example Misuse Cases for other NFRs such as Usability (Simple Simon presses the wrong button), Storability (Jack Frost damages the delicate components), Electromagnetic Compatibility (Jack the Lad's homemade transmitter fries the sensitive electronics) and so on for other '-ilities'.

While I wouldn't advocate blindly creating hundreds of Misuse Cases for every possible requirement, especially when the NFRs in question are well known in advance, the technique does appear to be widely applicable to elicit and justify different types of NFR.

6. Discussion

References

Alexander, Ian, Migrating Towards Co-operative Requirements Engineering, Computing & Control Engineering Journal, Volume 10, Number 1, pp17-22, February 1999

Jacobson, Ivar, et al: Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992