Alistair Cockburn proposed a detailed template for documenting Use Cases [Cockburn 2001]. We believe his approach is largely suitable for SE projects, but have modified it to cover Exceptions and Constraints explicitly [Alexander & Kiedaisch 2002; Scenario Plus 2002]. We also suggest that for the purposes of Systems Engineering, two basic types of Use Case at opposite ends of a continuum are worth considering:

• Domain Expert-facing Use Cases are mainly for eliciting and validating user requirements. They can be simple and story-like, to illustrate important points.
• System Engineer-facing Use Cases are mainly for specifying systems. They must be analytic, complete, correct, and measurable. They may be used to generate tests, animations, and simulations.

1. Applying Use Cases in the Systems Engineering Life-Cycle

Against the background of the concept of the Use Case (see box), we believe that Use Cases may be helpful throughout the Systems Engineering life-cycle (see figure). These are in the User Requirement and Specification phases, at both System and Subsystem levels, and Architectural Design at System level. The models in these places are not necessarily all distinct, and may evolve from one into another. Test Cases may also be more or less directly generated from Use Cases. In general User Requirement documents are mainly user-facing, while Specifications are mainly engineer-facing.



The Place of Use Case Models (UC) in Systems Engineering
(Sets of Test Cases, which may be generated from Use Cases, are marked TC)

