Software Requirements

Specification

for

Airline Ticket Reservation

Version 4.0 approved

Prepared by Elchin Aghazada, Faig Jafarguliyev, Ilkin Aghayev,

Vusala Shikhaliyeva

December 16, 2018

Table of Contents
Document Version Control..…………...………………………………. ​ 3
Requirements Version Control………………………………………... ​ 4
1 Introduction………………………………………………………. ​ 5
1.1 Purpose……………………………………………………………. 5
1.2 Document Conventions………………………………………….. 5
1.3 Intended Audience……………………………………………….. 5
1.4 Product Scope……………………………………………………. 5
1.5 Reference Documents…………………………………………… 5
1.6 Overview………………………………………………………….. 5
2 Overall Description​ …………………………………………….. 7
​
2.1 Product Perspective….………………………………………….. 7
2.2 Product Functions……………………………………………...... 7
2.3 Use-case Diagram……………………………………………… 8
2.4 User Classes and Characteristics……………………………… 14
2.5 User Interests……………………………………………………... 14
2.6 Operating Environment………………………………………….. 14
2.7 Design and Implementation Constraints………………………. 14
2.8 User Documentation…………………………………………….... 14
2.9 Assumptions and Dependencies………………………………… 14
3 Requirements and Goal Modelling​ …………………………… 15
​
3.1 Goal Modelling……………………………………………………. 15
3.1.1 Strategic Dependency Model…………………………… 15
3.1.2 Model of software-intensive system…………………….. 17
3.1.3 Goal and Agent Responsibility Model…………………… 18
3.2 Requirements Modelling…………………………………………. 21
3.2.1 Scope……………………………………………………….. 21
3.2.2 Booking a Flight……………………………………………… 21
3.2.3 State Models……………………………………………….. 22
3.2.4 Ticket Booking Process……………………………………. 24
4 Specific Requirements………………………………………...​ ​ 25
4.1 External Interface Requirements………………………………. 25
4.1.1 User Interfaces………………………………………….. 25
4.1.2 Hardware Interfaces……………………………………. 25
4.1.3 Software Interfaces…………………………………….. 25

1
 4.1.4 Communication Interfaces…………………………….. 26
4.2 Functional Requirements…………………………………….. 26
4.3 Software System attributes…..………………………………. 27
4.4 Nonfunctional Requirements………………………………… 28
4.4.1 Performance Requirements…………………..………… 28
4.4.2 Reliability Requirements………………………………… 28
4.4.3 Security Requirements...……………………………….. 28
4.4.4 Maintainability Requirements………………………….. 28
4.4.5 Portability Requirements……………………………….. 28
4.4.6 Safety Requirements……………………………………. 28
4.4.7 Other Requirements…………………………………….. 29
4.5 Solution-oriented Requirements…………………………….... 29
4.5.1 Class diagram requirements…………………………… 29
4.5.2 State diagram requirements…………………………….. 29
4.5.3 Sequence diagram requirements……………………….. 29
4.6 System Features……………………………………………….. 30
4.7 Requirements Prioritization……………………………………. 31
4.7.1 MoSCoW Method………………………………………… 31
4.7.2 Prioritization According to Cost………………………… 32
4.7.3 Prioritization According to Value………………………. 33
4.7.4 Plot ROI Graph.…………………………………………… 35
4.7.5 Hierarchical Prioritization.……………………………….. 36
4.8 Requirements Traceability…………………………………….. 37
4.8.1 Traceability Matrix……………………………………….. 38
4.8.2 Traceability Model……………………………………….. 38
5 Prototype ​……………………………………………………….. 40
Appendix A: Glossary​​……………………………………………….. 41

2
Document Version Control:

Full Date Change comments New Previous

name version version

Team 11.10.2018 Initial version V1.0 NA

6

Team 17.10.2018 Requirements prioritization according to V1.1 V1.0

6 value, ROI plot graph, prioritization
attributes, traceability model, traceability
attributes are added

Team 10.11.2018 Non-functional requirements are upgraded, V2.0 V1.1

6 strategic dependency model is constructed,
traceability model is upgraded, system goal
modelling is performed

Team 19.11.2018 Non-functional requirements are traced, V2.1 V2.0

6 strategic dependency model and KAOS
models are upgraded, software intensive
system model is introduced, use case
diagrams are upgraded

Team 03.12.2018 Scope of the main problem is defined, class V3.0 V2.1
6 diagram, state models, solution-oriented
requirements are extracted and documented
by being grouped into system features,
traceability model is upgraded

Team 09.12.2018 Class diagram is updated, scope is refined, V3.1 V3.0

6 state diagrams are updated, sequence
diagram is constructed, solution-oriented
requirements are updated

