Document Hotel PDF

Software Requirements Specification for Online Room Reservation System
Software Requirements Specification
for
Online Room Reservation System
Version 4.0 approved
Prepared by:
N Kothamasu
Las Bosgraaf
Nikolay Roll
Zaur Ayralov
Fortune Festus
Roza Mikeliani
15.12.2018
University of Tartu
Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Table of Content
1. Introduction ............................................................................................................................. 5
1.1 Purpose ............................................................................................................................. 5
1.2 Intended Audience and Reading Suggestions .................................................................. 5
1.3 System Scope ................................................................................................................... 5
1.4 Glossary............................................................................................................................ 6
1.5 References ........................................................................................................................ 7
2. Overall Description.................................................................................................................. 7
2.1 System Perspective ........................................................................................................... 7
2.2 System Functions ............................................................................................................. 8
2.3 User Classes and Characteristics ...................................................................................... 8
2.4 Actor Dependency Models ............................................................................................... 9
2.4.1 System goal modeling .................................................................................................... 10
2.4.2 Actors dependencies in a traditional approach ............................................................... 11
2.4.3 Actors dependencies in the software intensive system .................................................. 12
2.5 Goal Modelling .............................................................................................................. 13
2.6 Operating Environment .................................................................................................. 15
2.7 Design and Implementation Constraints ........................................................................ 15
2.8 Assumptions and Dependencies ..................................................................................... 15
3. System Functional Requirements .......................................................................................... 15
3.1 Checking Availability Page ............................................................................................ 16
3.2 Selection of a Room Page .............................................................................................. 16
3.3 Customer Details Page ................................................................................................... 17
3.4 Payment Page ................................................................................................................. 18
3.5 Confirmation page .......................................................................................................... 18
4. Other Nonfunctional Requirements ....................................................................................... 19
4.1 Performance Requirements ............................................................................................ 20
4.2 Reliability Requirements ................................................................................................ 20
4.3 Security Requirements ................................................................................................... 20
4.4 Maintainability Requirements ........................................................................................ 21
4.5 Portability requirements ................................................................................................. 21
4.6 Use cases ........................................................................................................................ 21
4.7 Use case Scenarios ......................................................................................................... 22
4.8 Solution Oriented Requirements Modelling .................................................................. 28
4.8.1 Class Diagram of the Process for Booking a Room ....................................................... 28

4.8.2 State Diagram for Objects of Booking a Room ............................................................. 29
4.8.3 Process of Booking a Room ........................................................................................... 30
4.9 Solution oriented requirements ...................................................................................... 31
4.10 Software Quality Attributes ........................................................................................... 32
5. Business Rules................................................................................................................ 33
6. Other Requirements ............................................................................................................... 33
7. Prototype of Web-Interface for Booking a Room ................................................................. 34
8. Traceability & Prioritization .................................................................................................. 37
8.1 Traceability Model ......................................................................................................... 37
8.2 Traceability Matrix ......................................................................................................... 37
8.3 Prioritization ................................................................................................................... 39
8.4 Value Matrix .................................................................................................................. 40
8.5 Cost Matrix..................................................................................................................... 40
8.6 Prioritization Plot ........................................................................................................... 41
8.7 Supporting documents .................................................................................................... 41
Table of Figures
Figure 1 – System Perspective ........................................................................................................ 7

Figure 2 - Notations ........................................................................................................................ 9
Figure 3 – Example of Notation.................................................................................................... 10
Figure 4 – ORRS Actor dependency model ................................................................................. 12
Figure 5 – ORRS technical actor dependency model ................................................................... 13
Figure 6 – ORRS System KAOS Goal Model .............................................................................. 14
Figure 7 – ORRS Use Case Diagram ............................................................................................ 22
Figure 8 – ORRS Class Diagram of Booking a Room ................................................................. 28
Figure 9 – State Diagrams of Objects from class diagram of booking a room part 1 .................. 29
Figure 10 - State Diagrams of Objects from class diagram of booking a room part 2 ................. 30
Figure 11 – Process of Booking a Room ...................................................................................... 31
Figure 12 –Traceability Model ..................................................................................................... 37
Figure 13 –Prioritization by value ................................................................................................ 40
Figure 14 –Prioritization by cost................................................................................................... 40
Figure 15 –Prioritization Plot........................................................................................................ 41
List of Tables
Table 1 - Versioning ....................................................................................................................... 5
Table 2 – Definitions and Acronyms .............................................................................................. 6

Table 3 – System Functions ............................................................................................................ 8
Table 4 – ORRS system Goals...................................................................................................... 11
Table 5 – Checking Availability Page .......................................................................................... 16
Table 6 – Selection of Room Page ............................................................................................... 17
Table 7 – Customer Details Page .................................................................................................. 17
Table 8 – Payment Details Page ................................................................................................... 18
Table 9 – Confirmation Page ........................................................................................................ 19
Table 10 – Performance Requirements ......................................................................................... 20
Table 11 – Reliability Requirements ............................................................................................ 20
Table 12 – Security Requirements ................................................................................................ 21
Table 13 – Maintainability Requirements..................................................................................... 21
Table 14 – Portability Requirements ............................................................................................ 21
Table 15 – Hotel Room Booking .................................................................................................. 23
Table 16 – Checking Availability ................................................................................................. 24
Table 17 – Payment ...................................................................................................................... 25
Table 18 – Confirmation ............................................................................................................... 26
Table 19 – Customer Details......................................................................................................... 27
Table 20 – Room Selection ........................................................................................................... 28
Table 21 – Other Requirements .................................................................................................... 33
Table 22 – Traceability Matrix ..................................................................................................... 39
Table 23 – Requirements Prioritization Matrix ............................................................................ 40
Revision History
Name Date Reason For Changes Version

