Towards better railway system specifications through scenarios

The Auto Driver Box (ADB) enables Automatic Train Operation (ATO) on the Victoria Line. Component obsolescence demands re-engineering the ADB to extend the operational life of trains. The old specifications were incomplete, so an approach was selected to support a low-risk, ‘right first time’ procurement of the ADB replacement.

Together with Infraco BCV experts (Infraco BCV is a subsidiary company of London Underground Limited, responsible for maintaining and upgrading the Bakerloo, Central, Victoria and Waterloo & City Lines), we held a series of workshops and interviews to identify all relevant viewpoints, to agree operational scenarios’ for normal ADB operations and also for testing, maintenance, and manual modes easily omitted from conventional specifications. This approach ensured more complete and more accurate specifications from the outset.

The scenarios were fed into a requirements database and traceability tool (DOORS with Scenario Plus). The scenario structure consisted of operational goals (e.g. ‘Operate train manually’) and the sequences of steps these entail. Additional information including alternative possibilities within a scenario, exception conditions, the user roles involved, and non-functional requirements (eg performance, braking accuracy and constraints) were added systematically. Results were exported as fully navigable hypertext available to the project team through a standard web browser.

A template of non-functional requirement types resulted in explicit references to numerous clauses of applicable standards, as well as identifying several new functional requirements.

All the requirements were documented with attributes including priority, justification, and acceptance criteria.

The BCV team felt that this approach gave a much clearer picture of the ADB’s behaviour and operational context, and a firm, traceable basis for subsequent acceptance testing.

The Auto Driver Box (ADB) provides the Automatic Train Operation (ATO) function on the Victoria Line. The ADB was first introduced in the 1960’s and has successfully controlled all Victoria Line trains since then.

Component obsolescence has led to the need to re-engineer the ADB to extend the operational life of trains. The opportunity has been taken to specify enhanced functionality to provide smoother and faster braking, thus improving both passenger comfort and enabling trains to take less time between stations (as braking can be later), and thus increasing the capacity of the line (more trains per hour).

The old specifications were incomplete, so an approach was selected to bridge gaps in the specifications to support a low-risk, ‘right first time’ procurement of the replacement unit. For example, the old specifications covered the system’s behaviour with respect to the train’s speed and track codes in detail, but did not cover issues of verification during development and maintenance; nor did they state explicitly the non-functional requirements such as reliability or conformance to existing interfaces.

It was necessary to maintain functional equivalence between old and new ADBs, making the Safety Case easier to establish, while permitting enhanced braking. The essence of the Safety Case is that should the enhanced braking fail, old-style ADB braking would continue to operate; and indeed, the Trainborne Safety Unit (TSU) would independently trip braking in an emergency.

The basic method used was to elicit and organize the scenarios as Use Cases [Cockburn 2001], and then to place these in a conventional specification structure to enable each requirement to function as an independently verifiable engineering object [Alexander & Stevens 2002].

The core concept in conventional requirements engineering is traceability [Palmer 1996]. It is essential to establish a complete set of traces between requirements and design (and also to tests) to show that all the requirements are satisfied. Otherwise, some requirements may be wholly or partly missed during design and testing. Traces are tedious to maintain by hand; reliable traceability demands tool support.

The principal tool used was Telelogic’s DOORS [DOORS 2002]. This is a leading commercial tool for managing requirements in a database designed for handling text. Information is stored principally in Formal Modules, which permit documents to be represented much as in a word processor, but also as database tables. This ‘split personality’ offers the convenience and legibility of familiar specifications, together with the precision of a database. The equivalent of a database record in such a Module is an Object, consisting of a piece of text (typically, a heading or a requirement) supported by any number of Attributes, such as Justification, Acceptance Criterion, and Priority. Objects can be linked to each other by any number of directional relationships of any number of link types. For example a test step could be linked to a requirement by a ‘verifies’ link.

Two add-on tools were used within the DOORS environment, both from the Scenario Plus toolkit [Scenario Plus 2002]:

• Scenario Plus for Use Cases supports the capture, documentation, and export as hypertext of structured scenarios, known as use cases.
• A Dictionary tool supports the semi-automatic creation of a project dictionary, based on (italicized) mark-up of terms to be defined in the text of scenarios, requirements or other project documents.

The Use Case is a structure for organizing scenarios, by which we mean stepwise descriptions of how agents (such as train operators and maintainers) interact with a system to achieve their goals. For example, the functional goal ‘(To) Take Train into Service’ is described as a Use Case in its own right (see Figure 2). Use Cases are usually written as a terse narrative, in which each paragraph describes a single step (or event) in the form:

The Use Case framework defined by Cockburn expects not only a normal course of events but also a description of how other events (which we call ‘Exceptions’) that might cause the system to fail should be handled; pre- and post-conditions are also defined.

All this is clearly very requirement-like, and in some domains (such as object-oriented software) functional

specifications are written directly as Use Cases.

However we felt it better to retain conventional railway industry specifications, and to supplement them with the scenarios via satisfaction traces (Figure 1).

Together with Infraco BCV (Bakerloo, Central & Victoria Lines) experts, we held a series of workshops and interviews to identify all relevant viewpoints. Subsequent workshops discussed and agreed operational scenarios not only for normal ADB operations but also for easily omitted testing, maintenance, and manual modes.

Figure 2: Scenarios as Hypertext

We also discovered a key group of requirements for a Simulator, which would have been costly to add further downstream. Essentially, since the available track is in constant use, on-track test time is a scarce resource; new systems must be ‘right first time’. Simulation must therefore cover not only the interfaces to the box, but must behave as if the box was in a train travelling the whole track, each station approach being unique.

We imported the existing (partial) specifications from Microsoft Word into the requirements tool. Then we added attributes (database fields) to document test criteria, justifications, and other details not previously covered given the limitations of ordinary word-processed project documents.

We checked the Specifications for the New Auto Driver Box (NADB), the Simulator, and other Test Equipment, against the use that would be made of these devices as described in the Scenarios.

The scenario structure consisted of operational goals (e.g. ‘Operate train manually’) and the sequences of steps these entail. Additional information such as alternative possibilities within a scenario, exception conditions, the user roles involved, and any constraints (e.g. performance, braking accuracy, etc) were developed and added in a systematic way.

Results were exported as fully navigable hypertext available to a project team through a standard web browser (Figures 2, 3). This meant that no access to or skill in using a specialized tool such as DOORS was required to review the scenarios.

Figure 3: Graphical Navigation of the Scenarios

We created a simple hierarchical template of headings (Figure 4) to document the ADB’s non-functional requirements, such as reliability, maintainability, physical and environmental constraints, and interfaces. It formed the last chapter of the specifications.

The effort to fill in this template with precise requirements resulted in explicit references to numerous clauses of applicable standards. Perhaps more surprisingly, it also led to the identification of several new functional requirements, seen to be necessary to make the system maintainable.

5 Global Non-Functional Requirements

Figure 4: Template for Non-Functional Requirements

We defined all terms used with special meanings within the project in the project Dictionary, using a tool to link terms (marked up in italics in the text) to their dictionary definitions semi-automatically (Figure 5).