KLM Flight Folder

Requirements Elicitation and Solution Specification for an Electronic Flight Bag

A.M. Spannenburg, BSc.

August 2011
KLM FLIGHT FOLDER

Requirements Elicitation and Solution Specification for an Electronic Flight Bag

MASTER’S THESIS

University of Twente, Enschede, the Netherlands

Author: A.M. Spannenburg

Internal supervisors: Dr. ir. C.P. Katsma

Dr. ir. P.A.T. van Eck

External supervisors: Ing. B. Gouma

Drs. ing. B.A. Dikkers

All rights reserved. The copyright of the master’s thesis rests with the author. No part of this publication may be reproduced or transmitted
in whole or in part, in any form or by any means without prior permission in writing of the author.
ACKNOWLEDGEMENTS

This master’s thesis would not have been possible with the help and support of several people, for
whom I would like to take the opportunity to thank them here. First, I would like to thank Mr. P.F.
Hartman and Mr. M.T.C. van Hout for providing the opportunity to put theory into practice at KLM.
Secondly, I would like to thank my external supervisors at KLM Bastiaan Gouma and Brend Dikkers
for their input and advice throughout the project. In addition I would like to express my gratitude
towards all KLM employees willing to help me. I’m also especially thankful for the continued support
and supervision of my academic supervisors Christiaan Katsma and Paul van Eck. I would also like to
thank my parents, family and friends in their interest and support. Last, but certainly not least, I
would like to thank Marjolein for her incredible patience and support.

Alexander Spannenburg
Enschede, August 2011
MANAGEMENT SUMMARY
Motive
The Flight Folder concept is envisioned by KLM to allow content used on-board its aircraft to be
digitally transmitted between the aircraft and several departments through various electronic
communication channels at any time and place. This would lead to higher operational efficiency. To
come to this desired future situation, this thesis provides the first steps towards the KLM Flight
Folder concept.

Goals
The thesis provides these first steps by the collection of requirements, the specification of an on-
board Flight Folder application and the development of a proof of concept. However the focus of the
thesis lies in the analysis of the overall design and development process in order to advise KLM on
EFB software development, since this is their first in-house development project. Summarized:

Describe and analyze the overall design and development process of a Flight Folder
information system, in order to make recommendations for future EFB software
development projects within KLM.
Approach taken
The approach taken in the thesis is depicted in the diagram below.

Software Solution
Business Business Software Software
Implementation
Problem Analysis Solution Design Solution Design Solution Specification
(Proof of Concept)

During each phase of the approach an iterative development style was taken to involve stakeholders
as much as possible and to be able to validate findings during the design and development process.

Main findings
This research results in several findings of which the most prominent are listed below:

• The journalistic method gave us a good understanding of the stakeholders’ requirements and
decision making which aiding us immensely in thinking along the same lines as the
stakeholders while developing design ideas in preparation for the stakeholder meetings
throughout the design and development process.
• Paper prototyping has shown to be a very effective technique for both the requirements
elicitation and the solution specification phases.
• The proof of concept developed, shows the technical feasibility of the Flight Folder concept.

Recommendations
This work leads to the following recommendations for KLM:

• Incorporate the paper prototyping technique in future EFB software development projects.
• Incorporate test scripts in future EFB software development projects.
• Include extensive usability testing in the eventual further development and implementation
phase of Flight Folder.
• Use a chicken little approach when Flight Folder is to be implemented into the organization.
TABLE OF CONTENTS
1 Introduction..................................................................................................................................... 9
1.1 Background.............................................................................................................................. 9
1.1.1 KLM Royal Dutch Airlines ................................................................................................ 9
1.1.2 E-enabled flight operations ............................................................................................. 9
1.2 Goals ...................................................................................................................................... 10
1.3 Approach ............................................................................................................................... 11
1.3.1 Interviews ...................................................................................................................... 12
1.3.2 Paper prototyping ......................................................................................................... 13
1.4 Thesis structure ..................................................................................................................... 14
2 Problem Analysis ........................................................................................................................... 15
2.1 Approach taken ..................................................................................................................... 15
2.1.1 The Onion model ........................................................................................................... 15
2.2 Stakeholder map ................................................................................................................... 17
2.2.1 Our system..................................................................................................................... 17
2.2.2 Containing system ......................................................................................................... 18
2.2.3 Wider environment ....................................................................................................... 19
2.3 Stakeholder’s Goals/Problems/Solution theories ................................................................. 19
2.3.1 Goals .............................................................................................................................. 19
2.3.2 Problematic phenomena ............................................................................................... 21
2.3.3 Solution theories ........................................................................................................... 24
2.4 Solution criteria ..................................................................................................................... 26
2.4.1 Run-time System Qualities ............................................................................................ 26
2.4.2 Non-runtime System Qualities ...................................................................................... 27
2.4.3 Stakeholders vs. Qualities ............................................................................................. 28
2.5 Conclusion ............................................................................................................................. 28
3 Business solution design................................................................................................................ 29
3.1 Approach taken ..................................................................................................................... 29
3.1.1 Use cases ....................................................................................................................... 29
3.1.2 Function Refinement Tree ............................................................................................. 30
3.1.3 Service Descriptions ...................................................................................................... 30
3.1.4 Interplay with software solution design phase ............................................................. 31
3.2 Notable outcomes ................................................................................................................. 31
3.2.1 General structure .......................................................................................................... 31
 3.2.2 Scoping .......................................................................................................................... 32
3.2.3 Meta-information .......................................................................................................... 32
3.3 Conclusion ............................................................................................................................. 33
4 Software solution design and specification................................................................................... 34
4.1 Approach taken ..................................................................................................................... 34
4.2 Paper prototyping ................................................................................................................. 34
4.3 Specification phase ................................................................................................................ 36
4.4 Solution decisions .................................................................................................................. 37
4.4.1 On-board Flight Folder .................................................................................................. 37
4.4.2 Content meta-information ............................................................................................ 37
4.4.3 Communication costs .................................................................................................... 38
4.5 Conclusion ............................................................................................................................. 39
5 Development phase ...................................................................................................................... 41
5.1 Functionality implemented ................................................................................................... 41
5.2 Application structure ............................................................................................................. 41
5.3 Observations.......................................................................................................................... 42
5.4 Conclusion ............................................................................................................................. 43
6 Conclusions & Recommendations ................................................................................................. 44
6.1 Conclusions............................................................................................................................ 44
6.2 Limitation............................................................................................................................... 45
6.3 Recommendations................................................................................................................. 45
References ............................................................................................................................................. 48
Appendices ............................................................................................................................................ 49
A.1 Detailed problem analysis (completing chapter 2) ............................................................... 49
A.2 Workflows to be supported (completing chapter 3)............................................................. 52
A.3 Desired properties and solution constraints (completing chapter 3) ................................... 59
A.4 Overview of content providers.............................................................................................. 60
A.5 Proof of concept (completing chapter 5) .............................................................................. 61
A.6 Other documents .................................................................................................................. 64
1 INTRODUCTION

1.1 Background
1.1.1 KLM Royal Dutch Airlines
KLM Royal Dutch Airlines (in Dutch: Koninklijke Luchtvaart Maatschappij) was established in 1919
and is the oldest airline still operating under its original name. Her first flight was between London
and Amsterdam on May 17 1920, a route which it still operates today, making it the worlds oldest
scheduled service route still in operation. On October 1 1924 KLM initiated its first intercontinental
flight from Amsterdam to Batavia (Jakarta) starting a scheduled route between Amsterdam and
Batavia in 1929. In December 1934 KLM made its first transatlantic flight from Amsterdam to
Curacao. March 1960 marked the start of the Jet Age for KLM with the introduction of the Douglas
DC-8. The Wide-body Age began with the arrival of KLM’s first Boeing 747 in February 1971. In 1993,
KLM started a strategic alliance with Northwest Airlines which in 1997 resulted in a joint venture
between the airlines. In 2004 KLM merged with Air France to form the Air France - KLM Group and
joined the SkyTeam airline alliance (KLM, 2011). KLM has 33,000 employees and a fleet of 116
aircraft serving 22,2 million passengers annually to 125 destinations in 63 countries (SkyTeam, 2010).

KLM uses a hub-and-spoke strategy with Amsterdam Airport Schiphol as its main hub. In this system
passengers (and cargo) travel from regional airports in small aircraft to a hub, transfer onto larger
aircraft to bring them to another hub from where they transfer to again to smaller aircraft to bring
them to their destination. This system allows for higher capacity utilisation whilst offering a large
number of destinations in comparison with a point-to-point network. In a point-to-point system a
service route is used between each destination pair. Since its merger with Air France, a dual-hub
strategy is operated by Air France - KLM with Paris-Charles de Gaulle Airport as the second hub.

KLM can be divided into three core activities: passenger transportation (Passenger Operations), cargo
transportation (KLM Cargo) and aircraft maintenance (KLM Engineering & Maintenance) department.
This thesis work was carried out at the Aircraft Data Communications (ADC) department, a part of
the Information Management Organization of the Passenger Operations division.

1.1.2 E-enabled flight operations

In the cockpit aboard KLM aircraft many processes are still completely or partly performed using
paper documents. One can think of flight plans, weather reports, maintenance reports, checklists,
manuals and incident reports to be filed by the crew. Some of these documents are for a single flight
(e.g. the flight plan), others can be used for a longer time frame (e.g. airport maps) and some
documents hold for a single aircraft (e.g. maintenance reports). The documents come from various
departments (e.g. Flight Operations and Engineering & Maintenance) and are manually brought
onboard.

KLM is in the process of digitizing the majority of the paperwork/processes for increased profitability,
increased employee’s quality of life and increased operational performance. For this purpose KLM
has introduced the Electronic Flight Bag onboard several of their Boeing 777 aircraft, which enables
the use of electronic documents / content by the Flight Crew. For example, the Airport Moving Maps
application presents the pilots with a view of the airport centred on their current location and the
eDuty Roster application supports the pilots with administering their duty rosters. The EFB also
houses a Document Viewer (from Boeing) for the use of electronic documents.

9
In the current situation, these electronic documents (mostly manuals) are uploaded during
international standardized (AIRAC) load cycles every 28 days. The content is frozen +/- 1 week before
such an AIRAC cycle, and the content remains unchanged until the next load opportunity (next AIRAC
cycle). Currently, for content that changes more than every AIRAC cycle, no electronic equivalent
exists. Content that changes regularly is manually brought onboard by maintenance crew or is being
hand carried by the Flight Crew (such as the briefing package).

In the desired future situation, content can be digitally transmitted between the (EFB in the) aircraft
and several departments through various electronic communication channels (e.g. wirelessly) at any
time and place. This would lead to higher operational efficiency, for instance by time saved due to in-
cockpit pilot briefings instead of briefings on ground before boarding.

1.2 Goals
To come to this future situation this thesis provides the first steps towards the KLM Flight Folder
concept, depicted in Figure 1. The standard Flight Folder concept is known in the airline industry
where strict flight related content (like the flight plan and NOTAMs 1) can be used on electronic
devices like an EFB by the cockpit crew. In KLM’s view, this concept is limited as KLM sees benefits in
using the electronic devices for a) non-strict flight related content, and b) content for cabin and
maintenance users, as well.

+
Figure 1: KLM Flight Folder concept

1
Notice to Airmen

10
Importantly, the Flight Folder application will be the first application completely developed in-house
by KLM from scratch. Applications currently in use on the EFB are bought from Boeing directly or
acquired from third party software vendors, with one exception. KLM’s E-Reporting application is
being developed in-house as well, but is in essence a copy of an e-reporting application bought
earlier from a third-party software vendor. KLM’s choice to start developing applications in-house is
grounded in the high licensing costs. Although development costs are high for an application, KLM
beliefs this outweighs the total licensing costs for all their aircraft paid each year.

This notice highlights the importance of the overall process taken in the thesis work in the design and
development of a generic architecture to support the Flight Folder+ concept. The design and
development of the architecture itself is done by the:

1. Collection of requirements for the Flight Folder system.

2. Specification of the on-board Flight Folder application.
3. Development of a proof of concept of the on-board Flight folder application for the EFB in
KLM Boeing 777 aircraft.