ORRS-V1 15/10/2018 V1
ORRS-V2 23/10/2018 Refining requirements, adding prioritization plot V2
ORRS-V3 11/11/2018 Add non-functional requirements, adding traceability, V3
adding system goal modeling, adding actor goal
modeling, adding use case diagram, adding use case
scenarios
ORRS-V3.1 18/11/2018 Refined Goal Models, Traceability Model and Syntax V3.1
according to the feedback 2
ORRS-V3.2 02/12/2018 Added Class Diagram, Sequence Diagram and State V3.1
Diagrams. Added few solution-oriented requirements
with their diagrams
ORRS-V3.3 08/12/2018 Refined Class Diagram, Sequence Diagram. Derived V3.3
state diagrams from Class diagram. Developed
solution oriented requirements from class diagram and
state diagrams. Refined Goal modelling part and goal
IDs. Added table for goals used in goal modelling.
Traced solution oriented requirements back to
functional requirements. Updated traceability model
and traceability matrix. Refined scopes for each
diagram presented.
ORRS-V4.0 15/12/2018 Refined and clarified scope of Class, Sequence and V4.0
State Diagrams. Prepared prototype for the system to
present. Updated Traceability model.
Prototype for the web interface has been created and
traced back to the system functions.
Table 1 - Versioning
1. Introduction
This section of the document provides purpose, system scope, list of definitions, acronyms,
abbreviations & references.
1.1 Purpose
The purpose of this document is to create a list of detailed requirements for Online room
reservation specification (ORRS). This document will capture interactions between different
internal web pages, environment scenarios of usage, constraints and Online room reservation
system prototype
1.2 Intended Audience and Reading Suggestions
This document will capture all stakeholders’ preferences, different conflicts and their resolution.
Also, it could be used by potential developers, design engineers, testers, project managers, etc.
Eventually this document can be used while preparing user documentation.
This document will be proposed to different stakeholders for their approval and can be used as a
reference guide in different phases of system development.
1.3 System Scope
The scope of the online room reservation system is to create an online web-interface for the users
to check the availability and book the room from any part of the world. This system will be an
alternative to the traditional offline way of checking available rooms and book them. The scope of
the sub-system which is described in this document is the user interface. The system will have two
major types of users: customers and hotel manager.
User interface is part of already existing system ORRS, which is not going to be discussed here.
Usage facet – sorting, selecting, and reserving a room by customers. Updating room information
and viewing reports by hotel manager.
Subject facet – entering different details to select and reserve a room at a hotel.
Development facet – GDPR, Terms and Policies and hotel’s internal policies to be considered.
IT System Facet – Hotel’s existing room reservation system, on which the user interface has
dependency explained below.
1.4 Glossary
Acronym Definition
ORRS Online Room reservation system
OFR Other Functional Requirement
User Interface User Interface is the landing page where the customer can use the functionalities
described in this document.
SYSF Abbreviation representing System Function – used as a prefix of function IDs
API Application Programming Interface
GDPR General Data Protection Rules
PAGE The term page is used to refer a component of the system (website) which
accommodates different functionality across the website. For example, customer
details page has functions that enable customers enter information, while
payment page has functions regarding card details.
Precondition the precondition realizing a functional requirement might be that the hardware
meets a specific performance requirement
Post condition Describing the state the system is in after all the events in the use case have taken
place
Evolution Satisfies – if artefact A is realized in the system, artefact B is realized as well
System ORRS is referred as System. It is the all the functions that ORRS has including
those not discussed in this document.
Table 2 – Definitions and Acronyms
1.5 References
● (n.d.). Retrieved from Agile Business Consortium:

https://www.agilebusiness.org/content/moscow-prioritisation-0
● SRS IEEE Template. (n.d.). Retrieved from
ieee.dochttps://web.cs.dal.ca/~hawkey/3130/srs_template-
2. Overall Description
This section will provide overview of the system, its perspective and main functions.
ORRS- Online Room Reservation System serves as a website of a hotel, through which customers
can check available rooms, select preferred arrival and departure dates and number of guests. They
can enter their personal and card details, confirm booking. The system as a response sends a
confirmation mail to them.
2.1 System Perspective
Online room reservation Administrative system

system (ORRS)
Common
database
Figure 1 – System Perspective
The system considers customer and hotel manager perspectives. It has ORRS – where customers
are able to book the rooms and use system functions described in his document, while for the
administrative use there is a separate environment, where accounting, logistics and all relevant
operations run. Both systems are based on the common database. They are integrated with each
other, meaning the relevant data is exchanged.
The subsystem “User Interface” is an element of ORRS and it represents the web-interface for
customer to book rooms online according to their choice of selection.
2.2 System Functions
SYSTEM FUNCTION SHELL
VER. Version of system function

SYSTEM FUNCTION ID Unique identification code of system function
SYSTEM FUNCTION Name of system function
DESCRIPTION Description of system function
Ver. System System Function Description