Team 16.12.2018 Sequence diagram is updated, scope is V4.0 V3.1

6 refined, prototype is built

3
Requirements Version Control:

Full Date Change comments New Previous

name version version

Team 11.10.2018 Initial specification of requirements V1.0 NA

6

Team 17.10.2018 Refining initial requirements according to V1.1 V1.0

6 criteria of good requirements

Team 10.11.2018 Non-functional requirements are upgraded V2.0 V1.1

6

Team 19.11.2018 Non-functional requirements are traced, V2.1 V2.0

6 performance, reliability, security, portability,
maintainability requirements are upgraded

Team 03.12.2018 Solution-oriented requirements are extracted V3.0 V2.1

6 and documented by being grouped into
system features

Team 09.12.2018 Solution-oriented requirements are updated V3.1 V3.0

6

Team 16.12.2018 Solution-oriented requirements are refined V4.0 V3.1

6 according to criteria of good requirements

4
Introduction
1.1 Purpose
This document lists the requirement specifications for an Airline Ticket Reservation System
(ATRS). The document is subject the change as the project progresses. The given version of the
document is the initial one. Further changes of the project will be recorded to the document.

1.2 Document Conventions

The document is formatted according to IEEE standard.

1.3 Intended Audience

The intended audience for this document consists of requirements engineers, software
developers, designers, testers and project manager.

1.4 Product Scope

Subject facet:​User Interface, Searching one-way flights, Searching round trip flights, Searching
multiple destinations, Flight reservations, Reservation cancellation, Online payment, Request
and response for reservation cancellation, Displaying warning messages.
Usage facet:​Searching, Sorting of flights, Reservation of tickets, Managing existing reservation,
Managing flight details, Keeping the flights up to date.
IT facet: D
​ atabase, Web-based software system, AAS for logins, Performance maintenance.
Development facet:​Internal policy and culture of the airlines company should be taken under
consideration.

1.5 Reference Documents