However, the main objective of this thesis is to:

Describe and analyze the overall design and development process of a Flight Folder
information system, in order to make recommendations for future EFB software
development projects within KLM.

The objective has two perspectives; first from a business perspective (of KLM) the main purpose is to
make a start in developing the Flight Folder system, and second from an academic perspective to
analyze the overall design and development process.

Applying the lessons learned here could significantly improve future EFB development projects in
terms of the overall quality of the end product as well as the development process. Better results
could be gained through more efficient development efforts.

For KLM, a specific goal is to keep the Flight Folder design as generic as possible, so it can easily be
adapted for future use. Focus should therefore not lie on the information contained in the content to
be handled by Flight Folder but on the meta-information describing the content (such as an
expiration date). An information analysis approach was therefore not chosen, the taken approach is
discussed in the following section. This work is not on a level of a detailed graphical user interface
(GUI) design, but on a level including the first workable screens solutions, a functional design, meta-
information, and architecture based on existing systems and interfaces.

1.3 Approach
The main approach taken in the thesis originates from the approach taken by Wieringa in his book on
the design of reactive systems (Wieringa, 2003) and is depicted in the figure below. The approach
was chosen based on the observation that the subject of the thesis is a practical problem for which a
solution is designed in a business context. A practical problem is defined as a difference “between
the way the world is experienced by stakeholders and the way they would like it to be” (Wieringa,
2009).

11
 Figure 2

For the thesis however the approach was slightly adapted since not all elements of the approach
were applicable, as can be seen in Figure 3. First, the software development phase has been added to
include the process of creating the proof of concept. Secondly, the software decomposition steps
have been taken into one (software solution specification) to simplify and balance the model in
terms of time taken in each step. Thirdly, the business solution design process and the software
solution design process have been put closer together to highlight the notice that both processes are
not separate, but closely related and more connected than appears in Figure 2. Traditionally, these
can be seen and are often regarded as highly separated processes where the business specifies a
solution to be developed by the software department in an “over the fence” approach. Here
however, this is not the case and the business and software solution were designed more hand in
hand.

Software Solution
Business Business Software Software
Implementation
Problem Analysis Solution Design Solution Design Solution Specification
(Proof of Concept)

Figure 3: Main approach

In the business problem analysis the practical problem is investigated by analyzing the stakeholders,
their goals, their problems in reaching these goals and the solution theories of the stakeholders. This
analysis forms the base for the business solution which defines the supported workflows and the
desired properties of the software solution. The solution design on a software level translates these
desired properties in the functional description of the Flight Folder information system. The
subsequent software solution specification consists of the stakeholders’ requirements of Flight
Folder and the specification of the on-board Flight Folder application.

1.3.1 Interviews
The main approach taken for gathering of information was by means of interviews with KLM domain
experts from the departments involved as identified during the stakeholder analysis phase. Experts
were chosen based on information needed in combination with their expertise as known to the
members of the ADC department, as well as asking the experts for additional persons of interest.

12
The first interviews with the experts were semi-structured interviews. Semi-structured interviews are
limited open-style interview with some general questions prepared in advance, allowing a focused,
conversational, and two-way-communication interview. This in contrast with questionnaires where
detailed questions are formulated in advance and no new questions are be brought up during the
interview. Subsequent interviews were more structured of nature; using information gathered in
earlier interviews with the same interviewee as well as information gathered in interviews with other
experts. Both serving validation; the former as a check whether information brought up during the
earlier interviews was interpreted correctly and completely, and the latter as a form of cross
checking. During the design phase, the meetings were structured around the prototyping methods
discussed below.

1.3.2 Paper prototyping

An important technique used in the design and specification phase of the thesis work is paper
prototyping. Paper prototyping is in its broadest sense a method for brainstorming, designing,
creating, testing, and communicating user interfaces, by means of paper and is often used in the
early stages of the design process (Sefelin, Tscheligi, & Giller, 2003). The origin of the method cannot
be pinpointed to a single source, but the concept of low-fidelity prototyping started to surface
around 1990 from authors like Jakob Nielsen, although during the 1980s some high-tech companies
used the technique. Paper prototyping can be seen as a subset of participatory design, which has
been around much longer. At the core of paper prototyping lies of course the general concept of
prototyping which exists for ages in engineering (Snyder, 2003).

The main advantage of paper prototyping can be summarized in a phrase coined by Snyder:
“Maximum feedback for Minimum effort” as it is “an efficient means of getting make-it or break-it
information about your interface (...) using only a few office supplies and a dash of ingenuity”
(Snyder, 2003). Since the development of paper prototypes requires no coding effort, little time and
development cost, it promotes rapid iterative development allowing you to experiment with many
ideas. Far more than possible in high-fidelity prototyping, which are time-consuming to create and
more expensive to develop (Rettig, 1994). In addition, substantive user feedback can be gained early
in the development process, before substantial efforts have been made in implementation and it is
relatively cheap to make changes. Snyder also states that paper prototyping facilitates
communication within the development team, and between the development team and customers.
Furthermore, it does not require any technical skills, so a multidisciplinary team can work together
(Snyder, 2003).

Another important advantage of paper prototyping is that it allows the users to focus on the general
elements of the design: the workflow, general layout, terminology, etc. This in contrast with a high-
fidelity prototype test where the test participants tend to comment on “fit and finish” issues such as
fonts, colours and button sizes (Rettig, 1994). It allows the participants to focus more on a product’s
concept and actual usefulness rather than letting technology constrain their thinking and dictate
what is allowed (Drugge, Hallberg, Parnes, & Synnes, 2006). Things that look somewhat unfinished
tend to encourage creativity and help users keep a more open mind (Snyder, 2001).

In the literature some concerns are considered regarding paper prototyping (Snyder, 2001) . The first
has to do with validity and questions whether paper prototyping finds the same problems as when
testing working prototypes, closer to the end product (high-fidelity prototypes). A study comparing

13
low-fidelity and high fidelity prototype testing found both methods to find the same problems for the
most part and at the same level of sensitivity (Virzi, Sokolov, & Karis, 1996). High-fidelity prototype or
real product testing however can find different classes of problems, such as performance issues. A
second concern lies in the thoughts of the developers not being comfortable using the unfinished
and possibly flawed prototypes in fear of what others might think of them. Outsiders might perceive
their work as incomplete or “cheap” where most developers are perfectionists of nature. However,
Snyder points out that this does not happen and users respond positively towards the method as
long as they have been told why paper prototyping is used at this stage. Additionally, as Jakob
Nielsen argues: when developers wait until they have a more perfect user interface before they show
it to customers “it will be too late to translate usability findings into the necessary change in direction
for your design“ (Snyder, 2003).

The main reason paper prototyping is used in this work lies in the fact that during meetings with the
various stakeholders it was found that some had trouble discussing Flight Folder concept and come-
up with concrete requirements/suggestions/ideas when using other more abstract techniques, such
as use case description and service descriptions or discussing various design alternatives verbally.
When looking for alternatives, the first meeting with a very simple paper prototype provided with a
small eureka moment when the participant found it much easier to quickly understand, evaluate and
discuss various design options. In hindsight, the choice for paper prototyping could be considered an
obvious one since the limited availability of the pilot experts demanding short and efficient meetings
and the need for encouraging out-of-the-box thinking in a domain bound by many rules and
regulations such as strict cockpit design guidelines.

In addition to the paper prototypes, storyboards were used to discuss workflow design. Storyboards
are a series of drawings or images that represent how an interface is used to accomplish a particular
task. Although it does not allow user interacting with the design, and thus considered by some as not
a true paper prototyping technique (Snyder, 2003), its benefits are similar to those of paper
prototypes. Paper storyboards are fast to set up and therefore allow discussing many possible
workflows quickly and in several iterations. They are therefore ideal for discussing multiple options
and alternative designs.

1.4 Thesis structure

As discussed before, the thesis holds two perspectives and therefore two themes; the first discussing
the design of Flight Folder and the second discussing the lessons learned of the project.

The reader interested in the former is advised to read along the structure of the report, which
follows the approach depicted in Figure 3, starting with the problem analysis by discussing the
involved stakeholders. The next chapter discusses the business solution design which bounds the
solution space of the software design, which is discussed in chapter four. Chapter five discusses the
development of the proof of concept and is followed by the conclusions and recommendations.

The reader interested in the lessons learned are pointed to concluding section of each chapter of the
thesis report; sections 2.5, 3.3, 4.4 and 5.4.

In appendix A.6 an overview is given of the documents developed for KLM which describe the Flight
Folder requirements and design. For spatial reasons it was decided not to include these in this thesis
report.

14
2 PROBLEM ANALYSIS

2.1 Approach taken

In the problem analysis phase we first identify the stakeholders, using the onion model discussed
below. Second we analyze the problems that the main stakeholders encounter in reaching their goals
and how they believe a solution such as Flight Folder could contribute in reducing these problems.
These goals, problematic phenomena and solution theories of the stakeholders were identified by
initial talks with ADC members, initial meetings with the stakeholders and comeback meetings with
the individual stakeholders asking if the identified goals/problems/solution theories where indeed
correct and complete. During these meetings, all information was put openly on the table, not
withholding goals of one stakeholder from another for instance.

These meetings were held with several members of the ADC department, three members of the
B777 Flight Technical department (including the engineering pilot), two members of the Engineering
& Maintenance (E&M) department, and two members of Flight Operations and Flight Dispatch over
the course of several weeks. The majority of the meetings were held with members of Flight
Technical, E&M and the engineering pilot.

2.1.1 The Onion model

A stakeholder of a project is much more than the eventual user of the project’s product. A
stakeholder is anyone who gains or loses something as a result of the project. Since this is a very
wide scope, a stakeholder model is useful. One such model specifically designed for this purpose is
the onion model, depicted in Figure 4. It presents a layered view centred on the project’s product
(the kit), which is distinguished from the system (our system) which houses the people who operate
(called the normal operators), maintain the equipment (called the maintenance operators) and
deliver its results. The surrounding containing system is outside of the project’s control and includes
the system plus the non-operational beneficiaries called functional beneficiaries (the people who
benefit from the work in the containing system), and interfacing systems. The wider environment
includes the containing system plus any other stakeholders who affect decisions made about our
system, such as financial beneficiaries (such as shareholders) and regulators (such as governments).
(Alexander & Robertson, 2004)

15
 Figure 4: Onion Model (Alexander & Robertson, 2004)

To determine the stakeholders for the Flight Folder project an empty onion model was taken as a
start, with the inner circle being the Flight Folder information system and subsequently filled based
on information gathered during interviews. An initial brainstorm session was held with ADC members
to determine the stakeholders in our system, asking specifically for which departments and people
play which roles and asking for contact information of these stakeholders. These potential
stakeholders were then contacted and interviewed in separate meetings. During these meetings, the
stakeholders were asked direct questions on their view of their possible relationship with the Flight
Folder system such as how they would be impacted by the system (either positively or negatively),
how they would impact the system, and what their role could be in the (containing) system. In
addition, they were asked to identify other possible stakeholders, their view on the relationship
these stakeholders would have with Flight Folder, and for contact information of important people
possessing such knowledge. Finally, the Volere stakeholder analysis template was used as a last
check to discover any missing stakeholders (Volere, 2011).

16
2.2 Stakeholder map
As can be seen in Figure 5, the kit in our case is the Flight Folder information system to be developed.
The stakeholder closest to the kit is the Aircraft Data Communications department of KLM which is to
be responsible for the development, roll-out, cost control and maintenance of the Flight Folder
system as explained by ADC members themselves.

The wider
environment

The containing
system

KLM
(financial beneficiary)
Our system

Pilots
(normal operators) Flight Technical
(operational support)
E&M responsible
(functional beneficiary)
E&M crew
(normal operators)
Flight Folder
ADC
(operational support) Government (IVW)
(regulator)
Content providers
(normal operators)

ADC
(maintenance operator)

CP’s systems
(interfacing technology)
User of reports
(functional beneficiary)

Technical specialist
(functional beneficiary)

Figure 5: Stakeholder map

2.2.1 Our system