Function ID
V1 SYSF1 Checking availability Customer shall be able to check the availability of rooms
V1 SYSF2 Selection of room Customer shall be able to view available rooms with brief
details and price information
V1 SYSF3 Customer details Customer shall be able to enter their details for
communication purposes
V1 SYSF4 Payment page Customer shall be able to enter payment details for
authentication & room booking confirmation purposes
V1 SYSF5 Confirmation Page Customer shall be able to view all entered details on
confirmation page
Table 3 – System Functions
2.3 User Classes and Characteristics
User characteristics
There are two user classes in ORRS: customer and hotel manager.
Customer
Customer is the main stakeholder of the software intensive system. Customer would be able
to check available rooms. Customer can select and sort rooms by price. Enter personal and
payment details, as well as confirm booking. Customer input is required for making
successful reservation.
Hotel Manager
Hotel manager is the administrative stakeholder of the software intensive system. Hotel
manager would able to update the information about listed rooms, see reports and check the
booking information.
2.4 Actor Dependency Models
It provides the visual description of a process about network of dependency relationships

between actors
Notations:
Figure 2 - Notations
Figure 3 – Example of Notation
2.4.1 System goal modeling
GOAL SHELL
GOAL ID Unique identification code of goal

GOAL NAME Name of goal
GOAL DESCRIPTION Description of goal
TRACEABILITY ATTRIBUTE Traceability relation to other artefacts
Goal ID Goal Name Goal Description Traceability attribute

G1 Book a room Booking a room is higher level goal and main purpose System Functions
of the system. It is broken down to lower level goals.
G01 Check availability Customer checks availability of rooms by dates, SYSF1
number of guests and price
G02 Sort rooms by Once available rooms are displayed customer has
price option to sort them by price
G03 Select a room Customer selects desired room in order to proceed SYSF2
with booking
G04 Enter customer Customer enters their personal details necessary for SYSF3
details booking
G05 Enter payment Customer provides card details to confirm booking.
details Actual payment at this stage is not required.
G06 Confirmation Customer confirms booking of the selected room SYSF5
G08 Add new room Hotel manager adds new information, photos and/or
Information details about rooms
G09 Check reports Hotel manager can see predefined report
G10 See latest Hotel manager checks latest bookings by customers
bookings
G11 Provide reports System provides reports for hotel manager
G12 Send confirmation System sends confirmation email to customer once
mail booking is done
G13 Contact by Customers can contact hotel manager by phone or

phone/face to face face to face to book a room
G14 Confirmation of Hotel manager can confirm customers that the room
reservation is booked
G15 Payment Hotel manager collects payment from customer at the
hotel
G16 Update Hotel manager manually updates information about
Information customers before ORRS started running
G17 Check availability System checks available rooms according to entered
by date dates
G18 Check availability System checks available rooms according to entered
by room type room type
G19 Check availability System checks available rooms according to prices
by price
G20 Enter Date by System pops up inbuilt calendar to enable customer
inbuilt calendar enter date
G21 Change price Customer can change price range when looking for
range rooms
Table 4 – ORRS system Goals
2.4.2 Actors dependencies in a traditional approach
Customer: A person who is interested to book a room

Hotel Manager: A person who will accept room reservations from customer
MS Excel: Master excel sheet with room details and booking information .
“Figure 4 – ORRS Actor dependency model” represents traditional way of booking room in
a hotel. Customer should call hotel manager or go to the hotel for booking a room. Payment
for room bookings is paid to hotel manager. Main database is MS Excel where hotel manager
can retrieve and update room and customer information from MS Excel.
Figure 4 – ORRS Actor dependency model
2.4.3 Actors dependencies in the software intensive system
Customer: A person who is interested to book a room

Hotel Manager: A person who will accept room reservations from customer
Web Interface: User Interface webpage for ORRS
Database: Storage for all room details, customer information etc.
As per “Figure 5 – ORRS technical actor dependency model”, the customer depends on the
ORRS to book a room as an end goal (G01.). Before that the customer has to see the available
rooms (G02.) and select on; enter the customer’s details (G04.); to confirm the details and the
room is booked (G06.).
On the other hand, the hotel manager depends on the system to provide the customer’s data, data
on available rooms, and other sorts of data (G09.). However, the systems require input of data in
case if a customer would like to reserve a room via email/phone call/in person.
In a meantime, the ORRS itself exchanges data between the interface with which the customer
interacts and database from where the hotel manager receives the data.
Figure 5 – ORRS technical actor dependency model
2.5 Goal Modelling
The Goal and Agent model shown below “Figure 6 – ORRS System KAOS Goal Model” assigns
roles to agents for satisfying goals in the system. The agent(customer) books a room through the
web by checking the availability of different rooms. This is done by selecting a date and room
type. The date is selected by using the inbuilt calendar function of the system.
Figure 6 – ORRS System KAOS Goal Model
2.6 Operating Environment
Operating environment for this system will be hosted virtually using any cloud service provider.
2.7 Design and Implementation Constraints
1. The system has dependency on the database and the hotel’s existing traditional system.
2. Internet connection is a constraint for this system because system is available from cloud
therefore customer needs to have good network connection to connect to our web
interface
2.8 Assumptions and Dependencies
1. The requirements for the user interface is developed under the assumption that user
interface is a subsystem of existing larger system for hotel reservation management,
which keeps and processes information about existing, booked and free rooms at the
hotel, including the data about room type, number of total rooms at hotel, time of check
outs and other factors that influence the room availability at any given time.
2. The process and algorithm for calculating available rooms are assumed to be given prior.
3. System Functional Requirements
This section illustrates the functional requirements for ORRS web interface which is having 5
different web pages that enables customer to select and reserve room online. Each web page is
supported by set of specific requirements given in below tables.
The requirements below are developed within the scope from customer perspective only.
3.1 Checking Availability Page
REQUIREMENT SHELL
VER. Version of requirement

REQ ID Unique identification code of requirement
DESCRIPTION Description of requirement
PRIORITIZATION ATTRIBUTE Prioritization of requirement according to prioritization
plot
Requirement Shell in the table:

Ver. Req ID Description Prioritization Traceability
Attribute Attribute
V1 R1.1 This page shall have a field for arrival and departure High
dates selection
V1 R1.2 This page shall have an option for selecting room High Content of R1.3
type
V1 R1.3* This page shall have an option for selecting number High Precondition to R1.2
of rooms
V1 R1.4* This page shall have an option for selecting number High
of adults
V1 R1.5 This page shall have an option for selecting number High
of children
V1 R1.6 Page shall show check availability and rates button High Precondition to the
to redirect customer to select a room page requirements from
SYSF2
Table 5 – Checking Availability Page
Note: * denotes mandatory field
3.2 Selection of a Room Page

Attribute Attribute
V1 R2.1 Check the availability of rooms High Precondition to R2.2
V1 R2.2 Page shall display available rooms according to High Evolution of R2.1
R2.1
V1 R2.2.1 Page shall display room pictures of all types of Medium Content R2.2
available rooms
V1 R2.2.2 Page shall display room prices per night of all High Content of R2.2
available rooms
V1 R2.2.3* Page shall display select & continue button High Precondition to
which will redirect the customer to customer requirements to
details page SYSF3
V1 R2.3 Page shall have sorting function to sort by price High
V1 R2.4 Price shall be displayed in Euros High Miscellaneous of

R2.2.2
V1 R2.5 Page shall display button to previous page with High

previous page name on the button
V1 R2.6 Page shall display cancel button which will High

redirect the customer to hotel home page
Table 6 – Selection of Room Page
3.3 Customer Details Page

Attribute Attribute
V1 R3.1* Page shall display text field for Firstname High
V1 R3.2* Page shall display text field for Lastname High
V1 R3.3* Page shall display field for Telephone number Medium
V1 R3.4* Page shall display field for E-mail address High
V1 R3.5* Page shall display mandatory checkbox field High

for agreement of terms and conditions
V1 R3.6 Page shall display submit details button which High Precondition to
will redirect to payment page requirements of
SYSF4
V1 R3.7 Page shall display button to previous page High

with previous page name on the button

Table 7 – Customer Details Page
3.4 Payment Page

Attribute Attribute
V1 R4.1 Page shall display Total price of selected room for High Evolution of R2.2.2
selected number of nights and R1.1
V1 R4.2 Page shall display field for Credit card number High
V1 R4.4 Page shall display field for expiration date of High

credit card
V1 R4.5* Page shall display mandatory checkbox field for High

agreement of terms and conditions
V1 R4.6 Page shall display a Note: Card details will be High Miscellaneous of
used for authentication purposes only and the R4.7
payment will charged upon customer check-in
V1 R4.7 Page shall display continue button which will High Precondition to
redirect to confirmation page requirements of
SYSF5


Table 8 – Payment Details Page
3.5 Confirmation page

Attribute Attribute
V1 R5.1 Page shall display previous inputs by customer High Evolution of

as SYSF3R3.1-SYSF3R3.4 SYSF3R3.1-
SYSF3R3.4
V1 R5.2 Page shall display arrival and departure dates High Evolution of
according to customer selection in SYSF1R1.1 SYSF1R1.1
V1 R5.3 Page shall display room selection details High Evolution of

chosen by customer according SYSFR2.2.3 SYSFR2.2.3
V1 R5.4 Page shall display total price according to High Evolution of

SYSF4R4.1 SYSF4R4.1
V1 R5.5 Page shall display customer payment details High Evolution of

entered by customer according to SYSF4R4.2- SYSF4R4.2-
SYSF4R4.4 SYSF4R4.4
V1 R5.6 Page shall display confirm button which will High

redirect to Home page
V1 R5.6.1 Page shall display a pop-up with a message:

Thank you for your booking
V1 R5.7 When customer clicks confirm button, All High

details from confirmation page will be stored in
the hotel’s common database.
V1 R5.8 Upon clicking confirmation button, an email High Evolution of

will be sent out with all details according SYSF5R5.1 –
SYSF5R5.1 – SYSF5R5.4 SYSF5R5.4
V1 R5.8.1 Email shall be sent out to customer’s email Evolution SYSF3R3.4

address according to SYSF3R3.4


VI R5.11 Upon Confirmation “Thank you for your Medium

booking” message shall be displayed
Table 9 – Confirmation Page
4. Other Nonfunctional Requirements
This section illustrates the non-functional requirements which includes performance, reliability,
security, maintainability, portability requirements, use cases, use-case scenarios, solution-
oriented requirements modelling, software quality attributes for ORRS web interface.
REQUIREMENT SHELL

PRIORITIZATION ATTRIBUTE Prioritization of requirement according to
prioritization plot
4.1 Performance Requirements

Attribute Attribute
V1 PFR1 Every booking submission & modification High Constraints to R5.7

should be updated in Hotel’s common
database within 10 seconds after each
submission & modification activity
V1 PFR2 Results for cross checking of availability High Constraints to R2.1

of rooms in internal database and
customer’s choice shall be in 5 seconds
V1 PFR3 Webpage UI load time should be within 2 High Constraints to R1.6,

secs R2.2.3, R2.5, R2.6,
R3.6, R3.7, R3.8,
R4.7, R4.8, R4.9,
R5.9, R5.10, R5.6
V1 PFR4 Redirection page load time shall be within High Constraints to R1.6,
2 secs R2.2.3, R2.5, R2.6,
R3.6, R3.7, R3.8,
R4.7, R4.8, R4.9,
R5.9, R5.10, R5.6
V1 PFR5 Confirmation email shall be sent into Low Constraint to R5.8.1