1. Naveed Ali, Richard Lai, A method of software requirements specification and validation for
global software development, June 2017, Volume 22, Issue 2, pp 191–214
(​[Link]
2. Lecture slides.
3. Luke Paireepinart, David Keyes, Jingtao Liu, Frank Medjo and Seth Orell, Software
Requirements Specification for Airline Flight Booking System, February 2009
(​[Link]
Booking_System_Software_Requirements_Specification_for_Airline_flight_booking_system​)
4. ​[Link]

1.6 Overview
The remaining part of the specification document is organized as follows.

5
● Section 2 defines overall description of the system which defines product perspectives
and functions, use-case diagrams, classes and characteristics of involved users, the
environment that the system is going to be deployed, constraints on design and
implementation of the system, user documentation, assumptions and dependencies.
● Section 3 focuses on requirements and goal modelling. Strategic dependency model,
model of software-intensive system, goal and agent responsibility model are used to
model goals, while class diagram, state models and sequence diagram are constructed to
model requirements.
● Section 4 contains all the specific requirements such as functional requirements,
performance requirements and external interface requirements, which in turn includes
user, software, hardware and communication interface requirements. Attributes of the
software system and nonfunctional requirements are also specified in this section.
Solution-oriented requirements extracted from requirements modelling part are
documented in this section.
Prioritization and traceability of requirements are also included in Section 4.

6
2. Overall Description
2.1 Product Perspective
ATRS is the digitized version of the traditional manual reservation system at the airline office.
Existing manual system requires every customer to come to the airline office in order to make a
booking. Apart from the fact that not all customers have time to come to the office, existing
system also causes long queues at the office. Some customers get bored from waiting in the
queue and airline loses its potential customers.
In addition to that, a hard copy of the passport is required during the reservation at office.
Customers who are not able to present their passports at the office for whatever reason cannot
make reservations.
The new system aims to overcome the above-mentioned drawbacks of the existing system. It will
allow users to make reservations according their needs from different parts of the world without
leaving their places. Furthermore, it will reduce the workload of the employees who are
responsible to make reservations at the office.
The system allows customers to check the availability of flights for specific dates and routes, get
information about durations of available flights. It also allows customers to check the prices and
the things that are included in the ticket such as baggage allowance, meal and etc. and booking
the ticket. Administrator can modify, remove existing flights, also add new flights to the system.
Furthermore, administrator can see customer requests about cancellation of bookings, and decide
whether to accept and reject them.

2.2 Product Functions

The system will have 10 functionalities for customers and administrators and they are listed
below.

2.2.1 Search for flights

Description: Using this function a customer is able to search for one-way, round-trip and
multiple destination flights by choosing specific dates and destinations.

2.2.2 Specify passengers

Description: With the help of this function customer selects the number of passengers and their
category, either adult, child or infant.

2.2.3 Sort flights

Description: Regarding to this functions, customer sorts flights either by price or duration of the
flight.

7
2.2.4 Book flights
Description: This function allows customer to book flights by choosing ticket types and
processing online payment.

2.2.5 Request cancellation

Description: This function indicates that customer can request the cancellation of the reserved
ticket.

2.2.6 Add new flights

Description: The function grants administrator the privilege of adding new flights to the system.

2.2.7 Modify flight details

Description: Using this functionality administrator can modify the details of the existing flights.

2.2.8 Remove flights

Description: With the help of this function administrator removes the flights from the system that
are cancelled for whatever reason.

2.2.9 See cancellation requests

Description: This functionality allows administrator to overview the cancellation requests of
customers, and approve or reject them.

2.2.10 See booking details

Description: This functionality enables administrator to view the customers’ booking details.

2.3 Use-case Diagram

Description: ​In the use case diagram given below, we have displayed how our users interact
with the system to accomplish their goals and responsibilities. Here in our diagram we have 4
actors (Customer, Administrator, Support Staff, Bank), 3 of which are the main users (Customer,
Administrator, Support Staff). In every use case mentioned in the diagram, the actions of the
users are described, and how these use cases are related to one another is represented by the help
of arrows. In our Use case diagram all functionalities of the system are displayed. Customer can
search for flights based on dates and destination, flights being one-way or round-trip, sort the
displayed flights according to price or duration, specify the passengers (how many adults,
children or infants), request cancellation, book flight, choose the ticket type and proceed with the
payment. The payment is processed by the Bank. Another actor, Administrator, is responsible for
adding new flights, modifying flight details and removing flights if needed, see the cancellation
request, approve or deny them and see booking details. Our final actor, Support Staff, is

8
responsible for maintenance of the system, ensuring the security of the system (by creating
predefined users and maintaining AAS), safety of the system (by restoring and recovering data
and assuring data integrity) and reliability of the system (by maintaining SLA).

Figure 1.​​Use case diagram

9
 Use Case ID: 01

Use Case Name: Search for flights

Created By: Ilkin Aghayev Last Updated By:

Date Created: 9/11/2018 Date Last 9/11/2018

Updated:

Actor: Customer

Description: Customer searches for the flights on specific dates

Frequency of Use: 1

Preconditions: Customer should have internet connection and be able to

access to the website

Postconditions: System displays the list of all available flights on a chosen date

Normal Course of Events: 1. Customer enters airline’s website

2. Customer chooses the specific date
3. System displays the flights on a given date

Alternative Courses: NA

Exceptions: System may not be available

Includes: Search for one-way, Search for round-trip, search for multiple
destinations.

Assumptions: System is available

Notes and Issues: NA

Use Case ID: 12

Use Case Name: Sort flights

Created By: Elchin Aghazada Last Updated By:

10
 Date Created: 10/11/2018 Date Last Updated: 10/11/2018

Actor: Customer

Description: Customer wants to sort flights.

Normal flow: 1. Customer enters airline’s website

2. Customer searches for flights
3. System displays the list of available flights
4. Customer chooses to sort the list of flights either by price or
the duration of flight.
5. System displays the sorted list of flights

Preconditions: System has displayed the list of available flights based on customer’s
query

Customer is displayed the sorted list of flights according to his/her

Postconditions: sorting criteria

Frequency of Use: 1

Normal Course of Customer chooses to sort the flights according to price or flight
Events: duration on the system.

Alternative NA
Courses:

Exceptions: System may not be available

Includes: Sort by price, Sort by duration

Assumptions: System is available, There are available flights according to

customer’s search criteria

Notes and Issues: NA

Use Case ID: 20

11
Use Case Name: Payment

Created By: Vusala Shikhaliyeva Last Updated By:

Date Created: 10/11/2018 Date Last 10/11/2018

Updated:

Actor: Customer

Description: Customer proceeds with the payment of the booked flight.

Frequency of Use: 1

Preconditions: Customer has selected the available flight and ticket type of
his/her choice

Postconditions: Customer has booked the flight and paid for the ticket(s)

Normal Course of Events: 1. Customer clicks “Book Now” button

2. System asks the customer to enter card details as
default
3. Customer enters the card details
4. Customer clicks “Make Payment” button
5. System handles the payment
6. System displays the confirmation of the payment
7. System sends an invoice to customer’s email

Alternative Courses: Customer chooses to pay with PayPal.

Exceptions: System may not be available.

Includes: Manually by card, PayPal

Assumptions: System is available, Customer has enough funds for the

payment

Notes and Issues: NA

Use Case ID: 25

12
 Use Case Adding new flights.
Name:

Created By: Faig Jafarguliyev Last Updated By:

Date Created: 10/11/2018 Date Last 10/11/2018

Updated:

Actor: Administrator

Description: Administrator adds new flights to the system.

Normal flow: 1. Administrator enters the website.

2. Administrator logs in to the admin panel.
3. Administrator adds details about new flights to the
system.
4. Administrator submits the addition of the new flights to
the system

Preconditions: Administrator successfully logs in to the system

Postconditions: The information about new flight can be displayed for

respective queries

Frequency of Use: Once in 6 hours.

Normal Course of Administrator logs in to the system and adds/modifies

Events: flights at the system.

Alternative Courses: NA

Exceptions: System may not be available, Administrator may fail to log

in.

Includes: NA

Assumptions: Administrator is able to access the system.

Notes and Issues: NA

13
2.4 User Classes and Characteristics
The system users are divided into three categories: administrators, customers and support staff.
Administrators should be trained and have a knowledge about using this application. On the
other hand, customers do not need a training or a background knowledge. Support staff consist of
of specialists who have good analytical and problem solving skills, up-to-date technical
knowledge, good interpersonal and customer care skills.

2.5 User Interests

Customers’ interests are getting information about available flights of specific dates and routes,
knowing their durations, checking the prices of the tickets. They are also interested in what are
included in different ticket types in terms of whether the ticket is refundable, include meal, what
is the baggage limit for each type of ticket. Moreover, customers concern about booking flights
without leaving the places where they are.
Administrator’s interests include modifying, removing existing flights and adding new flights to
the system. Furthermore, administrator can manage customers’ cancellation requests in terms of
either accepting or rejecting them.
Support staff’s duties are maintaining performance, ensuring security and reliability of the
system, alongside controlling AAS in terms of predefining administrator passwords, adding new
administrator customized passwords to the system, and granting them administrator privileges.

2.6 Operating Environment

The designed system is thought to be a website and will be available via any web-browser
application. It will not be dependent on the technical capabilities or operating system of user’s
device.

2.7 Design and Implementation Constraints

Flight dates and hours should be displayed according to the city of departure and destinations’
time zones and the daylight saving time settings for each country should be considered.
Additionally, information about any changes that are made in the database should be displayed
with no delay.

2.8 User Documentation

The instructions on how to book a flight will be provided on the website for inexperienced users.

2.9 Assumptions and Dependencies

It is assumed that the user has an internet access and can do online payments. The performance
of ATRS depends on the quality and speed of the internet connection.

14
3. Requirements and Goal Modelling
Goal Modelling
3.1 ​
3.1.1 Strategic Dependency Model

Figure 2. ​Strategic Dependency Model

Below given table explains the way how Strategic Dependency Model should be
read:

ID Description of Figure 2

G1.1 In order to see acceptance message of successful payment customers are dependent
on technical authority

G1.2 Customers are dependent on technical authority for customer interface

G1.3 Customers are dependent from technical authority on online payment

G1.4 For portability of the system in terms of being manageable in multiple browsers
customers are dependent on technical authority

G2.1 Administrators are dependent on technical authority for administrator interface

15
G2.2 Administrators are dependent on technical authority for access to database

G3.1 Administrators are dependent on support staff for predefined passwords

G3.2 In order being able to login with predefined passwords administrators are dependent
from support staff

G3.3 In order to see warning messages administrators are dependent from support staff

G3.4 To change their predefined passwords administrators are dependent from support
staff

G4.1 Customers are dependent on safety of communication channel from support staff

G4.2 Customers are dependent from support staff for fulfilment of SLA of 98%

G5.1 Customers are dependent on modification of details of existing flights from

administrators

G5.2 Customers are dependent on addition of new flights to the system from
administrators

G5.3 Customers are dependent from administrators on removal of cancelled flights from
the system from administrators

G6 Customers are dependent from bank on making payments

16
3.1.2 Model of software-intensive system

Figure 3. ​
Software-intensive system model
Below given table explains how ​Figure 3 ​should be read:
ID Description of Figure 3

T1.1 ATRS depends on administrator to add new flights

T1.2 ATRS depends on administrator to modify flights flight details

T1.3 ATRS depends on administrator to remove flights

T1.4 ATRS depends on administrator on management of cancellation requests

T1.5 Administrator depends on ATRS to display cancellation requests

T2.1 ATRS depends on customer’s query to search for flights

17
T2.2 ATRS depends on customer’s request to book the ticket

T2.3 ATRS depends on customer’s request to sort the flights

T2.4 ATRS depends on customer for specification of passengers

T2.5 Customer depends on ATRS to display information about flights

T3.1 ATRS depends on support staff to maintain performance of the system

T3.2 ATRS depends on support staff to ensure security of the system

T3.3 ATRS depends on support staff to ensure safety of the system

T3.4 ATRS depends on support staff to ensure reliability of the system

T4.1 Bank depends on ATRS to fetch the card details of customer to handle the
payment

T4.2 ATRS depends on bank to process the payment

3.1.3 Goal and Agent Responsibility Model

18
 Figure 4. ​KAOS Model 1
Below given table explains the way ​
Figure 4 s​hould be read:
ID Description of Figure 4

G1 Customer wants to book a flight

G2 Customer searches for flights

G3 Customer searches for one-way flights

G4 Customer searches for round trip flights

G5 Customer searches for flights of multiple destinations

G6 Customer specifies departure date of flight

G7 Customer specifies both departure and arrival dates of flight

G8 Customer specifies destinations for flight

G9 Customer wants to sort flights

G10 Customer wants to sort flights respect to price

G11 Customer wants to sort flights respect to duration

G12 Customer wants to make payment to book the flight

G13 Customer wants to choose ticket type to make payment

G14 Customer chooses ticket of Premium type

G15 Customer chooses ticket of VIP type

G16 Customer chooses ticket of Standard type

G17 Bank wants to handle payment

G18 Bank wants to handle payment made manually by credit card

G19 Bank wants to handle payment made by PayPal method

19
 Figure 5. ​
KAOS Model 2
Below given table explains the way ​
Figure 5​should be read:
ID Description of Figure 5

G1 Administrator uses AAS

G2 Administrator uses AAS to perform administrative tasks

G3 Administrator wants to remove cancelled flights from the system

G4 Administrator wants to manage customers’ cancellation requests

G5 Administrator wants to add new flights to the system

G6 Administrator wants to modify details of existing flights

G7 Customer specifies both departure and arrival dates of flight

20
 G8 Administrator uses AAS to ensure security of the system

G9 Administrator wants to restrict non-administrative users’ access to the system

3.2 Requirements Modelling

3.2.1 Scope
Scope for our diagrams is focused on the implementation of Use Case ID 15, to customer
booking a flight.
3.2.2 Booking a Flight

Figure 6. ​
Booking a flight
Description: ​Customer class contains information about customers, such as their full names,
locations, card details and genders. Operations performed by customers via interactions with
administrator, bank, flight and flight tickets are contained in the respective part of the Customer
class. Administrator class, on the other hand contains the data about the administrator (name and
account details) and the operations he/she performs on the system. It relates to customer on
approving or rejecting the cancellation requests made by the customer. Flight class is another key
class in our diagram and contains information about flight such as destination and origin city,
flight date, time and duration, number of seats and flight’s availability. Ticket class is also
21
essential for our diagram and contains the full name of the customer that it belongs to. It has its
own unique ID, price and type, which expands to Standard, Premium or VIP class tickets. The
last class in the diagram belongs to Bank and as operations its payment processing and receipt
generating functions are specified.

3.2.3 State Models

Description: ​As visible in class diagram, administrator can add or remove flights to the system.
In state diagrams these functionalities displayed as finite states. In first diagram, administrator
gets information about a new flight, adds the flight to the system and it is visible to the rest of the
users of the system. Second one displays administrator being informed of cancelled flight,
removing it and checking whether it is still available on the system. In third diagram, booking
flight and making payment functionalities of customer are explained. Here, customer books a
flight, he/she is asked to proceed with payment, and the process is finished if customer has
enough fund to make payment. In the last diagram bank handles the payment made by the
customer. Bank receives information about the payment, processes the payment and generates
the receipt.
1.1 SD_1 Administrator state

Figure 7. ​
Adding new flight

22
1.2 SD_2 Administrator diagram

Figure 8. ​
Removing existing flight
1.3 SD_3 Bank statement

Figure 9. ​
Processing payment

23
1.4 SD_4 Customer state

Figure 10. ​
Paying for booking

3.2.4 Ticket Booking Process

Description:​​In sequence diagram we have displayed how the objects of classes interact with
each other throughout the customer’s ticket booking process.

24
4. Specific Requirements
4.1 External Interface Requirements
4.1.1 User Interfaces
[Link]​​ATRS should have a customer user interface.
[Link] ATRS should have an administrator user interface.
[Link] Customer user interface should have a graphical user interface (GUI).
[Link] Administrator user interface should have a GUI.

4.1.2 Hardware Interfaces

No hardware interface is required for the Airline Ticket Reservation system​.

4.1.3 Software Interface​​s

[Link] ATRS should be a web-based system.
[Link] It should be possible to open and use the website on the computers with operating
systems of Microsoft 7, Microsoft 8, Microsoft 10, Mac Os, Linux, Ubuntu.
[Link] Oracle Database 12C should be used to store the data about flight details.
[Link] Oracle Database 12C should be used to store the data about users.

25
4.1.4 Communication​​​Interfaces
[Link] HTTP protocol should be used as an interface of communication between client and
server sides.

4.2 Functional Requirements

4.2.1 Customer should be able to search flights for a specific date for one-way trips.
4.2.2 Customer should be able to search flights for specific dates for round trips.
4.2.3 Customer should be able to search flights for multiple destinations.
4.2.4 Customer should be able to manually enter the names of departure and arrival cities.
4.2.5 Customer should be able to select the names of departure and arrival cities from the list of
all flight offered cities.
4.2.6 Customer should be able to specify the number of adults from 1 to 6 while searching for a
flight.
4.2.7 Customer should be able to specify the number of children from 0 to 6 while searching for
a flight.
4.2.8 Customer should be able to specify the number of infants from 0 to 3 while searching for a
flight.
4.2.9 Customer should be able to specify the travel class while searching for a flight.
4.2.10 Customer should be able to select the currency while searching for a flight.
4.2.11 Customer should be able see all the possible flights based on the information he entered.
4.2.12 Customer should be able to sort the list of possible flights by price.
4.2.14 Customer should be able to sort the list of possible flights by flight duration.
4.2.15 Customer should be able to select the type of the ticket.
4.2.16 Customer should be able to change the date of the booked ticket without paying extra
money if the booked ticket is type of VIP.
4.2.17 Customer should be able to change the date of the booked ticket by paying extra money if
booked ticket is type of Premium.
4.2.18 Customer should not be able to make any changes on the booked ticket if the latter is type
of Standard.
4.2.19 Customer should be able to request reservation cancellation.
4.2.20 Customer should be able to see given response to reservation cancellation request.
4.2.21 System should allow a customer to specify only departure date for one-way trips.
4.2.22 System should allow a customer to specify both departure and arrival dates for round
trips.
4.2.23 System should provide the list of possible flights matching criterion of user inputs.
4.2.24 System should allow customer to book the ticket to a flight of his choice.
4.2.25 System should allow customer to book tickets for maximum of 6 people.

26
4.2.26 System should demand customer to provide his/her full name to book the ticket.
4.2.27 System should demand customer not to enter numbers for full name label.
4.2.28 System should demand customer to provide his/her number of travel document to book
the ticket.
4.2.29 System should demand customer to enter only characters for full name label.
4.2.30 System should demand customer not to enter specific characters for travel document
number label.
4.2.31 System should demand customer to choose the payment method.
4.2.32 System should offer payment via manually manually entering card details as default
payment method to customer.
4.2.33 System should be able to handle payments done by the customer via PayPal.
4.2.34 System should be able to process the payments done by the customer via manually
entering the card details.
4.2.35 Provided list of flights should contain information about duration of flight for each flight.
4.2.36 Provided list of flights should contain information about price in chosen currency for each
flight.
4.2.37 Provided list of flights should illustrate the exact hours of departure and arrival for each
flight.
4.2.38 Provided list of flights should contain information about departure and arrival airport
names for each flight.
4.2.39 Flight offered cities should be grouped respect to the continents they are located.
4.2.40 Types of the tickets should be classified as Standard, Premium and VIP.
4.2.41 Administrator should be able to add new flights to the system.
4.2.42 Administrator should be able to modify the details of existing flights.
4.2.43 Administrator should be able to remove cancelled flights from the system.
4.2.44 Administrator should be able to see reservation cancellation requests.
4.2.45 Administrator should be able to accept reservation cancellation requests.
4.2.46 Administrator should be able to reject reservation cancellation requests.
4.2.47 Administrator should be able to see details of existing bookings.

4.3. Software System Attributes

4.3.1 Usability
[Link] Non-technical background of a user should not be an obstacle to understand and use the
system.
4.3.2 Robustness
[Link] System should be able to display the most recent inquiry by the user in case of
refreshment of page after sudden connection lost.
4.3.3 Consistency

27
[Link] Number of available seats for specific flight should be decreased by 1 unit once a
transaction of the payment for the flight ticket is made.

4.4 Nonfunctional Requirement​

​
s
4.4.1 Performance Requirements
[Link] System should be able to handle 1000 transactions per second. [4.2.21 - 4.2.30]

4.4.2 Reliability Requirements

[Link] System’s Service Level Agreement (SLA) level should be of 98%. [4.2.1 - 4.2.20]
[Link] Maximum 2 of 1000 online payment transactions through the systems can result in
failure. [3.2.31-3.2.34]

4.4.3 Security Requirements [4.2.41 - 4.2.47]

[Link] System should have an Authentication and Authorization System (AAS) for logins.
[Link] System should grant administrative privileges only to the one who logins with predefined
administrative username and password.
[Link] System should allow administrator to change his/her system-generated password as
he/she wishes.
[Link] System should allow administrator to login with customized password.
[Link] System should block access to one who fails to login three time in a row.
[Link] System should guarantee the security of communication channel.
[Link] Customized password should be at least 8 characters.
[Link] Customized password should contain both letters and numbers.

4.4.4 Maintainability Requirements [4.2.35 - 4.2.37]

[Link] User should be displayed acceptance message within 5 seconds, when he/she submits
entered data to the system.
[Link] Warning messages about entrance data out of defined standards must remain on the
screen for 3 seconds.

4.4.5 Portability Requirements [4.3]

[Link] System should be manageable in web-browsers of Internet Explorer, Google Chrome,
Mozilla Firefox, Opera and Safari.

4.4.6 Safety Requirements[4.2.35 - 4.2.37]

[Link] System should include restore and recover functions in order to prevent data loss.
[Link] System should assure data integrity.

28
4.4.7 Other Requirements[4.2.21-4.2.25]
[Link] System should display a warning message if the customer input for full name label is out
of defined standard.
[Link] System should display a warning message if the customer input for travel document
number is out of defined standard.
[Link] System should display a warning message if the customer wants to book flights for more
than 6 people.
[Link] System should display a warning message if the administrator tries to customize his/her
password out of defined standards.[4.2.47]

4.5 Solution oriented requirement

4.5.1 Class diagram requirements [4.2.1,4.2.2,4.2.3,4.2.15,4.2.23,4.2.43]

4.5.2​​State diagram requirements [4.2.32,4.2.34,4.2.41, 4.2.43,4,2,46]

4.5.3 Sequence diagram requirements [[Link], 4.2.42, 4.2.34, 4.2.5 - 4.2.17]

ID Requirements Diagram Priority

29
 [Link] Customer should be able to pay online. Based_on SD1_1 4 out of 5

[Link] Administrator should be able to modify the Based_on SD1_2 4 out of 5

details of existing flights

[Link] Administrator should be able to reject Based_on SD1_3 5 out of 5

reservation/cancellation request.

[Link] Customer should be able to see the list of Based_on SD1_4 5 out of 5
available flights based on the information he
entered.

4.6 System Features (contains functional, non-functional and solution-oriented

requirements)
Features of the system are the followings:
1. User Interface
2. Database about flights, reservations, and user details
3. Communication interface with HTTP protocol
4. Searching flights for specific dates
5. Searching flights multiple destinations
6. Manually entering names of destinations (by city, country, continent)
7. Specifying number of passengers while searching (adults, children and infants)
8. Multi - Currency and language
9. Sort flights either by price or duration
10. Show advantages of VIP and Premium Users
11. Request and response for reservation cancellation
12. Online payment
13. Addition of new flights to system
14. Modification of details about existing flights
15. Removing cancelled flights
16. Management of cancellation requests
17. See and change the details of bookings
18. Performance of ATRS
19. Guarantee security of communication channel
20. System attributes
21. AAS for logins
22. Predefined administrator passwords
23. Ability to change passwords
24. Defined requirements for password

30
25. Warning messages
26. Booking Tickets
27. Reliability of ATRS
28. Customizing administrator passwords
29. Security of communication channel
30. Acceptance messages

4.7 Requirements prioritization

4.7.1 MoSCoW Method

Must 1. User interface

2. Searching specific dates
3. Database about flights, reservations, and user details
4. Request and response for reservation cancellation
5. Online payment
6. Ticket reservation
7. Addition of new flights to system
8. System attributes
9. Modification of details about existing flights
10. Removing cancelled flights
11. Management of cancellation requests
12. See and change the details of bookings
13. Performance of ATRS
14. Communication interface with HTTP protocol
15. AAS for logins
16. Booking Tickets
17. Guarantee security of communication channel

Should 1. Sort flights either by price or duration

2. Request and response for reservation cancellation
3. Guarantee the safety of the channel
4. Ability to change administrator's password
5. Manually entering the names of destinations (by city, country,
continent)
6. Defined requirements for password

Could 1. Searching flights for specific dates

2. Searching by multiple destinations

31
 3. Specifying number of passengers while searching (adults,
children and infants)
4. Multi - Currency and language
5. Displaying warning messages
6. Maintain 1000 transactions in second
7. Customized administrator passwords
8. Acceptance messages

Won't 1. Login and sign in for customers

2. Hotel reservation
3. Airport pick-up

4.7.2 Prioritisation According to Cost

[Link] Main

[Link] Normalized

[Link] Percent
32
4.7.3 Prioritisation According to Value
[Link] Main

33
[Link] Normalised

[Link] Percent

34
4.7.4 Plot ROI Graph

Figure 11. ​
ROI Plot Graph

35
4.7.5 Hierarchical Prioritization

Figure 13​
. Hierarchical prioritization of requirements
​

36
4.8 Requirements Traceability
4.8.1 Traceability Matrix
Scenarios are defined as follows:
Scenario 1 – Customer wants to search for flights.
Scenario 2 – Customer wants search for flights of specific dates.
Scenario 3 – Customer wants to search for flights of specific routes.
Scenario 4 – Customer wants to see flight prices of different ticket types.
Scenario 5 – Customer wants to see what is included in different ticket types.
Scenario 6 – Customer wants to sort available flights according to price.
Scenario 7 – Customer wants to sort available flights according to duration.
Scenario 8 – Customer wants to proceed to payment for booked flight.
Scenario 9 – Customer wants to cancel his/her booked ticket.
Scenario 10 – Administrator wants to add a new flight to the system.
Scenario 11 – Administrator wants to modify the details about existing flights.
Scenario 12 – Administrator wants to remove cancelled flights.
Scenario 13 – Administrator wants to respond to cancellation requests of customers.
Scenario 14 – Customer wants to be sure about security of payment.
Scenario 15 – Customer wants to enter information to the labels.
Scenario 16 – Customer enters non-standard information while filling labels.
Scenario 17 – Administrator wants to log on the system.
Scenario 18 – Administrator types wrong password during log in.
Scenario 19 – Administrator wants to change his/her predefined password.
Scenario 20 – Administrator defines new password out of defined standards.
Scenario 21 – Customers cannot reach website.
Scenario 22 – Customer wants to change the currency and language.
Scenario 23 – Support staff wants to ensure the security of the system.
Scenario 24 – Support staff wants to ensure the safety of the system.
Scenario 25 – Support staff wants to maintain performance of the system.
Scenario 26 – Support staff wants to ensure the reliability of the system.
Traceability matrix according to these scenarios and previous mentioned features (contains
functional, nonfunctional and solution-oriented requirements) is constructed as follows:

37
 Figure 14. ​
Traceability matrix

4.8.2 Traceability Model

Figure 15. ​
Traceability model
38
In the given model following subtypes are defined under the traceability types of Content,
Abstraction and Evolution:
Content
● Contradicts​- ​inconsistency in the requirements artefacts
● Conflicts​- ​realisation of requirement A may hinder (but does not necessarily
exclude) the realisation of requirement B
Abstraction
● Generalizes -​ artefact is a generalisation of (one or) several other artefacts
Evolution
● Satisfies -​ if artefact A is realised in the system, artefact B is realised as well
● Based on -​ artefact A has influenced the definition of artefact B
● Formalizes ​- artefact A is a formal documentation of artefact B
● Derived ​- artefact A was derived based on a set of other artefact

39
5. Prototype
Description: Visualisation of website.
We try to visualize website of ITM Airlines and while customers using this website, they can
take several advantage of it. On the other hand, it is narrow version of website in order to make it
much more clear and understandable. In the first stage, customers will enter to home page of
website. Then, they can choose type of the ticket, number of adults/children/infants, sort tickets
either by duration or by price, and in this prototype, customers can only search tickets for one
way trip. Moreover, we were add sign in and register buttons for administrators in order to
register/enter the system itself. Finally, there are several buttons such as feedback, currency and
language buttons that allow customer in order to give their feedbacks about website, change
currency and language.

40
41
Appendix A: Glossary
IEEE ​ he Institute of Electrical and Electronics Engineers
T
HTTP Hypertext Transfer Protocol
ATRS Airline Ticket Reservation System
Authentication ​The process of identifying an individual, usually based
on username and password
Authorization ​The process of granting defined privileges to successfully
authenticated individuals
AAS ​Authentication and Authorization System
Database ​An organized collection of data, stored and accessed
Electronically.
Standby database ​Database replica created from a backup of a primary
database
Server ​Computer program that provides functionality to other programs
such as clients
World Wide Web ​Combination of all resources and users on the Internet that are
using HTTP.
Web-browser ​Software application to access information on World Wide Web
Client ​Computer application, such as web-browser, that runs on a
computer and connects to server as necessary
Service Level Agreement(SLA) S ​ tates agreed level of availability
VIP Very Important Person
Adult ​12+ years old individuals
Children ​0-12 years old individuals
Infant ​To 2 years

42