ADC plays several stakeholder roles in the our system section of our stakeholder map. First, ADC will
be responsible for the maintenance, keeping Flight Folder operational according to service level
agreements to be agreed upon with the other stakeholders. Second, ADC will be providing
operational support to the normal operators so they can make full effective use of the information
system. Their operational support work will most likely be carried out in cooperation with the Flight
Technical department which will be responsible for the development and publishing of the operation
manuals of Flight Folder for the flight crew.

17
The normal operators are seen to consist of the providers of the content handled by Flight Folder,
the pilots and maintenance crew. The content providers are from various departments: Flight
Operations, Flight Dispatch, Flight Technical, Engineering & Maintenance, Ground Services and Fleet
Services. In a meeting with ADC members it was decided to approach the various departments
playing the role of content provider as a single stakeholder in most of the cases, whilst not being
insensitive to potential differences. This was based on their past experiences with these
departments, their need for a general architecture (not focusing in detail on the actual content itself,
but on the broad picture) and observations made in the interviews showing great similarities
between the various departments.

The pilots are seen to be normal operators as well, as they will not only use Flight Folder to retrieve
information, but also provide information (such as administration work) to other parties through
Flight Folder as well. The pilots are seen to use Flight Folder in their flight preparation and during the
flight. The maintenance crew could use Flight Folder to retrieve aircraft related content during their
maintenance tasks.

A stakeholder which did not turn up during the interviews but was uncovered when checking the
Volere stakeholder template is the “Interfacing Technology” stakeholder. This stakeholder is defined
as “any system within the operational area - software, hardware or mechanical - that must have a
defined interface with the eventual solution” (Alexander & Robertson, 2004). In this case these are
the systems used by the content providers in creating content to be housed by the Flight Folder
system. An interface between Flight Folder and these systems is needed for the complete system
solution to be operational.

2.2.2 Containing system

In the containing system, several stakeholders have been identified playing the role as functional
beneficiary. Functional beneficiaries do not have direct, hands-on contact with the product but
benefit from its existence. The first identified in this case are the technical specialists who can
provide technical assistance from the ground to pilots during the flight when needed. One
interviewee from ADC mentioned a technical specialist could benefit from the existence of Flight
Folder when it would be able to supply information on which technical documentation is on board
the aircraft in need of assistance. Having this knowledge could improve communication between the
technical specialists and the pilots and thus the overall problem solving process, he argued.

A second possible functional beneficiary was identified by the Engineering & Maintenance (E&M)
department and is the responsible in this department for delivering data requested by the Dutch
regulatory body Inspectie Verkeer en Waterstaat. This data can consist of information on which
documentation was brought on board which aircraft at what moment in time and by whom.
According to the E&M interviewee the process of gathering and composing of the requested
information currently takes quite a lot of time and could be improved upon greatly by using a (partly)
automated process.

Another functional beneficiary stakeholder as mentioned by the ADC interviewee are the users of
reports which could be part of the output of the Flight Folder system to its containing system. These
reports could be automatically generated by the system and be used for various goals. One example
given was a report on fuel consumption during the flight, which could be used for analysis to improve
overall fuel efficiency.

18
2.2.3 Wider environment
In the wider environment, KLM in general is seen as a financial beneficiary stakeholder by several
interviewees as they envision possible cost savings due to the use of Flight Folder. The digitization of
the paper documents currently on-board lead evidently to the reduction of the use of paper, which in
turn is believed to reduce overall weight on-board the aircraft resulting in fuel savings. Reduced use
of paper would also reduce paper processing and logistic costs.

A second stakeholder in the wider environment is the before mentioned regulator Inspectie Verkeer
en Waterstaat (Inspectorate for Transport, Public Works and Water Management) which could
demand information regarding the content handled by Flight Folder for auditing purposes.

2.3 Stakeholder’s Goals/Problems/Solution theories

Now that we have identified the stakeholders we further analyze the problem by investigating what
the problematic phenomena are that the stakeholders encounter in reaching the goals they have. In
addition we identify what the stakeholders believe that the impact of a solution such as the Flight
Folder concept would be. In this analysis the focus lies on the normal operator stakeholders - the
content providers, pilots and maintenance crew - as they are envisioned to be the main ‘end-users’.

The purpose of this analysis is to gain better insight in the actual problems of the various actors
involved, why these are problems by analyzing their goals and finally gain some insight in the solution
ideas those involved may have. This increases our understanding of why stakeholders may have
certain requirements for the final solution and make certain decisions when presented with multiple
design options during the design and development process. Furthermore, it helps us in thinking along
the same lines as the stakeholders during the birth of these design ideas and options in preparation
for stakeholder meetings and during the meetings themselves.

Several rounds of meetings were held with each of the stakeholders for several reasons. First, in
order to be able to check whether all the discussed goals, problematic phenomena and their causes
where indeed identified and correctly incorporated in our work. Second, in order to be able to
discuss the views of one stakeholder with the others, giving a more coherent understanding amongst
the parties involved and giving the stakeholders time to reflect on the ideas of others. And finally, to
allow the interviewees time between meetings in order to reflect on what was discussed during the
meetings and come up with new or changed ideas or insights since a single meeting will not allow
everything to be discussed fully or allow all the issues to be raised.

2.3.1 Goals
To describe the goals of the stakeholders, goal trees are used. In each goal tree, the top of the tree
holds the general goal of the stakeholder. A node below is a sub goal which contributes to the goal
above it (its parent). In determining the goals of the stakeholders, the why-question is very important
during the interviews. Repeatedly asking why a stakeholder wants something, or wants to reach a
particular goal, is the best way to gain deeper insight and come to the underlying goals. These goal
trees are not only used here, they were also used and developed in the meetings with the various
stakeholders.

19
2.3.1.1 Pilots
For the pilots, the main and most important goal is ensuring a safe flight for its passengers and fellow
crew. This seems very evident; however this goal was only explicitly stated during a later interview. It
seems that sometimes axioms are not mentioned since it is assumed everyone in the room is aware
of them. This is however not always the case, underlying the importance of using the journalistic
technique of asking why even when things seem clear for all the parties involved.

In order to reach the goal of safe flying, pilots feel that fast and correct decision making is essential.
This is in order to be able to adequately react on (emergency) situations that come at hand. To make
a correct decision swiftly it is required to be able to swiftly retrieve information and have access to
correct information. Decisions can be correct based on the information available, but when the
information is incorrect the decision will most probably still be wrong, as elegantly stated by one
interviewee.

Another part of the pilot’s job is administration, which they want to do efficiently and (are required
to do) correctly. As highlighted by the interviewed engineering pilot, pilots not only need the act of
administration to be efficient and correct, but also the process of filing (or sending) of their
administration work needs to be efficient in order to perform their administration tasks efficiently
and correctly.

The encompassing goal of the pilots is to do a good job, constituting to the goal tree seen below.

Do a good job

Safe flying
Perform administration
tasks efficiently and
correctly
Fast & Correct
Decision making

Efficient & Efficient Filing /

Swift
Have correct Correct Sending of
information
information Administration Administration
retrieval
information

Figure 6: Goal tree - Pilots

2.3.1.2 Maintenance crew

In meetings with members of KLM’s Engineering & Maintenance department it was concluded that
for maintenance crew the goals in their work are very similar as to those earlier identified for the
pilots, with one exception. The goal of ensuring a safe flight is not shared and the encompassing goal
for the maintenance crew is to perform tasks efficiently and correctly, as can be seen in the figure
below.

20
 Perform tasks
efficiently and
correctly

Perform administration
Fast & Correct
tasks efficiently and
Decision making
correctly

Swift Efficient & Efficient Filing /

Have correct Sending of
information Correct
information Administration
retrieval Administration
information

Figure 7: Goal tree - Maintenance crew

2.3.1.3 Content providers

In their role of providing content, the main concern for the various departments is to provide the
content on time and correctly as this is what they are judged upon by the users of the information.
As stated by an interviewed flight dispatcher; when content required for a particular flight is not
delivered on time it can have considerable financial consequences. Special runners have to be hired
to speed deliver the content to the aircraft and the flight could be significantly delayed leading to
more financial (and non-financial) issues. Incorrect information could be the cause for this as well,
but can also cause other problems as it could lead to wrong decisions by pilots. In addition, as
mentioned by E&M, KLM is audited by regulatory bodies requiring some content to always be on-
board. When this content is not correct, or not correctly provided, reprimanding actions could be
taken against the content providers or KLM in general.

Besides the goal of providing the information correctly and on-time, the content providers want this
process to be efficient as mentioned by several interviewees. This leads to the following goal tree.

Provide information

Provide Information Provide Information Provide Information

Efficiently On Time Correctly

Figure 8: Goal tree - Content providers

2.3.2 Problematic phenomena

The goals identified during the first meetings with the stakeholders, and discussed in the previous
section, form the base for determining the problematic phenomena the stakeholders encounter
during their work activities and the root causes for these problems. Interview meetings with the
stakeholders were held, asking them directly what these are with the goal trees used to structure the
meetings. This was done for example by asking a stakeholder to describe certain scenarios where
they faced problems in reaching a particular goal and what they felt the causes for these problems to
be. Here the journalistic method of continuously asking the typical why question; asking why a raised

21
problem was indeed a problem, asking what the cause of the problem could be and further asking
what the source of this cause was, etc, was very important to make issues explicit .

The notation used for the problems, their causes and the relations amongst them is a rudimentary
causal diagram which is a graphical tool for visualizing causal relations between variables, shown in
Figure 9 below. In the figure, the arrow denotes a causal relation between the two variables A and B.
Two symbols are used (+ and -) to indicate the type of causal relation. A plus sign (+) indicates a
positive causal relation, meaning when variable A increases, variable B increases as well. A minus sign
(-) indicates that an increase of variable A causes a decrease of variable B.

Variable +/- Variable

A B

Figure 9

This notation may seem very simple in comparison with more complex techniques such as i*
(pronounced as i-star) (Yu, Giorgini, Maiden, & Mylopoulos, 2011) which offer a significant number of
notation elements and possibilities. The simplicity of this visualization technique however proofed
itself when using it with stakeholders not experienced with diagram notations in general and with
causal relationship diagrams in particular. During the meetings were the diagram was first used some
explanation was necessary; however after this short introduction the stakeholders were able to
quickly understand the diagrams and became confident in using them during the discussions. In this
particular case, if a more complex notation would have been used, more explanation would have
been necessary and would most probably have led to more time being spent on discussing the
technique than the actual content of the diagram. This would have had significant negative impact on
the problem analysis not only in terms of time wasted but also in terms of creativity.

2.3.2.1 Content users

The results of the meetings identifying the problematic phenomena and their causes encountered by
the content users - the pilots and the maintenance crew - are shown in Figure 10. The left side of the
diagram shows the root causes of the problems, whilst the right side show the various goals of the
stakeholders including the desired level of the goal variable. The findings visualised in the diagram
are discussed in more detail in appendix section A.1.1.

The diagram shows a significant overlap in the problems encountered by both content users, with
pilots encountering some additional problems, an additional root cause and the additional goal of
flight safety. For both content users holds that the use of paper is seen as the most significant root
cause of their problems.

22
 Low-Bandwith, Pilots only
Possibilities to

-
High-cost
receive rich-data
communication
while in flight
channels

-+
Time needed to get % Out of date
information on board information

+
Correctness of
# distribution errors
Decision making
gh

+
Hi
+

Use of paper Speed of

+
Decision making gh

-
Hi
+

Time needed for

Pilots only

+
-

browsing / searching
information Head down time Flight Safety

+
gh
Hi

Figure 10: Problem theory - Content users

Time needed for
-

administration
Efficient & Correct

+
-

adminstration
Manual gh

+
# errors in Hi
administration
tasks administration

+
Time needed for Efficient Filing/Sending
-

filing information/ of Adminstration h

reports information Hig

23
2.3.2.2 Content providers
The problems encountered by the content providers and their causes are shown in Figure 11. The
findings visualized in the diagram are discussed in detail in appendix section A.1.2.

Manual revision + - Percentage of

# revison errors
+ of documents Correct information gh
- Hi
Use of paper
# distribution
errors
+ Percentage of on-time
+
- content provision igh
H
Manual distribution + Time needed to
of documents distribute information -
Efficiency of
content provision gh
+ Hi