customer’s mentioned email within 2 secs
after confirmation page termination
Table 10 – Performance Requirements
4.2 Reliability Requirements

Attribute Attribute
V1 RR1 Database should be synchronized to cloud High

every 5 minutes
V3 RR2 System shall be accessible 98% of the time High

Table 11 – Reliability Requirements
4.3 Security Requirements
Ver. Req ID Description Prioritization Traceability Attribute

Attribute
V1 SR1 Customer’s personal details shall be High Miscellaneous

encrypted
V1 SR2 Customer’s credit card details shall be deleted High Miscellaneous

from database after checkout date
Table 12 – Security Requirements
4.4 Maintainability Requirements

Attribute
V3 MTR1 No method in any object may exceed 100 High

lines of code
V1 MTR2 System failure recovery shall be within 40 High

mins
Table 13 – Maintainability Requirements
4.5 Portability requirements

Attribute
V3 PTR1 System shall be accessible on mobile devices High Miscellaneous
V3 PTR2 System shall be accessible on Google Chrome, High Miscellaneous

Firefox, Safari, Opera and Internet explorer
Table 14 – Portability Requirements
4.6 Use cases
“Figure 7 – ORRS Use Case Diagram” identifies main actors. In the diagram there are two
actors, though the document will only develop specific requirements from the customers’
perspective.
On the figure 6 system’s main functions are depicted and along with the ID. Customer will
predominantly be using the following functions 1-4, while hotel manager’s main functions will
the rest (5,6).
Figure 7 – ORRS Use Case Diagram
4.7 Use case Scenarios
General:
Use Case ID: ORRS - 1
Use Case Name: Hotel Room Booking
Created By: N Kothamasu Last Updated By: N Kothamasu
Date Created: 10.11.2018 Date Last Updated: 10.11.2018
Actors: Customer, Hotel Manager
Description: Customer accesses the web interface of ORRS and checks the availability of rooms
available for him to book. Then he can select the room and complete all requested
details to complete the booking
Trigger: Customer accessing web interface
Preconditions: NA
Postconditions: Customer completes booking for the room
Normal Flow: Customer selects the check-in and check-out date, room type, number of adults,
number of children from the web interface of ORRS and click next button
System displays available rooms available for the customer chosen dates
Customer can sort using sort option using highest & lowest
Customer selects the room and click next button
System displays a page to enter customer details
Customer enters all requested details and click next button
System displays payment details authentication page
Customer enters credit card details for authentication purpose and click submit
button
System stores details and send a confirmation email to customers with customer
entered details and check-in/check-out information
Alternative Flow:
Exceptions: Customer could enter some wrong details because of typo errors
Includes: NA
Priority: All mandatory requirements
Frequency of Use: Depending on Customer interaction
Business Rules:
Special
Requirements:
Assumptions:
Notes and Issues:

Table 15 – Hotel Room Booking
Use Case Name: Checking Availability
Created By: Roza Mikeliani Last Updated By: Roza Mikeliani
Actors: Customer
Description: Customer accesses the web interface of ORRS; Enters the preferred dates of stay in the
inbuilt calendar with date format dd/mm/yyyy based this dates website displays
available rooms, with prices and other details.
Trigger: Customer entering dates in inbuilt calendar
Preconditions: NA
Postconditions: Customers presses button to proceed with the next page
Normal Flow: Customer enters arrival and departure dates based on which system displays available
rooms along with the prices.
Alternative Flow: If customer doesn’t enter any date, system by default takes “today” and “tomorrow”
for arrival and departure dates, and base on these dates displays available rooms along
with the prices.
Exceptions: NA
Includes: NA
Priority: Mandatory
Frequency of Use: Depending on Customer interaction
Business Rules: Customer cannot book room without proceeding this page
Special NA
Requirements:
Assumptions: Customer uses inbuilt calendar to enter dates
Notes and Issues:

Table 16 – Checking Availability
Use Case ID: ORRS – 3
Use Case Name: Payment
Created By: Nikolay Roll Last Updated By: Nikolay Roll
Actors: Customer, ORRS
Description: Customer shall be able to enter payment details for authentication & room booking
confirmation purposes
Trigger: Customer is redirected to the “Payment page” after clicking “Submit details” button on
the page “Customer details”
Preconditions: Customer has selected a room/rooms and entered details
Postconditions: Customers presses button to proceed with the next page
Normal Flow: Customer sees the displayed Total price of the room he/she is going to reserve.
Customer enters the card data into the system which includes:
- select card type (Visa, Mastercard, other)
- enter card number (16 numbers);
- enter expiration date (month and year)
Customer agrees with terms and conditions by reading them and clicking a checkbox.
Customer reads a Note (Card details will be used for authentication purposes only and
the payment will charged upon customer check-in) if he/she wants to reassure why the
card data is requested.
Customer clicks “Continue” button to proceed to confirmation page
Alternative Flow: Customer checks entered information and notices information is not correct.
Customer clicks previous page button to correct information that is wrong.
Exceptions: NA
Includes: NA
Priority: Mandatory
Frequency of Use: Depending on customer interaction
Special NA
Requirements:
Assumptions: Customer uses dropdown menus to enter dates
Notes and Issues:
Table 17 – Payment
Use Case Name: Confirmation
Created By: Lars Bosgraaf Last Updated By: Lars Bosgraaf
Actors: Customer, ORRS
Description: Customer shall be able to view all entered details on confirmation page and confirm
details with confirm button
Trigger: Customer is redirected to the “Confirmation page” after clicking “Continue” button on
the “Payment page”
Preconditions: Customer has selected a room/rooms, entered details, entered payment information,
and agreed with terms and conditions
Postconditions: Customers presses confirm button to return to website homepage
Normal Flow: Customer sees information displayed, entered by customer on check availability page,
room selection page, customer details page and payment page.
Customer checks entered information and confirms if information is correct.
Customer clicks confirm button.
Customer is redirected to homepage.
System sends confirmation e-mail with information displayed on confirmation page to

