EandE Requirements Specification

E&E
Economical & Ecological Requirements Specification
Abstract
Requirements specification for an innovation project that aims to show users that an
ecological travel option is not necessarily more expensive than the traditional options. To
achieve this the project provides a way to compare multiple modes of transport, for multiple
date combinations in parallel, to find the best option for the environment and the user.
Cdric Bhler, Mathieu Heer, Vithushan Mahendran,

Sandro Osswald, Roger Siegenthaler
Authors and Contributions
Name Contribu- Ideas, Concepts Parts of the Specification
tion in %
Cdric Bhler 10% 3.3 (together), 4.2 (together), 5.3
Mathieu Heer 15% 3.1.4, 4.1
Vithushan Mahendran 25% Pricing matrix for all 2.0 2.2, 3.0 3.1.3, 3.2.1 (revi-
transport providers sion), 3.3 (together), 4.2 (to-
gether), 5.2
Sandro Osswald 15% 3.2.1 3.2.2, 4.1
Roger Siegenthaler 35% Intermodal route- Document administration & Or-
finding system thography
1, 2.3, 3.2.3, 3.3 (together), 3.4,
5.1
Supervised by:
Prof. Dr. Samuel A. Fricker

Mini Project Requirements Engineering
Product Innovation
Spring Semester 2017
Requirements Specification E&E 2017-06-11

Requirements Engineering Mini Project Page 1 of 27
Revisions
Version Date Comment Author
Tem- 20-03-2016 Creation of Template Samuel Fricker
plate
0.1 19-03-2017 Product Aims & Vision, Competition Analysis, Roger Siegenthaler
Adaptation of template
0.2 27-03-2017 Team, Problem Background & Goals All
0.3 11-04-2017 Key Idea Mathieu Heer
0.4 25-04-2017 Viewpoints Sandro Osswald
Questionnaire Vithushan Mahendran
Personas Roger Siegenthaler
0.5 30-04-2017 Features, Constraints, Requirements-Engi- Cdric Bhler
neering Process, Validation & Clickable Proto- Mathieu Heer
type Roger Siegenthaler
Vithushan Mahendran
0.6 09-06-2017 Incorporation of S. Frickers Feedback, Clarifi- Roger Siegenthaler
cation of goals and resulting changes to rest Vithushan Mahendran
of document.
0.7 10-06-2017 Use Cases, Non-functional Requirements Mathieu Heer
Cdric Bhler
Sandro Osswald
0.8 11-06-2017 Finalisation Roger Siegenthaler
Vithushan Mahendran
0.9 11-06-2017 Proofreading Roger Siegenthaler
1.0 11-06-2017 Authors and Contributions Roger Siegenthaler

Table of Contents
Authors and Contributions...................................................................................................................... 1
Revisions ................................................................................................................................................. 2
Table of Contents .................................................................................................................................... 3
1 Introduction .................................................................................................................................... 5
1.1 Our Vision................................................................................................................................ 5
1.2 Our Team ................................................................................................................................ 5
1.3 Requirements-Engineering Process ........................................................................................ 6
1.3.1 Innovation ....................................................................................................................... 6
1.3.2 Verification and Documentation of Innovation .............................................................. 6
1.3.3 Elicitation and Verification of Features........................................................................... 7
1.3.4 Definition of Constraints and Requirements .................................................................. 7
2 The Problem .................................................................................................................................... 8
2.1 Background ............................................................................................................................. 8
2.2 Product goals .......................................................................................................................... 8
2.3 Evaluation of Existing Alternatives (Competition Analysis) .................................................... 9
3 Concept: E&E .............................................................................................................................. 11
3.1 Key Idea ................................................................................................................................. 11
3.1.1 Position statement ........................................................................................................ 11
3.1.2 Differentiation statement ............................................................................................. 11
3.1.3 Scenario......................................................................................................................... 11
3.1.4 Business Process ........................................................................................................... 12
3.2 Viewpoints (Stakeholder Analysis) ........................................................................................ 13
3.2.1 Onion Model ................................................................................................................. 13
3.2.2 Stakeholders.................................................................................................................. 14
3.2.3 Personas ........................................................................................................................ 16
3.3 Features ................................................................................................................................ 17
3.4 Constraints ............................................................................................................................ 18
3.4.1 Regional availability ...................................................................................................... 18
3.4.2 Operator type limitations ............................................................................................. 18
3.4.3 Hardware constraints.................................................................................................... 18
3.4.4 API constraints .............................................................................................................. 18
4 Requirements ................................................................................................................................ 19
4.1 Functional Requirements ...................................................................................................... 19
4.1.1 Get routing suggestions ................................................................................................ 19

