1 Embedded user interface specifications

Most significant user interfaces are designed in collaboration with other specialists participating in a larger process of project development. Because user interfaces are integral to systems, and because user interface design is subordinated to the development method adopted for a project, requirements specifications for user interfaces are often embedded in the systems requirements document. In this paper we address the issue of how user interface designers work with embedded requirements specifications and how to enable them to work more effectively with those requirements.

The requirements document for the AIRBUS A380 Datalink ATC system well illustrates the issues. The Datalink ATC system is a cockpit system enabling pilots and ground control to communicate by digital links, supplanting the traditional radio communication (Wickens et al. 2003). Information and instructions from the ground controllers appear as visual text on a display screen in the cockpit (Helleberg and Wickens 2003); pilots send requests to the controllers by making selections from a menu system using menu navigation buttons.

The primary requirements specification for the Datalinks system is referred to as the Detailed Technical Specification (DTS) and consists of more than 1,500 pages of structured text, containing more than 3,500 requirements that exhaustively prescribe the required structures and functions of the system. Every part of the development of the Datalink ATC system is referenced to the DTS, including the design of the pilot interface. The DTS is therefore a critical document for conformance with the Avionic Systems certification standard for safety critical software and in particular its associated Certification Review Item which obliges avionics systems’ providers to “relate each development and assurance level to a comprehensive list of requirements” (Papadopoulos and McDermid 1999).

The DTS is one of a number of specifications produced in the development of the Datalinks system. It is preceded by a specification of required system functionality (the “Function Requirement Document”, or FRD) which sets out the generic functions that the system will provide and principles governing how these functions will be provided by the system. An important source for those requirements is interviews with pilots and observations of pilot activity in the cockpit. How requirements are elicited and represented in the FRD is outside the scope of our study, although it is important for the purposes of our study to note that it does not involve documenting use cases. The DTS is developed from the FRD to be the comprehensive and authoritative specification of requirements for what the system is and what it will do. It is followed by a formal specification for the Datalinks system from which some, though not all code for the implemented system is automatically generated (the formal specification and code generation is outsourced on the basis of the DTS, an important contractual role for the document).

The issue of certification reaches into every part of the development of the Datalinks system. Without certification, the system will not become operational and certification may be refused over any element of the system. Certification demands amongst other things that each feature of the Datalinks system can be traced back to a specification in which a requirement for that feature was expressed. It demands equally that each requirement in the requirements document is realised in the implemented system. The formal specification is unable to support this tracking between feature and requirement, because it does not explicitly represent the requirements and the certification process insists that systems requirements are expressed in natural language. The DTS therefore plays a vital role in enabling requirements to be traced to implemented features and vice versa, albeit through the intervening formal specification.

Significant numbers of analysts are involved in creating the DTS which is used by engineers in designing and implementing the system; yet other specialists are involved in testing the system. In the midst of all these specialisms are the Human Factors engineers who have responsibility for ensuring that the DTS conforms with the principles set out in the earlier FRD and that the implemented interface conforms with the DTS.

The Datalink ATC system is now operational on the Airbus A380 and development of the system has entered a new phase in which the DTS continues to play a vital role. Through a succession of releases the system is being enhanced in response to anomalies exposed by various processes, pilot experience with the operational system, new standards and procedures for aircraft operation, and possibilities arising from new technologies. With each system release, conformance with the DTS must be re-evaluated and so too the DTS must be maintained as the authoritative account of the requirements that the system embodies. Variants of the Datalink ATC system are being developed for the family of Airbus aircraft and development of each variant has its corresponding variant of the original DTS for the A380. So the DTS is a living document, an evolving repository of the technical knowledge about the system possessed by the developers. Developers work continually with the specification accessing, modifying and sometimes extending its content.

The Datalinks DTS contains all the requirements for the DTS system including the requirements for the user interface. The requirement which specifies a scroll bar for viewing text on screen is reproduced in Fig. 1, and well illustrates the way in which user interface requirements appear in the DTS. User interface requirements are embedded in the sections of the DTS corresponding with the systems functionality to which they relate. The DTS does not offer a directly accessible and coherent representation of the user interface specification for the Datalinks system.

Fig. 1
figure 1

Requirements for the pilot interface are embedded in the Detailed Technical Specification (DTS). Here the DTS specifies that pilots should access pages within the Air Traffic Control Communication (ATCCOM) display by scrolling, and the interface controls for scrolling

Full size image

2 Working with the Detailed Technical Specification

