Informationsvisualisering
och interaktionsdesign
anpassad för intelligenta
fastighetssystem
Nils Dickner
Johan Lind
2013-11-06
LiU-ITN-TEK-A-13/060-SE
Informationsvisualisering
och interaktionsdesign
anpassad för intelligenta
fastighetssystem
Examensarbete utfört i Medieteknik
vid Tekniska högskolan vid
Linköpings universitet
Nils Dickner
Johan Lind
Handledare Jimmy Johansson
Examinator Camilla Forsell
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/
Abstract
Today there are many IT-systems holding information about different things. The information can for example be anything from news feeds to complex en-viroment systems. By making these system collaborate with each other new oppurtunities and functionality can be established. However, since most of the systems are developed individually, there are different ways to communicate with each system. Therefore, The IT-agency Gaia has started a collaboration with the real estate company Kl¨overn AB. The intention was to develop a plat-form for functional- and inplat-formational distribution focusing on commercial real estates. The platform was supposed to be available for Kl¨overns tenants and be used in public environments providing access to intelligent environment systems, processes in facility management and interactive information channels. This re-port describes the user study, the idea development and the implementation of two Windows 8 Metro application prototypes communicating through this platform. The two prototypes was directed towards the Cnema and Gaia which are both tenants of Kl¨overn. Furthermore, both the applications was written in C# and uses ASP.Net library Signalr for real-time communication.
1 Introduction 1 1.1 Gaia System AB . . . 1 1.2 Kl¨overn AB . . . 1 1.3 Background . . . 1 1.4 Requirements . . . 2 1.5 Problem . . . 2 1.6 Constraints . . . 3 1.7 Method . . . 4 1.8 Structure . . . 4 2 Related work 5 2.1 KNX . . . 5 2.2 OPC . . . 6 3 Information visualization 8 3.1 Techniques . . . 9 3.1.1 Choropleth map . . . 10
3.1.2 Brushing and filtering . . . 10
3.1.3 Tooltip . . . 11
3.1.4 Zoom, pan and rotate . . . 12
4 Process theory 13 4.1 Development process models . . . 13
4.2 Iterative Development in combination with User Research . . . . 14
4.3 Research plan . . . 16
4.3.1 Qualitative and quantitative studies . . . 16
4.4 Requirements . . . 17 4.4.1 Interviewing . . . 17 4.4.2 User Profile . . . 18 4.4.3 Contextual inquiry . . . 18 4.4.4 Surveys . . . 18 4.5 Design . . . 19 4.5.1 Storyboarding . . . 19 4.5.2 Prototyping . . . 20
CONTENTS CONTENTS
4.6 Implementation . . . 20
4.6.1 SCRUM . . . 21
4.6.2 Revision control system . . . 21
4.7 Evaluation . . . 21 4.8 Maintenance . . . 21 5 Planning 22 5.1 Process . . . 22 6 Requirement 24 6.1 Research plan . . . 24 6.2 Process . . . 24 6.3 Gaia . . . 25 6.4 Kl¨overn . . . 26 6.4.1 Departments . . . 26 6.5 Cnema . . . 27 6.6 Result . . . 27
6.6.1 Qualitative study of Gaia . . . 27
6.6.2 Quantitative study . . . 28
6.6.3 Quantitative study on the categories . . . 29
6.6.4 The contextual inquiry of Kl¨overn . . . 31
6.6.5 The contextual inquiry of Cnema . . . 32
6.6.6 Common result . . . 33 6.6.7 User profiles . . . 33 6.6.8 Profile 1 . . . 33 6.6.9 Profile 2 . . . 35 6.6.10 Profile 3 . . . 36 6.7 Conclusion . . . 38 7 Design 40 7.1 Defining the applications . . . 40
7.1.1 Information application . . . 40
7.1.2 Control and Monitoring directed towards Gaia . . . 41
7.1.3 Control and Monitoring directed towards Cnema . . . 41
7.1.4 Process and Service . . . 42
7.2 Designing the applications . . . 42
7.2.1 Information distribution application . . . 43
7.2.2 Control and monitoring . . . 45
8 Implementation 51 8.1 Window 8 applications . . . 51 8.2 SignalR . . . 52 8.2.1 Hubs . . . 53 8.3 System design . . . 53 8.3.1 General architecture . . . 53 8.3.2 Client architecture . . . 55
8.3.3 Model View ViewModel . . . 55
8.4 Data . . . 56
8.5 Development tools . . . 58
8.5.1 Kinect SDK 1.7 . . . 58
9 Result 59 9.1 Information distribution application . . . 59
9.1.1 Main view . . . 59
9.1.2 Calendar view . . . 60
9.1.3 Local view . . . 61
9.2 Control and monitoring application directed towards Cnema . . . 61
9.2.1 Active view . . . 63 9.2.2 History view . . . 63 9.2.3 Filter menu . . . 65 9.2.4 Visualization components . . . 65 10 Evaluation 71 10.1 Evaluation process . . . 71 10.2 Results . . . 72 11 Conclusion 74 11.1 Conclusion . . . 74 12 Discussion 75 12.1 Prestudy . . . 75 12.2 Design . . . 76 12.3 Implementation . . . 76 12.4 Evaluation . . . 76 13 Future work 77 13.1 Design and restructuring . . . 77
13.2 Develop the applications further . . . 77
13.3 Security . . . 77
13.4 Kinect Client . . . 78
Appendices 82 A Application proposals 83 A.1 Information distribution application . . . 83
A.1.1 Goal . . . 83
A.1.2 Availability . . . 83
A.1.3 Installed packages . . . 83
A.2 Control and monitoring application directed towards Gaia . . . . 84
A.2.1 Goal . . . 84
A.2.2 Availability . . . 85
A.2.3 Included packages . . . 85
CONTENTS CONTENTS
A.3.1 Goal . . . 86
A.3.2 Availability . . . 86
A.3.3 Included packages . . . 86
A.4 The Process and service application proposal concept . . . 87
A.4.1 Goal . . . 87
A.4.2 Availability . . . 88
A.4.3 Included packages . . . 88
B Time report 89 B.1 Introduction . . . 89 B.1.1 Background . . . 89 B.1.2 Problem definition . . . 90 B.1.3 Approach description . . . 90 B.1.4 Constraints . . . 91 B.2 Literature basis . . . 91 B.3 Project organization . . . 91
B.3.1 Department and roles . . . 92
B.4 Time plan . . . 92
B.4.1 Start and end time . . . 93
B.4.2 Milestones . . . 93 B.5 Gant chart . . . 93 C Research plan 95 C.1 Research introduction . . . 95 C.1.1 Research aim . . . 95 C.1.2 Research scope . . . 95 C.2 Research plan . . . 96 C.2.1 Goals . . . 96 C.3 Research structure . . . 96 C.3.1 Research timeplan . . . 97 C.4 Research plan . . . 98 C.4.1 Cycle process . . . 98
C.4.2 Interviews and surveys . . . 99
C.4.3 Usecases . . . 103
D Requirement specifications and package definitions 105 D.1 Requirements . . . 105
D.1.1 Information - Viktighetesgrad: 2.941666667 . . . 105
D.1.2 Funktionalitet - Viktighetesgrad: 2.266666667 . . . 113
D.1.3 Tj¨anster - Viktighetesgrad: 2.775 . . . 116
D.2 Packages . . . 117
D.2.1 The customer package . . . 117
D.2.2 The employee package . . . 119
D.2.3 The status package . . . 119
D.2.4 The communication package . . . 121
D.2.6 The news package . . . 124
D.2.7 The service package . . . 124
D.2.8 The green package . . . 128
D.2.9 The contact package . . . 130
D.2.10 The specification package . . . 131
Chapter 1
Introduction
This report is a master thesis written at the Media technology and engineering program at ITN1, Link¨opings university, in collaboration with Gaia System
AB[1] and Kl¨overn AB[2]. This chapter will give the reader a brief introduction on why the project was created. The introduction chapter will describe how the project emerged and which restrictions were made during the process.
1.1
Gaia System AB
Gaia System AB, hereafter Gaia, is a IT-company founded in Norrk¨oping spe-cializing on developing intelligent customized IT solutions and business intelli-gence(BI) applications for other companies in the east Sweden region. Gaia has been an active company for about 15 years and have 28 employees.
1.2
Kl¨
overn AB
Kl¨overns AB, hereinafter Kl¨overn, is a real estate company and is one of the larger real estate companies in Sweden specializing in commercial premises. Their service office and headquarters lies in Nyk¨oping but their business units are divided into four regions. South-, East-, Stockholm- and Central/North region.
1.3
Background
During the recent years, the development of intelligent environmental systems has increased significantly, and this has lead to new systems which can provide intelligent and effective solutions for a customer’s business. Example of such a system is KNX2[3], which is a common standardized automated system used
1Department of Science and Technology 2Konnex
for lighting control and building automation. The aim with KNX is to make it easier to communicate between different environment systems and to make the environment more intelligent by giving the environment possibility to make de-cisions. For example, when a person leaves a room, the lights will automatically switch off because the sensors in the room tells the room that it is empty.
However, the majority of the environmental systems are complex, and are often installed by external competences. This has resulted in that the lack of deeper understanding to the user has increased and the usage of the system has been limited.
Gaia has therefore started a collaboration with the real estate company Kl¨overn. The intention is to develop a platform for functional- and informa-tional distribution focusing on commercial real estates. The platform shall be available for Kl¨overns tenants and be used in public environments providing access to intelligent environment systems, processes in facility management and interactive information channels. To the project’s disposal, Gaia has developed two different techniques for communicating with two intelligent environment systems.
• KNX: A standard system which is used for lighting control and building automation.
• OPC: A standard for communication to and from different industrial sys-tems.
Except data from the environment systems, temperature, weather informa-tion and data about the environmental factors (i.e. power consumpinforma-tion, recycle management etc.) will also be available to the project. For more informa-tion about each intelligent environment system used in this project, see chapter 2.Related work.
1.4
Requirements
Based on the project’s disposal, Gaia required the information from the platform to be visualized and manageable through an Window 8 Metro application. The application was also required to be able to handle real time data gathered from the platform.
1.5
Problem
The project is in a startup phase and requires further examination to determine the possibilities of using the platform. This implies that the platform needs to be limited and seperated into concrete ideas which can be further investigated, otherwise, it may be difficult to see the true potential.
1.6. CONSTRAINTS CHAPTER 1. INTRODUCTION
To investigate the ideas further, the following categories needs to be exam-ined for each idea.
• Usability: Who is the user for this idea? Will the idea satisfy the end-user? Will the idea improve the user’s daily work? Do the idea satisfy the end user’s needs?
• Relevance: Why is the idea important related to the user? How should the idea be implemented so that the user thinks it is relevant?
• Availability: Should the idea be available for mobile devices or on larger devices?
• Information Architecture: How should the idea be structured to match the user’s needs?
• Interaction design: Which information should be visualized to the user? • Identity design: How can the idea be memorable for the user?
• Environment: Should the idea be an internet application?
To create ideas that are adapted for the user is a complex process and has been mentioned in many research articles and books. This has resulted in lots of different methods of solving this process and in this master thesis, some of the methods will be used. For more information about each method that was used, see 4.Process theory.
Since Gaia required the information from the platform to be visualized and manageable through an Window 8 Metro application, the ideas from the user re-search must be specified to application concepts. This implies that each applica-tion concept will be prioritized(i.e each applicaapplica-tion will be designed, developed, implemented and evaluated if time permits).
1.6
Constraints
As mentioned in section 1.3.Background, the project definition was originally developed from the collaboration between Gaia and Kl¨overn, and since Gaia are the company who will develop the platform they have decided that the the project will be developed and implemented on Microsoft Windows 8 RT[4], which is a version of the operating system Windows and Windows 8. Unlike Window 8 which is build and designed on X86-architecture, Windows 8 RT is designed to run on mobile devices utilizing the ARM architecture[5].
This implies that Windows RT cannot run traditional Windows programs, due to the programs are designed with the X86-architecture. Instead, Windows 8 RT is limited with the Windows apps, which can be downloaded on Windows store. The apps are developed by different web standards and this implies that
it is possible to run the apps on both Windows 8 and Windows 8 RT, i.e the apps are independent of process architecture. The disadvantage of developing these apps are the limited performance. Since the programs are running on a framework, instead of sending commands directly to the processor, the apps will not have as high performance as traditional x86-programs.
Another constraint is the limited time of the thesis work. Since the project requires a large investigations, all the relevant ideas that will be gathered, will not be implemented. However, the ideas that will not be implemented will also be defined and evaluated so that they can be used for further implementations.
1.7
Method
The working methods that was used in this project and in this master thesis was gathered from literature studies and laborations. In the implementation phase, the data was gathered from the stakeholders and from other IT-companies such as Yr[6] which is a weather site providing weather data for Scandinavia.
Furthermore, since Windows 8 application developing was released 2012, our knowledge of developing Windows 8 applications were limited. To accomplish the implementation of the Windows 8 application environment, lots of time was spent on laborations and tutorials.
1.8
Structure
The next chapter(2.Related work ) will describe the intelligent environment sys-tems and the work that was done before the thesis.
Afterwards, there will be a theory part containing two chapters, 3.Infor-mation visualizations and 4.Process theory. The first chapter will cover the information visualizations techniques that was used during the project and the second chapter will cover all the other method that was used during the differ-ent parts in the project process. The next part of the report, is structured as six separated chapters, 5.Planning, 6.Requirement, 7.Design, 8.Implementation, 9.Result and 10.Evaluation. The Planning chapter will cover how the project was planned and structured. Afterwards, chapters about the prestudy(i.e 6.Re-quirement) and the design approach(i.e. 7.Design) will be presented. Later the implementation of the applications is explained together with the actual result of the applications.The last part will cover the evaluation of the applications(i.e. 10.Evaluation).
After the six separated chapters, 11.Conclusion, 12.Discussion chapter and 13.Further work chapter will be presented.
Chapter 2
Related work
The development of intelligent environment systems has significantly increase for the past years. Today, almost every big company in Sweden has a sort of intelligent environment system in their environment. As mentioned in the 1.In-troduction, Gaia has developed different techniques for integration of intelligent environment systems. These systems will be described in the following chapters.
2.1
KNX
KNX is a building automation system that is often used in larger environments such as restaurants, airports and offices, but can also be used in much smaller environments, such as homes, rooms or specific objects. The usage of KNX is usually to control lights, heat, cold and ventilation but it can also control fire alarms, blinds and project screens. The important thing is that the device has a KNX certificate.
KNX was created and is own by the KNX Association[7] and became a standard 1999. The system is originally developed from three other systems, BatiBus, EIB, EHS and according to KNX homepage, the only standard for home and environment automation. The system is confirmed of the following standards
• Europe - CENELEC EN 50090 and CEN EN 13321-1 • International - ISO/IEC 14543-3
• Chinese - GB/Z 20965 • US - ANSI/ASHRAE 135
These standards implies that all the devices that have the KNX-logotype(shown in figure 2.1) are KNX certified and garanties compatibility, interaction and communication between each other but also between different suppliers. Each
Figure 2.1: This figure shows the KNX logotype which is required for a KNX certificate.
device with a KNX-logotype is programmed with the same programming tool ETS, which is KNX own programming tool.
So, why should I use KNX? The answer lies in KNX ability to controlling the environment. For example, the KNX is established in a large room with 10 lights and ventilation. After the room has been used and it is time to go home the system goes into “not active” state. This implies that KNX shuts down both the lights and ventilation for the night and waits to be active. Thus, instead of shutting down the all the systems manually every day, KNX can make the system more intelligent and efficient so that the system becomes more independent.
2.2
OPC
OLE1for Process Control(OPC), is a specified standards specification that was
created 1996 by the OPC foundation. The standard specifies the communication of real-time data between control devices from different manufactures and is usually seen as a translator between different systems. An example on OPC can be seen in figure 2.2.
2.2. OPC CHAPTER 2. RELATED WORK
Figure 2.2: This figure shows how the OPC-server is communicating as a trans-later between both the client and the device drivers.
Information visualization
The cognitive processes of the human brain can easier interpret images rather than a set of numbers. Therefore, many different visualization tools handling such information has been developed. This chapter will describe the theory behind the visualization tools used during the project.
According to Ware[10], The stages of processing data into a data visual-ization includes four basic stages, these stages can be combined in a several feedback loops depending on the interactivity of the visualization.
• Data gathering - To collect and store the data.
• Data transformations - The process of filtering out excess data in order to get an easier interpretation and manipulation in the visualization. • Visual mapping - Map the selected data into the visualization including
interactivity for the viewer to manipulate.
• User perception - The cognitive and perceptual system of the viewer. Data can be of different types, such as entities, relationships and attributes. The entity type is generally representing the object of interest and the rela-tionship type can be defined as the relarela-tionship between two entity types. For example, the enitity ’window’ can have a ’part of’ relationship to the other entity ’house’. Both entities and relationships can have attributes. Generally an attribute is something that cannot be thought of independently, e.g. width, color or number of rooms in for example a house entity, where the width, color and number of rooms are attributes to the entity house. However, the decision making concerning what is an attribute and what is an entity is not always obvious.
The data of the attributes can consist of different types of measurements. According to Stevens[9] there are four different levels of measurements, those are nominal, ordinal, interval and ratio scales. The nominal scale is a sort of
3.1. TECHNIQUES CHAPTER 3. INFORMATION VISUALIZATION
Figure 3.1: The figure illustrates the four stages in data processing labeling function that specifies objects of the same type into different groups. For example cars can be divided into a several branches. The nominal scale cannot be sorted in any natural way. Ordinal scales on the other hand is sortable and do consist of numbers in use for that specific reason. The interval scale makes it possible to define gaps of, for instance, time between two time data values. Finally, the ratio scale consist of any number and can for example help to derive whether a specific object is larger than another[10].
In visualization therms Stevens’s four levels of measurement are simplified into three data types: Category data, Integer data and Real-number data. The category data type shares the same specifications as Stevens’s nominal class. The integer data type acts like Stevens´s nominal class, since it is supposed to be discrete and ordered. And finally, the real-number data type representing the combination of Stevens´s two interval and ratio scales [10].
3.1
Techniques
Different visualization techniques can be used depending on the data to visualize in order to provide as much understanding of it as possible. The following techniques described in the sections 3.1.1 - 3.1.4 were used during this work.
Figure 3.2: The image to the left represents a choropleth map mapped with two neighbouring colors. The image to the right represents a choropleth map with a larger span of colors.
Figure 3.3: The figure illustrates the brushing technique where the selected region is colored black in both the map and the line chart.
3.1.1
Choropleth map
A choropleth map, also called pseudocoloring is the technique to represent the variation of values in a map using a color scheme, i.e. a sequence of specified colors. One common color scheme holds the colors of the whole visual spectrum of a human eye, i.e. the colors of the rainbow (blue, cyan, green, yellow, orange and red). Furthermore, according to Ware[10], the more the colors in a color scheme there are, the lower understanding concerning the meaning of the colors there will be. Therefore, by using for example two neighboring colors according to the color spectra the understanding of the meaning of the colors will increase and the efficiency of the visualization will raise. Two examples of choropleth maps can be found in figure 3.2
3.1.2
Brushing and filtering
Brushing is a technique considering representation of the same data over many different views. The technique is built on interactivity and helps the user to locate certain data of interest in the different views available. For example, one
3.1. TECHNIQUES CHAPTER 3. INFORMATION VISUALIZATION
Figure 3.4: The figure illustrates the brushing technique where the filtering is controlled through the map and only the selected region is viewed in the line chart.
Figure 3.5: The figure illustrates a tooltip example clarifying the value of the selected data item.
view is a map over regions in a country and another view is a line chart showing the number of wounded in traffic during the past years. By selecting a specific country on the map the line representing that specific country get highlighted on the line chart. The brushing technique can be used to keep the context of the visualization and to provide a focus toward the point of interest [10]. The brushing technique is shown in figure 3.3.
The filtering technique on the other hand can show/hide specific information of the context in the visualization, i.e. selection of a subset of the data. This can provide a cleaner data representation and give the user focus on only the information of interest[8]. The filtering technique is shown in figure 3.4.
3.1.3
Tooltip
As shown in figure 3.5, A tooltip can be used as a tool to provide additional information or to clarify a certain data item in a visualization. The
activa-Figure 3.6: The rectangles in the figures represents the view field of the screen. Up left panning, Up right rotating and down left zooming.
tion/deactivation of a tooltip is controlled through user interaction[11].
3.1.4
Zoom, pan and rotate
Zooming, panning and rotating can all be used as a tools to manipulate the data to visualize. According to Spence[8] zooming is the increasing magnification of a decreasing fraction of an image. So, the more zoom applied to an image the more focus, but the less context will be achieved. Panning is described as the smooth movement of a viewing frame over a 2D image. By adding rotation functionality onto these two tools, orientation of the visualization according to the user’s desire can be established. These three techniques is shown in figure 3.6.
In order to make the zooming functionality more effective it can be combined with an automatically integrated filtering functionality. The filter filters the information of the visualization depending on the zoom level applied, if the zoom state is zoomed in, detailed information will appear and vice versa. This prevents the visualization from getting cluttered and helps the viewer to gain focus on the points of interest. Concerning the navigation of a visualization, e.g. a map, zoom and pan has been proven to be a very effective combination and is currently used by Google Earth[12][8].
Chapter 4
Process theory
This chapter describes all the theory that was used during the process of the project.
4.1
Development process models
A software development process, i.e. life cycle[13] of a project usually consist of the following phases:
• Requirements analysis and definition - Gather, analyze and define the requirements of the project
• Design - Create prototypes
• Implementation - Implement the system according to the prototypes and requirements
• Testing - Test the system and design relative to the requirements • System delivery - Deliver the system
• Maintenance - maintenance of the system
These phases can be carried out in many different ways and orders depending on which process model and which method the project is using in a certain phase. One common approach is called serial development, also referred to as the waterfall model and is suitable for short and “stable” projects with static requirements[14].
The waterfall model contains goals, such as milestones and deliverables for each phase in the life cycle and states that every phase or activity of the project needs to be complete before moving on to the next one. However, the model does not forbid planning of parallel activities. According to Winston[15], the waterfall model can be improved by allowing iterations within each phase.
Figure 4.1: The figure illustrates how the different sections of a development process could be overlaped using parallel development
One disadvantage with the waterfall model is that some phases or activities can be rather time consuming and therefore lead to delays in the project since each activity needs to be complete before moving on to the next. By parallelizing different parts of a project lots of time can be earnt, this approach is called the parallel development approach, shown in figure 4.1 and is also called concurrent engineering [16].
Models suited for “unstable” projects, i.e. projects with dynamic require-ment can be so called iterative. In terms of software engineering, an iterative process is an approach of building software where the lifecycle process is sepa-rated into several iterations. Each iteration contains activities which together will compose a mini-project. An example of activities involved in a mini-project are requirements analysis, design, programming and test. The goal with itera-tive development is to get a better overview over the process by doing several iteration releases. The most iteration releases are internal which means that the system is not released to the customer. However, the final release is the complete product which is released to the customer. An example of an itera-tive process is shown in the figure 4.2. For more information about iteraitera-tive processes, please see [17].
4.2
Iterative Development in combination with
User Research
The combination of iterative development and user research has its advantages. A step in the user research can be relatively short and therefore be divided into one iteration. By examining the result of each iteration, questions related to the previous iteration may be answered and thereby provide support for the coming ones. According to Mike Kuniavsky[18], the core ideas behind iterative development can be summarized into three basic stages.
4.2. ITERATIVE DEVELOPMENT IN COMBINATION WITH USER
RESEARCH CHAPTER 4. PROCESS THEORY
Figure 4.2: The figure describes the design of a iterative development
Figure 4.3: The figure shows how the three phases examination, definition and creation of each iteration are combined with the user research methods (e.g. Contextual inquiry, focus groups etc.). The spiral depth indicates the under-standing of the users needs.
• Examination - The purpose of the examination phase of each iteration is to examine/test the result from the previous iteration, the examination will vary depending on the user research method used, e.g. testing the usability of a prototype
• Definition - The definition phase is where the result from the examination phase are considered relative to the purpose of the current user research method, e.g. reconsider and redefine the prototype based on the results given from the previous examination phase.
• Creation - During the creation phase the new definitions made in the previous definition phase are created, e.g. create a new prototype. The process of these three phases is shown in figure 4.3
4.3
Research plan
A research of a user can consist of a lot of different techniques, to ease the re-search process a rere-search plan can be carried out. The purpose of a rere-search plan is to make the user research formal by putting goals and schedule of the research down to paper. A well structured research plan prevents the research process from unnecessary, redundant or hurried research. A research plan consists of three major parts, the goals, the schedule and the budget.
• Goals - The goals are a statement of why the research is made and how it is going to be implemented.
• Schedule - The schedule declares when the different researches is going to be made
• Budget - The cost of the research
The research plan shall contain the planned techniques and outcomes of those techniques during the research process, i.e. it is a tool of keeping the user research process structured and documented. Techniques included in a research plan includes both qualitative and quantitative studies.
The sections 4.4 - 4.5 describes the studies that was made during this project.
4.3.1
Qualitative and quantitative studies
To gain understanding of the user, both qualitative and quantitative research studies can be made. A qualitative study is designed to gain a deeper under-standing and knowledge of situations and needs of the user, i.e. a qualitative study is good to do before a quantitative study in order to create questions directed to points of interest. The purpose of a quantitative study is to gener-ate measurable values, connected to each question in the study, to be able to prioritize the different question areas. Quantitative studies often include a high
4.4. REQUIREMENTS CHAPTER 4. PROCESS THEORY
Figure 4.4: The figure shows different techniques included in a user research relative to the approach and datasource affection.
4.4
Requirements
The gathering of requirements can be done in by many different methods and strategies. One method is by doing a comprehensive user research using a research plan which provides techniques for increasing the understanding of the user in many different levels[18]. This is shown in figure 4.4.
4.4.1
Interviewing
An interview session is a conversation between two or more people. The purpose of an interview is to gain qualitative information from the interviewee. In order to do that, non directed and open-ended questions shall be asked and by adding some seconds of silence after every single question, the interviewee really starts to think and interesting answers may appear [19]. Through a face to face in-terview the understanding of the inin-terviewee can be reached on a psychological level, in which can lead to valuable information.
4.4.2
User Profile
A user profile is a short textual description of a typical user. The typical user can be defined through interviews with the users. By generalizing the users into one, or if more is needed the typical user/users can be defined. To make the user profile as realistic as possible it shall be given a realistic name, a profile photo, a short personal description and some information about its technological skills, tasks at the working place, current problems and personal values. The user profile can consist of more specifics if it seems to be significant for the personalization of the profile. The aim with the user profile technique is to provide a deeper understanding of the typical user’s needs and way of thinking in to be able increase the performance and the accuracy of the development process [18].
4.4.3
Contextual inquiry
Contextual inquiry (CI) is a type of qualitative study and according to [20] it can be defined as follows “Contextual inquiry is a field data-gathering technique that studies a few carefully selected individuals in depth to arrive at a fuller understanding of the work practice across all customers. Through inquiry and interpretation, it reveals commonalities across a system’s customer base.”
In other words, CI is a way of examining how the user is working in its natural environment in order to find out weaknesses and strengths in its current way of work. By examining the user when he/she is performing tasks involved in the every day of work problems the user did not know existed can be revealed. In order to avoid unnecessary questions during the CI examination, it is important for the examiner to have insight in the domain the user are working with. To gain as much information during the CI the relationship between the examiner and the user should strive for master/apprentice where the apprentice is the CI examiner and the master the user. The task of the master is to talk aloud of what he/she is doing and try to teach the apprentice how to do the different tasks on the specific domain. The apprentice shall have the possibility to occasionally ask questions revolving what the master is doing. Important things to collect from the inquiry is, what tools are used, the sequences in which actions occur, methods of organization in the domain and what kinds of interactions they have [18].
4.4.4
Surveys
A survey is a type of a quantitative study which can be executed both analog or digitally. The survey includes a set of carefully selected open-ended questions directed towards a certain group of people, i.e. a target group. When responses are collected and analysed assumptions and results can be made. When a sur-veys is done right it can produce a higher degree of certainty than any qualitative
4.5. DESIGN CHAPTER 4. PROCESS THEORY
Figure 4.5: The figure illustrates how the fidelity of a prototype can be enhances over time.
i.e. the questions are asked to the wrong target group it can result in responses containing incorrect, inconclusive or misleading statistics [18] [19].
4.5
Design
The purpose of the design phase of a project is to generate a design of the product. Depending on what the product is, different techniques can be used in order to come to the final design. The first thing to find out is what problems exist and how should the process be for solving the problem. Techniques ap-propriate to use for that is storyboarding. When the task solving problems has been taken care of the focus should be lying on the user interface. One common way of designing user interfaces is through prototyping.
4.5.1
Storyboarding
The design of a product does not only concern the visual user interface, but also the how the tasks in the interface can be conducted. Therefore, the focus during the start of a design process should be lying on how the tasks will be be performed. A good tool for finding such a process is through storyboarding. Storyboarding is all about telling how a task can be solved through a process including, the setting, the sequence and the satisfaction leaving out the interface [19].
• Setting - Who are involved during the task, in what environment is the task performed and what the task is.
• Sequence - What steps are included in completing the task, the purpose and an explanation of it.
• Satisfaction - Motivation of the application, what the application man-ages to perform and what needs does it fill.
4.5.2
Prototyping
The process of making a successful and effective user interface can be made through prototyping. Prototyping is a tool for communicating both low fidelity and high fidelity user interfaces and interactivity to reach a final design. The process of prototyping can be executed according to two known methods. You can either produce prototypes one at a time and and gradually improving during the process (serial prototyping) or you can create several of prototypes at time and then throw away some and continue with some others during the process (parallel prototyping). According to Coursera homepage [19] parallel prototyp-ing leads to better results than serial prototypprototyp-ing.
One common way to start a prototyping process with is through paper pro-totyping. Paper prototyping is all about communicating visual and functional ideas on a basic level. A paper prototype can be mainly built by papers, post-its, pencils and tape. In order to visualize and get the feel of a prototype additional material such as cardboards can be used. Paper prototyping is a fast method of communicating ideas and get feedback from the potential user early in the process and is therefore a very effective method for generating user interfaces. The longer into the prototype process the higher the fidelity of a prototype shall be conducted. One common way of generating more advanced prototypes is through digital mockups. Digital mockups communicates through a digital medium and can be represented in both low-fidelity and high-fidelity [21].
4.6
Implementation
To process the implementation phase of a project different methodologies can be applied. One common methodology concerning software development is called agile, which is an approach specialized for software development. According to Martin Fowler and Jim Highsmith[22] the highest priority in how to satisfy the customer using agile development is through early and continuous delivery of valuable software. So, the agile approach is all about being able to adapting to changes in the requirements, involving the customer into the development process, prioritize the production of software rather than the documentation, and to lay faith into each individual that he/she will do the job well[13].
4.7. EVALUATION CHAPTER 4. PROCESS THEORY
4.6.1
SCRUM
One common agile approach is called Scrum. The people involved in a Scrum project are split up into so called Scrum teams, where each team starts every day with a short (maximum 15 minutes) daily scrum meeting where each member of the team talks about what he/she done since the last meeting, what is planned for the next meeting and if there are any problems in the way. Scrum is based on iterative development, and splits up the planning schedule into iterations, so called sprints. One sprint lasts for about 30 days, and during each sprint a set of prioritized tasks i set up to be complete before the end of the spring and each task is supposed to be complete before moving on to the next one[23][13].
4.6.2
Revision control system
According to Schmerl Bradley a revision control system can be explained as follows: “Version control (VC) is the part of CM which manages the storage of different versions of documents and controls the changes to documents to produce new versions” In other words, a revision control system is a system that keeps track of versions of files. The purpose of such a system is to increase the efficiency of parallel development and to keep track of what has been changed, who changed it and when[24].
4.7
Evaluation
The evaluation process takes part at the end of the project. The purpose of the evaluation process is to verify that the result of the project meets up with the requirements set up during the start. Depending on the result reached is mea-surable or not different strategies can be built up concerning the verification of the product. Measurable result can be tested by different types of performance tests and the unmeasurable results through evaluation processes with the cus-tomer. An evaluation process can contain techniques like surveys or interviews with questions directed towards the result of the project[11].
4.8
Maintenance
After the release of a product a maintenance phase can be applied. The purpose of the maintenance phase is to maintain the developed system in service by fixing unforeseen bugs or other crucial things that may appear during the use of the system[11]. The need for maintenance varies depending on what type of system is built. The more changeable elements of the system, the greater is the need for maintenance [13].
Planning
This chapter will cover the planning process that was conducted during the planning phase.
5.1
Process
At the beginning of the planning phase, a preliminary time report was cre-ated. The time report contained information about the overall structure of the project. The purpose of the overall structure was to get a better overview of the stakeholders and to get a better summary of the actual project. The infor-mation that was conducted during the creation of the time report was gathered from the project manager at Gaia.
After the creation of the time report, the choice of using the parallel devel-opment approach as a process model was determined. This was done by first examining the information that was conducted during the creation of the time report, by comparing different approaches against critical project stones, such as time and stakeholders.
The second part was to make sure that the parallel development approach works with the project. This was done by separating the information in the first part(i.e project stones) into different project’s assumptions and then comparing the assumptions with the approach.
• Workload - The workload will especially be focused on the investigation of the platform due to the platform has not been evaluated or developed. This implies that most of the work needs to be done at the startup phase(i.e. Requirement and Design phase) and to the project’s disposal, there will mainly be two students who will investigats and implement the project. However, for the backplane implementation, there will be help from Gaia.
5.1. PROCESS CHAPTER 5. PLANNING
• Project size - The project has a lot of stakeholders and the workload is heavy but since the project is define as a thesis work, the project needs to be limited, thus a small project(i.e not a enterprise solution).
• Time iterations - Stakeholders - The stakeholders wants to have sev-eral milestones after the prestudy phase and during the implementation. • Time iterations - Since the project’s workload is heavy and the time
period is limited, it is important to keep a structured documentation. • Time period - The time is relatively low and is planned to be around 23
weeks.
• Project stability - The project is defined as a unstable project and has the potetial of not succeeding, due to the fact that the project is a pilot project and requires alot of investigation to determine the platforms potential. • Location - Norrk¨oping
• Stakeholders - The two main users of this platform are Gaia and CNEMA AB.
The last part of the planning phase was to create a time plan for the project and by using a Gantt chart on the applied process model described in the text above, the time plan could be established. However, since the Gantt chart is basically a time scheme which requires a time estimation, the Gantt chart was time estimated and milestones were created. For more information about the time report and the Gantt chart, please see Appendix B.
Requirement
Due to the aim of the project described in section 1.5, the requirement phase in this project required lots of investigations. Ideas were needed to be created and evaluated and the user of the platform had to be analyzed. This chapter will cover all of the investigation techniques that were applied during the requirement phase. It will also cover the results gathered from the investigations.
6.1
Research plan
As mentioned in the text above, the requirement phase required alot of investi-gations and since there are many stakeholders with different roles and a limited time schedule, a research plan was conducted. The main idea of the research plan was to create a proper plan for prioritizing and organizing the user re-search, and also to define and specify the research techniques that should be applied for each main stakeholder. Notice that the research plan was planned to be executed in two phases, i.e. the requirement and the design phase. The research plan can be found in Appendix C.
6.2
Process
During the startup of the requirement phase, more stakeholders were involved in the project and since the time limit of the requirement research was short, the stakeholders were prioritized into two categories, main stakeholders and other stakeholders. The only category that was further investigated were the main stakeholders category.
• Main stakeholders - Gaia, CNEMA and Kl¨overn.
• Other stakeholders - Link¨opings university, Effektfabriken AB
6.3. GAIA CHAPTER 6. REQUIREMENT
ments for the platform, the following techniques were applied for each of the main stakeholder
• Gaia - Interviews and form. • Kl¨overn - Contextual inquiry • Cnema - Contextual inquiry
The results gathered from the study was summarized into a common docu-ment containing user profiles for each main stakeholders and requiredocu-ment spec-ification list. This was done in order to make it easier for identifying the users and to get a good structure over the specific requirements gathered through the research.
Furthermore, since the requirements were many and very different from each other, the requirements were grouped into packages where each package symbol-ized a specific idea. Thereafter, the packages were improved by creating mind maps and storyboards for each idea. This resulted in an easier way to prioritize and to understand the requirements.
The last thing that was done during the requirement phase was to prioritize the packages due to the aspect of time limit.
6.3
Gaia
During the requirement phase, two interviews were created. The purpose of the first two interviews was to gain qualitative information in order to find the genuine user(i.e. user profile) and to collect as many ideas from Gaia as possible. The purpose of the survey was gain quantitative information in order to get actual measurements on what the employees of Gaia value about the gathered ideas and what they think is relevant to the platform.
The structure of the questions asked on the interviews was constructed on three categories those were, information, functionality and service. The purpose of the categories was to make it easier to organize the requirements and to analyze each category separately and together with the other categories.
The purpose of the information category was to handle all the questions about what information should be included on the platform, e.g. information such as weather, lights, rooms etc. The next category, functionality, was meant to handle all the questions about what functionality should be applied on the platform, i.e. should the platform be able to control different mediums. The last category, services, was meant to handle all the questions about what services should be applied on the platform,e.g. services such as different faults, cleaning, error instructions etc.
The questions regarding the two earlier mentioned interviews were tested on 3 persons before each interview session in order to gain as much relevant information as possible out of the interview.
The structure of the interviews was separated into two steps. The first step was to send a neutral description of the main purpose of the application to the interviewee and the second step was to hold the actual interview. The purpose for this was to give the persons a chance to think, which hopefully would lead to a more profitable interview, without getting affected by any proposals or ideas from the description.
The survey was constructed with an importance scale between 1(not impor-tant) to 5(imporimpor-tant) for each question. The questions defined in the form was developed from the ideas created in the two first interviews.
The survey was spread out to the employees of Gaia and can be found in Appendix C.
6.4
Kl¨
overn
A qualitative study was conducted on four different departments on Kl¨overn by applying a contextual inquiry and a survey. During the study, all of the participants were first interviewed with question adapted for each department. After the interview, the participants were asked to talk about and show their work ing tasks and what they think should be relevant for such a platform described in 1.3. The last thing that was done was to ask the participants to talk about things that can be improved in their working processes. The interviews can be found in Appendix C.
6.4.1
Departments
The following departments was participating in the study • The technical department in Norrk¨oping • The technical department in Link¨oping • The managing service in Norrk¨oping • The technical department in Nyk¨oping
From the technical department in Norrk¨oping, a real estate technician re-sponsible for the real estates in the Kopparhamnen region was studied. The aim of the study was to get a insight of how the technicians works and how their work process was structured. Since the technician are the ones who work with applications in contact with the OPC-server. It is important to get their insight of what they think about the system and what data that should be available
6.5. CNEMA CHAPTER 6. REQUIREMENT
From technical department in Link¨oping, two computer engineers was inter-viewed. The aim was to get a insight of how their systems works and what their proffesional opinions is for the platform.
From the managing service in Norrk¨oping, a real estate agent responsible for the real estates in Norrk¨oping region was studied. The goal of the study was not only to get an insight of their work, but also to analyze which information that can be gathered from their systems and what information that would be relevant for the customers.
The last but not least, from the technical department in Nyk¨oping , a com-puter engineer responsible for the integration of OPC to their business was studied. The aim of the study was to get information about how they have integrated OPC in their systems and to get information on what they think is important information to give their customers.
6.5
Cnema
A qualitative study was conducted at Cnema by using the contextual inquiry and survey technique. The participant studied was a technical manager respon-sible for all the technical systems installed on Cnema. During the study, the participant was first interviewed with question adapted for Cnema. After the interview, the participant was asked to show us the environment and how the participants work. The interviews can be found in Appendix C.
6.6
Result
To give the reader a better overview of the data that was gathered from each stakeholder, the result will be separated into sections, i.e Gaia, Kl¨overn and Cnema. However, since all the ideas and requirements were specified in the requirement specification and package definition, these sections will only cover the most general information that was gathered through the research. The result chapter will also cover a summary of the common result that was defined after the requirement research was done.
6.6.1
Qualitative study of Gaia
In the first two interviews, the participants were asked to choose which device the platform should be implemented on. The device that the participant had to choose from were the following devices
• 50 inch touch screen - stationary, i.e. the device cannot move. • 13 inch touch screen - portable, i.e the device can be moved around.
Figure 6.1: This figure shows the answer distribution of the three categories relative to three age ranges. Notice how the employees(all ages) thinks that the functionality category is the most insignificant category of all the categories.
The result of the questions showed that 40% wanted a big screen rather than a small screen and the majority reason was that the big screen can visualize more information and can be seen by more than one person at the time. 40% wanted a small screen rather than a big screen since the big screen is too large and unnecessary. The remaining 20% did not know what they wanted since it was hard to imagine what information, service and functionality that should be on the platform.
6.6.2
Quantitative study
There were nine people from Gaia who participated on the quantitative study and the general result of the how they prioritized the 3 categories information, functionality and service relative to their age is shown in figure 6.1.
6.6. RESULT CHAPTER 6. REQUIREMENT
Figure 6.2: This figure shows how the result was divided through the first thir-teen questions on the survey. The first staple diagram(top) shows the mean value of each question and the second staple diagram(bottom) shows the per-centage of the importance factor for each question. Notice the second staple diagram x-axis numbers are connected to the defined questions subjects(top right).
6.6.3
Quantitative study on the categories
By examining the questions from the different categories, some interesting facts could be found. One of these was that the Gaia employees thinks that it is not important to have information about the lighing of the facility but more interesting to have relevant information about the energy consumption and the temperature. This can also be seen in figure 6.2.
Furthermore, the result also indicates that the Gaia employees are more interested in what happens on Gaia rather than how the environment or external news. This allegation can be amplified by examining the functionality category in figure 6.3.
The figure 6.3 shows that the Gaia employees believed that the most im-portant functionality that should be implemented on the platform was to book rooms. Notice that second staple diagram(bottom) indicates a certain separa-tion of the value spread.
However, by examining the service category(shown in figure 6.4), some in-teresting facts could also be found. One of these was that the service questions were more interesting than the functionality category and that the answers were
Figure 6.3: This figure shows how the result was divided through the second part of the questions on the survey. The first staple diagram(top) shows the mean value of each question and the second staple diagram(bottom) shows the percentage of the importance factor for each question. Notice the second staple diagram x-axis numbers are connected to the defined questions subjects(top right).
6.6. RESULT CHAPTER 6. REQUIREMENT
Figure 6.4: This figure shows how the result was divided through the last part of the questions on the survey, i.e. the service questions. The first staple diagram(top) shows the mean value of each question and the second staple dia-gram(bottom) shows the percentage of the importance factor for each question. Notice the second staple diagram x-axis numbers are connected to the defined questions subjects(top right).
more stable than the other categories.
6.6.4
The contextual inquiry of Kl¨
overn
These are the following results was gathered through the study described in chapter 6.4
Current problems
• Kl¨overn receives unnecessary fault reports from theirs tenants, e.g. com-plaints about temperatures in certain rooms with no specific information. • The KNX system cannot be used optimally since it’s not properly con-nected within the K7 building, e.g. to raise the temperature in the Gaia’s
office, the entire buildings temperature needs to be raised.
• The technician on Kl¨overn works like a message deliverer between the tenants and subcontractors. This problem should not exist, since e.g. Cnema with still going warranty on their technical gear already have other support. But the lack of knowledge and information makes the tenants(Cnema) turn to Kl¨overn instead of directly to the subcontractors. • Waste management, the tenants are throwing bulky refuse in the garbage
room which it is not meant for.
• Warranty issue, ongoing efficiency improvement. When a tenant declares a fault report to Kl¨overn on a item with a still going warranty, Kl¨overn rents in a third part, an entrepreneur, to come and fix the problem. This is an unnecessary task for Kl¨overn to do, if the tenant instead had a better knowledge of his/hers warranties. Kl¨overn could be left out of this task. • The current interface concerning error handling and fault reports lacks in
usability.
Possibilities for the platform
• Give the tenant more knowledge and information about the situation of the building. May decrease the misunderstandings of the systems, which in turn leads to less workload for Kl¨overn.
• Give the tenant information about what processes are active, e.g. if the tenant activate the ventilation manually, the tenants can get information about the status of the ventilation and how much time the ventilation will be activated.
• Functionality to activate systems with a corresponding counter indicating the time the system will be active.
• Visualize information about energy consumption for the entire building. • Additional services that Kl¨overn can offer, e.g. Change lamps, broadband
etc..
• Digitalize the demarcation list and connect it to the fault management system in order to increase the understanding of the tenants of the issue during a fault report declaration.
6.6.5
The contextual inquiry of Cnema
These are the following results was gathered through the study described in chapter 6.5
6.6. RESULT CHAPTER 6. REQUIREMENT
Current problems
• The complaints about the environment(i.e. temperature, carbon dioxide etc.) cannot be answered from the employees due to fact that they have no information about the environment. The only possibility for answering those questions is to call the technician on Kl¨overn.
• The machinist have no environment information about movie saloons. Thus, the machinist have no information about for example temperature, ventilation etc.
• Some of the environment systems starts automatically during inappropri-ate times without informing the employees.
Possibilities for the platform
• Visualization of temperatures in each room, especially in cinemas, but also in other spaces.
• Visualization of carbon dioxide levels in each room, especially in cinemas, but also in other spaces.
• Important to keep a correct temperature of the projectors, i.e. Stable temperature in the control rooms.
• Visualization of the energy consumption (to find out where the power goes)
• Visualization of active processes, keep track of what processes are active and not.
• Effective fault reports to Kl¨overn. Since the employees on CNEMA doesn’t know the technical name of each devices, the platform can give more specific information about each device.
6.6.6
Common result
The result of the requirement specification and requirement packages that were created after the study can be found in Appendix D. For more information about the process, see chapter 6.5.
6.6.7
User profiles
For prototyping purposes and user identification, three different user profiles were created after the interviews were applied. Each user profile is defined in the sections below.
6.6.8
Profile 1
Figure 6.5: Johan Svensson Personal description
• Name - Johan Svensson • Age - 31 year old
• Education - Master of science, Media Technology, 5 years • Work - Working approximated 40 hours per week.
• Family - Wife, two children. • Location - Lives in Norrk¨oping
Technological Johan has two computers(work, home) and a Windows 8 mobile phone that he uses, he is a so-called little technology geek. He loves new technology, however, sometimes it can go to the extreme.
Tasks Johan is working as a software engineer on Gaia system AB. He is a member in one of the scrum teams and his current task is to develop a web application for the company Rejmes.
Typical tasks that he does includes the following: • Planning the work process using TFS.
• Try to solve the work tasks that he has set up in the TFS. • Notify the TFS about tasks that he has completed.
• Time report the hours that he has worked.
During the work process, Johan has sometimes meetings with the customer where they discuss the work process and the development of the web application.
6.6. RESULT CHAPTER 6. REQUIREMENT
Figure 6.6: System value diagram
Problem Johan thinks that some of the environmental systems(i.e. KNX, OPC etc) in the office is a bit complicated and unnecessary. He believes that the systems needs a more manual approach.
Values Johan feels satisfied with working in a small company such as Gaia system AB rather at a large IT company. Concerning systems of different kinds he want one that can solve his problems but at the same time look nice and clean. Johans system value can be seen in figure 6.6
“Rather a clean interface with less functionality than a advanced system with lots of functionality that no one understands”
6.6.9
Profile 2
Company role Operation manager, Cnema Personal description
• Name - Erik Johansson • Age - 30 year old
• Education - Graphic design and communication, 3 years. • Work - Working approximated 40 hours per week, most evenings. • Family - Wife, three children.
• Location - Lives in Link¨oping but works in Norrk¨oping.
Technological Erik is a self learning person who has one computer that he uses for work purposes. He is not so interested of technology, he rather prefer to work with movies. However, by working with the cinematics, he has gained more general knowledge of the enviromental systems installed, since he wants the cinema to be a success.
Figure 6.7: Erik Johansson
Tasks Eriks work mostly consists of maintaining the cinema in shape so that the customers remains happy. Thus, his work differs from day to day, one day he can be planning the movie schedule and another day he be fixing the projector.
Problem Currently, Erik has no possibility to gain information regarding the temperature, oxygen level etc. from the systems installed in the facility. Be-cause of the lack of knowledge, Erik cannot reflect over the customer complains revolving the temperature, air and light, and this annoys him.
Values Erik prefers to work with systems that are easy to understand due to his busy schedule. He doesnt have the time to learn new systems that are complicated and he thinks that a new system should be based on that everyone should be able to understand it in a short limit of time. Eriks system value can be seen in figure 6.8
An application that can visualize all our systems can be very helpful! This can solve a lot of unnecessary problems
Just by having information about how long the ventilation will be activated, will help us!
6.6.10
Profile 3
6.6. RESULT CHAPTER 6. REQUIREMENT
Figure 6.8: System value diagram
Figure 6.9: Karin ˚Akerman Personal description
• Name - Karin ˚Akerman • Age - 29 year old
• Education - Facility manager, 3 years, Stockholm.
• Work - Working approximated 40 hours per week, most evenings. • Family - Husband, one child.
• Location - Lives in Norrk¨oping.
Technological Karin works with computers every day and is very active in public communities such as facebook, instagram etc. Karin believes it is nec-essary to be a public person, due to the profession. Karin is not a programmer but she is able to handle facility systems with ease.
Tasks Karin works as a facility manager, which includes selling and han-dling of different facilities. Her working days varies in tasks from day to day.
Figure 6.10: System value diagram
Problem Karin hates customer complaints, especially ones that are un-necessary which can be solved by the customer themselves. Karin also thinks that Kl¨overns communication with the customer is not one hundred percent perfect. There has been some several unnecessary problems with the customers of who is responsible for a specific object. She think this can be solved but she does’nt know how.
Values Karin prefers systems that are easy to use and she thinks that they can be a tool for communication. If this system should be installed on the customer side, we can maybe have a communication through that system. Karins system value can be seen in figure 6.10
6.7
Conclusion
Based on the investigations done in the requirement phase, it is clear that the Gaia employees are most interested in a platform that can show information and services rather than a platform that can control the environment. As the result shows, the Gaia employees are more interested of a platform showing information about the Gaia office and the only functionality the platform should have is functionality for solving internal problems, such as booking rooms, making fault report etc. Concerning the result from the investigation of the screen, the Gaia employees are not certain of what screen the platform should be visulized on. However, since the Gaia employees are more interested in a public platform rather than a private platform, the platform should have a central position where everyone can see it instead of a private place where only a few can see it. For Cnema, however, the case is the quite opposite. Since Cnema has a lot of environmental equipments that have lot of data that is “hidden” for the technician, the platforms aim is more about gather the environmental data and visualize it to the technician rather than solving internal problems on the platform or having a public platform where everyone can see the information. The result also indicates some problems in the relationship between Cnema and Kl¨overn and that some of these problems may be solved with the platform. Nevertheless, the platform needs to be investigated further.
6.7. CONCLUSION CHAPTER 6. REQUIREMENT
Furthermore, by applying a proper research plan and documenting all an-swers from the research that was done during the research phase, the project is now ready to be moved to the next phase, i.e. the design phase.