4.1.2 Show the latest prices ................................................................................................... 19
4.1.3 Get the CO2 friendliest route ........................................................................................ 20
4.1.4 Get price comparison of different dates ....................................................................... 20
4.1.5 Choose and pay for a chosen route .............................................................................. 20
4.2 Non-functional Requirements .............................................................................................. 21
4.2.1 Performance of search .................................................................................................. 21
4.2.2 Availability ..................................................................................................................... 21
4.2.3 Usability criteria ............................................................................................................ 21
4.2.4 Security of payments .................................................................................................... 21
5 Appendix ....................................................................................................................................... 22
5.1 Glossary ................................................................................................................................. 22
5.2 Questionnaire (Persona Verification) ................................................................................... 22
5.3 Clickable Prototype ............................................................................................................... 26
6 References .................................................................................................................................... 27
6.1 Table of Figures ..................................................................................................................... 27

1 Introduction
This introduction aims to give the reader a quick overview of the team behind this document and the
idea and vision that pushed us to make it. This chapter also contains our reflection of the require-
ments engineering process.
1.1 Our Vision

Our vision is to make it easy for users to see that ecological travel options are economically competi-
tive (cheaper than more polluting options).
For travellers and tourists who are planning a trip, the cloud based solution, E&E provides inter-
modal route suggestions tailored to the users personal needs. This results in the user choosing a
more ecological option without changing his budget.
Unlike rome2rio.com and other competitors, which either use historical pricing and routing infor-
mation, have no option to compare multiple dates or only work for plane travel. Our solution pro-
vides real time pricing and routing for all transport operators, provides a way to compare multiple
travel dates and shows the ecological aspect of each option to the user.
A successful solution promotes eco-friendliness while keeping the price the same for the user.
1.2 Our Team

Cdric Bhler
He did an apprenticeship as a carpenter. After that he finished the technical

"Berufsmatura" and is now studying iCompetence in the 2nd semester. Because
of his change from a skilled trade to a totally different occupational area he has
never had any prior contact with requirements engineering.
He likes to travel and visit different countries, so he always is forced to check

multiple webpages to find the cheapest travel ticket and accommodation. That requires a lot of time
and effort. His dream is that some day in the future he can use our idea and plan his trips with E&E.
Mathieu Heer
He is studying iCompetence in the 2nd semester. He completed an apprentice-

ship as an application developer, but has little to no experience with require-
ments engineering. Environmental protection is nowadays a very important
topic, so this aspect of the idea is important to him.
Vithushan Mahendran
He is studying iCompetence in the 2nd Semester at the FHNW Brugg/Windisch.

Before that he completed college at the Kantonsschule Baden and studied Bio-
chemistry for 2 years at the University of Zurich. He has a small amount of expe-
rience in requirements engineering from his school project where he acted as
project manager, but not more so than other members. As a regular traveller
around Europe he has realised that it is very hard to find lastminute tickets to a destination and
there is no option to combine different transportation modes so that you can travel on your re-
quired date if theres no more direct connections.

Sandro Osswald
He is currently studying iCompetence at the FHNW in Brugg/Windisch. Origi-

nally, he finished college with a focus on economics, before changing his focus
to computer science. He has little to no prior experiences with requirements en-
gineering, besides witnessing it from afar during the first-year-project of the
FHNW.
He does not own a drivers license and has no plans to own a car in the coming years, so public
transportation is essential to his daily life. Every longer trip therefore requires Google maps or simi-
lar tools to plan his journeys.
Roger Siegenthaler
He is studying iCompetence in the 2nd semester, before the FHNW he com-

pleted college at the Kantonsschule Baden. He has a limited amount of experi-
ence in requirements engineering through previous projects of his own.
He has spent more time than he would like to admit searching for the best deal
on plane tickets. A little over a year ago, he discovered that train tickets for a
given trip could often be cheaper than plane tickets, while being more ecological than a flight. This
assertion gave us the foundation for our vision and idea.
1.3 Requirements-Engineering Process