customer.
Alternative Flow: Customer checks entered information and notices information is not correct.
Customer clicks previous page button to correct information that is wrong.
Exceptions: NA
Includes: NA
Priority: Mandatory
Frequency of Use: Depending on customer interaction
Special NA
Requirements:
Assumptions: Customer enters information on check availability page, room selection page,
customer details page and payment page.
Notes and Issues:

Table 18 – Confirmation
Use Case Name: Customer details
Created By: Zaur Ayralov Last Updated By: Zaur Ayralov
Actors: Customer
Description: Customer should complete all requested details to complete the booking
Trigger: Customer selecting room
Preconditions: NA
Postconditions: Customer completes booking for the room
Normal Flow: Customer enter firstname, lastname, telephone number, email address and click submit
button
System displays payment page
Alternative If customer does not fill mandatory fields, system notify customer
Flow:
Exceptions: Customer could enter some wrong details because of typo errors
Customer could enter wrong format of email address and telephone number
Includes: NA
Priority: All mandatory fields
Frequency of Depending on Customer interaction

Use:
Business Rules: Customer cannot book without proceeding this page
Special NA
Requirements:
Assumptions:
Notes and
Issues:
Table 19 – Customer Details
Use Case Name: Room selection
Created By: Fortune Festus Last Updated By: Fortune Festus
Actors: Customer.
Description: Customer shall be able to select room type by clicking single or double and sort room by
price and date.
Trigger: Customer is re-directed to the “select room page” after clicking the “check availability
and rates” button.
Preconditions: Customer has entered arrival and departure date. Customer has selected room type.
Customer has clicked check availability button.
Postconditions: Customer selects a room
Normal Flow: Page displays pictures of all available room.

Page displays prices per night in Euros.
Customer selects room
Page displays continue and select button which re-directs customer to customer details
page.
Page displays previous page button
Page displays cancel button which directs the customer to home page.
Alternative Page shall display error message if customer omits to select a room.
Flow:
Exceptions: Customer could enter wrong details.
Includes: NA
Priority: All mandatory requirements
Frequency of Depending on Customer interaction

Use:
Business Rules: NA
Special
Requirements:
Assumptions: NA
Notes and Issues:
Table 20 – Room Selection
4.8 Solution Oriented Requirements Modelling
4.8.1 Class Diagram of the Process for Booking a Room
During modelling solution oriented requirements, the scope of the system has been narrowed
down to the customer and web-interface interaction during the process of booking a room.
“Figure 8 – ORRS Class Diagram of Booking a Room” describes the classes, subclasses and
associations between them. As well as object attributes and their main functions.
Figure 8 – ORRS Class Diagram of Booking a Room
4.8.2 State Diagram for Objects of Booking a Room
State models describe how system objects and operations transit from one state to anoter. States
of the system objects have been derived from the class diagram for booking a room and have
been traced to specific requirements.
Figure 9 – State Diagrams of Objects from class diagram of booking a room part 1
“Figure 9 – State Diagrams of Objects from class diagram of booking a room” describes states for the all 5
main pages (objects of “Figure 8 – ORRS Class Diagram of Booking a Room”).
Availability Page has two major functions choosing a date and a room type according to which
availability is checked.
For first attribute of this object (Date) is empty, until customer clicks on date field which pops up
inbuilt calendar, where customer selects preferred date. The last state is in loop until customer
selects a date. Once date is selected state diagram reaches its end.
Room Selection Page starts with the state when room type is not defined. Customer clicks on the
field and room types are displayed within a drop-down menu. Once customer chooses room type,
“room type selected state” will be reached and that is the final state of this object.
Figure 10 - State Diagrams of Objects from class diagram of booking a room part 2
4.8.3 Process of Booking a Room
“Figure 11 – Process of Booking a Room” describes the sequential interaction between the
customer and the system. After every webpage in the web-interface, the system has to redirect
the customer to the next page of the web-interface. The customer and system constantly go back
and forward in the process.
Figure 11 – Process of Booking a Room
4.9 Solution oriented requirements
During the modelling of ORRS system, new requirements have been elicited. These
requirements are shown in the table below.
REQUIREMENT SHELL

prioritization plot
Ver. Req ID Description Traceability

Attribute
V4 SOR1.1 Web interface checks if checkbox is selected R5.8

for accepting terms & conditions
V4 SOR1.2 Web interface shall check customer entered R4.2

card details or not
V4 SOR1.3 Web interface shall check email if is entered R3.4

or not
V4 SOR1.4 Web interface shall not accept arrival date R1.1

later than departure date.
V4 SOR1.5 Web interface shall not accept total number of R1.4, R1.5
guests higher than 50
V4 SOR1.6 Web interface shall not accept e-mail address R3.4

if e-mail address does not have one “@”
character and at least one “.” character in e-
mail address.
V4 SOR1.7 Web interface shall verify credit card type R4.2

from credit card number entered by customer
V4 SOR1.8 Web interface shall not accept special R3.1, R3.2

characters in name fields
V4 SOR1.9 Web interface shall not accept numbers in R3.1, R3.2