Effort needed to - Possibility/Efficiency of

track distribution distribution verification
h
Hig

Figure 11: Problem theory - Content providers

In the meetings with the various content providers, the use of paper was also identified is the root
cause of their problems which results in an important overlap in the cause of the problems for both
the content users and the content providers. The time needed to distribute information and the
number of distribution errors are the pivotal constructs in both diagrams.

2.3.3 Solution theories

The stakeholders were also asked to give their view on how their problems could be solved by using
an information system. The purpose of this phase was again to gain better insight in the line of
reasoning of the stakeholders to improve the overall design and development process. The notation
used to describe the solution theories is the same as the one used for visualizing the problematic
phenomena. Also the process of identifying the theories was very similar; using initial interviews and
holding comeback meetings. As one might expect, the identification of the problems and the solution
theories was not a separate process. Often when discussing problems, people (unintentionally) start
to describe how they could be solved or state a problem in the form of the absence of a solution,
which happened during several interviews in this case as well.

For the interviewed content users, the solution theory is mainly based on their belief that an
information system would bring three improvements: better communication means, electronic
distribution of the content and electronic tools for supporting their tasks. How these improvements
are seen by the interviewees to help the pilots and maintenance crew in more successfully reaching
their goals is depicted in the diagram in Figure 12. The findings visualized in the diagram are
discussed in more detail in appendix section A.1.3.

24
 Possibilities to Pilots only
receive rich-data
while in flight

-
+
Time needed to get % Out of date
information on board information

+
-

-
-

+
Manual distribution & Correctness of
# distribution errors
revision of documents Decision making

-
-
gh
Hi

-
Electronic
# interpretations errors
Flight Folder
+

-
Speed of

-
Decision making h
igH
+

Time needed for

-
browsing / searching Pilots only
-

information
Head down time Flight Safety

+
gh
Hi
-

Figure 12: Solution theory - Content users

Time needed for
-

-
administration

% digitally assisted Efficient & Correct

-

-
administration tasks adminstration
gh
# errors in Hi
administration

Possibilities to Time needed for Efficient Filing/Sending

-
-

send reports filing information/ of Adminstration h

while on board reports information Hig

25
From the point of view of the interviewed content providers the introduction of an information
system would reduce (or remove) the need for manual distribution and revising of documents. In
their view, this would result in fewer errors made and less time needed for distribution and less
effort would be needed to track distribution tasks since they can be logged electronically. This is
shown in the figure below.

Manual revision + - Percentage of

# revison errors
- of documents Correct information gh
- Hi
Electronic
Flight Folder # distribution
errors
- Percentage of on-time
+
- content provision igh
H
Manual distribution + Time needed to
of documents distribute information -
Efficiency of
content provision gh
+ Hi

Effort needed to - Possibility/Efficiency of

log performed
distribution verification
distribution tasks h
Hig

Figure 13: Solution theory - Content providers

2.4 Solution criteria

The final part of the stakeholder analysis is to determine the criteria which the stakeholders will use
to judge the (final) solution design and to determine the priorities of these criteria. Identifying these
criteria will help determine the scope of the solution, their priorities help guide the solution design
process and finally it gives additional insight in the stakeholders’ line of reasoning.

The solution criteria were identified by means of interviews and analyzing the goals and problems of
the stakeholders. To structure them, we divide them in runtime quality attributes and non-runtime
quality attributes. The former are attributes which can be measured during the use of the solution
and the latter are attributes which cannot be measured at this runtime.

2.4.1 Run-time System Qualities

Functionality
As expected and mentioned during the most interviews, one of the first criteria used to judge the
solution is whether its provided functions meet the stated and implied needs. Especially the end
users of the solution product will look at which functionality is provided and whether this is sufficient
for solving their problems (suitability). When the promised functionality is not provided the solution
will simply not be used since there already is an existing system in place.

Security
Security quality is concerned with how well the system is able to resist unauthorized attempts at
usage or behaviour modification, while still providing service to legitimate users. For KLM this is very
important since the information passing in the domain of the solution is not to be used outside KLM.
Additionally, the integrity of the information is very important since it directly influences decision
making of pilots for instance, as identified in the previous sections.

26
Performance
Performance quality is concerned with aspects such as response time, utilization, and throughput
behaviour of the system. Content providers will mostly judge the performance of the system on how
fast content is delivered. For example, Engineering & Maintenance wishes near-real-time delivery of
updated documents from ground to aircraft. End users will judge the performance based on
measures such as how much time is needed to retrieve a specific document.

Reliability
Reliability is concerned with how much the users can depend on the systems availability, measured
in terms of system up time, the time between failures and the time needed to recover from failures.
As indicated by several interviewed stakeholders, the amount of failures should be low, the time
between failures should be high and when a failure occurs, the system should be able to recover
from it swiftly.

Usability
Usability is concerned with the capability of the solution to be understood, learned, used and liked by
the users. Not surprisingly this is of paramount importance to the end-user. Simply put, when the
solution is deemed to be less usable than the existing system the end-users will have no need for it.
Other stakeholders have stakes here as well, for example as they are responsible for the training of
the end users (Flight Technical).

Efficiency
Here, efficiency is concerned with the capability of the solution to provide appropriate performance,
relative to the amount of resources used. This is measured, for example, in terms of the cost for
delivering content per byte. As stated by an ADC interviewee, this is important since using expensive
communication channels for high-data content (such as a complete aircraft manual)) could have
significant financial consequences.

Interoperability
Interoperability is concerned with the capability of the solution to cooperate with other systems at
runtime. For example, the system should be able to cooperate with the other systems used by Flight
Dispatch.

2.4.2 Non-runtime System Qualities

Maintainability
Maintainability is concerned with the capability of the solution to be modified. Modifications may
include corrections, improvements or adaptations of the solution to changes in the environment and
in the requirements and functional specifications. For ADC, this quality is especially important since
they will be responsible for the maintenance of Flight Folder. In addition ADC needs the solution to
be easily modifiable for possible future content types, their providers and the systems of these
content providers.

Portability
Portability is concerned with the capability of the solution to be transferred from one environment to
another. The environment may include organizational, hardware or software environment. This is
important for ADC as explained by one the ADC members since the airborne component of the
solution will most probably be used in a variety of aircraft using a variety of hardware.

27
Time to market
For ADC one important criterion is to quickly have a first prototype of the solution, which underlines
the importance of creating a proof of concept. Reasons for this are for ADC to be able to show the
technical feasibility, to raise awareness of the possibilities and gain more support for the envisioned
Flight Folder concept.

2.4.3 Stakeholders vs. Qualities

In the table below, the various qualities are mapped against the stakeholders. The numbers in the
table represent the priorities of the qualities to the stakeholders which were determined by directly
asking the stakeholders to prioritize them, with 1 being the highest priority and allowing shared
priorities amongst the different qualities.

Content Content ADC Flight

Users Providers Technical
Runtime Qualities
Functionality 2 1
Security 2
Performance 3 3
Reliability 4 2
Usability 1 2 1
Efficiency 2
Interoperability 3
Non-Runtime Qualities
Maintainability 1
Portability 3
Time to market 1
Table 1: Stakeholders vs. Qualities

The priorities summarized in the table shows the importance of the focus of the thesis work on the
usability of the design and covering all the desired functionality from the content users and the
content providers’ point of view. From the ADC department’s view it shows the importance of the
focus on maintainability and shows the necessity of investing time in developing a proof of concept.

2.5 Conclusion
Concluding the chapter, we discuss some of the findings done in the problem analysis phase. First we
emphasize the importance of using the journalistic method of asking the why-question repeatedly to
gain deeper insight and to make possible hidden issues explicit. This was especially fruitful in
developing the problem theories depicted in the problem trees.

The trees were very useful as well, as they gave structure to the held meetings and worked very well
in communicating the theories with and between the stakeholders due to their simplicity. One critical
note which can be made is that the goal trees are somewhat generic. However, the cause for this lies
in the explicit demand of KLM for the design of the Flight Folder to be generic, which was mentioned
during some of the first meetings with the stakeholders.

Finally, the comeback meetings proved valuable in checking whether findings from earlier meetings
were indeed correct and complete and to clear any misunderstandings. In addition it allowed
stakeholders to bring up things previously not discussed, because they were forgotten or new
insights were gained.

28
3 BUSINESS SOLUTION DESIGN
The next phase of the thesis work consisted of taking the knowledge gained in the problem analysis
phase as a base to start working towards a solution design. As discussed in the first chapter, this
consisted of designing both a business solution and a software solution. The business solution design
is the description of the desired business situation, which describes how the software solution is seen
to be part of the business context and determines the scope of the software solution design
(Wieringa, 2003).

3.1 Approach taken

To come towards a satisfactory business solution design individual meetings were held with the
stakeholders from the various departments (ADC, E&M, Flight Technical, and Flight Dispatch) and
KLM’s Boeing 777 engineering pilot. The goals of the meetings was first to determine how the
eventual solution is seen to become part of the business context by analyzing the current workflows
of the stakeholders and determining how and where the solution would support these. The second
goal was to determine the scope of the software solution by determining its desired properties and
solution constraints.

The first rounds of meetings consisted of open-style brainstorm sessions followed by more directed
sessions. During these more structured meetings several tools have been used to work towards the
business solution design. The iterative development of the goal, problem and solution trees (as
described in the previous chapter) gave means for exploring the workflows of the stakeholders. Some
points in the workflows which the solution could support and its desired properties and solution
constraints were also derived from the results of the problem analysis phase. These were then
verified in the meetings with the stakeholders. During the meetings, the trees were also used as a
kind of a checklist. In this way it was possible to check whether the earlier identified problems were
addressed by the discussed solution and no issues or goals were being overlooked.

3.1.1 Use cases

During this phase we made use of use cases, which are descriptions of steps or actions between a
user and an information system which can be used in various situations (Cockburn, 2001). In this case
we attempted to use them to describe the identified interactions between Flight Folder and the
stakeholders. These descriptions could then be used in follow-up meetings or in meetings with other
stakeholders and to be used as a base for the requirements formulation. However, it was found that
the use cases technique was not really suitable in this case. Particularly since the use cases took a
considerable amount of time to set up and their usefulness in the meetings was very limited. The
interviewed stakeholders were not familiar with the concept and it took considerable amount of time
to explain them. The stakeholders found them difficult to reflect on, which inhibited the creativity
and flow of the brainstorm sessions. Therefore we decided to use short usage scenario’s (also called
use stories) which are short descriptions of general usage patterns since they would be quick to set
up and interpret. These proved to indeed be easier to understand for the stakeholders and could
effectively be put to use.

29
3.1.2 Function Refinement Tree
Whilst determining the desired functional properties, or the functionality, of Flight Folder another
very effective tool was the so-called function refinement tree. This notation lists the desired system
functions hierarchical and can be seen as a shopping list of what the system must do (Wieringa,
2003). As an example, the final version of the refinement tree as used in this case is shown in below.

Support use of flight and non-

flight related content digitally

On-board Functions Ground Functions

Content use Content creation Content request Content management Reporting

Request update Add content Report provisioning
View content Create new content of content
Update content
Edit content Report subscription
Accept content Request new content
Replace content
Print content File content Automated requests Delete content

Content retrieval

Figure 14: Function refinement tree

The main advantage of using this notation as experienced during the meetings is that it gives an
immediate overview of the desired functionality, which aids significantly in structuring the
discussions or brainstorms which can evolve in several directions during the meetings. In addition it
helped in quickly clearing some misunderstandings. For example whether a discussed functionality
(such as the creation of content) was to be used on-board by the content users or by the content
providers on the ground could be cleared by relating the function discussed to the refinement tree.

The refinement tree was created in an iterative fashion; adding, removing or ordering functionality
and categories (e.g. the content use category) in several steps. Its first version held the till thus far
identified functionalities divided in some categories. In subsequent meetings, the subdivision
between on-board and ground functions was added to clarify the distinction in functions to be used
on ground and those on-board the aircraft. This was done after a misunderstanding in a meeting
where the pilot mentioned that an electronic reporting tool was already available in the cockpit.
Some functions were added (such as printing content) or removed as the development progressed
over the course of the meetings.