1.3.1 Innovation
In the beginning our team members all brought in ideas that we looked at and analysed. After some
discussion and an informal market and competition analysis of each idea we settled on our final
choice. This choice was an inter-modal pathfinding service.
Sadly, while we were doing our competition analysis we realised that there already were such ser-
vices available. This meant we would need to pivot to a new idea, or find a new innovative feature
that would differentiate our service from the competition. With a brainstorming session using the
grouping method many new ideas were collected. Analysing and discussing the latest ideas, we
ended up with our current product. A focus on the ecological aspect of a trip was created.
1.3.2 Verification and Documentation of Innovation

A more extensive competition analysis followed, which verified that we indeed had found a market
opportunity. We also got a lot of inspiration from features we enjoyed on other services and saw
many things that we wanted to avoid.
However, our own opinion on what users wanted wasnt enough. We started a questionnaire to
elicit whether our target stakeholders also felt the same way. Our target group, students, clearly
stated that their foremost goal when searching for travel routes was not an ecological aspect but ra-
ther the cost was the deciding factor (see 5.2 Questionnaire (Persona Verification)).
After much deliberation and analysis of the results we realised that our system of combining differ-
ent travel options was also a better way to find cheaper prices versus the competition. Therefore,
the goal of our system was reformulated to be show users that ecological travel is price competi-
tive.

Having completed our innovation verification, we began formalising our documentation. The verifi-
cation gave us the foundation to formally define our product goals, stakeholders and persona.
1.3.3 Elicitation and Verification of Features

Having laid our groundwork, we began defining our features. First, we analysed existing solutions
which are already on the market and collected existing features. These were verified using
wireframes (see 5.3 Clickable Prototype) and the feedback from our tests flowed back into our
project. Our tests confirmed that most users wanted an easier usage of the existing websites but
there was not a lot that needed to be changed to appear much better.
1.3.4 Definition of Constraints and Requirements

Finally, we documented our constraints and use cases. We made sure to keep the feedback from our
two questionnaires in mind when formulating the concrete requirements. We cross-referenced our
requirements to our features and therefore to our goals making sure that our requirements fulfil our
project goals.

2 The Problem
The chapter The Problem focuses on defining the problem, showing its existence and proving that
it has not yet been solved. A part of this chapter will show why travellers and tourists need our ser-
vice E&E.
2.1 Background
CO2 emissions have been a trending topic over the last decade. Discussions over climate change have
affected everyone, for example in the form of taxes, the inflated cost of fossil fuels and other extra
charges. As a traveller, you are focused on finding the right flight at a competitive price, while the
ecofriendly aspect of the journey is neglected. You never consider anything other than a plane trip
due to economic factors. Another related issue is that route-finding services on the market do not
provide options that combine multiple different travel modes. This affects the flexibility of their algo-
rithms, resulting in suboptimal suggestions.
Imagine a user who wants to visit Amsterdam. The option, which most of her friends recommend, is
to travel by plane. Out of curiosity she also looks at other travel options to get to Amsterdam. After
an hour of research, she finds out that there are more travel options available than she thought.
Shockingly she finds out that she would save money and produce much less CO2 emissions if she
took the train. Additionally, she will have a more comfortable and relaxing trip.
2.2 Product goals

Our goals are to provide a service to users that helps them lower their travel costs (both environ-
mental and economical E&E). Below we will define our specific goals that will be used as a refer-
ence throughout our project.
Goal #G1. Lower CO2 emissions

Show users that more ecological travel options exist at the same price point for
their given search.
The goal is achieved when the user has less of an environmental impact by using
E&E vs the users traditional travel habits.
Goal #G2. Lower time spent planning
Save the user from stress by preventing the user from having to use multiple
services to plan his travel.
The goal is achieved when the user doesnt have to use multiple services to
achieve the same goal as before.

2.3 Evaluation of Existing Alternatives (Competition Analysis)
There are already many websites, apps and as of lately chatbots that have the aim of being the best
service for users planning their trips. Sadly, none of these options push the more ecological travel
options in such a way that the user can see that they are competitive in price. They either rely on
historical pricing information and are therefore seen as less trustworthy by users. Or they dont even
provide options other than travelling by plane.
Following is only a snippet of the alternatives, but for each specific example there is a list of further
services which for the purposes of this analysis fall into the same group.
Name Positive elements Negative elements