The vast content of the DTS document is organised around the system’s six main functionalities; for example, there is one section dedicated to the Automatic Dependent Surveillance (ADS) functionality (which allows ground control centres to obtain reports about aircraft status such as position, altitude, etc). There is also a general section which specifies common requirements referenced by other requirements (e.g. display character fonts). Although the DTS is comprehensively indexed according to the functional division of the Datalinks system, special purpose search and retrieval mechanisms are not provided and users of the document often resort to basic word searches to find particular requirements in the DTS.

The problems for user interface designers are particularly acute. The DTS is used by user interface designers to assure conformance of the Datalinks pilot interface requirements with established principles for the design of the cockpit interface; it is used to document requirements for the pilot interface that subsequently emerge; and it is used to guide implementation of the pilot interface and for testing. Yet because the user interface for the Datalink system must support distinct tasks, and because the pilot’s activity typically involves interacting with several technical sub-systems, the specification of requirements for the user interface is dispersed within the DTS. For example, to operate an ADS functionality, a pilot must go to a Connection Status screen displayed on an Air Traffic Control Communication (ATCCOM) screen. The DTS contains a section for the ADS, but vital information about accessing the ADS functionality is also found in the section detailing the ATCCOM functionality. Other information about the ADS connection functionality is to be found in the general requirements section of the DTS (the DTS–GEN section). As a consequence, identifying and retrieving user interface requirements from the DTS is difficult. Worse still, the DTS confounds the efforts of the user interface designer to model (in the sense of forming a coherent understanding) the operation of the pilot’s user interface.

To better understand the difficulties encountered in using the DTS, we conducted informal interviews with four specialists representing different roles which use the Datalinks DTS:

  1. 1.

    specialists writing the DTS document (Group 1)

  2. 2.

    specialists using the DTS to produce formal specifications for the system (Group 2)

  3. 3.

    specialists testing the implemented system to ensure compliance with the requirements (Group 3)

  4. 4.

    user interface designers who work with pilots to define the user interface principles for the system and who ensure that the DTS is compliant with these principles (Group 4)

All of the specialists interviewed had at least 4 years experience of working with the DTS. The interviews were structured around these questions: How do you use the DTS document in your work? What are the main difficulties you encounter with the DTS? Can you give examples of these difficulties? What do you think about the structure of the DTS? What would you like to see changed with the DTS? Table 1 summarises the problems with the DTS reported in the interviews.

Table 1 Problems using the Detailed Technical Specification, reported in interviews with representatives of the four different stakeholder groups
Full size table

The difficulties which these different stakeholders reported include many that are particular to their individual roles, however they also include several which are shared, and most prominently:

  1. •

    Navigation and retrieval: the difficulty in searching for and retrieving requirements related to a particular aspect of the system

  2. •

    Interpretation: the difficulty in understanding the composite behaviour of the system (for example, it is often necessary to read entire chapters to understand particular operations of the system)

  3. •

    Assurance: the difficulty in ensuring the completeness and correctness of the requirements specification

The interviews also elicited some suggestions and positive features of the DTS (Table 2).

Table 2 Sample of suggestions for improving the Detailed Technical Specification, reported in the interviews with the stakeholders
Full size table

In the following section we propose a concept for a tool intended to assist user interface designers working with the DTS for the Airbus Datalink ATC system. The concept exploits Sequence diagrams combined with hypertext to provide a means of accessing relevant user interface requirements embedded in the DTS according to the use cases to which they relate. A prototype that implements the tool concept, and an evaluation of this prototype, are described in Sect. 3. The results of the evaluation are examined in Sect. 4.

3 Tool concept for embedded user interface specifications

To be effective, a requirements specification must reflect the particular use to which it is put. In a very real sense then, a requirements specification is itself a system that should be designed to support the needs of the developers who use it (Potts 2006). The content of the specification, its structure and representation, and the mechanisms for accessing and modifying the specification all need to be adapted to the way it will be used by the developer. Requirements specifications built to standards and templates may not be sensitive to particular contexts and uses, and can be fundamentally ineffective (Kovitz 1999).

The DTS for the Airbus Datalink ATC system is used by several different developer specialisms, including the pilot interface designers. Those different developers each have particular needs that the specification must satisfy. The needs of the analyst for a DTS to support them in creating a formal specification for the telecommunications systems will inevitably be very different to the needs of the user interface designer. Yet at present, the construction and access to the DTS offers little concession to the particular needs of any one kind of developer. The specification is stored as a Microsoft Word document and developers rely entirely on using the facilities offered by this general purpose environment, such as the string search tool for finding words and phrases. What is needed then, is not merely a more elaborate index for the DTS but rather, a task specific interface to the DTS for the different specialist developers who must use it.