name fields
V4 SOR1.10 Web interface shall check if all fields are R3.1, R3.2, R3.3, R3.4
filled
V4 SOR1.11 Web interface shall not accept expiration date R4.4

of credit card that is prior to current date
V4 SOR1.12 Web interface shall have select button next to R2.2

available rooms
4.10 Software Quality Attributes
Software Quality Attributes:

● Flexibility: System should be built flexible enough to add new features and integrate
with external system API’s from booking.com or expedia.com in future.
● Integrity: System should secure customer’s details to avoid data losses and data
manipulation
● Usability: System should be able to easily accessible by all users
● Maintainability: System shall be able to maintain easily at any point of time in future
● Testability: System shall be able to test and confirm all the specifications according to
client’s requirements.
5. Business Rules
● Room Type: Single Room; Double Room.

1 single room can accommodate either 1 adult or 1 child. 1 double room can
accommodate 2 adults, 2 children or 1 adult and 1 child.
● GDPR implies deleting Customer’s Credit card information within 24 hrs. after checkout.
6. Other Requirements
REQUIREMENT SHELL

prioritization plot

Attribute
V1 OFR1 Customer shall be notified by email after Low

checkout with a message: “Thank you for
your stay , Hope we will see you back again
and receive 10% discount”
V1 OFR2 System shall be able to translate into Medium

customer’s choice of language using inbuilt
google translator API
Table 21 – Other Requirements
7. Prototype of Web-Interface for Booking a Room
For the functions introduced in Table 3 – System Functions prototype of web-interface pages
have been developed.
Page 1: Traced back to Checking Availability Page
Page 2: Traced back to Selection of a Room Page
Page 3: Traced back to Customer Details Page
Page 4: Traced back to Payment Page
Page 5: Traced back to Confirmation page
Page 6: Traced back to Confirmation page - R5.11
8. Traceability & Prioritization
8.1 Traceability Model
Figure 12 –Traceability Model
Precondition -the precondition realizing a functional requirement might be that the hardware
meets a specific performance requirement
Post condition - Describing the state the system is in after all the events in the use case have
taken place
Evolution - Satisfies another requirement, meaning if artefact A is realized in the system,
artefact B is realized as well
Miscellaneous - any kind of information related to a requirements artefact.
Constraint - when a solution-oriented requirement can be a constraint of another solution-
oriented requirement
8.2 Traceability Matrix
In the matrix below each requirement is traced back to the source function/goal to which it
supports. Some requirements satisfy more than one goal.
Satisfies SYSF1 SYSF2 SYSF3 SYSF4 SYSF5
R1.1 X
R1.2 X
R1.3* X X
R1.4* X X
R1.5 X
R1.6 X
R2.1 X
R2.2 X
R2.2.1 X
R2.2.2 X
R2.2.3* X X
R2.3 X
R2.4 X
R2.5 X
R2.6 X
R3.1* X X
R3.2* X X
R3.3* X X
R3.4* X X
R3.5* X X
R3.6 X
R3.7 X
R3.8 X
R4.1 X
R4.2 X
R4.4 X
R4.5* X X
R4.6 X
R4.7 X
R4.8 X
R4.9 X
R5.1 X
R5.2 X
R5.3 X
R5.4 X
R5.5 X
R5.6 X
R5.6.1 X
R5.7 X
R5.8 X
R5.8.1 X
R5.9 X
R5.10 X
Table 22 – Traceability Matrix
8.3 Prioritization
Moscow technique was used for prioritization purposes. The results are presented below:
WOULD (Can
COULD
SHOULD (of be postponed
MANDATORY MANDATORY (Preferred but
High Priority) and suggested
not necessary
for future
R1.3 R4.4 R1.1 R2.2.1 OFR1
R1.4 R4.5 R1.2 R3.3 PFR5
R1.5 R4.7 R2.3 OFR2
R1.6 R4.8 R4.6
R2.2 R4.9 R5.8
R2.2.2 R5.1 PFR2
R2.2.3 R5.2 PFR3
R2.4 R5.3 PFR4
R2.5 R5.4 RR1
R2.6 R5.5 MTR2
R3.1 R5.6
R3.2 R5.7
R3.4 R5.9
R3.5 R5.10
R3.6 PFR1
R3.7 SR1
R3.8 SR2
R4.1
R4.2
R2.1
Table 23 – Requirements Prioritization Matrix
8.4 Value Matrix
Prioritization by value
The following figure describes the prioritization of requirements according to the value they it
offers. A number and higher percentage means the requirement offers more value.
R1.1 R1.2 R2.3 R4.6 R5.8 PFR1 PFR2 PFR3 PFR4 SFTR1 SFTR2 sum %
R1.1 0,02 0,11 0,14 0,09 0,01 0 0,01 0,01 0,01 0,02 0,04 0,45 4%
R1.2 0 0,02 0,05 0,08 0,01 0 0,01 0,01 0,01 0,02 0,05 0,24 2%
R2.3 0 0,01 0,02 0,11 0,01 0 0,01 0,01 0,01 0,02 0,05 0,23 2%
R4.6 0 0 0 0,01 0,01 0 0,01 0,01 0,01 0,02 0,05 0,12 1%
R5.8 0,16 0,12 0,11 0,11 0,08 0,09 0,08 0,15 0,13 0,04 0,08 1,15 10%
PFR1 0,16 0,14 0,12 0,11 0,03 0,03 0,01 0,01 0,1 0,03 0,05 0,78 7%
PFR2 0,12 0,12 0,11 0,09 0,04 0,16 0,04 0,01 0,13 0,03 0,05 0,9 8%
PFR3 0,14 0,14 0,12 0,09 0,03 0,22 0,21 0,05 0,13 0,03 0,05 1,21 11%
PFR4 0,07 0,08 0,08 0,05 0,02 0,01 0,01 0,01 0,03 0,02 0,04 0,41 4%
SFTR1 0,16 0,12 0,12 0,12 0,39 0,22 0,29 0,35 0,23 0,19 0,14 2,33 21%
SFTR2 0,17 0,14 0,14 0,12 0,39 0,25 0,33 0,4 0,25 0,58 0,41 3,18 29%
Figure 13 –Prioritization by value
8.5 Cost Matrix
Prioritization by cost
The following figure describes the prioritization of requirements according to the cost of
satisfying this requirement. A number and higher percentage means it costs more to satisfy this
requirement.
R1.1 R1.2 R2.3 R4.6 R5.8 PFR1 PFR2 PFR3 PFR4 SFTR1 SFTR2 sum %
R1.1 0,02 0,05 0 0,05 0,01 0,01 0,01 0,01 0,01 0,02 0,04 0,23 2%
R1.2 0,01 0,02 0,09 0,07 0,01 0,01 0,01 0,01 0,01 0,02 0,04 0,28 3%
R2.3 0,09 0 0,02 0,07 0,01 0,01 0,01 0,01 0,01 0,02 0,05 0,29 3%
R4.6 0 0 0 0,01 0,01 0,01 0,01 0,01 0,01 0,02 0,04 0,12 1%
R5.8 0,11 0,14 0,11 0,11 0,04 0,02 0,01 0,03 0,02 0,03 0,08 0,7 6%
PFR1 0,13 0,12 0,11 0,12 0,13 0,06 0,28 0,12 0,22 0,02 0,05 1,35 12%
PFR2 0,11 0,1 0,12 0,11 0,17 0,01 0,06 0,06 0,07 0,03 0,08 0,93 8%
PFR3 0,13 0,12 0,14 0,1 0,08 0,03 0,06 0,06 0,07 0,03 0,08 0,89 8%
PFR4 0,14 0,14 0,12 0,12 0,13 0,02 0,06 0,06 0,07 0,04 0,09 1,01 9%
SFTR1 0,11 0,14 0,14 0,11 0,21 0,39 0,22 0,31 0,22 0,13 0,08 2,06 19%
SFTR2 0,16 0,16 0,14 0,12 0,21 0,45 0,28 0,31 0,29 0,65 0,38 3,15 29%
Figure 14 –Prioritization by cost
8.6 Prioritization Plot
Figure 15 –Prioritization Plot
8.7 Supporting documents
1) Prioritization calculation document
2) Prioritization Plot R script