3.1.3 Service Descriptions

Conjointly with the function refinement tree, service descriptions were setup together with the
involved parties in a similar iterative fashion. The service descriptions delineate the services
delivered by the solution. A service is seen as the interaction between a product (or the kit: the Flight
Folder) and its environment, that is valuable to the environment. Each service description lists the
triggering event of the service, the value of the service for the environment, and any assumptions
made about the environment in an implementation independent manner. In this fashion the service
descriptions help determine the desired functionality of the solution and form the base for the more
detailed functional requirements. An example of a used service description is presented in Table 2.

30
 Name Add content
Triggering event Content Provider requests upload of content to a set of aircraft.
Delivered service Flight Folder sends the content to the aircraft within a required time frame.
Assumptions Communication with the aircraft is available within the required time frame.
Table 2: Service description example

The strength of the service descriptions lies in the fact that they capture the essence of the described
functionality in a standardized, precise and concise manner whilst emphasizing the utility of the
service for the user. We found this very helpful in sharing an understanding of the desired system
services amongst all the involved stakeholders whilst bounding the functionality of the system.

3.1.4 Interplay with software solution design phase

Although advancing from the business solution to the software solution phase may seem as a linear
process with clearly defined and separated steps, this was not the case. The process taken, allowed
for more interplay between the two solution design phases. The outcomes of the business solution
design phase were indeed taken as a base for the software solution design phase; however the latter
phase had influence on the former as well, and were developed more hand-in-hand as traditionally
might be the case.

3.2 Notable outcomes

In appendices A.2 and A.3 respectively, the outcomes of the business solution phase are presented
with regard to the supported workflows and the desired properties and solution constraints. Here we
present some notable outcomes of the phase.

3.2.1 General structure

At a high level the business solution envisioned by all the involved parties is to introduce a Flight
Folder information system, which the content providers can use to distribute information to aircraft
and the content users can use for information retrieval. This implies designing a composite system
which is divided in a ground based component which interfaces with the different content providers
and an on-board component which the content users can use to retrieve and view the information.

Composite
system

Content Content
Flight Folder
Users Providers

On-board Ground
component component

Figure 15: Composite system

31
3.2.2 Scoping
In determining the scope of the composite system shown above, the function refinement tree
together with the service descriptions was immensely useful. The former gave an immediate
overview of all the functions to be supported by the system and the latter gave a clear description of
what use each function would deliver to the stakeholders. Therefore discussing the scope with the
various stakeholders was an efficient and effective process. Determining the scope was also relatively
straightforward since no real conflicts arose between the views or demands of the involved parties.
Some differences came up, but could be resolved quickly. We believe this was mainly due to the fact
that the problem analysis phase already produced a rough outline for the scope and that the
problem and solution theories were developed iteratively with all stakeholders involved.

In terms of scoping the solution space one important decision made was for the border of the Flight
Folder system to be at the content packaging phase in the content providers’ process (see appendix
section A.2.1). This means that Flight Folder will not support the content providers in creating the
actual content it will distribute. This was decided in consensus with the involved stakeholders (the
content providers and the ADC department) as not to raise the need to redesign the content creation
work processes of all the various content providers, their different systems and strict rules and
procedures. Instead it was decided to specify how the stakeholders should package the content in a
Flight Folder standard way.

One might argue that a complete redesign of the workflows surrounding the Flight Folder system,
instead of working towards an improved digital version of the current paper system (crudely put). As
explained by ADC, common practice within KLM however is to first develop and implement the
technical infrastructure of a new system, including the requirements of those stakeholders involved
and then focus on changing and optimizing the workflows. This was also the starting point for the
Flight Folder system and the assignment laid out by KLM for this thesis. The main reason for this is
that many different departments are involved, each with their own specific work practices
embedded in many rules and procedures not easily changed. Many of these rules and procedures are
bound to regulatory systems such as the aforementioned Inspectorate for Transport, Public Works
and Water Management (in Dutch: Inspectie Verkeer en Waterstaat) and the Federal Aviation
Administration. Changing these procedures would therefore not only require many discussions and
time within KLM, but also between KLM and the infamously slow and conservative regulatory bodies.
A complete redesign of all the work processes of the parties involved is therefore deemed not a
suitable approach by KLM. On a critical note however; such complete redesign solutions tend to be
more widely supported throughout the company as all parties are heavily involved in working
towards a shared solution, as discussed in the work of Katsma (Katsma, 2008). This should therefore
be considered by KLM as a serious solution alternative.

3.2.3 Meta-information
During this phase it was also very important to discuss the information describing the content
needed in the various workflows (such as the expiration date of a document). As mentioned in
chapter 1, the focus lied on this meta-information instead of the actual information contained in the
content itself since solution design should be generic and suitable for future content. This caused
some problems and misunderstandings with the stakeholders as they were often referring to specific
documents and had trouble in discussing ‘their’ content in a more abstract manner. In hindsight, this

32
could have been expected since most people focus on their current work and set of documents
involved in this work and are not concerned with the ‘helicopter view’.

Overcoming these obstacles and performing this analysis proved very important since in this phase
we uncovered differences in how content was handled by the various content providers. For
example, most content provided by Flight Dispatch has an expiration date (such as the weather
reports), whereas the content from Engineering & Maintenance does not. Furthermore, handling of
expired content was also different between the content providers. In some cases it can be deleted
immediately since it may not be used once expired, in other cases it is desirable for the content to
still be available to the user until an update is present. This teaches us that the simple term of
expired content has several meanings across the organization, each with considerable implications
for the design and that used terminology should be clearly defined and be agreed upon by all parties
involved. Setting up a dictionary to capture the terms and their meanings is therefore often
advisable.

3.3 Conclusion
Overall the business solution design phase was a smooth process due to the involved stakeholders
and the work done in the previous phase. The deployment of the journalistic method and working
out the stakeholder’s goal trees and problem theories increased our understanding of why
stakeholders had certain requirements for the final solution and made certain decisions when
presented with multiple design options during this (business) solution design phase. Furthermore, it
helped us in thinking along the same lines as the stakeholders during the birth of these design ideas
and options in preparation for the stakeholder meetings and during the meetings themselves held in
this phase.

In addition the problem analysis phase laid a good foundation for determining the scope and
identifying the workflows of the stakeholders as they were already discussed to a small extent during
the development of the goal and problem trees. The function refinement tree and the service
descriptions also greatly aided the process.

The deployment of the use cases tool however did not meet its expectations as stakeholders found
them difficult to work with, inhibiting the creativity and flow of the brainstorm sessions. This may lie
in the fact that the stakeholders did not have previous experience with this kind of tool and did not
have the patience (or time) to learn them.

In hindsight, we could conclude that we may have missed an opportunity for a complete redesign of
the workflows of all the involved parties in order to make a bigger improvement then an improved
digital version of the current paper workflows. This however, would fall outside of the scope of a
Master’s thesis project considering the amount of effort needed to change all the rules and
procedures in all of the involved departments, governed by the slow and conservative regulatory
bodies.

33
4 SOFTWARE SOLUTION DESIGN AND SPECIFICATION
In the software solution design and specification phase, the desired functionality identified in the
previous phase were worked out in more detail by eliciting the functional requirements and
specifying a software solution based on these requirements. In this chapter we describe the overall
process. The outcomes of the work (the requirements and specification documents) are referred to
in appendix A.6.

4.1 Approach taken

The software solution design started with the working out the service descriptions into more detail
by gathering the requirements of the stakeholders. The requirements elicitation already started
during the meetings in the business solution phase whilst discussing the desired functional properties
and especially whilst discussing the service descriptions. Although the purpose of the meetings was
to discuss the wanted functionality in general, naturally detailed requirements already came to light
as the stakeholders sometimes tended to discuss ideas in a detailed manner. This provided us with
the possibility to set up a first set of requirements for most of the desired functionality.

With regard to the content providers, the main method of gathering the requirements was to
present this first set of requirements and discuss them in meetings with the individual stakeholders.
During the meetings the content providers reflected on the given list and together we brainstormed
for potential missing requirements. Here the function refinement tree was again used as kind of
checklist during the meetings. Similarly to the previous phases, several rounds of meetings were
held, allowing for new requirement documents being set up between the meetings and distribute
them amongst the stakeholder before each meeting. Using several rounds of meetings gave the
stakeholders time to reflect on the contents of the meetings and possibly come up with new
requirements not brought up in earlier meetings.

This approach worked well for the content providers. With regard to the engineering pilot however,
this method was less effective. For him it was difficult to come up with new requirements by
analyzing the already set up requirements or by using the aforementioned use cases and usage
scenarios. During one meeting however, the pilot started to try and visualize certain ideas about the
content request functionality by scribbling some kind of workflow / GUI ideas. This immediately gave
us the idea of deploying the method of paper prototyping for the requirements elicitation, and for
the software specification phase as well. When used during a subsequent meeting it delivered a kind
of ‘eureka moment’ as the pilot found it very easy to work with and the meeting was very productive.

4.2 Paper prototyping

During this first ‘prototyping’ meeting, a simple pencil and paper drawing such as shown in Figure 16
was used to present several design alternative examples. Upon examining the drawing the pilot
stated something in the line of “Ah... is this what you meant with the various options? Well in that
case this is the preferred approach”. This immediate understanding of the various design alternatives
and the quick decision making by the stakeholder made the meeting very effective. An important
development in the process since the engineering pilot’s availability was limited and the meetings
therefore had to be productive in the short amount of available time.

34
 Figure 16: Design alternatives drawn with pencil on paper

In the first couple of meetings, the focus lied on discussing multiple design alternatives and workflow
ideas in general for setting up the requirements. This involved the development of storyboards
representing several design alternatives for each desired function previously identified. These were
set-up prior to the meetings. In the meetings the general idea behind each storyboard was explained
after which the engineering pilot was able to reflect and discuss them; choosing the most desired
alternative, altering them by drawing on the storyboards themselves or starting with a blank paper
and drawing his own. During these open-style brainstorm sessions the requirements were set-up
together with the pilot as well as afterwards by analyzing the meetings ourselves, discussing and
validating them in subsequent meetings.

As the requirements elicitation phase converged towards the specification phase, the focus shifted
towards the details in the design of the application. For this purpose more detailed prototypes were
developed using a Microsoft PowerPoint EFB GUI template already available. Using this template, the
application’s screens, such as the one shown in Figure 17, could be designed fairly quickly. Another
major advantage of the template was that it already contained design decisions on how certain GUI
elements (such as menu buttons) should look like and behave. These design choices were
consolidated in an earlier development process by ADC and the B777 Flight Technical department.
This ensured that the pilot was not distracted by “fit and finish” issues such as the used fonts, colours
and button sizes, but was focused on the design choices at hand. The workflow designs developed
earlier were useful in these meetings as they showed the location of each screen in the workflow.

35
 Figure 17: Detailed prototype

4.3 Specification phase

Although a clear border between the requirements elicitation and the solution specification phases
cannot be drawn, this phase focussed more on the technical aspects of the solution. Several
meetings were held with members of ADC as technical expertise was required to be able to specify
certain aspects of the solution. For example in determining the use of the appropriate
communication channel with regard to the available communication channels, their bandwidth and
cost-per-byte in combination with the size and priority of the content to be transmitted.

The approach was similar as in earlier phases: preparing several design ideas in advance of
brainstorm style meetings with ADC members. As most of the thesis work was carried out in the ADC
department, brief consultations could be performed on a very regular basis as well.

As mentioned, it was somewhat difficult to draw the line between the requirements and
specification phase and to determine whether something had to be recorded as a requirement or
could be left to be decided by the people specifying the solution. In this case however, this was
relatively uncomplicated since we played both the role of requirements engineer as well as the
solution specification engineer. This however will be more complicated in practice since different
people, and often different departments, will be responsible for each phase.

36
4.4 Solution decisions
In this section we highlight some of the many design decisions made during the solution design and
specification phase.

4.4.1 On-board Flight Folder