The fundamental need of the user interface designers working on the Airbus Datalink ATC system is for a better front end to the DTS, one that would allow them to model and manage the pilot interface expressed by the requirements document. This front end needs to provide an explicit representation of the pilot’s interface and enable the designer to more easily understand the system behaviours corresponding with particular operations performed by the pilot. It needs to support designers in retrieving the requirements embedded in the DTS that correspond with this pilot interface model. It needs to enable those designers to assess the effects of changes in the pilot interface model on the contents of the DTS, and vice versa.

In response to this need, we developed a prototype user interface requirements modelling tool. The tool exploits use cases and sequence diagrams as a representational medium for modelling the pilot interface, combined with hypertext for retrieving the relevant requirements contained in the DTS. The three sections of the tool are visible in Fig. 4 which shows how the tool is used to retrieve the requirements corresponding with a particular use case. The highest level of the tool consists of a catalogue of use cases. By selecting a use case title from this catalogue, access is gained to the sequence diagram representing the pilot activities corresponding with the selected use case. The sequence diagram is augmented by a map diagram describing the architecture of the user interface corresponding with the use case. Elements in the sequence diagram provide access via hyperlinks to the set of specific requirements embedded in the DTS corresponding with the particular elements in the sequence diagram.

The specification of requirements for the Datalinks system does not currently make use of use cases as a representational construct, although use cases are a well established means of documenting systems requirements. Use cases are a useful way of documenting and analysing users’ tasks for the purposes of designing the user interface and correspond well with a scenario-based approach (Benyon et al. 2005). Within the Unified Systems Development Process, use cases are a central construct and all development initiates from them. Use cases describe a set of actors or users, their goals, and a sequence of their activities for achieving the goals. Use cases originate from investigations with users during the systems analysis activity, are realised during design, and are verified during testing, they are expressed in the form of structured text, often augmented with simple use case diagrams. Significantly, there is no standard definition of a use case, or standard way of organising their content (Fowler 2004). Use case maps (Fig. 3) are a supplementary form of diagram that show relationships between use cases (Amyot and Mussbacher 2001) and help developers relate requirements to system structures and features (Buhr 1998).

Sequence diagrams (Fig. 2) compliment use cases by diagrammatically representing the logical and temporal relationships between activities. In our prototype, sequence diagrams follow the notation of Message Sequence Charts which were originally developed to describe the order of message passing between a telecommunications system and its environment (Wieringa 1998). These charts are now incorporated into the Unified Modelling Language alongside use cases, (Fowler 2004). A sequence diagram uses vertical lines to shows different actors (users, processes) involved in a use case; messages passed between these actors are shown as horizontal arrows between the vertical lines in the sequence in which they occur. Sequence diagrams are able to specify time constraints on message delays and can therefore return useful additional timing information, such as the minimum and maximum possible delays between pairs of events. These aspects of the notation have potential value to the pilot interface of the Datalink ATC system and need to be augmented for their use in describing user behaviour, for example to be able to represent alternative flows and iteration. In our tool concept, in order to link the different states of the Datalinks system relative to the different actors’ actions, every sequence diagram contains hyperlinks to the requirements describing this particular state. The diagrams are able to represent alternative states of the Datalinks systems.

Fig. 2
figure 2

Sequence diagram for the “REQUEST” use case

Full size image

The tool concept was developed through a series of sessions with the developers who use the DTS, including the pilot interface designers. Early prototype versions of the tool were used in the sessions to explore the features needed to search for requirements related to particular kinds of design issue. The prototype evolved through incorporating suggestions made by the developers. In summary, the interactive diagrams were intended to assist the search for and retrieval of all requirements describing the system behaviour relevant to particular user operations with the Datalink ATC user interface. It was also intended to support understanding of those system behaviours in relation to specific user activities.

4 A study to evaluate the tool concept