Background: The Systems Engineering Life-Cycle The standard hierarchical model of Systems Engineering, e.g. as described by Richard Stevens and his colleagues [Stevens 1998] divides up the life-cycle horizontally by phase (conventionally named User Requirements (UR), System Requirements (SR), Architectural Design (AD), and System Test (ST), and vertically by level (System, Subsystem, etc). The basic life-cycle phases recur at each lower level, with the possible exception of User Requirements. There may not be any real user requirements at lower levels, unless there are specific user interfaces, such as in an instrument panel subsystem. But subsystems are often developed by subcontractors. The subsystem team needs to re-evaluate the incoming specification from the level above to understand what the subsystem is supposed to achieve for its system "users". We differ from Stevens, therefore, in asserting that subsystem development often needs a requirements activity ("SS-UR") before specification, just like a system development. The model thus has a strong regularity (see figure). A simplified view of Systems Engineering Activities The arrows indicate satisfaction traces. Verification traces are omitted for clarity However, this model assumes conventional requirements elicitation and analysis. Scenarios are becoming increasingly widespread, especially in the form of Use Cases. This paper looks at how the Systems Engineering model may be reconciled with the Use Case approach, principally for functional requirements. A companion paper will look at how Use Cases may help to elicit and analyse non-functional requirements such as for safety, security, and reliability [Alexander 2002].

1. Eliciting Top-Level User Requirements

So in short, the use cases should initially be sketchy and illustrative to serve as a vehicle for communication with users. Use cases made to help elicit requirements from users do not necessarily have to "survive" throughout the project, but can be allowed to evolve in later phases to an engineered analytical set of use cases, which the next section will treat.

System Specification and Design

A complex system has to be allocated by a system-level architectural design into subsystems. These are typically intended to be suitable for letting as subcontracts. Preceding such a division (i.e. definition of the subsystem interfaces), the System has to be unambiguously specified and designed at high level. Therefore the initial user requirements have to be transferred into a complete and consistent system requirements specification. In this specification, use cases can again be applied to document the functional requirements – probably in conjunction with other means of specifying behaviour (see below) – but in a rather different form and quality from user requirements. This form and quality can be described as:

• correct and complete, as a definition of the system
• straight (not colourful)
• traceable item by item
• verifiable, measurable
• requirement-like.

In short, we are talking about an (engineered) analytical use case model. Creating this out of the initial sketchy user requirements is an intensive task. The use cases are thought through in terms of detailed alternative paths, exceptions, local constraints, triggers and preconditions. The analyst’s search for exceptions is guided by a use case template [e.g. Cockburn 2001, Kulak & Guiney 2000], so the system specification should be of higher quality.

Background: Black- and White-Box Test Cases/Use Cases Test Engineers familiarly describe tests that demand no insight into the mechanisms or composition of a System as 'Black-Box', implying that the system is opaque to the tester. A Black-Box Test Case merely calls for the tester to supply a valid set of inputs and to test whether the resulting outputs are as expected. In contrast, a White-Box Test Case requires the tester to 'look inside the box' and observe whether the system's components are functioning as intended. Thorough test campaigns generally use both approaches. Applying the same concepts to Use Cases, a Black-Box Use Case describes a system purely from outside. For instance, a fax machine need have no knowledge of how the telephone network sets up a call; it only needs to know how to ask for a call to be set up. A White-Box Use Case looks inside the box and considers the role of parts of the system under design, to enable designers to make sure that, if built, the system would indeed be able to operate as intended.

The role of Use Cases in System Architectural Design is interesting. The aim here is to identify at least the first level of subsystems and the interfaces between these, to enable the subsystems to be designed on a secure footing. The use cases for this purpose must therefore look ‘inside the system box’ to name and define the role of the subsystems. For Design, use cases must therefore be White-Box at system level, or Black-Box at subsystem level, depending on your point of view. This is in marked contrast to User-facing use cases which should certainly treat the System as a Black-Box.

Should System Specification use cases be black- or white-box? If you believe that the specification should be completed before the design, and should leave maximum freedom for the designers, then you ought to say black-box. If like [Swartout & Balzer 1982] you believe that system specification and design are inextricably intertwined, then System Specification use cases must be white-box and can conveniently be handled as one model shared with Architectural Design. We are not system architects but we suspect the latter position is more realistic.

1. Elicitation and Understanding of Subsystem "User" Requirements

   The third place where use cases can be applied is in the elicitation of the user requirements for subsystems. Now the goal is to elicit requirements for the subsystem, so we will treat the subsystem as a black box. Subsystem "users" are often not human roles – many subsystems have no user interface; those that do may require additional contact with users to identify and validate new user requirements not identified at system level. Requirements for a subsystem have narrower scope than top-level user requirements, and may have to be more detailed. We conclude that the abstraction level covered by use cases is relative to the system-layer we are currently focusing on.

   One might ask why there is a need to elicit "user" requirements at subsystem level at all – if the black-box view of the subsystem is fully specified by the system architectural design. But this may not be so in practice. Subsystem engineers need to re-analyse the subsystem’s "user" requirements to ensure that they correspond to something that can actually be delivered without excessive contractual risk. The benefit of use cases at this level is therefore not so obvious as in the top-level User Requirements phase. However we believe there are good reasons for the use case approach even here in the ‘Subsystem User Requirements’.

   For example, a Door Control Unit subsystem for a car may support several distinct capabilities afforded to the driver, such as adjusting the wing-mirrors or closing the windows automatically when locking the car. Some of these may not have been analysed in any detail at system level. Another example is with a car’s instrument panel, where the detailed user interface may involve analysis of specific driver interactions at subsystem level.

2. Specification of Subsystems

Subsystems in an environment like automotive embedded systems need carefully-analysed requirements because of contractual boundaries. An external or black-box requirements document sometimes isn’t sufficient, because a supplier may want to reuse specifications between models of car. Reuse may be facilitated by defining the functional behaviour of the subsystems in use cases [Alexander & Kiedaisch 2002]. However, use cases are likely to form only part of such a subsystem specification, for three reasons.

Firstly, additional constraints such as agreed values of signals on the communications bus have to be included to ensure that subsystems can be integrated and do not conflict; these can be viewed equally as interface requirements created at system level, or as design constraints applicable at subsystem level.

Secondly, some subsystem behaviour must be defined algorithmically, for example control laws that express continuous functions. This is discussed further below (see 'Algorithmic Subsystems').

Thirdly, some non-functional requirements may be difficult to express in use cases. These are conventionally listed at the end of the specification. It may however be possible to address many of these by means of 'Misuse' Cases framed from the point of view of hostile actors [Alexander 2002].



Relationships of Different Use Case Models
in the Systems Engineering Life-Cycle

3. Conclusions – Use Cases throughout the Life-Cycle

• The abstraction level in a use case model is relative to viewpoint within the Systems Engineering life-cycle. Use cases make sense in different phases, but in different ways.
• The use case models are not necessarily all distinct. In particular it seems reasonable to use a combined Specification/Design white-box model. This may perhaps evolve from a sketchier black-box use case model created in the User Requirements phase. Similar considerations apply at subsystem level. Subsystem User Requirements models (black-box as regards the relevant subsystem) can be created by copying relevant parts of System Specification models (white-box as regards the whole system, black-box for the contained subsystems).
• Who or what needs to be treated as an actor depends on the life-cycle phase and the specific problem.
• Engineers should create sketchy, incomplete but easy-to-read models to elicit, validate, and explain requirements.
• Engineers should construct analytical models, including use case models, to specify systems for development and verification.

1. Even Control Subsystems may benefit from Use Cases

   Use Cases have been enthusiastically welcomed in the object-oriented software world. They are relatively new to Systems Engineering, but even so, it is clear that some engineers are concerned about how far concepts such as Use Cases may be applicable to Systems Engineering problems.

   From our limited experience with Use Cases at DaimlerChrysler, we think that there are two distinct types of situation for Use Cases, and that these are most easily distinguished by thinking about subsystems. These are where subsystems clearly provide separate functions to users, and where subsystems appear to provide one continuous range of function controlled by some set of rules or algorithm. Let us consider these two situations in turn.

   1. Subsystems Providing Separate Functions to Users

   The first situation is where a subsystem has readily-identified human or system user Roles ('Actors'), and where these actors have readily-distinguished uses for the subsystem.

   

   Suppose that a car has a Door Control Unit that automatically handles the locking and unlocking of the doors, the raising and lowering of the windows, and the adjustment of the wing-mirrors and seats, as well as the setting and retrieval of different drivers’ personal preferences for such settings [Houdek 2001]. The listed functions are clearly distinct, and can be described straightforwardly as discrete Use Cases. The cases interact in a few specific ways: for example, door locking may automatically close the windows; retrieving a driver’s preferences may automatically adjust the wing-mirrors.

   In such a well-behaved situation, Use Cases help to sharpen up the concepts of each case, making the control unit better specified and easier to test. The Use Cases may also help to detect situations – especially exceptions – that had been overlooked, such as what to do if the two wing mirrors are initially misaligned relative to each other: a calibration Use Case may be required.

   2. Control or Algorithmic Subsystems

   The second situation is where a subsystem consists mainly of an algorithm that appears to represent one continuous approach to a wide range of possible inputs.

   

   Many subsystems seem to us to be probably of this ill-behaved type: after all, engineering is all about control, which typically consists of implementing a set of control laws. These are often differential equations that relate the necessary control outputs to the detected state inputs. If the laws are correctly specified, then the effect of the subsystem is to change the state of the world in the desired direction and amount to maintain control.

   Suppose that a vacuum cleaner automatically controls the height of the air-intake nozzles above the floor being cleaned, and the degree of vacuum (the pressure drop) applied at the nozzles. These variables together control how hard the cleaner extracts dirt from the surface being cleaned, and how much damage is inflicted on delicate surfaces such as carpets. For this purpose, the cleaner has a Cleaner Control Unit that continuously senses the roughness of the surface and its distance from the nozzles, and instructs the fan and height-adjustment motors accordingly.

   In such a situation, there seems at first sight to be just one large and continuous Use Case: for the vacuum cleaner it is the uninformative ‘Clean the Floor’. Worse, it seems that all its behaviour is describable only in terms of the control laws that relate surface type to nozzle height and vacuum pressure. If this was the whole story, as implied pessimistically by [Jackson 2001, Rupp & Hruschka 2001], there would be little future for use cases in systems engineering.

   However, the situation is not quite so simple. Let us ask some of the questions that a requirements engineer eliciting user requirements might ask stakeholders such as carpet owners.

   For instance, do you want only to have the cleaner decide for itself how to set the nozzles and the vacuum power? Maybe a manual mode is desirable. In any case, if the control unit fails, why shouldn’t the vacuum cleaner still be usable? If the fan works and the nozzles can be set at a fixed height, the cleaner can continue to do its job – this would be a more graceful degradation of function than simply breaking down.

   And another thing: what if the user leaves the cleaner running and answers a call at the front door or from a distressed child: what should the cleaner do then? Plainly, wearing a hole in the carpet is not ideal, so it would be better to idle if the cleaner was not moved for a while. Incidentally, this example illustrates how more or less ‘colourful’ use cases can lead directly to requirements.

   Finally, thinking about the use of the vacuum cleaner in different countries, might it not be necessary to configure it for wetter or dustier places, or where, say, thick pile carpets were habitually replaced annually? Different types of user might require very different amounts of cleaning effort, and expect different amounts of consequent wear and tear on carpets.

   

   Such requirements elicitation work at Use Case level might lead to the following Use Case Model. The user is able to configure the vacuum cleaner to local conditions, and may either allow the cleaner to clean the floor according to its control laws, or may vacuum manually with the user’s chosen settings. Whether automatic or manual, the cleaner goes into idle (perhaps the fan runs softly for some minutes before powering down completely) if it is left on but not moved over the floor for a certain time.

   The ‘Handle Errors’ Use Case is also an important case when software is performing control functions: software errors can arise, and must be handled safely as Exceptions to prevent damage. If errors persist, the machine’s owner might need to take it for remedial maintenance, where the error log could be examined on a special testbed and the maintenance engineer can ‘Diagnose Problems’ accurately. This too is quite a general case for control systems.

   Notice that both the ‘Idle’ and the ‘Vacuum Manually’ cases demand some degree of control from the control unit; there is work to be done, and not only for the more apparent ‘Clean the Floor’ case. There are, in short, several non-trivial Use Cases essential to the system’s correct and safe functioning, not only one. In general, any of these cases may need to be implemented with their own algorithms or control laws. Use Case modelling neatly complements the framing of algorithmic problems within specific use cases.

2. The Way Ahead

1. Use Cases do have a place in Systems Engineering

We suggest, therefore, that there is a somewhat justifiable feeling that Use Cases may be tricky to think about in many Systems Engineering situations, such as in control subsystems, where at first sight there are few system functions and hardly any distinguishable cases to describe. But we observe that even in simple-looking situations, a little Use Case elicitation and analysis can readily discover plausible Use Cases.

The ‘Idle’ case for the control unit discussed above is interesting, as it represents a boundary condition – long known to generate the sort of test case often worth running. Use Cases are excellent candidates for test cases: indeed, each path and exception branch identified in a Use Case is a candidate for a test case. The Idle case represents a zero velocity of the cleaner over the floor. Such cases can lead to undefined values in equations as illustrated in the sketch diagram below. Discontinuities between cases ought to be picked up during analysis – and if not, during testing – but finding them early is both desirable and cost-effective in Systems Engineering terms [Stevens 1998].



Special cases in apparently continuous control-loop algorithms –
Cases such as zero velocity must often be handled specially

Any Use Case discovered is at the least an area of functionality that users would have missed in the developed product. Any Exception-Handling Use Case discovered and correctly implemented represents a class of system failures prevented. Many control systems are safety-related, so preventing failures is extremely important. Happily, the cost of applying Use Case thinking is small, and the tools and techniques needed are simple [Cockburn 2001]. It seems to us that the chance of preventing even one class of failures is sufficient justification for applying use case thinking, leaving aside all the normal benefits claimed for use cases.

By deliberately identifying different types of User, their Viewpoints and Interests, possible Conflicts requiring resolution, whole life-cycle scenarios, and Exceptions, the requirements engineer can help to find ‘offline’ cases such as storage, configuration, setup, diagnosis, repair, test, and disposal that might otherwise be missed. Concerns as varied as the desire of a householder not to damage a valuable Persian carpet, or the need for a maintenance engineer to download error records into a diagnostic system, are valid considerations in requirements engineering.

2. Systems Engineering may need to use different types of Use Case

We suggest that the sort of Use Case ideally suited to requirements elicitation early in a project has the character of a sketch: it is colourful, easy to grasp, quickly prepared, and may well be both inaccurate and incomplete. In contrast, the sort of Use Case suited to system specification later in a project has the character of requirements: it is analytic, careful, detailed, accurate, and as complete as it can be made.

It is possible to derive analytic Use Cases from sketchy ones by developing them or letting them grow organically as relevant facts emerge. To keep large numbers of cases organized and consistent over time, a requirements tool specialized for Use Cases, such as DOORS with Scenario Plus, is probably amply justified [DOORS 2002, Scenario Plus 2002].

As attention moves down from System to Subsystem level, the scope narrows, contact with users diminishes, and interfaces between subsystems become more important. Steps in Use Case scenarios often concern messages between subsystems. However, the character and role of the Use Cases seems to us to remain much the same. They draw attention to ways of using the system that might otherwise have been overlooked; they indicate the order in which functional steps should be taken; they help to identify exceptions that might cause system failure if not handled; and they indicate possible test cases.

3. Discussion: Effect of Use Cases on Systems Engineering

Engineers familiar only with software may believe that Use Cases are all that need to come between users and the developed system: for small or medium software projects, this may be an acceptable viewpoint. But for large and safety-related hardware/software systems, the collapsing of system and subsystem levels, and user-facing and system-facing activities, into one item labelled ‘Write Use Cases’ is clearly inadequate.

We have no doubt that the conventional Systems Engineering model [Stevens 1998] is essentially correct – leaving aside the important question of 'soft' issues – and will survive the addition of Use Case modelling to the systems engineer’s repertoire of techniques. Use Cases are very good for telling the stories of a system; we suggest that there may be several kinds of story to tell. These need not conflict in any way with conventional Systems Engineering documents, though if desired it is quite feasible to replace functional requirements with Use Cases, or rather, to organise such requirements in Use Cases at all levels of a system.

We are surprised that the concept that the Use Cases are the functional requirements, as asserted by [Cockburn 2001], is controversial, but [Jorgensen 2001] explicitly denies it:

I personally must object to the notion introduced by many UML proponents that a "Use Case" is equivalent to or expresses a "Requirement". Use Cases and Requirements are still two separate notional entities. A Use Case can be effectively used to help more concisely define a requirement, but use cases do not substitute for requirements. … The use case states what the user does, and what the machine does in response, but the use case cannot declare that the user [sic; perhaps he meant 'system'] "shall" do anything.

Jorgensen perhaps feels that since Use Cases are traditionally stated as descriptions rather than as mandated actions ("shalls"), they are unsuitable for use as requirements. This is a matter of style rather than of substance; a shall-statement is only necessary when no other means of indicating scope and priority exists. However, requirements tools make it straightforward to define attributes to qualify functions in these ways. Even on paper, a simple table with a priority column can show how important each requirement is without resorting to the use of "shall".

He may perhaps also be indicating that the place of Use Cases is the same as traditional Operational Scenarios, namely to set the context for systems rather than to define what they must do. However, Use Cases defined at different levels and in different amounts of detail can achieve both these purposes.

A more slippery issue that may be behind Jorgensen's concern is whether there is a 1:1 mapping between Use Case steps and requirements. If the scenarios being described are concrete instances ('John and Mary are having a picnic beside their car. …') then there can clearly be numerous examples per requirement. However if as we expect the Use Cases are generalized (to form abstract classes) then each step should occur exactly once. [For a fuller discussion, see On Abstraction in Scenarios, Alexander 2002.]

We agree with Cockburn that Use Case steps directly state the functions that must take place, but would caveat that not all of them need be automated – some steps may be manual. However, all that is needed to enable Use Case steps as requirements is to indicate with attributes whether a step is in scope, and if so what priority it has and in which release it is to be implemented. The pre- and post-conditions that Cockburn says should be defined as part of every Use Case then form the basis for acceptance test criteria for the requirements. All this is part of the normal work of documenting requirements, and is readily carried out using requirements management tools [DOORS 2001, Scenario Plus 2001].

In addition, Jorgensen seems to believe that Use Cases are necessarily black-box descriptions:

[T]he use case describing interaction with the machine is only the first entry point into the definition of what the machine does.

This is partly correct: a use case should not assume the structure of the 'machine' whose functional behaviour it is helping to define. However, it is wrong in its implication that use cases can only be used to define a system's boundary at the highest level.

Firstly, use cases may be applied at any level within a system or subsystem: what is black-box for a subsystem is white-box for the level above. Conventional use case examples such as teller machines are small subsystems within a bank's overall computer network, which in turn is a part of the clearing system that allows customers to draw cash from a teller machine owned by another bank.

Secondly, an analytic system use case model is in our view necessarily a white-box model at that level. Jacobson's original application of use cases to analyse telephone systems was itself white-box. [Kulak & Guiney 2000] apply use cases first black-box in a 'façade' iteration and then white-box in a 'filled' iteration. System specification and design are to some extent inevitably intertwined [Swartout & Balzer 1982], even though decomposition into subsystems does to some extent undo the intertwining into successive stages.

Some engineers have suggested that Use Cases are inherently unsuited for use as analytic system models [e.g. Jackson 2001]. We don’t hold that view, but we do agree that an unorganized collection of sketchy Use Cases certainly does not constitute a system model. Engineers will need to develop or replace initial Use Case models to move from sketches to solid analyses – there is no substance in loosely-stated claims that system modelling will somehow be abolished. Systems need to be modelled in a range of ways. The goal and task sequences inherent in Use Case thinking are relevant and necessary supplements to existing system modelling techniques. This is not to claim, either, that Use Cases afford the only effective way of modelling goals and tasks [compare, e.g. van Lamsweerde 1998]: simply, that they offer a convenient and accessible way of doing so.

Use Cases can be represented very satisfactorily in document hierarchies linked by typed relationships (such as acts in, includes, has exception). These data structures permit easy understanding, navigation, calculation of metrics, animation and test case generation, while also favouring traditional requirements engineering techniques such as traceability. Tools to manipulate such structures in our opinion form an essential part of the system engineer’s toolkit.

The benefits of Use Case modelling in Systems Engineering are real and substantial, and are different from the effects of Use Cases in software engineering. We suggest that there are good grounds for believing that these benefits are available even for unpromising areas such as control subsystems.

We do not believe that Use Case models can always completely specify systems and subsystems – there are certainly cases where specifications must in the main consist of mathematical analysis. However, Use Cases can act as valuable checks that situations and classes of exception that require such analysis have not been omitted.

Finally, we think we can allay fears that Use Case analysis will only increase the Systems Engineering workload. Firstly, the effort required to identify Use Cases seems usually to be quite modest. Secondly, the resulting cases form readable sets of functional requirements: we concur with Cockburn that Use Cases can define all the functions at user level, and suggest that they can also form the framework from which to hang precise specifications such as control laws when specifying subsystems. Therefore the additional workload for Use Case analysis compared to conventional analysis should be small. Indeed, if Use Cases make requirements easier to follow, the time taken to write and review such documents should actually decrease.

3. References