Description What can we potentially re-
Other Examples use What can we do better
Google Maps Large database of local A user cannot purchase ti-
places. Large amount of re- ckets, nor do you have any
A website by the search giant sources available to the de- pricing information. The web-
Google that allows a user to enter velopment team. site also does not combine
two places and have a route cal- different modes of transpor-
culated between the two. tation further than walking at
the beginning and public
BING MAPS, HERE WEGO, TRAVELINE, transportation.
MAPQUEST, GOEURO, FROMATOB
OpenTripPlanner These APIs can be used by No ticketing capabilities na-

other apps to provide inter- tively.
A (open source) API to consume modal path finding capabili-
transport data. Provides inter- ties. Also, most options are highly
modal route-finding capabilities. limited in their area of func-
tionality.
Navitia, Optygo, NetworkedTrav-
eller
Rome2Rio Shows many options at one Routing suggestions arent

time, and can provide intelli- calculated with actual timing
An intermodal route-finding web- gent combinations between details and pricing is only an
site, works with a world-leading all available agencies. See Er- estimate based on historic
amount of travel agencies. ror! Reference source not community reported pricing.
found.Figure 2 for an exam-
TripGo, Qixxit ple of an intermodal route. TripGo: No pricing details
other than Uber and highly
TripGo: Provides true timing limited in available regions.
for connections.
Qixxit: Only available in Ger-
Qixxit: Provides pricing and many so it doesnt have pric-
true timing. ing information for planes.
Also, prices cannot be com-
pared across different days.

Name Positive elements Negative elements
Description What can we potentially re-
Other Examples use What can we do better
Kayak Compares multiple flight des- Limited to plane travel only.
tination/departure points. Also, can only compare +/- 3
Your average flight search engine Also, provides a price matrix days to the chosen dates.
to compare different depar-
Ebookers, momondo, etc. ture/arrival dates in unison Skyscanner can compare
(see Figure 2). more than +/- 3 days but uses
cached prices from searches
by other users to achieve this.
Figure 1: An example of a price matrix of a flight search

(kayak.ch)
Figure 2: An example of a suggestion from Switzerland to