From the perspective of the pilot, the most important design decisions made in this phase were
related to the workflow of the on-board Flight Folder GUI. For each function of the application design
decisions were aimed at minimizing the effort required from the user to perform a certain task,
whilst keeping the GUI understandable. One decision was, for example, to include a dynamic menu
structure based on the phase of flight. The phase of flight is automatically determined by Flight
Folder and when it changes, the menu structure changes accordingly.

Second, designing the behaviour of the on-board Flight Folder application concerning out-of-date
content was important as well since some content should not be used by the flight crew once
expired. This is for the reason that the pilots should not base mission-critical decisions on out-of-date
information as forbidden by law in some cases. This however does not apply to all situations as
sometimes having expired information is better than having no information available at all. Therefore
we made the decision to require the content providers to specify if the expired content is allowed to
be shown based on the content type. The rules are part of the configuration of Flight Folder allowing
changes to be made whilst Flight Folder is in operation and to be ready for future content types and
their corresponding rules.

4.4.2 Content meta-information

An important task in designing the communication between Flight Folder internally and between the
content providers and Flight Folder was to come up with a way to describe the content meta-
information. As KLM’s requirement of having the solution as generic and portable as possible, we
decided to look for an industry standard for describing the required content meta-data. Such a
standard was found in the ARINC 633 specification, which is an air-ground data and message
exchange format for data / message exchange between aircraft and ground entities (ARINC, 2010).
However, not all of the required metadata for Flight Folder could be housed in the specification.
Fortunately the standard houses an XML format specification, which we choose to adopt and expand
with the KLM specific meta-information as can be seen in Figure 19.

37
 Flight Folder package

EFF xml
M633Header
Flight Folder package
M633SupplementaryHeader
FF identification Flight
- Aircraft ID
- Flight ID Aircraft

SubFolder
Content metadata
- ID Document
- Title - id
- Version - type
- MIME type - file
- Size - title
- Topic - timeToLive
- Effective date
- Expiration date Topic

KLMSpecificMetaData
- Version
Content - Size
- EffectiveDate

Content

Figure 18: Flight Folder metadata in extended ARINC 633 XML format

4.4.3 Communication costs

The main design decision regarding the control of communication costs was to introduce a
mechanism in Flight Folder for determining the appropriate communication channel to use. This
mechanism bases its decision on the available communication channels, the content priority and the
maximum allowed content size per channel, as shown in the table below which is configurable by
ADC. The diagram depicted in Figure 19 shows how the table is used to determine an appropriate
communication channel, if possible.

Communication Content priority Maximum allowed

channel A B C D content size
GateLink 1 1 1 1 ... MB
ACARS 2 2 - - ... KB
SATCOM (IP) 3 3 2 - ... KB
Table 3

38
 Determine list of allowed
communication channels
based on content priority

Filter list by checking

content size vs.
maximum allowed size
List empty?

[yes]

[no]

Determine communication
No channel found channel to use based on
availability and priority
Available
channel found ?

[no]

[yes]

Channel found

Figure 19

Another important design decision cost wise was to introduce a delay between content update
requests initiated by the pilots. This configurable time interval is designed to reduce the data
bandwidth costs by preventing too frequent requesting of content by the pilots who are infamous for
requesting updates of information (such as weather reports) continuously if possible. This issue was
brought up by ADC members and later confirmed by the engineering pilot.

4.5 Conclusion
The main conclusion drawn from the software solution design and specification phase is that the
deployment of paper prototyping was very effective, both for gathering requirements and the
solution specification phase. In the former phase the prototypes were very rudimentary pencil
drawings allowing for the focus to be on the general workflows and promote creative out-of-box
thinking instead of on fit-and-finish issues. In the latter phase, these storyboards were then put to
effective use as a guide for the more detailed PowerPoint GUI prototypes.

39
Although paper prototyping was not planned to be used, it emerged during the phase at meetings
with the engineering pilot. This shows that the most suitable approach cannot (always) be planned
ahead, but can emerge during the process itself. Keeping an open mind and being sensitive towards
the experiences of the stakeholders during the process is very important in achieving a smooth and
effective design and development process.

Another important observation made was the fact that it is difficult to draw the line between the
requirements and specification phase and to determine whether an issue should be classified as a
requirement or be left to be decided by the people specifying the solution. This decision is even more
complicated in common practice since different people, and often different departments, will be
responsible for each phase.

40
5 DEVELOPMENT PHASE
The development phase consisted of developing a proof of concept of the on-board Flight Folder
application as a small study for the technical feasibility of Flight Folder.

5.1 Functionality implemented

As time was limited for this phase we decided in consultation with the ADC department to
implement a limited set of the functionality identified and specified in the previous phases. This set
consisted of the general menu structure of the application, the content viewing function, the
communication function and functionality for retrieving aircraft data. These functions were chosen
as they are considered to be the core of the on-board Flight Folder application on which the other
functions build upon. Background information on the development and test environments can be
found in appendix section A.5.

The implemented menu structure is dynamic as its contained dynamic content library changes
according to the aircraft’s status, the active flight phase, the content available and the content
status. The content viewing function allows viewing PDF as well as image type documents. The
implemented communication functions allows for communication between the captain and co-pilot’s
EFB and allows content to be sent from a simulated ground environment to the EFBs. The aircraft
data retrieval function allows for various aircraft data parameters to be retrieved from the various
systems on-board the aircraft, for instance to determine the flight information (e.g. flight number,
route and departure date) automatically.

5.2 Application structure

The general structure of the proof of concept application follows the so-called Model-View-
Controller architectural pattern in which the application is divided in three components with
different responsibilities; the data model (model), the data presentation (view) and the application
logic (controller) (Burbeck, 1987). The main advantage of the separation of the responsibilities is that
it improves the readability and re-use of the code, improving maintainability. This separation also
implies that any changes made to the user interface do not have direct effect on the data model,
greatly improving the portability of the application.

As can be seen in Figure 20, the application also has a communication and a configuration
component. The former handles the communication between the main application (controller) and
the ground Flight Folder system. The latter allows for easy configuration of the application by its
maintainers allowing for changes to be made to the behaviour of the application without the need to
change its code. Separating the communication responsibility from the main application improves
the maintainability and portability.

41
 Figure 20: General structure

5.3 Observations
The base for the development phase was actually already laid in the first month of the internship at
KLM in which a small aircraft data retrieval application was developed in order to get acquainted
with the development environment. During this phase we observed that the Boeing Software
Development Kit (SDK) and KLM’s EFB Toolkit allowed us to develop an EFB application fairly quickly
and that aircraft data could be retrieved from the various information systems on-board the aircraft.
This already gave us the impression of the feasibility of the Flight Folder EFB application which was
then confirmed in the final period of the internship by the successful development of the other
functionality.

With regard to the implemented viewing function we observed that content formatted as PDFs will
most likely have limited usability as the interface of the EFB does not lend itself for easy navigation
through files (such as scrolling or zooming). The presentation of information or documents housed in
a format using separation of style and contents such as (X)HTML & CSS or XML & XSL(T) can be tailored
to the EFB interface and would therefore provide more usability when developed properly. With our
limited time available this could unfortunately not be implemented.

During our test work, test scripts were deployed to structure and formalize the testing. The
preparation of the test scripts forced us to think about what was to be tested and how this could be
done most effectively resulting in some implementation errors already found before the test and
very efficient test runs. Another major benefit of the use of test scripts is that it allows for any errors
found to be reproduced easily, when documented correctly. This became even more apparent by
observing another EFB development project running at the ADC department. In this project no test
scripts were used and many discussions arose about reproducing bugs or abnormal application

42
behaviour when a tester found such issues which could not be reproduced by the project manager or
programmers afterwards.

5.4 Conclusion
In conclusion we can say that the proof of concept has shown the technical feasibility of the on-board
EFB Flight Folder concept including the transmission of content from a ground system to the EFB
application and the retrieval of aircraft data from the various aircraft systems. The observations
made during the test phase of the development project also underlined the importance of using test
scripts in order to structure and improve the efficiency of the tests as well as the improved
reproducibility of any issues encountered.

43
6 CONCLUSIONS & RECOMMENDATIONS
The goal for the thesis was twofold: first from a business perspective to make a start in developing
the Flight Folder system, and second from an academic perspective to analyze the overall design and
development process. The recommendations for KLM are discussed in the final section of this
chapter. We first discuss the conclusions regarding the design and development process which are
the result of the reflection process.

6.1 Conclusions
Importance of the journalistic method for understanding the stakeholders
From the work performed in the problem analysis phase we can promote the importance of using
the journalistic method of asking the why-question repeatedly to gain deeper insight and to make
possible hidden issues explicit. The problem analysis gave us better insight in the actual problems of
the various stakeholders involved, why these are problems by analyzing their goals and finally gave
some insight in the solution ideas those involved may have. This increased our understanding of why
stakeholders had certain requirements and why they made certain decisions, helping us in thinking
along the same lines as the stakeholders. This in turn aided us in preparation for stakeholder
meetings and during the meetings themselves, improving the overall design and development
process.

Iterative development for involving the stakeholders

The technique of iterative development played a large role in the thesis project as many aspects
were developed together with the stakeholders in this manner. In our experience this approach
improves user involvement as it allowed the stakeholders to participate in the overall design and
development process. In addition, the comeback meetings proved valuable in checking whether
findings from earlier meetings were indeed correct and complete, and to clear any
misunderstandings. In addition, it allowed stakeholders to bring up things not discussed in earlier
meetings.

Advantages of paper prototyping

A small “eureka moment” was experienced when first deploying the simple pencil and paper
drawings as the interviewed immediately understood them and could reflect on and work with them
easily. The paper prototypes were then successfully deployed for both the elicitation of the
requirements and during the solution specification phase. In the former phase the rudimentary
drawings helped focussing the meetings on the general aspects and not on fit and finish issues which
would inhibit creative thought. In the latter, these storyboard drawings helped guide the meetings
were more elaborate prototypes were deployed. In conclusion, the paper prototyping tool was very
successful in this case during multiple phases in the design and development as they were quick to
set up, gave a substantial amount of user feedback and really involved the user in the design and
development.

44
Keeping an open mind
The emergent use of paper prototyping shows that the most suitable approach cannot (always) be
planned ahead, but can emerge during the design or development process itself. Keeping an open
mind and being sensitive towards the experiences of the stakeholders during the process is very
important in achieving a smooth and effective design and development process. This is closely
associated with the iterative development approach which allows for moments of reflection and if
necessary changing approaches between its cycles.

Proof of concept shows technical feasibility

With regard to the technical feasibility the proof of concept has shown the feasibility of creating an
application with a dynamic content library and a content viewing function for retrieving and viewing
content on the EFB currently installed in KLM’s Boeing 777 using the Boeing SDK and KLM’s EFB
toolkit. Furthermore, it was shown that content can be transmitted to the EFB from ground systems
and aircraft data can be retrieved from various aircraft systems and used in the Flight Folder
application.

6.2 Limitation
One limitation of the study which can be raised regards the validity of the solution design and
specification which was not thoroughly tested with a significant stakeholder sample size in a separate
step of the study. Instead it was chosen to focus on the technical feasibility of the design and
therefore implement parts of the solution design in the proof of concept. The limitation is mitigated
however by the approach taken during the design and development process. Firstly, an expert group
was used during a process starting with an extensive problem analysis phase with considerable user
involvement due to the iterative nature of the meetings held. The problem analysis gave as a firm
understanding of why the stakeholders have certain requirements and make certain decisions with
regard to design alternatives. Secondly, this iterative style of development including comeback
meetings allowed for validation of the analysis performed by the researcher on the contents of
earlier meetings. A larger population however, would also allow for a real usability test, which in this
case could not be performed on the implemented functions of the proof of concept. Therefore
recommendations regarding usability test are made in the next section.

6.3 Recommendations
Develop the content view function as a toolkit module
The first two recommendations concern technical aspects of Flight Folder, which are also discussed in
the documents referred to in appendix A.6. The first is concerned with the development of KLM EFB
toolkit and states that is advisable to develop the new content viewer function of Flight Folder as a
module within the toolkit, since future use of the content view function by other application is
foreseeable.

Introduce low-cost high-bandwidth communication channels