An evaluation was conducted to examine the value of the tool concept for assisting developers in searching for and retrieving requirements from the DTS, for assessing the relevance of requirements to given problems, and for understanding the pilot interface design expressed by those requirements. A prototype of the tool concept was constructed by fully developing two particular use cases for the Datalink ATC system. As a front end to the DTS, the prototype could be used to retrieve the requirements from the specification corresponding with each of the use cases. A set of design anomalies associated with these two use cases was also devised, based on the experiences reported to us by the developers in the interviews. An anomaly in this context is an inconsistency, apparent or real, between the implemented Datalinks system and the DTS or between different aspects of the implemented system. The developers were then observed using the prototype requirements tool to access the DTS in order to resolve the anomalies.

The use cases developed for the study concerned primary tasks that pilots would perform with the Datalink system:

  1. •

    The “REQUEST” use case, concerning the pilot sending a specific request message to the Air Traffic Controller.

  2. •

    The “RECEIVING A MESSAGE” use case, concerning the pilot receiving a message with only a single element from the Air Traffic Controller.

Figure 2 reproduces the sequence diagram corresponding with the first of these use cases, Fig. 3 reproduces the corresponding map diagram.

Fig. 3
figure 3

A map diagram for the “REQUEST” use case

Full size image

The requirements corresponding with our two use cases were contained in two particular sections of the DTS: the “CPDLC ATCCOM Pages”; and, the “CPDLC MailBox Pages”. Figure 4 shows the pathways through the prototype corresponding with the two use cases. The highest level menu presents a list of use cases. Selecting the hyperlink for a particular use case results in a navigation to the corresponding sequence diagram and map for that use case. Selection within the sequence diagram results in a navigation to the relevant section of the DTS containing the requirements corresponding with the use case.

Fig. 4
figure 4

Pathways through the prototype tool for the two use cases, “Request” and “Receiving a message”. A catalogue of use case titles provides hyperlink access to the sequence diagram corresponding with the selected use case. The sequence diagram provides hyperlink access to the requirements in the Detailed Technical Specification (DTS) corresponding with each activity

Full size image

A set of anomalies in the Datalink ATC system was devised, based on the kinds of anomalies which user interface designers must typically resolve using the DTS. The set was fictitious but based on examples of real anomalies reported by the developers in the interviews. Figure 5 reproduces one of the anomalies concerning the way the command for requesting a climb to a particular level is labelled on the user interface; the labelling is at odds with the convention for labelling other commands. To resolve this apparent inconsistency requires a check on whether this different form of labelling is specified in the DTS. The requirement that precisely describes the CLIMB TO label in the case of a CLIMB TO request must be found. The labelling of the command is specified by a particular requirement (DTS-ATC-CPDLC-205-1) contained in the DTS. Figure 5 explains how a developer would be expected to search for this requirement using the DTS alone, and alternatively, how they would use the prototype tool to find the requirement. An initial study was conducted to confirm that the anomalies were technically plausible, had a singular and definite resolution, and were expressed unambiguously. Five Airbus engineers working on cockpit avionics systems participated in this initial study and contributed to a significant refinement of the anomalies for the main study.

Fig. 5
figure 5

Example of an anomaly and how it would be resolved by searching for a relevant requirement in the Detailed Technical Specification (DTS). The method for searching with the DTS alone, and with our prototype requirements tool are both described

Full size image

Twelve engineers working on cockpit avionics systems for Airbus participated in the experiment. Their knowledge about the Datalink ATC system and particularly about the DTS varied greatly; some had considerable experience of working with the document whilst others had no experience of it. This variation well represents the real population of potential and current users of the DTS. Participants’ knowledge of the Datalink ATC system and the DTS was graded.

The study began with briefing each participant about the use of the prototype. Each participant was then given two training tasks involving finding the requirements relevant to resolving an anomaly. Additional clarifications of the use of the tool, and of the task were provided on request.

The study then consisted of two test phases. The first phase observed reasoning and knowledge use with the prototype tool and the DTS. Five participants were asked to identify the requirements in the DTS corresponding with four anomalies. They used the prototype tool for two of the anomalies and the DTS unaided for the other two anomalies. Participants were asked to think aloud as they worked on each task and their protocol was audio recorded.

The second phase examined performance with the prototype tool. Twelve participants were asked to resolve four further anomalies by again finding and interpreting the corresponding requirements. A within-subjects design was used, each participant using the prototype tool for two anomalies and the DTS-unaided for two other anomalies. Allocation of anomalies to presentation conditions (tool or DTS-unaided) was balanced by dividing participants into two groups according to their prior knowledge ratings; each anomaly was presented in either presentation condition to each group. The four anomalies were given to each participant in the same order.

