Case Study on requirements, design, and evaluation: NATS

1
Chapter 19

• Case Study on requirements, design, and
  evaluation NATS

2
Introduction

• FAST Final Approach Spacing Tool
• An air traffic control system
• Developed for UK National Air Traffic Services
  (NATS)
• Controllers tasks
• analyze data from radar screen
• communicate to pilot

3
FAST

• Designed to automate calculation of approach
  timings
• User-centered iterative design
• iterating between design and evaluation
• Key concern spacing between aircraft
• FAST was developed to help calculate this spacing
  and advise controllers when aircraft should turn
  to final

4
Example radar display
Not the real radar display--just something I
found on the web
5
Final approach control

• Radar display shows aircraft that should be
  flying in their flight corridors, according to
  their flight plans
• Flights get passed between controllers
• Physical strips are used to pass along flight
  info---these are color-coded indicating size
• Size determines spaces cant have a small
  aircraft fly into the wake vortex of a larger one

6
FAST UI

• Improved radar display
• runway lines added
• landing sequence boxes
• star and diamonds representing aircraft
• small white number indicating seconds to imminent
  turn to final (the FAST output)
• Touch panel
• input to FAST (e.g., wind, visibility, minimum
  spacing required)

7
Points to ponder

• If users enter minium spacing required into FAST,
  what does FAST calculate?
• How else could this be accomplished?
• how about a dB of aircraft--there are only so
  many makes and models?
• one could hardcode the minimum separation
  distances and simply look them up
• alternatively, calculate based on aircraft
  dimensions and weight

8
FAST Development

• Project team 5 core members, interdisciplinary
  (CS HF user)
• usability practitioner
• software developer
• algorithm developer (eh? whats the diff?)
• requirements engineer (whats that?)
• manager

9
Requirements Gathering

• Users
• 23-50 years old well paid and motivated
• Tasks (briefly)
• analyze data from radar screen
• communicate to pilot
• Environment
• well-lit, noisy, could be stressful
• Requirements gathering
• observations
• questionnaires

10
UI Design

• Prototypes used
• low-fidelity (paper) initially
• mid-fielity (powerpoint with animation)
• high-fidelity (C simulator basically)
• Note the investment here writing a simulator to
  test the GUI
• may seem prohibitively expensive
• however, some algorithms were re-used (e.g.,
  separation calculations presumably)

11
Planning the Evaluation

• Start with a plan (e.g., experimental design
  recipe subjects, i.v.s, d.v.s, procedures,
  etc.)
• Select users (representative sample)
• Simulate environment (or test in vivo?)
• Plan the scenarios, be ready for users
• Collect data

12
Evaluate

• Collect data on SEE (Satisfaction, Efficiency,
  Effectiveness), if possible
• FAST looks like mainly concerned with
  satisfaction, i.e., subjective data,
  self-assessment
• Analyze data (here, mainly questionnaires)
• Apply results to re-design and iterate
• Report results (to customers, or write a SIGCHI
  paper )