The second technical recommendation regards the data communication channels needed between
ground information systems and the aircraft. The currently available channels for communications
during flight are of very low bandwidth and not very suitable for file transfer, only for transfer of
small messages or tiny files. The uploading of more data intensive content (such as graphical weather
information) would therefore only be recommendable when low-cost high-bandwidth
communication channels are made available.

45
Incorporate paper prototyping in EFB software design and development
Seeing the success of deploying the paper prototyping tool during both the requirements elicitation
and solution specification phases, it is highly recommendable for KLM to incorporate it in their EFB
design and development processes. Paper prototyping is cheap in both time and Euros, brings results
very quickly and promotes user creativity and involvement. This promotes rapid iterative
development allowing experimentation with many design ideas, improving the final product quality.
In addition, it can bring substantial user feedback early in the design and development process when
it is relatively cheap to make changes, resulting in considerable potential cost savings for the overall
development process.

Incorporate test scripts in EFB software development

Another recommendation concerns the testing of EFB software during the development. For KLM it is
highly recommended to incorporate and standardize the use of test scripts in their EFB software
development efforts. They will improve the efficiency of each test performed since less time is
required per test as the result of the preparation work needed for developing the scripts. This could
imply more testing can be performed and the tests to become more thorough, improving both the
development process as well as the quality of the end product. In addition, test scripts allow any
issues found during a test to be reproduced with relative ease, improving the problem treatment
process.

Use a Chicken Little approach when implementing Flight Folder

The fifth recommendation made is concerned with an eventual implementation of the Flight Folder
system into the operation. For KLM it is recommended to use a so-called chicken little approach
instead of a cold turkey approach, which in essence means that the implementation should be
undertaken in small steps and not in one big leap (Britton & Bye, 2004). For KLM this could mean to
introduce the Flight Folder in its Boeing 777 fleet first and expand it to more type of aircraft once
successful. This recommendation is made for several reasons. First, because the observation was
made that KLM’s maturity of the in-house development of EFB software is quite low. Second, the
operational environment is highly dynamic which implicates that problems will arise which could not
have been found during the test-phase. Using an initial pilot phase on a small number of aircraft will
allow for these start-up and ‘real-world’ problems to be tackled before a big launch, after which any
changes to the system become very time-consuming and costly. This could also allow for the system
to proof itself on a small scale first and raise support amongst its users for a major implementation.

Perform extensive usability testing before introducing Flight Folder

During a pilot program undertaken in such a chicken little approach, tests could be performed to
assess the applications usability during the highly dynamic operational environment. Although paper
prototyping should be the main approach in assessing the usability, real-world tests can find different
classes of problems such as performance issues. These test could possibly also be performed in KLM’s
flight simulators, however such tests under the actual working environment would give better insight
on how well the application can be and is used in the real world. Considering the importance given to
the applications’ usability by both the pilots and the Flight Technical department, extensive usability
tests would be highly recommendable before introducing Flight Folder on a large scale.

46
Consider a complete redesign type solution
A final recommendation to be made is that KLM should seriously consider the option of a complete
redesign type of solution where most involved work processes and procedures are overhauled. As
stated in section 3.2.2, KLM considers it not as a viable option because these department specific
work practices are embedded in procedures and rules and spread out over numerous departments,
often regulated by the Dutch regulatory body of Inspectorate for Transport, Public Works and Water
Management. However, such a redesign solution could proof itself by the fact that this type of
solution is often more widely supported throughout the company as the involved stakeholders are
heavily involved in working towards a shared solution. Such a complete redesign project could also
open-up the possibility of introducing beneficial innovations currently not foreseen or possible due
to the conservative position.

47
REFERENCES
Alexander, I., & Robertson, S. (2004). Understanding project sociology by modeling stakeholders.
Software, IEEE, 21(1), 23-27.
ARINC. (2010). 633-1 AOC Air-Ground Data and Message Exchange Format.
Britton, C., & Bye, P. (2004). IT architectures and middleware: strategies for building large, integrated
systems (2nd ed.): Addison-Wesley.
Burbeck, S. (1987). Applications Programming in Smalltalk-80: How to Use Model-View-Controller
(MVC): Softsmarts, Inc.
Cockburn, A. (2001). Writing effective use cases (Vol. 1): Addison-Wesley.
Drugge, M., Hallberg, J., Parnes, P., & Synnes, K. (2006). Wearable systems in nursing home care:
prototyping experience. IEEE Pervasive Computing, 86-91.
Katsma, C. P. (2008). An organizational change approach for enterprise system implementations.
KLM. (2011). KLM Corporate - History Retrieved May, 2011, from
http://www.klm.com/corporate/en/about-klm/history/index.html
Rettig, M. (1994). Prototyping for tiny fingers. Communications of the ACM, 37(4), 21-27.
Sefelin, R., Tscheligi, M., & Giller, V. (2003). Paper prototyping-what is it good for?: a comparison of
paper-and computer-based low-fidelity prototyping.
SkyTeam. (2010). SkyTeam Fact Sheet Retrieved May, 2011, from
http://www.skyteam.com/downloads/news/facts/skyteamFactSheet.pdf
Snyder, C. (2001). Paper prototyping Retrieved January, 2011, from
http://www.cim.mcgill.ca/~jer/courses/hci/ref/snyder.pdf
Snyder, C. (2003). Paper prototyping: The fast and easy way to design and refine user interfaces:
Morgan Kaufmann Pub.
Virzi, R. A., Sokolov, J. L., & Karis, D. (1996). Usability problem identification using both low- and high-
fidelity prototypes. Paper presented at the Proceedings of the SIGCHI conference on Human
factors in computing systems: common ground, Vancouver, British Columbia, Canada.
Volere. (2011). Stakeholder analysis template Retrieved May, 2011, from
http://www.volere.co.uk/templates.htm
Wieringa, R. (2003). Design Methods for Reactive Systems: Yourdon, Statemate, and the UML.
Wieringa, R. (2009). Design Science as nested problem solving. Paper presented at the 4th
International Conference on Design Science Research in Information Systems and
Technology, Philadelphia, Pennsylvania.
Yu, E., Giorgini, P., Maiden, N., & Mylopoulos, J. (2011). Social Modeling for Requirements
Engineering: Mit Pr.

48
Appendices

A.1 Detailed problem analysis (completing chapter 2)

This appendix completes chapter 2 as it provides a more detailed analysis of the problematic
phenomena encountered by the stakeholders and the solution theories of the stakeholders shown in
the figures in chapter 2.

A.1.1 Problematic phenomena - Content users

Out of date information
The problem of information being out of date is encountered by pilots mostly on-board the aircraft
and related to information which is subject to frequent change, such as weather forecasts which are
only valid for a short period of time. Out of date information is problematic for pilots as it negatively
influences the correctness of their decision making, which in turn influences flight safety negatively.

The problem has two root causes: the use of paper and the low-bandwidth communication channels
between ground and the aircraft. The use of paper increases the time needed to get the information
on board the aircraft, which decreases the “freshness” of the information. The low-bandwidth, high-
cost communication channels reduce the possibility to receive information during flight which could
reduce the amount of out of date information the pilots would have to base their decisions on.

Time needed for browsing/searching information

The root cause for the time needed for browsing/searching information is the use of paper since
needed information can be spread over several documents in a large group of documents. For
maintenance crew the time needed to retrieve information is problematic because this reduces the
speed of decision making which they want to be high. Pilots need the speed of decision making to be
high for flight safety reasons. Additionally, increasing the time needed for pilots for the retrieval of
information increases their head down time: the time not spend on actual flying tasks. Increased
head-down time reduces flight safety.

Distribution errors
The main cause for the distribution errors is the manual distribution of paper which is error prone.
Content is sometimes brought to the wrong aircraft. Distribution errors result in incorrect and
missing information, negatively influencing the correctness of decision making.

Time needed for administration tasks

The time needed for administration tasks is perceived as being too high because they have to be
done manually, on paper. For pilots, the more time they spent administrating the more time they
spent with their head down, decreasing flight safety. For both pilots and maintenance crew, the time
needed for manual administration is perceived as negatively influencing the efficiency of the
administration.

Errors made in administration

Performing the administration manually is error prone as well, increasing the number of errors made
which inhibits the content users in reaching their goal of correct administration.

49
Time needed for filing administration
Both types of content users want efficient filing of the administration information because it is a
bothersome task they want to be done with quickly. This is however inhibited because of the use of
paper which increases the time needed for filing administration since it has to be done manually.

A.1.2 Problematic phenomena - Content providers

Revision errors
Revision errors are introduced because the documents have to be revised manually which is an error
prone process. Revisions are sometimes performed in the wrong aircraft, or are not performed
completely. The more revision errors are made, the lower the percentage of correct information,
which content providers need to be high.

Distribution errors
As discussed in the previous section, distribution errors are introduced because it is done manually,
lowering the percentage of correct information.

Time needed to distribute information

Because the information has to be distributed manually, content providers feel the time needed to
distribute the information is too high. The high time needed for distribution results in both a lower
percentage of on-time content provision and lower efficiency of content provision then wanted.

Effort of distribution verification

Because distribution is done manually, is takes significant effort to track the distribution process in
order to verify whether it has been done correctly. This inhibits the possibilities and efficiency of the
distribution process which the content providers want to be high.

A.1.3 Solution theory Content users

Improved communication means
Improved communication means would increase the possibility for pilots to receive new information
while in flight which, decreasing the percentage of out of date information. This in turn would
improve their correctness of decision making and in turn, flight safety.

Electronic distribution
When the content is distributed electronically, it would take less time to get the content on board
which lowers the percentage of out of date information for pilots as well.

Electronic distribution would also significantly decrease (or remove) the need for manual distribution
and revising of documents. This would lead to less distribution errors made and therefore improve
the correctness of decision making since the decisions are based on correct information.

Electronic distribution of content would also enable the content users to file their administration
electronically. This would reduce the time needed for, and therefore increase the efficiency of, this
process.

Electronic tools
According to the content users, the information system would house electronic tools supporting
them with the retrieval of information and their administration tasks, and could potentially reduce
interpretation errors.

50
Being able to search digitally through content would reduce the information retrieval time,
increasing the speed of decision making. For pilots the increased speed would result in less head
down time, increasing flight safety.

Electronic tools could also be introduced for performing administration tasks digitally with the
possible added benefit of tools capable of assisting in administration. Assisting could be in the form
of automatically filling in parts of the administration or automatically checking for administration
errors. These tools would then reduce the time needed for administration and reduce the number of
errors made in the administration. This would lead to more efficient and correct administration. For
pilots the reduced administration time would reduce head down time, increasing flight safety.

Electronic tools could also reduce the number of interpretation errors by having more possibilities to
represent and filter information, than possible on paper. Examples are filtering out not needed
information based on the situation on hand and overlaying information from one document on
another, such as dynamic airport information (from NOTAMs) on an airport map.

51
A.2 Workflows to be supported (completing chapter 3)
A.2.1 Content provisioning
In general, a content provider starts with creating content. This activity can be comprised of the
creation of new material, editing existing content, assembling content from various sources or a
mixture. An example of creation of contents is the writing and editing of manuals by the Flight
Technical department. A good example of assembling of contents is the process of assembling flight
related content such as the flight plan and NOTAMs for a flight and compose them into a briefing
package. The figure in appendix section A.4 shows the various content providers and the content
they currently provide.

The next step is packaging the content for delivery. This activity is comprised of specifying where the
content has to be delivered. In the end content is always destined for a particular aircraft
registration. However content is generally created for either a set of aircraft registrations or a
particular flight, which is performed using a specific aircraft. A set of aircraft can for example be
identified by their subtype (e.g. all Boeing 777-300s), or be the entire fleet.

Step three is the actual distribution of the content to (an) aircraft. Some content providers do this
step themselves, but mostly this is left to other parties. Such as carrying flight related content on-
board by pilots or specially hired ‘runners’. The distribution of content includes bringing new content
on-board but also other content management tasks, such as removing content. Removing content
occurs when content which is already on-board should be replaced by a new version and when
content is on-board and is no longer valid (such content related to a specific flight after a flight has
been carried out).