Participants were asked to work on each anomaly until they had successful resolved it. In each case, a resolution was achieved by finding a requirement in the DTS that related to the feature of concern in the anomaly. Since only one requirement was relevant to an anomaly, participants were able to recognise accurately when they had found the requirement that resolved the anomaly. The time to resolve each anomaly was recorded.

Anomalies 1, 2, and 4 concerned the system’s behaviour when the pilot responds to a “Standard Clearance” message. Anomaly 1 concerned the system’s behaviour when the pilot responds with the command “STANDBY” and whether it is possible to re-send this command redundantly. Anomaly 2 concerned the system’s behaviour when responding with the “WILCO” command and whether it is possible to select the “UNABLE” command once the “WILCO” command has been selected. Anomaly 4 concerned the layout of the page once the “UNABLE” command is selected and whether the “UNABLE status” is displayed in Green Reverse video. Anomaly 3 concerned the layout of the CLIMB TO request label in the case of a “Vertical Standard Clearance” request and whether this label is displayed with the “modifiable pilot format”.

Finally all the participants were asked to fill in a questionnaire. The aim of the questionnaire was to assess the different effects of the tool on finding the relevant requirements for a given anomaly, navigation through the DTS document, understanding of the context related to the requirements, and the general understanding of the ATC system. The questionnaire also examined ease of use and learning of the tool.

5 Conclusions about the prototype tool

The data collected in the study is evidence of the way in which developers work with the embedded user interface specifications for the Datalink ATC system. It is also evidence of how our prototype requirements tool modified their way of working, and the success of our design. We now consider in turn the evidence provided by the think-aloud protocols, the task measurement data and the questionnaires.

5.1 Reasoning and knowledge use with the tool

Thirteen think-aloud protocols were transcribed for analysis, seven from people searching directly with the online DTS and the six others searching with the prototype tool. Analysis of the transcripts was necessarily highly interpretive in order to discover how the prototype tool influenced the way the developers solve problems when searching for particular information in the DTS document. The focus of the analysis was on the processes and sequences of actions which the participants exhibited in solving their problems.

Overall, it was apparent that the developers’ search behaviour when using the DTS on its own was significantly more varied than when using the prototype tool. In the DTS-unaided condition, developers used several search techniques including keyword searching, the document map, the table of contents, the headings in the text, or simply rapidly scanning the document. Although the same search methods were also evident when the developers used our prototype requirements tool, usually one method alone (most often, a keyword search) was sufficient to find the correct requirement.

It was similarly very apparent that prior knowledge of the DTS and of the Datalink ATC system was vital for an unaided search of the DTS. Developers with prior knowledge were able to navigate much more easily through the DTS and retrieve the relevant requirements. Novice users of the DTS were stymied by their lack of knowledge; they frequently became lost in the specification, particularly when using the key word search. Keyword search is clearly an inefficient retrieval mechanism, and produces severe disorientation for the developer who is unable to relate a found instance of a keyword to the document structure; the net effect on the developer is a sense of severe uncertainty about whether the correct requirements have been identified. Being lost in the DTS occurs even for those novice users who use the document map, as the following statement (translated from French) by one of the developers indicates:

“You can see I haven’t used the control F yet, I haven’t needed to. I prefer navigating using the table of contents as I know perfectly well where I am in the document, whereas by using control F, I can come down anywhere in the document. (…)

.. So exactly the same requirement is reused in another section, so I was wrong. It is exactly the same requirement but it could have been a different one for this particular case and it would have been an error”.

By contrast, when using our prototype requirements tool the developers were usually confident of where they were in the DTS document and were more confidently able to assess the relevance of a requirement to the problem they were given.

The prototype tool encourages developers to reason about the problem before starting to search, in contrast with their unaided use of the DTS. In effect, the tool’s use case catalogue and sequence diagrams provided a sufficient minimal knowledge about the pilot interface to allow the developers to more accurately predict which requirements would be relevant. The following statement by another of the developers illustrates this thinking about searching behaviour which the prototype encourages:

“What we want to see is what is displayed on the (Datalink ATC) screen but we (the pilot) haven’t made any action for the moment ….so it (the requirement) should be in Message Reception. I am clicking on the link…“

Some developers had a surprising tendency to ignore the map diagrams, possibly because their capability with the tool was still improving and they had yet to discover for themselves the value of the map diagrams.

5.2 Performance with the tool