Document Hotel PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Document Hotel PDF

Transféré par

Droits d'auteur :

Formats disponibles

Software Requirements Specification for Online Room Reservation System

Software Requirements Specification

Online Room Reservation System

Version 4.0 approved

4.8.1 Class Diagram of the Process for Booking a Room ....................................................... 28

Figure 1 – System Perspective ........................................................................................................ 7

Table 2 – Definitions and Acronyms .............................................................................................. 6

Name Date Reason For Changes Version

1.2 Intended Audience and Reading Suggestions

1.3 System Scope

ORRS Online Room reservation system

OFR Other Functional Requirement

SYSF Abbreviation representing System Function – used as a prefix of function IDs

API Application Programming Interface

GDPR General Data Protection Rules

Evolution Satisfies – if artefact A is realized in the system, artefact B is realized as well

Table 2 – Definitions and Acronyms

● (n.d.). Retrieved from Agile Business Consortium:

2.1 System Perspective

Online room reservation Administrative system

Figure 1 – System Perspective

2.2 System Functions

SYSTEM FUNCTION SHELL

VER. Version of system function

Ver. System System Function Description

2.3 User Classes and Characteristics

2.4 Actor Dependency Models

It provides the visual description of a process about network of dependency relationships

Figure 3 – Example of Notation

2.4.1 System goal modeling

GOAL ID Unique identification code of goal

Goal ID Goal Name Goal Description Traceability attribute

G13 Contact by Customers can contact hotel manager by phone or

2.4.2 Actors dependencies in a traditional approach

Customer: A person who is interested to book a room

Figure 4 – ORRS Actor dependency model

2.4.3 Actors dependencies in the software intensive system

Customer: A person who is interested to book a room

Figure 5 – ORRS technical actor dependency model

2.5 Goal Modelling

Figure 6 – ORRS System KAOS Goal Model

2.6 Operating Environment

2.7 Design and Implementation Constraints

2.8 Assumptions and Dependencies

3. System Functional Requirements

3.1 Checking Availability Page

VER. Version of requirement

TRACEABILITY ATTRIBUTE Traceability relation to other artefacts

Requirement Shell in the table:

Note: * denotes mandatory field

3.2 Selection of a Room Page

Ver. Req ID Description Prioritization Traceability

V1 R2.1 Check the availability of rooms High Precondition to R2.2

V1 R2.3 Page shall have sorting function to sort by price High

V1 R2.4 Price shall be displayed in Euros High Miscellaneous of

V1 R2.5 Page shall display button to previous page with High

V1 R2.6 Page shall display cancel button which will High

3.3 Customer Details Page

Ver. Req ID Description Prioritization Traceability

V1 R3.1* Page shall display text field for Firstname High

V1 R3.2* Page shall display text field for Lastname High

V1 R3.3* Page shall display field for Telephone number Medium

V1 R3.4* Page shall display field for E-mail address High