New York (rome2rio.com)
In summary, to visualise our analysis, we will compare the alternatives based on our previously
stated goals. Our team graded them on a standard school scale, from 1 to 6. A score lower than a 4
means that they did not achieve our goal in a manner usable for a user and a 1 means they do not
do so at all.
To lower the CO2 emissions (#G1) a service would need to provide routes that spanned different
transport operators and show the relevant environmental impact. To lower the time spent planning
a trip (#G2) a service had to include all relevant transport operators and provide booking options
(Qixxit manages this, but only within Germany; TripGo has the only inter-modal route finding).
5
Google Maps
4 OpenTripPlanner
3 Rome2Rio
TripGo
2
Qixxit
1
Kayak
0
Lower CO2 (#G1) Lower Time (#G2)
Figure 3: Graphical comparison of the available options on the marketplace

3 Concept: E&E
3.1 Key Idea
3.1.1 Position statement
For Travellers
Who Want to go to vacation or on a trip
The E&E Travelling Service
That Lets travellers plan a trip
3.1.2 Differentiation statement

Unlike Other solutions which have no real-time prices or connections (rome2rio), or pro-
vide services for only one transport mode (kayak).
Our solution Is a service that provides real-time prices and connection information. It contains
a way to compare all relevant transport operators and allows the user to find the
cheapest price across multiple dates (see 3.3 Features). In doing so it allows
the user to see ecological options that fall in his price range.
3.1.3 Scenario
Do you ever feel exhausted and overworked? You really need to go on vacation and you check the
internet for options. All you find are lots of different websites, but you cant quite find the best solu-
tion for yourself.
E&E helps you find the eco-friendliest and optimally tailored trip for you. Just enter a destination
and the date range in which you wish to go. You see the options, book your trip and off you go!
Figure 4: Storyboard of our main scenario (Create your own at StoryboardThat.com)

3.1.4 Business Process
Our process is simple: the user inputs his origin and destination, the period of possible departure
dates/times (optionally also return dates/times). This information is sent to our service where all
possible travel times and prices are pulled from the transportation providers. This information is
then used to calculate all possible combinations and their environmental impact. Finally, the results
are presented to the user in the most suitable order.
Figure 5: BPMN of our Business Process

3.2 Viewpoints (Stakeholder Analysis)
3.2.1 Onion Model
To visualize who our stakeholders are and in what relation they stand to our product, we use an on-
ion model. We have two distinct groups that are differentiated by how they are in contact with our
product. Our direct stakeholders are the end-users, it is these stakeholders that our product must
satisfy for the goals to be achieve. The second group contains our indirect stakeholders. These are
the people/companies from which we pull our data or on which we are otherwise dependent.
Figure 6: Onion Diagram of our Stakeholders

3.2.2 Stakeholders
3.2.2.1 Direct Contact
These are the users of our service. They are split into the 3 groups discussed above.
Name Tourists
Characterisation Tourists are users who wish to plan a trip abroad. Their reasons for travel-
ling can be for business, visiting family or wanting to go on a vacation. They
plan their trips alone, not with the use of a travel agent or another helper.
Background They use multiple websites and tools to plan their trips, which can be a
complicated and time-consuming endeavour. They use a different website
for flights and the rest of the trip.
Goals They would like to minimise their trips impact on the environment and pos-
sibly find more ecological alternatives to flying. Furthermore, they desire to
be able to plan trips in an easy and quick way, without having to juggle se-
veral websites at once to do so. They are highly cost-sensitive and a higher
cost must result in a more comfortable trip for them.
#G1 & #G2
Representatives Ourselves, David Schlebusch, Tamara Bttiker and further students.
Walkthrough #F001, #F002, #F003, #F004, #F005
Name Travellers
Characterisation Travellers are users who want to plan a short trip (within their own country
or bordering regions). They plan daytrips, short excursions or business trips.
They plan their trips alone, without the help of a travel agent or other assis-
tant.
Background They use websites and apps to plan their trips. They must use different
websites if they want to incorporate alternative modes of traveling, such as
car sharing or their own car for parts of the trip.
Goals They would like to minimise the impact of their trips on the environment,
while still arriving in a timely fashion. However, they are sometimes willing
to pay a premium for an ecological option. They would also like the ability
to combine different modes of transportation.
#G1 & #G2
Representatives Maria Schmidli, Ruth Hausmann and others.
Walkthrough #F001, #F002, #F003, #F005
Name Commuters
Characterisation Commuters are users who want to plan a repeated daily trip within their
own country.
Background Some use a website to plan their daily commute, others rely on their own
intuitiveness or on friends tips.
Goals Primarily they want to optimise their time spent travelling daily. They may
also want to make sure they can work during the commute or spend time
with friends on the way. They are unwilling to spend much time finding a
better way to get to work.
#G2
Representatives Vijayakumary Mahendran, Jan Leutwyler and ourselves.
Walkthrough #F001, #F002, #F003, #F005

3.2.2.2 Indirect Contact
Name Transport Operator (public Transportation)
Characterisation Transport operators are all companies or organisations that provide a vari-
ety of public transportation to travel from point A to point B, e.g. Bus,
Train, Tram, etc.
Background Travellers, tourists and commuters are their main target groups. Theyd like
to sell their services these groups.
Goals Gain more users through our service.
Have their service be fairly represented by our service.
Representatives SBB, A-Welle, RVBW, etc.
Walkthrough #F001, #F002, #F005 (#F004)
Name Transport Operator (private Transportation)

Characterisation Transport operators are all companies or organisations that provide a vari-
ety of private transportation to travel from point A to point B, e.g. Taxi,
Limousine, Airlines, etc.
Background Travellers and tourists are their main target groups. Theyd like to sell their
services to these groups.
Goals Gain more/new users through our service.
Have their service be fairly represented by our service.
Representatives Lufthansa, Uber, BadenerTaxi, Victor, etc.
Walkthrough #F001, #F002, #F005 (#F004)
Name Third-parties
Characterisation Third-parties are all companies or organisations that provide resources
and/or information which our product needed to satisfy our direct Stake-
holders that are not included above (for example our hosting provider).
Background -
Goals To sell us their product
Representatives Microsoft Azure, Bank, others
Walkthrough #F001 (computational power), #F002 (currency conversion), #F003 (com-
pensation certificates), #F005 (payment processor)
Name Government
Characterisation The government is the governing body.
Background Voted into power by the constituents and is charged with making their lives
better by supporting certain practices and penalising others.
Goals Wants its constituents to be as eco-friendly as possible.
Wants to reduce congestion on the roads.
Representatives The City of Baden, the Kanton of Aargau, the Swiss Federal Government,
the EU Commission, etc.
Walkthrough #F001, #F003, #F004

3.2.3 Personas
For our first version, we are focusing only on one, highly important subgroup out of our stakehold-
ers, namely an ecologically minded student looking to travel on a vacation in Europe. This is a per-
sona that represents the student subgroup of the tourist stakeholder group. It is based on our Ques-
tionnaire (see 5.2 Questionnaire (Persona Verification) for the raw data).
Hannah Jones
24 years of age; Student
Biography
Hannah is a student of biology at the University of Z-
rich. On the side, she has a job working as a barista at
a coffee-shop. She goes on holidays as often as her
studies and her wallet allow her, which results in at
least 4 trips across Europe per year. Normally she
books these online though for her trip to St. Peters-
burg she had to go through a traditional travel agent.
Motivations
get to learn many new cultures
get away from the stress of daily life
Diverse cultures have taught me so
much about myself
Goals Frustrations
Travel as no security that the cheapest price was
cheaply as possible truly found
ecologically as possible when comparing train prices, she cant
compare multiple days
poor usability of most travel websites
Personality Technology
caring Capable of basic smartphone and PC usage.
extroversive Knows how to use MATLAB to compute statis-
perceptive tics.

3.3 Features
Here are our products features as we present them to our users. They are sorted according to their
priority for our product goals and our stakeholders.
Name Routing information

ID #F001
Description Our product can get and analyse the routing and timing information of all
transportation modes.
Goals Our service will provide routing suggestions for all modes of transport
with correct connecting times.
#G1 & #G2
Costs 300 hours
Name Pricing information

ID #F002
Description Our product can get real time pricing information for all routes.
Goals Our service will be able to show the latest prices for all legs of a route.
#G1 & #G2
Costs 50 hours
Name CO2 Emission

ID #F003
Description Our webpage can sort the different travel-routes by their CO2 emissions.
It is possible to choose the CO2 friendliest way to travel. The page shows
the total amount of CO2 that a routing option produces.
Goals To show the amount of CO2 that the customer will use while travelling
and to filter the travel options by the amount of CO2 production.
#G1
Costs 75 hours
Name Price Comparison over Multiple Days

ID #F004
Description Our webpage can compare the prices for a given route on different days
making it possible to find cheaper prices by travelling a day earlier or
later than initially planned.
Goals To show the prices for the chosen route over multiple arrival and depar-
ture date combinations. The results are sortable for cheapest and most
expensive price possible.
#G1 & #G2
Costs 75 hours
Name Booking service

ID #F005
Description Our product can complete the entire booking process for the user.

Goals The user does not need to use different websites to book the individual
legs of a chosen route. The entire payment process is handled by our ser-
vice.
#G2
Costs 200 hours
3.4 Constraints
Our constraints limit what our product can do and must be adapted should new features arise or
stakeholder needs change. These constraints should also be revisited periodically to make sure they
remain correct throughout the products lifespan.
3.4.1 Regional availability

To begin with the E&E service will contain only transportation operators from within the European
countries. This is to limit the complexity of the system to begin with and the effort needed to
achieve a high coverage of transportation operators.
3.4.2 Operator type limitations

To prevent a too high engineering expenditure before going to market only public transportation
and airlines should be supported in the beginning. These two groups provide the largest benefit to
the users, especially our chosen persona. The other groups are more focussed on local travel op-
tions.
3.4.3 Hardware constraints

Our routing algorithm must be highly optimised but at the same time it is unrealistic that we can
achieve a 100% deterministic answer on a graph of our size within an acceptable timeframe. This is-
sue is primarily constrained by the underlying hardware speed available.
3.4.4 API constraints

We must use the APIs (Application Programming Interfaces) of the transport providers to gather our
data. Within Europe it is hardly possible for transport providers to restrict our access due to compe-
tition laws.

4 Requirements
Our Requirements are split according to whether they are functional or not and are appropriately
cross-referenced with the feature they fulfil.
4.1 Functional Requirements

Our functional requirements are documented as use cases and are summarised as a use case model
(see Figure 7 below).
Figure 7: Use Case Model
4.1.1 Get routing suggestions

Use-Case Get routing suggestions
ID #UC001
Feature(s) #F001
Actor User, Provider of Transportation, E&E service
Precondition The user has opened the E&E service.
Scenario 1. The user puts in their origin, desired location and time of possible de-
parture.
2. The system sends the information to E&E service.
3. Within the E&E service, the different providers are requested the
needed data.
4. The data is being send back to the system and displayed.
Postcondition The routing information is returned to the user.

4.1.2 Show the latest prices
Use-Case Show the latest prices
ID #UC002
Feature(s) #F002
Precondition The user has requested possible routes.

Scenario 1. The user chooses to show all the prices.
2. The request gets sent to E&E service.
3. The E&E service asks the providers of transportation or the latest prices.
4. The E&E service sends back the prices and they are displayed.
Postcondition The latest prices are returned to the user.
4.1.3 Get the CO2 friendliest route
Use-Case Get the CO2 friendliest route
ID #UC003
Feature(s) #F003
Scenario 1. The user puts in their origin, desired location and time of possible de-
parture.
2. The user wishes he wants to select the CO2 friendliest way.
4. Within the E&E service, the different transportation providers are re-
quested for the needed data.
5. The amount of CO2 is calculated.
6. The data is being send back to the system and displayed.
Postcondition The user sees the CO2 friendliest way and the amount of CO2.
4.1.4 Get price comparison of different dates
Use-Case Get price comparison of different dates
ID #UC004
Feature(s) #F004
Scenario 1. The user opens the price matrix.
2. The user puts in their origin, desired location and time of possible de-
parture.
4. Within the E&E service, the different providers are requested the
needed data.
5. The data is being sent back to the system and displayed in the matrix.
Postcondition A matrix of different prices is returned.

4.1.5 Choose and pay for a chosen route
Use-Case Choose and pay for a chosen route
ID #UC005
Feature(s) #F005
Precondition The user has received different routes to choose from.
Scenario 1. The user chooses the most suitable option.
2. The user chooses a payment method.
3. The information gets sent to E&E service.
4. The payment gets transferred to the involved providers.
Postcondition The booking process is completed.

4.2 Non-functional Requirements
We have two non-functional requirements. First the E&E service must be available 24h and second
the information which is requested has to be shown in less than five seconds.
4.2.1 Performance of search

When the user initiates a search with a clearly defined date the system should be able to begin pro-
ducing results within 1 second and be finished with calculations within 10 seconds.
When the user initiates a search with variable dates the system should be able to begin producing
results within 1 second and be finished with calculations within 30 seconds.
4.2.2 Availability
When the user uses the E&E service the system should be three-nines available (99.999% uptime)
and accessible without any interruption.
4.2.3 Usability criteria

When the user does a search on E&E service the system should require at the most 5 clicks for the
user to get to the results.
When the user does a search on E&E service the system should make sure that in no more than 1%
of all uses the user is unsure of what the results mean.
4.2.4 Security of payments

When the user initiates the payment procedure the system must ensure that the payments are pro-
cessed by a PCI-DSS certified provider/subsystem.

5 Appendix
5.1 Glossary
Multimodal: Search systems that provide multiple transit options without combining them.
Intermodal: Search system that does provide intermodal travel across private AND public transport.
5.2 Questionnaire (Persona Verification)

To find out how the travel behaviour of our target audience looks like, we made an online question-
naire on google forms. We shared this questionnaire in our circle of friends and posted it in social
networks. The goal was to find out the behaviour in travelling and what kind of tool they are familiar
with in the process of finding the right travel route. We had in total 52 participants which gave us a
solid validation for our requirement.
Here is the link to our questionnaire: https://goo.gl/forms/hZRSofpve0pjw6jl2
Figure 8: A snapshot of our questionnaire

Figure 9: Frequency of travel in 2016
Figure 10: Usage of public transportation
Figure 11: Influence on travel booking

Figure 12: 86% of the participant like this price matrix
Figure 13: 68% of the participant like a list of all travel possibility

Figure 14: 53% would travel ecologically
Figure 15: 93% would combine public transportations

5.3 Clickable Prototype
Figure 16: Homepage of E&E
Figure 17: Results with filter options

6 References
6.1 Table of Figures
Figure 1: An example of a price matrix of a flight search (kayak.ch) .................................................... 10
Figure 2: An example of a suggestion from Switzerland to New York (rome2rio.com) ....................... 10
Figure 3: Graphical comparison of the available options on the marketplace ..................................... 10
Figure 4: Storyboard of our main scenario (Create your own at StoryboardThat.com)....................... 11
Figure 5: BPMN of our Business Process .............................................................................................. 12
Figure 6: Onion Diagram of our Stakeholders ...................................................................................... 13
Figure 7: Use Case Model..................................................................................................................... 19
Figure 8: A snapshot of our questionnaire ........................................................................................... 22
Figure 9: Frequency of travel in 2016 ................................................................................................... 23
Figure 10: Usage of public transportation ............................................................................................ 23
Figure 11: Influence on travel booking ................................................................................................. 23
Figure 12: 86% of the participant like this price matrix ........................................................................ 24
Figure 13: 68% of the participant like a list of all travel possibility ...................................................... 24
Figure 14: 53% would travel ecologically .............................................................................................. 25
Figure 15: 93% would combine public transportations ....................................................................... 25
Figure 16: Homepage of E&E ................................................................................................................ 26
Figure 17: Results with filter options .................................................................................................... 26


EandE Requirements Specification

Uploaded by

Copyright:

Available Formats

You might also like

EandE Requirements Specification

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EandE Requirements Specification

Uploaded by

Copyright:

Available Formats

E&E

Economical & Ecological Requirements Specification

Cdric Bhler, Mathieu Heer, Vithushan Mahendran,

Prof. Dr. Samuel A. Fricker

Spring Semester 2017

Requirements Specification E&E 2017-06-11

Requirements Specification E&E 2017-06-11

Requirements Specification E&E 2017-06-11

Requirements Specification E&E 2017-06-11

1.1 Our Vision

1.2 Our Team

He did an apprenticeship as a carpenter. After that he finished the technical

He likes to travel and visit different countries, so he always is forced to check

He is studying iCompetence in the 2nd semester. He completed an apprentice-

He is studying iCompetence in the 2nd Semester at the FHNW Brugg/Windisch.

Requirements Specification E&E 2017-06-11

He is currently studying iCompetence at the FHNW in Brugg/Windisch. Origi-

He is studying iCompetence in the 2nd semester, before the FHNW he com-

1.3 Requirements-Engineering Process

1.3.2 Verification and Documentation of Innovation

Requirements Specification E&E 2017-06-11

1.3.3 Elicitation and Verification of Features

1.3.4 Definition of Constraints and Requirements

Requirements Specification E&E 2017-06-11

2.2 Product goals

Goal #G1. Lower CO2 emissions

Requirements Specification E&E 2017-06-11

Name Positive elements Negative elements

OpenTripPlanner These APIs can be used by No ticketing capabilities na-

Rome2Rio Shows many options at one Routing suggestions arent

Requirements Specification E&E 2017-06-11

Figure 1: An example of a price matrix of a flight search

Figure 2: An example of a suggestion from Switzerland to

Figure 3: Graphical comparison of the available options on the marketplace

Requirements Specification E&E 2017-06-11

The E&E Travelling Service

That Lets travellers plan a trip

3.1.2 Differentiation statement

Figure 4: Storyboard of our main scenario (Create your own at StoryboardThat.com)

Requirements Specification E&E 2017-06-11

Figure 5: BPMN of our Business Process

Requirements Specification E&E 2017-06-11

Figure 6: Onion Diagram of our Stakeholders

Requirements Specification E&E 2017-06-11

Requirements Specification E&E 2017-06-11

Name Transport Operator (private Transportation)

Requirements Specification E&E 2017-06-11

Requirements Specification E&E 2017-06-11

Name Routing information

Name Pricing information

Name CO2 Emission

Name Price Comparison over Multiple Days

Name Booking service

Requirements Specification E&E 2017-06-11

3.4.1 Regional availability

3.4.2 Operator type limitations

3.4.3 Hardware constraints

3.4.4 API constraints