7 RESULTS FROM THE DESIGN PHASE USABILITY REQUIREMENTS THE LEARNABIL...

6.7 Results from the design phase

Usability Requirements

The learnabilty requirements are, summarized, that a controller should be able to judge

the nature of a problem to solve it the traditional within one day, and two days to solve it

using Descartes.

Because the time available for workshops with users was not enough to test this

requirement, and the fact that no actual database information could be retrieved from the

systems in use today, the learnability requirements were not possible to test satisfactory.

The results of the tests depended on the users opinions in this matter as well as our

judgment of how well understood the concept was. This way of measuring learnability

goals is not preferable, but in this case necessary. Therefore the learnability requirements

are more recommendations for future tests, and for successfully introducing this tool

into the controllers context.

The flexibility requirement was that the Operations Monitor is to be used as a tool still

working in the traditional way, but also to use it with Descartes. The different qualities of

the prototypes, meaning the different levels of technicality and graphics, made it possible

to test this requirement with the real users. Also the scenarios being presented in two

different ways, traditionally and the new way of Descartes, contributed to this. It was

found that the flexibility requirement was fulfilled.

One of the throughput requirements was that the time finding information about the

scope should be reduced compared to today. This had to be tested upon what the test

persons estimated, since there was no connection to real live databases. From the data

base information presented in the Operations Monitor and the functionality within it,

this would most probably reduce the time, and the requirement was therefore fulfilled.

The second throughput requirement was to support the user to choose which alarm to

handle next. The concept of the Operations Monitor as it is presented in this thesis fulfils

this requirement, according to test results.

The attitude requirements were that 80 % of the users should answer yes to that the work

would become easier with the Operations Monitor, that it would be easier to retrieve

information about the effects of an inconsistency in the roster, and that the decision-

making process would become more proactive.

The users were convinced that the use of the Operations would definitely make

their work easier; they expressed enthusiasm towards having all information within the

same view. They also thought that working more proactively would be possible due to

the fact that they, which is a consequence of the second throughput requirement, could

actually choose themselves which problem they wanted to handle next.

Functional Requirements

The functional requirements are that the Operations Monitor should visualize alarms,

details of alarms, data from the airlines databases, history of events, the data should be

updated in real time, it should be possible to create a disruption and send it to the

Disruption Manager.

That the data should be updated in real time is a technical requirement that was

not possible to test with the prototypes available, but it is the most necessary requirement

of them all, the requirement is the basis for the alarm generation defined in the

Operations monitor. The rest of the functional requirements have been possible to test

with the prototypes, and the users have considered them as the most relevant aspects of

the Operations Monitor and also considered them as fulfilled. Testing has also shown

that the main list of functions described in the functional requirements chapter 4.4, are

directly dependent on the succeeding list of functions.

7 D E S I G N R E C O M M E N D A T I O N S

In this chapter, recommendations on the design of the Operations Monitor are

presented. They are the result of our studies of the crew controllers and their work

environment, as well as the background information on human factors and information

visualization, and are meant to give a pointer to which direction to take when designing

the Operations Monitor.