The final step in the workflow is a control step: assuring the delivery of the content. Here it is
determined whether the content has been successfully delivered by checking amongst others which
content version has been delivered to which aircraft and when. This step is mainly performed to
collect distribution data which could be needed in a future auditing process where authorities
request content distribution information, as mentioned by the E&M department.

Package Distribute Verify

Create content
content content distribution

Figure 21: Content provisioning workflow

Flight Folder support

Flight Folder is envisioned to support the last three steps in the workflow, as indicated by the italic
font in Figure 21.

The consensus of the interviewed content providers was that the main support of Flight Folder for
content provisioning will mainly be comprised of the distribution of contents to the aircraft. Content
providers wish to be able to send content to the Flight Folder ground component and then have
Flight Folder be responsible for the distribution to the aircraft.

52
Flight Folder will partly support the packaging of content by allowing the content providers to specify
content distribution requests not only on the single aircraft registration level, but some levels higher
such as the aircraft subtype.

In the view of the content providers, the Flight Folder support of the content distribution verification
should also consist of logging the distribution actions, provide delivery (failure) notifications and
allowing content providers to request content distribution status reports and distribution logs.

A.2.2 Content use - Flight Operations

The use of content by the flight crew for flight operations can best be described for the various
phases of flight, as depicted in the diagram below; Pre-Flight, In-Flight and Post-Flight.

Pre-flight In-flight Post-flight

Boarding Climb Cruise Descend

Take-off (V) Landing

Figure 22: Phases of flight

Pre-Flight phase
In the current situation the cockpit crew performs part of their pre-flight (briefing) tasks in the crew
centre at Schiphol airport and partly on-board. At the crew centre the cockpit crew performs the
following tasks in order:

• Collect & print briefing package

• Read & interpret briefing package
• Check & accept briefing package, or contact dispatch

After boarding the aircraft the cockpit crew checks and accepts the load sheet and passenger
information, or contacts dispatch when something is not correct. This workflow is depicted in Figure
23.

53
 Collect & print
briefing package

[receive new
package] Read & interpret
briefing package

Contact Dispatch

[not ok] Check briefing

package

[ok]

Accept Briefing
Package

Board aircraft

[receive new info]

Check Loadsheet &

Contact Dispatch passenger
information

[not ok]
[ok]

Accept loadsheet
& passenger info

Request
push-back

Figure 23: Current content use in pre-flight phase

In the envisioned e-enabled situation, the flight preparation is performed on-board, as can be seen in
Figure 24. Crew no longer carries documents on-board as needed information is made available
digitally in the cockpit.

54
 Board aircraft

[receive new Read & interpret

information]
Flight Related
documents
Contact
Dispatch

Check Flight Related

[not ok]
documents

[ok]

Accept Flight Related

documents

Request push-back

Figure 24: Content use with Flight Folder in pre-flight phase.

As depicted in Figure 24 using italics, the on-board Flight Folder component is envisioned to support
the reading and interpretation of flight related documents and the acceptation process. The process
of reading and interpreting the flight related documents is supported by means of a document
viewer. The process of checking the documents is supported by allowing crew to view and search
through non-flight related documents (such as the Minimal Equipment List) needed for their checks.
Third, the on-board Flight Folder component is envisioned to be used by the crew to communicate
their acceptation (or rejection) of contents to ground.

In-Flight phase
During flight several content-related tasks are performed in parallel by the flight crew. The main
tasks where the content is used are, as identified before, decision making and administration tasks.
The general decision making workflow is depicted in Figure 25.

55
 Decide need for
information

[no need
Search [info not available] for request]
information
[need for
request]

Request
information

[info available]

Waiting for
information

[receive information]

View information View information

Interpret Accept / reject

[accept]
information information

[reject]

Make decision

Figure 25: In--Flight decision making

The on-board Flight Folder is envisioned to support the decision making by allowing users to search
for information, request information when the needed information is not available, and viewing the
information. Flight Folder will also allow the user to accept or reject received content, which is an
action required by authorities.

In addition to the use of content in the decision making process, the cockpit crew creates content
while performing their administration tasks. These tasks include writing of reports and the
administration of the flight plan. Examples of reports written are about deviations from normal

56
operations (IFRs), and safety incidents or accidents (ASRs). The administration of the flight plan is
comprised of writing down the actual fuel and time when the aircraft reaches a waypoint (a
predefined position on the route). Another example of the creation of contents by flight crew is the
filling of questionnaires which are sometimes included in the briefing package.

The on-board Flight Folder is envisioned to support the creation (and editing) of contents, excluding
the creation of reports such as IFRs and ASRs since the KLM e-reporting application is already
available for these processes.

Post-flight phase
After landing, the flight crew finalizes the flight by singing content which needs to be sent to various
departments. A good example is the annotated flight plan which needs to be sent to the archiving
department where it is archived for a period of time as required by authorities. After signing the
contents is gathered and packaged and finally send.

Gather &
Sign content package Send content
content

Figure 26: Post-flight workflow

The on-board Flight Folder is envisioned to support this workflow process completely by allowing
users to sign content and send it digitally. The ground Flight Folder will then be responsible for the
distribution of the content to the addressee

A.2.3 Content use - Maintenance activities

The activities of engineering and maintenance crew which can be supported by Flight Folder are very
similar to those of the flight crew. Flight Folder is envisioned to support the decision making process
of engineering and maintenance crew by allowing them to search and view technical content.
Requesting of content is not considered to be required by the Engineering & Maintenance
department. Supporting the process of creating and editing content is considered to be a possibility
in the special case of the Buckle & Dent card which is currently the only E&M document edited and
stored in the cockpit. In this case the Flight Folder would also include support for the signing and
sending of the content, similar to that of the flight crew in the post-flight phase.

A.2.4 Integrated workflow picture

In Figure 27 the workflows discussed in the previous sections are integrated in one big picture to
show the interaction between the stakeholders. Some parts of the in-flight workflow for the pilots
have been left out to fit the diagram on one page. In the content provider swim lane, the first
process of creating and distributing content holds for all the involved departments whereas the
second and third are for Flight Dispatch only. The envisioned support of Flight Folder in the work
processes is indicated by italic font.

57
 Content Provider Flight Crew User of reports

Create content

Package,
Distribute & Verify
content

Board aircraft

Read & interpret

Flight Related
documents

Flight Dispatch

Create new Contact Check Flight Related

[not ok]
content Dispatch documents

Package,
[ok]
Distribute & Verify
content

Receive accept Accept Flight Related

message documents

Request push-back

Pre-Flight

In-Flight
Decide need for
information
[info not available]
Flight Dispatch

Request
Create content [info available]
information

Package,
View & use
Distribute & Verify
information
content

Post-Flight
Sign, gather
Process
package and
send content content

Figure 27: Integrated workflow

58
A.3 Desired properties and solution constraints (completing chapter 3)
A.3.1 Desired functional properties
For the ground based Flight Folder component:
1. Accept content from various content providers
2. Deliver the content to the aircraft wirelessly.
3. Allow content providers to perform content management actions, such as adding new
content, updating content, replacing content and deleting content.
4. Provide content (delivery) status information reports
5. Provide content delivery (failure) notifications
6. Accept content from aircraft and deliver it to the addressee

For the On-Board Flight Folder component:

7. Accept content from the ground based system
8. Show content to the user
9. Allow the user to retrieve content through browsing, searching and bookmarking.
10. Allow the user to print content
11. Allow the user to request (updates of) content
12. Allow the user to accept or reject content.
13. Allow the user to edit contents.
14. Allow the user to perform digital administration, e.g. of the flight plan.
15. Allow the user to create content quality reports.
16. Support the user in editing contents (e.g. by automated filling in parts of content using
aircraft data)
17. Allow the user to digitally sign content
18. Allow the user to send content from aircraft to the ground
19. Be able to automatically collect aircraft data and send it to ground.

A.3.2 Solution constraints

Solution constraints shape the boundaries of the creativity scope for the solution.

For the system in general:

• Use of the ARINC 633 standard as much as possible, for portability and interoperability.

For the ground based system:

• The product shall be able to interface to the existing systems of content providers and
receivers.

For (the first prototype of the) on-board component

• The product shall be implemented on the Boeing EFB environment as installed on KLM’s
Boeing 777-300 aircraft.
• The product shall be implemented in Java using the Boeing SDK.
• The product shall adhere to Boeing and KLM cockpit design guidelines, such as specific GUI
design guidelines.

59
A.4 Overview of content providers

60
A.5 Proof of concept (completing chapter 5)
This appendix gives some insight in the proof of concept developed for KLM.

A.5.1 Development & testing environment

The proof of concept was developed in Java using Boeing’s software development kit for the EFB
hardware and KLM’s EFB toolkit which consists of basic building units for the graphical user interface
tailored to KLMs requirements. The programming work was performed on an ordinary laptop using
the Eclipse software development environment together with Maven, a software tool for project
management and build automation.

A.5.1.1 E-enabled infrastructure

Figure 28 shows an overview of the current e-enabled infrastructure on-board KLM’s Boeing 777-
300ER, including: the two EFBs connected over the cockpit LAN with a network file server (NFS),
which is connected to the various communication channels (ACARS, GateLink & ACARS).

Figure 28: E-enabled infrastructure

A.5.1.2 Testing environments

In total, four environments were available to test the proof of concept with each one a step closer
towards the ‘real thing’, as depicted in Figure 29 below. Also shown in the figure is that the more
realistic the test environment was, the more time it took to prepare and perform a test.

low low
Development laptop
Realism of test

Time needed

VMware systems
for test

EFB test hardware

Flight simulator
high high

Figure 29: Test environment

61
The programmed application could be run on the development laptop itself, so quick bug fixing was
possible. The VMware systems, shown in Figure 30, allowed for testing communication between the
(simulated) EFBs and between an (simulated) EFB and a ground communication system capable of
sending file and text messages. Additionally the VMware set-up allowed for testing the reception and
use of aircraft data parameters, such as the actual fuel on board and the weight on wheels available
to the EFB from the aircraft’s various computer systems.

Figure 30: Simulated EFB cockpit setup (VMware)

The setup shown in Figure 31 is present at the ADC department and is a step closer to ‘the real thing’
as an actual EFB is used, comprising of an EFB display (in the middle on the desk) and an EFB
computer (the black box in the top of the cabinet). The EFB computer is connected to various
components simulating other aircraft systems, with which it can communicate, as well as an actual
printer and a network file server. This means testing in this environment is much more realistic as
actual EFB hardware is used, which for instance gives better insight in the application’s performance
for instance. However, installing (or loading as it is called) a new application onto the EFB is a
burdensome and time consuming process. This means a test has to be prepared in advance and
should assess several aspects, negating the time required to prepare the EFB hardware.

Figure 31: EFB test hardware

62
The final method of testing available is running the developed application in a flight simulator used
for training and assessing pilots. This environment is closest to testing in the operating environment
(an actual aircraft) and would therefore be the preferred testing bed as the time needed to set up
the test is only slightly more than with the EFB test hardware. However, as the flight simulators are
very expensive careful planning is done to allow maximum usage for the trainings and assessments.
Testing new applications has lower priorities and can therefore only be really performed during
maintenance slots which do not occur frequently. In addition an operator is also required to prepare
the test and operate the simulator during the test.

A.5.2 Application statistics

Some statistics of the application giving insight in the size of the developed proof of concept are
summarized in the table below.

Number of packages 4
Number of classes 23
Lines of code approx. 4000

63
A.6 Other documents
Requirements
The requirements document holds all the functional requirements identified for Flight Folder from
the perspectives of the involved stakeholders and is comprised of 35 pages.

On-Board specification
The On-Board specification document specifies the behaviour of the on-board Flight Folder
application. It is comprised mainly of the functional description and the integration and configuration
of the application. It contains 54 pages.

Flight Folder communication

The Flight Folder communication document describes the designed communication between the on-
board and ground component and the various communication channels which can be used. It is
comprised of 12 pages.

Ground functional description

This document holds a functional description of the ground component of Flight Folder which
describes the content management, reporting and notification functionality. It also describes the
fallback functionality envisioned and is comprised of 13 pages.

Availability
All of the above documents can be made available upon request via:
a.m.spannenburg@alumnus.utwente.nl

64