Aggregated task times to resolve the design anomalies in Phase 2 of the study are given in Table 3, separated into the DTS-unaided and the prototype tool conditions. The median value for tasks completed with the prototype is some 20 s less than that for the DTS-unaided condition, indicating the overall success of the tool concept. Although the average values show a negligible increase for the tool condition, given the small numbers of participants involved in the study, median values are provided as a more reliable indicator of the group performance than the average values. Large standard deviations indicate a significant variability in performance within the groups. This variability is partly explained by the improvement in task times over the first two anomalies, regardless of condition, indicating that the training task had been insufficient.

Table 3 Task completion times with the DTS un-aided and with use of the tool, both aggregated and according to experience with the DTS
Full size table

Expert users performed better than novices both with and without the prototype, suggesting that (1) the tasks developed for this evaluation study faithfully represented the real tasks which developers perform with the DTS, and (2), the message diagrams and use case map diagrams have a good correspondence with the experts’ own knowledge representations. The experts’ performance times with our prototype tool showed some improvement relative to using the DTS document unaided. By contrast, novice users’ performance in the tasks was not improved by using the prototype, and may be inferior. Certainly their task times when using the tool are significantly more variable than when not using the tool and significantly more variable than those of the experts (the difference between standard deviations equates to more than 35 s). Novices’ search behaviour relies on a surface level understanding of the Datalinks system and of the DTS document, and are therefore unable to benefit from the sequence diagram which corresponds with a deeper and more meaningful understanding of what the Datalinks system is and how it works. In sum, the prototype requirements tool appears to improve the performance of experts in searching for particular requirements in the DTS document.

5.3 Developers’ views about the prototype tool

The questionnaire asked the developers to rate the usefulness of the prototype tool in relation to specific activities, to rate its ease of use, and to rate the ease of use of the diagram notations. The results showed a very high level of agreement with each of these statements:

  1. (1)

    The tool assists finding and retrieving relevant requirements from the DTS

  2. (2)

    The tool assists understanding the relationship of a particular requirement to the set of behaviours and structures of the user interface

  3. (3)

    The tool makes navigation in the DTS simple

  4. (4)

    The tools improves understanding of the general system mechanisms

  5. (5)

    The tool is easy to use

  6. (6)

    It is easy to understand the diagrams

The developers were asked about the value of the tool for the kinds of tasks represented by the study, involving resolving anomalies in the operational system by interpreting the user interface design model in the DTS. The developers’ approval of the tool in this usage is clear, however they also volunteered that the tool would be valuable for writing and executing test procedures, for training novice developers, and even for writing the DTS itself. Their concern about the tool was that by interposing a new layer between themselves and the DTS, the tool introduced new uncertainty about whether all relevant requirements were being identified.

6 Prospects for the tool concept

The tool concept we have presented offers some interesting solutions to the problems encountered by developers working with the requirements document for the Airbus A380 ATC system. The study found that all the developers felt the tool would be helpful. The tool appeared to improve performance in finding and retrieving user interface requirements from the DTS, and there was evidence that using the tool helped developers to better reason about a problem and to better navigate through the specification. This evidence is a sufficient basis for developing and assessing a more comprehensive realisation of the tool concept. The use cases used in our study are typical of use cases for the Datalinks user interface, but are not the most complex of use cases and further development of the tool concept needs to explore its application to these more extreme complex use cases.

A surprising aspect of our study is the observation that even for the latest generation of flight deck systems, standard office tools are currently used for documenting and managing requirements. This is in spite of the availability of sophisticated and proven requirements management technologies. In fact there is now a planned adoption of such a requirements technology for building and maintaining the Datalinks DTS document. Proprietary requirements specification tools do not, however, support modelling and the direct specification of requirements for the user interface. It is now vital that they acquire this user interface—specific capability if these tools are to be used by the specialists responsible for the user interface requirements specifications. It would be an unattractive prospect if the user interface designers alone continued to use text documents and Microsoft Word for the DTS, whilst the other requirements specifications functions migrated to proprietary tools. In fact our study was initiated to help better understand the user interface for requirements specification tools which user interface designers need to help them model and specify requirements for cockpit avionics user interfaces. The study is contributing to negotiations with tool producers to obtain a requirements technology that does support the user interface designers for the Airbus pilot interfaces.

In conclusion, our study provides early evidence that the use of a combination of use cases and sequence diagrams to access extracts of requirements can support developers working with textual requirements documents and can particularly assist in understanding the dynamics of a user interface design. It demonstrates the value of interactive sequence diagrams for traceability and for working with requirements specifications in downstream evaluation activities typified here by its use for assessing anomalies in a user interface design.