1. 0
Hotel Reservation System
G S U I n n o v a t o r s
Shweta Dasgupta
James Li
Lauren Robinson
Terrance Taylor
CSC 4350/6350 Software Engineering
S p r i n g 2 0 1 5
4 / 2 / 2 0 1 5

2. 1
Table of Contents
1.0 Version Control.............................................................................................................................4
2.0 Summary of system.......................................................................................................................5
2.1 Scope of the System..................................................................................................................5
2.2 System/Project Rationale...........................................................................................................5
3.0 Work Document............................................................................................................................6
4.0 Horizontal Prototype.....................................................................................................................7
5.0 System Requirements....................................................................................................................9
5.1 Functional Requirements...........................................................................................................9
5.2 Nonfunctional Requirements ...................................................................................................10
5.3 Requirements Traceability Matrix.............................................................................................11
6.0 Use cases and Interaction Diagrams.............................................................................................17
6.1 Access ....................................................................................................................................17
6.1.1 Access HRS .......................................................................................................................17
6.1.2 Access Internal HRS...........................................................................................................18
6.2 Make a Reservation.................................................................................................................19
6.2.1 Specify Dates for the reservation .......................................................................................19
6.2.2 Number of rooms needed for the reservation.....................................................................20
6.2.3 Type of room needed........................................................................................................21
6.2.4 System calculates reservation amount ...............................................................................22
6.2.5 User makes payment for the reservation............................................................................24
6.2.6 Add contact information – without user registration..........................................................25
6.2.7 Reservation confirmation ..................................................................................................26
6.3 Existing Reservation ................................................................................................................27
6.3.1 User views existing reservation..........................................................................................27
6.3.2 User edits existing reservation...........................................................................................28
6.3.3 User cancels existing reservation .......................................................................................29
6.3.4 User accesses help and support page.................................................................................31
6.4 Registration ............................................................................................................................32
6.4.1 User registers....................................................................................................................32
6.4.2 Registered user sees reservationlogs.................................................................................32

3. 2
6.5 Internal Users..........................................................................................................................33
6.5.1 Internal users check in/out guests......................................................................................33
6.5.2 Internal users access cleaning system.................................................................................33
6.5.3 Permission groups.............................................................................................................34
6.5.4 Adding new rooms............................................................................................................34
6.5.5 Edit existing room type, rate and number of rooms.............................................................35
6.5.6 Create staff profiles...........................................................................................................35
6.5.7 Update and Delete Staff profiles........................................................................................36
6.5.8 Internal users update cleaning room status ........................................................................37
6.6 System....................................................................................................................................38
6.6.1 System updates cleaning room status.................................................................................38
6.6.2 System information storage - user profiles..........................................................................39
6.6.3 System authenticates paymentinformation .......................................................................39
6.6.4 System information storage...............................................................................................40
6.6.5 System Availability............................................................................................................40
6.6.6 System back up.................................................................................................................41
6.6.7 Data Architecture standards..............................................................................................42
7.0 Gantt Chart.................................................................................................................................44
...........................................................................................................................................................
8.0 Function Point Cost Analysis........................................................................................................45
9.0 Software Architecture .................................................................................................................46
9.1 Software.................................................................................................................................46
9.2 Database ................................................................................................................................46
10.0 Category Interaction Diagram ....................................................................................................47
11.0 Object Design Document...........................................................................................................48
11.1 Introduction..........................................................................................................................48
11.1.1 Object design trade-offs..................................................................................................48
11.1.1.1 Memory Space vs. Response Time.............................................................................48
11.1.1.2 Developmental Cost vs. Functionality.........................................................................48
11.1.1.3 Buy vs. Build.............................................................................................................48
11.1.2 Interface documentation guidelines.................................................................................48

4. 3
11.1.2.1 Naming Conventions.................................................................................................49
11.2. Packages..............................................................................................................................49
11.3. Class interfaces.....................................................................................................................50
11.3.1 Reservation.....................................................................................................................50
11.3.2 Availability......................................................................................................................50
11.3.3 Admin.............................................................................................................................51
11.3.4 Guest..............................................................................................................................51
11.3.5 Receptionist....................................................................................................................51
11.3.6 House keeping................................................................................................................52
11.3.7 Room .............................................................................................................................52
12.0 Object Design Diagram..............................................................................................................53
13.0 Interface Design Screenshots.....................................................................................................54
14.0 Project Rationale.......................................................................................................................59
14.1 Conceptualization Rationale:..................................................................................................59
14.2 Scope Rationale.....................................................................................................................60
14.3 Project Charter Rationale:......................................................................................................61
14.4 Requirements Analysis Rationale:...........................................................................................61
14.5 Use Cases Rationale:..............................................................................................................62
14.6 Design and Implementation Rationale ....................................................................................63
14.7 Testing Rationale...................................................................................................................63
15.0 Test Cases.................................................................................................................................64
16.0 Definitions and Acronyms..........................................................................................................82
16.1Acronyms...............................................................................................................................82
16.2Definitions.............................................................................................................................82
17.0 References................................................................................................................................83

5. 4
1.0 VersionControl
Version Rev # Date Author
0.1 1.0 2/3/2015 James Li
0.2 1.0 2/4/2015 Lauren Robinson
0.2 2.0 2/5/2015 Shweta Dasgupta
0.3 1.0 2/18/2015 Shweta Dasgupta
0.4 1.0 3/8/2015 Lauren Robinson
0.5 1.0 3/12/2015 LaurenRobinson, ShwetaDasgupta
0.6 1.0 3/25/2015 Shweta Dasgupta
0.7 1.0 3/30/2015 Lauren Robinson

6. 5
2.0 Summary of system
The primaryobjective of the system istocreate a Hotel Management System(HRS).Thissystemisa
desktopapplicationwhichallowsuserstoreserve ahotel room(s).The softwareintendstohave an
interactive userinterface thatallowsforbothcustomersandinternal administrationtohave accessto
the system.
2.1 Scope of the System
The scope of the systemisto create runningsoftware thatallowsuserstomake hotel reservations.The
overall hotel managementsystemalsoallowsinternaluserslikeadministrative staffandcleaningstaff to
have access tothe cleaningsystemandthe reservationsystem.The scope of thissystemisalsotoallow
usersto make changesto an existingreservation.
2.2 System/Project Rationale
The goal of the HMS is to give usersa seamless,intuitive waytocreate a hotel reservation.Planning
vacationsisstressful enoughandwithHMS,guestwill have one lessthingtoworryabout.HMS will
allowuserstocreate reservations,cancel reservationsandview existingreservations.HMSalso
encompassesfunctionalityformaintainingthe cleaningof rooms,toverifythata room has beencleaned
already,oris inneedof cleaning.WithHMS bothguestsand hotel staff will be able toresteasyknowing
theirinformationisingoodhands.

7. 6
3.0 Work Document
Terrence Taylor
Terrence is a senior at GSU and hopes to get his bachelors by the end of this year or Spring of
next year. T, short for Terrence is an Atlanta native but his parents were born in Liberia. Terrence likes to
travel whenever he gets the chance. T is currently looking for internships to gain hands-on experience in
the computer science field. He is most familiar with Java and is using this project to gain more hands– on
experience in Programming.
Role: Technical writer, Document Contributor, Co-developer
Responsibilities:
Lauren Robinson
Lauren holds Bachelors in Computer Science from Georgia Southern. She has been in the IT field
since 2007. She has held several positions in the field starting from the Huddle House and now at
Georgia Tech where she has been for 3 years and is responsible for app dev., enhancement and support.
Lauren has hands on experience with Coldfusion and SQL. She is currently enrolled in the Masters of
Computer Science program.
Role: Tester, Technical Documenter & contributor
Responsibilities: Documentation, Contributor, Test Lead
James Li
James is in his senior year and all the courses that he has taken gives him a solid foundation in
Java. He believes he is highly motivated and works well in a team environment. He believes working in a
team environment allows him to learn new things and ideas from teammates that would help him to
come up with new ideas.
Role: Developer
Responsibilities: Development, Solution Design, Contributor
Shweta Dasgupta
Shweta is an Enterprise Architect by profession. She has diverse global experience in managing IT
and Engineering projects. She has a passion for Digital Enterprise strategies and Business Architectural
frameworks. She is also an artist and loves to paint during free time. She is also a trained Classical singer
and performs at cultural events.
Role: Solution Architect, Project Manager
Responsibilities: Project Manager, Solution definition and Technical documenter

8. 7
4.0 Horizontal Prototype

9. 8

10. 9
5.0 SystemRequirements
5.1 Functional Requirements
Thissectionisa detailedrequirementselicitationsectionthatisspreadacrosselevencategories.
These include bothfunctional andnon-functional requirements.The requirementswill be tracedinto
theirrespective categoriesinthe RTM.Listedbelow are requirementsthatintendtoserve three typesof
usercommunities –Internal,External andSystem.
The systemshall consistof twodifferentusergroups,internal andexternal.External usergroup
shall containpermissionsetstoallowcustomerstoaccessthe system.External usersshall alsobe able
to access the systemwithoutrequiringpermissions.Internalusergroupshall containpermissionsetsto
allowadministratorsandstaff toaccessthe system.
The customershall be able to complete creatingareservation.Theyshallbe able tospecifythe
datesneededof the reservation.Theyshall be allowedtospecifythe numberof roomsneededforthe
reservation.The customershall be able tospecifythe type of roomneeded.The systemshallreturnthe
resultsfromthe userquery(includingprice),ortell the usersnoroomsare available.The systemshall
showthe total amountof the reservation,includingall roomsandall days,plustax.
If the customerchoosestocontinue,the systemshall allow the customertoinputpayment
information.The systemshallverifythatavalidcreditcard has beenentered.The systemshall also
allowthe userto inputtheircontactinformation(name,address,phonenumber,email).The system
shall write all information enteredtothe textfile(s)forthe selectedroom(s) andshall show he customer
a confirmationpage.The systemshall sendanemail confirmationuponsuccessful completionof a
reservation.Once the registrationiscomplete,the systemshall writecustomer registrationinfointothe
textfile
The systemshall allowexternal userstocreate customerprofiles. The systemshall allow the
customerto loginand be able tosee past,presentandfuture reservations.The customershall alsobe
able to viewanexistingreservation.The customershall be able toeditanexistingreservation.The
customershall be able tocancel an existingreservation.The customershall be allowedtoaccessHelp
and Supportpage.
The systemshall allowadministrative staff tocheckinandcheck out customers.The system
shall allowadministrative staff toaccessroomcleaningstatus.The systemshall allow cleaningstaff to
access roomcleaningstatus.The systemshall allow cleaningstaff toupdate roomcleaningstatus.The
systemshall write newandupdatedcleaningstatusintothe textfile(s).The systemshallchange the
statusof the room cleaningto‘NC’(NeedsCleaning) uponcheckoutoradate passedthe endbooking
date for that room.Once a roomhas beencleaned,the system shallwrite the new statustothe text
file(s)(‘A’ –Available).

11. 10
The administratorshall have accessmultiple functionalities,includingeditingrooms,creating
profilesandreporting.Thesefunctionalitiesshall be available uponloggingin.
The administratorshall be able toadd new roomsand editexistingroom.The editingrooms
shall consistof beingable toeditthe roomtype and room rate.The addingof new roomsshall allowthe
administratortoenterroomtype and roomrate. The systemshall write thisinfotoa file,includingan
initial statusof ‘A’.
The administratorshall be able torun reports.The administrative reportsshall include:available
rooms,occupiedrooms,roomsneedingcleaning.The administratorshall alsobe able toexportthe
reportsto excel.
The administratorshall be able tocreate staff profiles.The systemshall allowthe administrator
to put ina username andemail addressforthe staff memberforthemtobe able touse to logintothe
system.The systemshall alsoallowthe administratortoremove staff.The systemshall alloweditingthe
numberof roomsavailable.
Thissystemshall containtextfilesthatshall be usedtostore reservation,staffingandprofile
information.There shallbe one textfileforeachroom.Reservationinformationshall be savedtothe
textfile.There shall alsobe atextfile thathasuserprofile information,includingusername andaccess
for administratorsandstaff.
5.2 Nonfunctional Requirements
The systemshall implementuserfriendlyandintuitivedesign.The GUIof the systemshall have
appropriate contrastratiosand designedtobe 508 compliant.The systemneedstobe available for
99.95% withan RPO of < 4hrs. The systemshall be portable onmostdesktopcomputers,andshall be
supportedonIE v8+, Firefox andChrome.The GUI shall containa title anda logoof the hotel
reservationsystem.The customerbillinginformationstoredinatextfile shall be encrypted.The
program shall have a fastresponse time.The datastoredinthe textfilesshall be backedup daily
incremental (onsite) &weeklyfull (onsite).The datadesignshall follow SIDframework

12. 11
5.3 Requirements Traceability Matrix
(Numberedbysentence)
Req.
#
Section Paragraph Req-Type Role Type Category RequirementDescription Use case ID Use case Name
1 5.1 2.1 SW User Groups Accessand permissions
The systemshall consistof two
differentusergroups,internal and
external.
UC-18 Permissiongroups
2 5.1 2.2 SW User Groups Accessand permissions
External usersshall alsobe able to
access the systemwithoutrequiring
permissions.
UC-01 AccessHRS
3 5.1 2.3 SW User Groups Accessand permissions
External usergroupshall contain
permissionsetstoallowcustomers
to access the system
UC-18 Permissiongroups
4 5.1 2.4 SW User Groups Accessand permissions
Internal usergroupshall contain
permissionsetstoallow
administratorsandstaff toaccess
the system
UC-02 AccessInternal HRS
5 5.1 3.1 SWC External Make a new Reservation
The customershall be able to
complete creatingareservation.
UC-03, UC-04, UC-05,UC-
06, UC-07, UC-08
Make a reservation
6 5.1 3.2 SW External Make a new Reservation
The customershall be able to
specifythe datesneededof the
reservation
UC-03
SpecifyDatesforthe
reservation
7 5.1 3.3 SW External Make a new Reservation
The customershall be allowedto
specifythe numberof rooms
neededforthe reservation
UC-04
Numberof roomsneeded
for the reservation
8 5.1 3.4 SW External Make a new Reservation
The customershall be able to
specifythe type of roomneeded
UC-05 Type of roomneeded
9 5.1 3.5 SW
External,Internal,
System
Implementation
The systemshall returnthe results
fromthe userquery(including
price),ortell the usersnorooms are
available
UC-06
Systemcalculates
reservationamount
10 5.1 3.6 SW
External, Internal,
System
Pricing
The systemshall showthe total
amountof the reservation,including
all roomsand all days,plustax
UC-06
Systemcalculates
reservationamount
11 5.1 4.1 SW External Bill Pay
The systemshall allowthe customer
to inputpaymentinformation
UC-07
User makespaymentfor
the reservation
12 5.1 4.2 SW Internal Bill Pay
The systemshall verifythatavalid
creditcard has beenentered
UC-26
Systemauthenticates
paymentinformation

13. 12
Req.
#
Section Paragraph Req-Type Role Type Category RequirementDescription Use case ID Use case Name
13 5.1 4.3 SW External Contact Information
The systemshall alsoallowthe user
to inputtheircontactinformation
(name,address,phone number,
email)
UC-08
Addcontact information -
withoutregistration
14 5.1 4.4 SW System Implementation
The systemshall write all
informationenteredtothe text
file(s)forthe selectedroom(s) and
shall showhe customera
confirmationpage
UC-25 Systeminformationstorage
15 5.1 4.5 SW External Reservation Confirmation
The systemshall sendanemail
confirmationuponsuccessful
completionof areservation.
UC-09 Reservationconfirmation
16 5.1 4.6 SW System Implementation
The systemshall write customer
registrationinfointothe textfile
UC-27 Systeminformationstorage
17 5.1 5.1 SWC External Register
The systemshall allowexternal
usersto create customerprofiles
UC-14 User registers
18 5.1 5.2 SW External Register
The systemshall allowthe customer
to login andbe able tosee past,
presentand future reservations
UC-15
Registeredusersees
reservationlogs
19 5.1 5.3 SW External View anexistingreservation
The customershall alsobe able to
viewanexistingreservation
UC-10
User viewsexisting
reservation
20 5.1 5.4 SW External Editan existingreservation
The customershall be able to edit
an existingreservation
UC-11
User editsexisting
reservation
21 5.1 5.5 SW External Cancel an existingreservation
The customershall be able to cancel
an existingreservation
UC-12
User cancelsexisting
reservation
22 5.1 5.6 SW External Helpand support
The customershall be allowedto
access HelpandSupportpage
UC-13
User accesseshelpand
supportpage
23 5.1 6.1 SW Internal Check-in/out
The systemshall allow
administrativestaff tocheck inand
checkout customers
UC-16
Internal userscheckin/out
guests
24 5.1 6.2 SW Internal CleaningStatus
The systemshall allow
administrativestaff toaccessroom
cleaningstatus
UC-16
Internal usersaccess
cleaningsystem
25 5.1 6.3 SW Internal CleaningStatus
The systemshall allowcleaningstaff
to access roomcleaningstatus
UC-16
Internal usersaccess
cleaningsystem

14. 13
Req.
#
Section Paragraph Req-Type Role Type Category RequirementDescription Use case ID Use case Name
26 5.1 6.4 SW Internal CleaningStatus
The systemshall allowcleaningstaff
to update roomcleaningstatus
UC-16
Internal usersupdate
cleaningroomstatus
27 5.1 6.5 SW System Implementation
The systemshall write newand
updatedcleaning statusintothe
textfile(s)
UC-24
Systemupdatescleaning
room status
28 5.1 6.6 SW System Implementation
The systemshall change the status
of the roomcleaningto‘NC’(Needs
Cleaning)
UC-24
Systemupdatescleaning
room status
29 5.1 SW Internal CleaningStatus
The staff shall be able to selectthe
roomscleanedinthe system
UC-23
Internal usersupdate
cleaningroomstatus
30 5.1 6.7 SW System Implementation
The systemshall write the new
statusto the textfile(s) (‘A’ –
Available)
UC-19 Addingnewrooms
31 5.1 7.1 SW Internal Accessand permissions
The administratorshall have access
multiple functionalities,including
editingrooms,andreporting
UC-18 Permissiongroups
32 5.1 7.2 SW Internal Accessand permissions
The administratorshall be able to
access these functionalitiesupon
login.
UC-02 AccessInternal HRS
33 5.1 8.1 SW Internal Accessand permissions
The administratorshall be able to
add newroomsand editexisting
room
UC-19 Addingnewrooms
34 5.1 8.2 SW System Availability
The editingroomsshall consistof
beingable toeditthe roomtype and
room rate
UC-20
Editexistingroomtype,
rate andnumberof rooms
35 5.1 8.3 SW Internal Pricing
The addingof newroomsshall allow
the administratortoenterroom
type and roomrate
UC-19 Addingnewrooms
36 5.1 8.4 SW System Implementation
The systemshall write thisinfotoa
file,includinganinitialstatusof ‘A’
UC-19 Addingnewrooms
37 5.1 9.1 NTH Internal Reporting
The administratorshall be able to
run reports
out of scope out of scope
38 5.1 9.2 NTH System Implementation
The administrative reportsshall
include:available rooms,occupied
rooms,roomsneedingcleaning
out of scope out of scope

15. 14
Req.
#
Section Paragraph Req-Type Role Type Category RequirementDescription Use case ID Use case Name
39 5.1 9.3 NTH Internal Reporting
The administratorshall alsobe able
to exportthe reportsto excel.
out of scope out of scope
40 5.1 10.1 SW Internal Register
The administratorshall be able to
create staff profiles
UC-21 Create staff profiles
41 5.1 10.2 SW Internal Accessand permissions
The systemshall allowthe
administratortoputin a username
and email addressforthe staff
memberforthemto be able to use
to logintothe system
UC-21 Create staff profiles
42 5.1 10.3 SW User Groups Accessand permissions
The systemshall alsoallowthe
administratortoremove staff
UC-22
Update and Delete Staff
profiles
43 5.1 10.4 SW Internal Availability
The systemshall alloweditingthe
numberof rooms available.
UC-23
Editexistingroomtype,
rate andnumberof rooms
44 5.1 11.1 SW System Implementation
Thissystemshall containtextfiles
that shall be usedtostore
reservation,staffingandprofile
information
UC-27 Systeminformationstorage
45 5.1 11.2 SW System Implementation
There shall be one textfile foreach
room
UC-27 Systeminformationstorage
46 5.1 11.3 SWC System Implementation
Reservationinformationshall be
savedto the textfile
UC-27 Systeminformationstorage
47 5.1 11.4 SWC System Implementation
There shall alsobe a textfile that
has userprofile information,
includingusernameandaccessfor
administratorsandstaff
UC-25
Systeminformationstorage
- userprofiles
48 5.2 1.1 SW System Implementation
The systemshall implementuser
friendlyandintuitivedesign
UC-31 GUI Design
49 5.2 1.2 SW System Implementation
The GUI of the systemshall have
appropriate contrastratiosand
designedtobe 508 compliant
UC-31 GUI Design
50 5.2 1.3 NTH System Implementation
The systemneedstobe available for
99.95% withan RPO of < 4hrs
UC-28 Systemavailability
51 5.2 1.4 HW System Implementation
The systemshall be portable on
mostdesktopcomputers,andshall
be supportedonIE v8+, Firefox and
Chrome
out of scope out of scope
52 5.2 1.5 SW System Implementation
The GUI shall containa title anda
logoof the hotel reservationsystem.
out of scope out of scope

16. 15
Req.
#
Section Paragraph Req-Type Role Type Category RequirementDescription Use case ID Use case Name
53 5.2 1.6 SW System Bill Pay
The customerbillinginformation
storedina textfile shall be
encrypted
out of scope out of scope
54 5.2 1.7 SW System Implementation
The program shall have a fast
response time
UC-28 Systemavailability
55 5.2 1.8 NTH System Implementation
The data storedin the textfilesshall
be backedup dailyincremental
(onsite) &weeklyfull (onsite).
UC-29 Systemstorage - back up
56 5.2 1.9 SW System Implementation
The data designshall follow SID
framework
UC-30
Data Architecture
standards

17. 16
5.3 Use case Matrix
Usecase # Use case Category Usecase Title In Scope/ Out of Scope
UC-01 Access AccessHRS In scope
UC-02 AccessInternal HRS In scope
UC-03 Make a reservation SpecifyDatesforthe reservation In scope
UC-04 Numberof roomsneededforthe reservation In scope
UC-05 Type of roomneeded In scope
UC-06 Systemcalculatesreservationamount In scope
UC-07 User makespaymentforthe reservation In scope
UC-08 Addcontact information - withoutregistration In scope
UC-09 Registrationconfirmation In scope
UC-10 ExistingReservation User viewsexistingreservation In scope
UC-11 User editsexistingreservation In scope
UC-12 User cancelsexistingreservation In scope
UC-13 User accesseshelpand supportpage In scope
UC-14 Registration User registers In scope
UC-15 Registereduserseesreservationlogs In scope
UC-16 Internal Users Internal userscheckin/outguests In scope
UC-17 Internal usersaccesscleaningsystem In scope
UC-18 Permissionsets In scope
UC-19 Addingnew rooms In scope
UC-20 Editexistingroomtype,rate andnumberof rooms In scope
UC-21 Create staff profiles In scope
UC-22 Update and Delete Staff profiles In scope
UC-23 Internal usersupdate cleaningroomstatus In scope
UC-24 System Systemupdatescleaningroomstatus In scope
UC-25 Systeminformationstorage - userprofiles In scope
UC-26 Systemauthenticatespaymentinformation In scope
UC-27 Systeminformationstorage In scope
UC-28 SystemAvailability In scope
UC-29 SystemCompliance In scope
UC-30 Data Architecture standards In scope
UC-31 GUI Design out of scope
UC-32 SystemSecurity out of scope
UC-33 Systembackup out of scope

18. 17
6.0 Use cases and InteractionDiagrams
6.1 Access
6.1.1 Access HRS
Thisuse case helpsinthe developmentof all functionalityrelatedtoAccesstothe HRS
PC-REQ-10 Use Case Name
PC-REQ-20 Access HRS
PC-REQ-30 Use case ID
PC-REQ-40 UC- 01
PC-REQ-50 Use case actorsPC-REQ-60 Internal Users, External Users, System
PC-REQ-70 Flow of events
1. A user types in the url to the HRS
2.System responds by showinginterface to the HRS
PC-REQ-80 Entry conditions
PC-REQ-90 An existing portal that supports the HRS
PC-REQ-100 Exit conditionsPC-REQ-110

19. 18
6.1.2 Access Internal HRS
Thisuse case helpsindeterminingaccess relatedtothe Internal HRS.Internal HRSis a subsystemunder
the overall HRS.
PC-REQ-120 Use Case Name
PC-REQ-130 Access Internal HRS
PC-REQ-140 Use case IDPC-REQ-150 UC- 02
PC-REQ-160 Use case actors
PC-REQ-170 Internal Users, System
PC-REQ-180 Flow of events
1. A user accesses the HRS System
2. User then authenticates identity
3. The systemauthenticates and authorizes the user with associated
permission
4. Takes user to the Internal HRS system
PC-REQ-190 Entry conditions
PC-REQ-200 User has a user ID and password
PC-REQ-210 User has necessary access privileges
PC-REQ-220 Exit conditions
PC-REQ-230 An existing systemthat supports the Internal HRS functionality

20. 19
6.2 Make a Reservation
6.2.1 SpecifyDates for the reservation
Thisuse case helpsinthe developmentof makingareservationwhere the userisrequiredtospecify
datesof the reservation.
PC-REQ-240 Use Case Name
PC-REQ-250 Specify dates for the reservation
PC-REQ-260 Use case ID
PC-REQ-270 UC- 03
PC-REQ-280 Use case actors
PC-REQ-290 Internal Users, External Users, System
PC-REQ-300 Flow of events
1. User accesses the HRS.
2. User attempts to make a reservation
3. User is allowed to enter the dates of reservation
PC-REQ-310 Entry conditions
PC-REQ-320 An internal user is in the Internal HRS
PC-REQ-330 An external user is in the External HRS
PC-REQ-340 Exit conditions
PC-REQ-350 The systemchecks availability for the user specified reservation dates and
displays results.

21. 20
6.2.2 Numberof rooms neededforthe reservation
Thisuse case helps determine the numberof roomsthatthe userisintendingtoreserve forthe
reservationdatesspecified.
PC-REQ-360 Use Case Name
PC-REQ-370 Number of rooms needed for the reservation
PC-REQ-380 Use case ID
PC-REQ-390 UC- 04
PC-REQ-400 Use case actors
PC-REQ-410 Internal Users, External Users, System
PC-REQ-420 Flow of events
1. User is on the HRS.
2. User enters the dates of the reservation
3. System displays availability
4. User specifies the number of rooms needed
PC-REQ-430 Entry conditions
PC-REQ-440 An internal user is in the Internal HRS
PC-REQ-450 An external user is in the External HRS
PC-REQ-460 Rooms in the specified date range are available
PC-REQ-470 Exit conditions
PC-REQ-480 The systemchecks availability for the user specified number of rooms and
displays results.

22. 21
6.2.3 Type of room needed
Thisuse case helpsdetermine the roomtype neededforthe saidreservation.
PC-REQ-490 Use Case Name
PC-REQ-500 Type of room needed
PC-REQ-510 Use case ID
PC-REQ-520 UC- 05
PC-REQ-530 Use case actors
PC-REQ-540 Internal Users, External Users, System
PC-REQ-550 Flow of events
1. User is on the HRS.
2. User enters the dates of the reservation
3. User specifies the number of rooms needed
4. User specifies the type of room needed or chooses from the drop
down
PC-REQ-560 Entry conditions
PC-REQ-570 An internal user is in the Internal HRS
PC-REQ-580 An external user is in the External HRS
PC-REQ-590 Rooms in the specified date range are available
PC-REQ-600 Exit conditions
PC-REQ-610 The systemchecks availability for the user specified type of rooms and
displays results.

23. 22
6.2.4 System calculatesreservationamount
Thisuse case helpsinunderstandingthe developmentof the systemsresponse incalculatingthe
reservationamountforthe reservation.
PC-REQ-620 Use Case Name
PC-REQ-630 System calculates reservation amount
PC-REQ-640 Use case ID
PC-REQ-650 UC- 06
PC-REQ-660 Use case actors
PC-REQ-670 System
PC-REQ-680 Flow of events 1. User enters the dates of the reservation, type of room needed and
the number of rooms needed.
2. User makes a selection
3. System checks the rate chart and returns the amount due for the
reservation
PC-REQ-690 Entry conditions
PC-REQ-700 Rooms in the specified date range are available
PC-REQ-710 Rate per room and type is pre calculated and stored
PC-REQ-720 Exit conditions
PC-REQ-730 System blocks the specified room type, number of room for the dates with
the returned cost on hold until 15 minutes.

24. 23

25. 24
6.2.5 User makes paymentfor the reservation
PC-REQ-740 Use Case Name
PC-REQ-750 User makes payment for the reservation
PC-REQ-760 Use case ID
PC-REQ-770 UC- 07
PC-REQ-780 Use case actors
PC-REQ-790 Internal User or External User, HRS Payment System
PC-REQ-800 Flow of events
1. User confirms reservation and proceeds to payment
2. System takes user to the HRS payment system
3. User chooses the method of payment and enters credentials
4. The payment information is entered
5. The payment system validates the credentials and accepts
payments
PC-REQ-810 Entry conditions
PC-REQ-820 User accepts the reservation rate and proceeds ahead
PC-REQ-830 User has an acceptable method of payment available for online payment
PC-REQ-840 Payment system is able to validate, authenticate and accept payments
PC-REQ-850 Exit conditionsPC-REQ-860 System uses secure encryption and decryption for payments made.

26. 25
6.2.6 Add contact information– without user registration
Thisuse case helpsingettinguser’scontactinformationforthe systemtobe able tosendreservation
notificationslike confirmationsorcancellationstothe user.Thisuse case isintendedtowardsexternal
userswhochoose not to registerwiththe HRS
PC-REQ-870 Use Case Name
PC-REQ-880 Add contact information - without registration
PC-REQ-890 Use case ID
PC-REQ-900 UC- 08
PC-REQ-910 Use case actorsPC-REQ-920 Internal Users or External Users, HRS System
PC-REQ-930 Flow of events
1. User makes a payment for a reservation
2. System prompts users to enter contact information like email id,
phone number and address
3. System stores this information and associated this with the
reservation
PC-REQ-940 Entry conditions
PC-REQ-950 Existing reservation with payment made
PC-REQ-960
PC-REQ-970 Exit conditionsPC-REQ-980 System stores contact information with reservation associated with it.

27. 26
6.2.7 Reservation confirmation
PC-REQ-990 Use Case Name
Reservation Confirmation
Use case ID
UC- 09
Use case actors
System
Flow of events
1. User makes payment for a reservation
2. User inputs contact information
3. System sends out automated email with reservation dates, room
type and payment confirmation to the provided user email id
4. System also sends out confirmation number in the email
Entry conditions
Existing reservation with payment made
Existing user contact information - email
Exit conditions --

28. 27
6.3 Existing Reservation
6.3.1 User viewsexistingreservation

29. 28
6.3.2 User editsexistingreservation
Thisuse case helpsinthe understandingof a scenariowhere auserintendstoeditandexisting
Use Case Name
Existing Reservation
Use case ID
UC- 10
Use case actors
Internal Users, External Users, System
Flow of events 1. User navigates to manage booking portal
2. User enters confirmation number
3. System validates confirmation number and displays associated
booking
Alternate flow 4. User logs in to the HRS
5. User navigates to manage booking portal
6. System displays all bookings made by the user
Entry conditions
Sub portal to manage bookings
Existing Reservation confirmation number
Existing active or historic reservation
Exit conditions --

30. 29
reservation.
6.3.3 User cancelsexistingreservation
Use Case Name
User edits existing reservation
Use case ID
UC- 11
Use case actors
Internal Users, External Users, System
Flow of events
1. User views existing reservation
2. User clicks on edit reservation to make changes to the room type
or dates of reservation
Entry conditions  Existing active reservation
 Sub portal to manage bookings
 Reservation is eligible for change
Exit conditions  System checks for eligibility of change reservation and proceeds
further if eligible
 System checks for eligibility of change reservation and displays
ineligibility message if reservation is ineligible for change.
 System checks availability and returns price if available
 System checks availability and returns unavailability message if
rooms are unavailable for the specified dates
 System checks availability and returns available room type.

31. 30
Use Case Name User cancels existing reservation
Use case ID
UC- 12
Use case actors
Internal Users, External Users, System
Flow of events
1. User clicks on edit reservation to make changes to the room type
or dates of reservation
2. System checks for eligibility and returns eligibility message
3. User clicks on cancel reservation
4. System cancels the reservation
Entry conditions
Existing active reservation
Sub portal to manage bookings
Reservation is eligible for change
Exit conditions
System processes refund
System makes the reserved room and room type available for the dates it
was initially reserved

32. 31
6.3.4 User accesseshelpand support page
Thisuse case helpsinthe designof the functionalityrelateduserhelpandsupport
Use Case Name
User accesses help and support page
Use case ID
UC- 13
Use case actors
Internal Users, External Users
Flow of events
1. User clicks on help and support tab
2. System responds by taking the user to the help and support page
Entry conditions
Existing help and support page
Available pre built FAQs
Customer service number displayed
Live chat functionality built
Exit conditions

33. 32
6.4 Registration
Thissectioncoversuse casesrelatedtouserregistration –both Internal andexternal users.
6.4.1 User registers
6.4.2 Registereduserseesreservationlogs
Thisuse case helpsaregisteredreturningusertoview historicreservations.
Use Case Name User Registers
Use case ID
UC- 14
Use case actors
Internal Users, External Users
Flow of events 1. User navigates to the registration page
2. System provides
Entry conditions
Existing help and support page
Available pre built FAQs
Customer service number displayed
Live chat functionality built
Exit conditions --
Use Case Name Registered user sees reservation logs
Use case ID
UC- 15
Use case actors
Internal Users, External Users
Flow of events 1. User navigates to Manage Reservation page
2. User navigates to ‘My reservations’
3. System displays all the reservations associated with the user
Entry conditions
User is an active registered user.
Exit conditions --

34. 33
6.5 Internal Users
Thissectioncoversall the use casesrelatedtointernal users.
6.5.1 Internal userscheck in/out guests
Thisuse case describesthe howInternal usersare providedwiththe functionalityof checkin/out.
Use Case Name Check in/Check-Out
Use case ID UC- 16
Use case actors Internal Users,System
Flow Of Events 1. User logs into HRS
2. User selects Check-In/Check-Out
3. System returns form
4. User enters reservation number and submits
5. System responds by displaying the reservation
6. User checks in/ out
Entry Conditions  User is an active, registered and an internal user
Exit Conditions  System responds by updating the status
6.5.2 Internal usersaccess cleaningsystem
Thisuse case helpsunderstandhowcleaningmanagementsystemisasub systemwithinHRSandhow
Internal usersaccessit.
Use Case Name Internal users access cleaningsystem
Use case ID UC-17
Participating Actors Internal users,System, CMS
Flow Of Events 1. User logs into HRS
2. User navigates to the CMS
3. CMS responds by taking the user to the CMS interface
Entry Condition  User is an internal, active and registered user
Exit Condition  System displays rooms, cleaning status and assigned to
information
Quality Requirements  Rooms status can be changed to cleaned in under 30 seconds

35. 34
6.5.3 Permissiongroups
Thisuse case helpsinthe understandingthe variouspermissiongroupswithvariouspermissionsets
withinHRS
Use Case Name Permission groups
Use case ID UC- 18
Use case actors System, Internal users
Flow Of Events
1. System admin sets permission groups
2. System authorizes admin to set access permission sets and
create permission groups for internal and external users
Entry Conditions  System admin is pre- identified in the program
Exit Conditions  System initiates permissions.
6.5.4 Adding newrooms
Thisuse case helpsinprovidinginternal usersthe functionalityof Addingnew roomstothe hotel
inventory
Use Case Name Adding new rooms
Use case ID UC - 19
Use case actors Internal users,System
Flow Of Events 1. User logs in into the Internal HRS
2. System authorizes an internal user with admin or managerial
privileges to access rooms inventory
3. User navigates to ‘ room inventory’ and further navigates to
add new rooms with appropriate room type and availability
date
Entry Condition  User is logged into the system
 User is an internal user with admin or managerial permissions
Exit Condition  System updates room inventory with the new number of
rooms and appropriate room types

36. 35
6.5.5 Edit existingroomtype, rate and number ofrooms
Thisuse case helpsprovide internal usersthe functionalitytoeditexistingroomtype,rate andnumber
of rooms.
Use Case Name Edit existingroom type, rate and number of rooms
Use case ID UC - 20
Use case actors Internal users,System
Flow Of Events 1. User logs in into the Internal HRS
2. System authorizes an internal user with admin or managerial
privileges to access room inventory
3. User navigates to ‘edit rooms’
4. System responds by authorizing the user to access to be able to
edit room type, rate and delete rooms.
Entry Condition  User is logged into the system
 User is an internal user with admin or managerial permissions
Exit Condition  System updates room inventory with any changes made to
room type, room rate and number of rooms
6.5.6 Create staff profiles
Thisuse case helpsInternal userswithmanagerial oradministrativepermissionsaddnew staff profiles
to the staffinginventory.
Use Case Name Create Staff Profiles
Use case ID UC- 21
Participating Actors Internal users,System
Flow Of Events 1. User logs into the Internal HRS
2. User navigates to ‘Staff profile’ page
3. System displays staff id, profile and inventory
4. User navigates to add staff to add new internal users
5. User adds internal user type to associate due permissions to
the staff profile
Entry Condition  User is logged into the system
 User is an internal user with admin or managerial permissions
Exit Condition  System generates initial user id and password and emails this
information to the user email address.

37. 36
6.5.7 Update and Delete Staffprofiles
Thisuse case helpsInternal userswithmanagerial oradministrativepermissionstoedit(make changes
to existing)staff profilesandstaffinginventory.
Use Case Name Update and Delete Staff profiles
Use case ID UC- 22
Participating Actors Internal users,System
Flow Of Events 1. User logs into the Internal HRS
2. User navigates to ‘Staff profile’ page
3. System displays staff id, profile and inventory
4. User navigates to edit staff to edit staff information
Entry Condition  User is logged into the system
 User is an internal user with admin or managerial permissions
Exit Condition  System updates staff inventory based on the changes made

38. 37
6.5.8 Internal usersupdate cleaningroom status
Thisuse case helpsinupdatingthe cleaningroomstatussothat roomsare readyfor occupancy or made
available forcleaning.
Use Case Name Internal users update cleaningroomstatus
Use case ID UC- 23
Participating Actors Internal users,System, CMS
Flow Of Events 1. User logs into the Internal HRS
2. User navigates to room inventory to gain access to the room
cleaning status
3. All rooms baseline cleaning room status to the color ‘red’
4. After cleaning the room, Internal user with access permissions
to update cleaning room status, example- cleaning staff,
update status of the room
5. System updates cleaning room status to the color ‘yellow’
6. System sends notification of updated status to the direct line
supervisor
7. Internal users with managerial permissions receive notification
of the changed status
8. Manger verifies and approves the cleaning room status
9. System changes the cleaning room status to green
Alternate flow 1. Internal user with managerial or administrative permission sets
overrides the cleaning status to red or green
2. System allows two overrides per room
3. System sends notification to the internal user’s direct line
reporting manger upon second override.
Entry Condition  User is an active registered internal user
 User is logged into the system
 Internal user is mapped to organizational chart
 Internal user is mapped to appropriate permission sets for
appropriate functionality
Exit Condition  System updates cleaning room status in the CMS.

39. 38
6.6 System
Thissectioncoversall the use casesrelatedtothe System – bothHRS and the CMS
6.6.1 System updatescleaningroom status
Thisuse case helpsinunderstandinghow the systemupdatesthe cleaningroomstatuswhenInternal
usersmake changesto it.
Use Case Name System updates cleaningroomstatus
Use case ID UC- 24
Participating Actors HRS, CMS
Flow Of Events 1. Internal users update cleaning room status in the CMS
2. CMS sends updated cleaning status information to HRS
3. HRS responds by updating rooms with cleaning status ‘green’
to be available
4. HRS responds by updating rooms with cleaning status ‘red’ and
‘yellow’ as unavailable
Alternate Flow 1. HRS updates room inventory when rooms are added internally
within HRS by internal users
2. HRS allows change of status within room inventory when new
rooms are added by Internal users with managerial or
administrative privileges
Entry Condition  HRS and CMS are integrated
Exit Condition  Cleaning room status is updated in the HRS
 Rooms with cleaning room status ‘green’ are listed in the HRS
room inventory and are made available for reservation

40. 39
6.6.2 System informationstorage - user profiles
Thisuse case helpsunderstandhowsystemstoresinformationaboutuserprofiles.
Use Case Name System information storage- user profiles
Use case ID UC- 25
Participating Actors System
Flow Of Events 1. Internal User updates Staff profile inventory
2. System requests First name, Last name, Date of Birth, SSN,
phone number , email id and Role
3. User enters all the information
4. System creates a text file for every unique SSN
5. System follow SID framework to store data
Entry Condition  Internal user is an active registered user
 If internal user is not an active or registered internal user, user
is an administrator
Exit Condition  System responds by updating the staff inventory
 System generate a unique user id and one time password
 System sends an email notification to the user email provided
 System associates permission sets with the role allocated
6.6.3 System authenticatespayment information
Thisuse case helpsinthe understandingof how a useris billedandhow paymentisprocessed.
Use Case Name System authenticates payment information
Use case ID UC- 26
Participating Actors Internal Users,External Users,HRS, 3rd party billingsystem
Flow Of Events 1. User confirms registration and proceeds to make payment
2. User selects the method of payment and enters credentials
3. HRS sends these credentials to 3rd party billing systemto
process bill
4. 3rd party billing systemprocesses payment and sends back
confirmation
5. HRS updates payment information
Entry Condition  HRS and 3rd party billing systemare integrated
Exit Condition  HRS updates payment confirmation information
 HRS sends reservation confirmation notification

41. 40
6.6.4 System informationstorage
Thisuse case describeshowthe systemstoresall data.
Use Case Name System information storage
Use case ID UC- 27
Participating Actors HRS, CMS
Flow Of Events 1. Internal and External users make changes to the inventories
2. System writes all data to a text file
3. System retrieves and refreshes the text files as needed upon
changes to the specific files
Entry Condition  Functionality built to store data in a text file
Exit Condition --
6.6.5 System Availability
Thisuse case helpsinsettingstandardsrelatedtoSystemAvailability.These standardsare derivedfrom
the ITIL framework.
Use Case Name System Availability
Use case ID UC- 28
Participating Actors HRS, CMS
Flow Of Events No relevant flow of events
Constraints System to be built per availability standards defined
Standards
Business
Criticality
Availability:
Applicationmustbe available 24x7except
inworst case failure
ProcessRecovery:
Abilitytobeginrecoveryof business
process< 4 hours inthe eventof system
failure
Data Recovery:
Loss of businessdatainthe eventof
systemfailure <4 hours
Minimum
Infrastructure
platform
specification
Hosting: Tier3 data centerfacility
Availability:
Infrastructure platform99.9% available
(excludingplannedoutages),or526
minutes unplanneddowntime
peryear
Redundancy:
Some redundantcomponents.Onplatform
failure RPO< 4 hours , RTO < 4 hours .
Disaster Recovery:
Intra Site DR solutioninplace withRPO< 4
hours, RTO < 4 hours from DR invocation
Entry Condition  Infrastructure, systemand support team available
Exit Condition --

42. 41
6.6.6 System back up
Thisuse case helps insettingstandardsrelatedtoSystemBackup.These standardsare derivedfromthe
ITIL framework.
Use Case Name System back up
Use case ID UC- 29
Participating Actors HRS, CMS
Flow Of Events No relevant flow of events
Constraints System data is backed up standards defined
Standards Backups: Backups:dailyincremental (onsite) &weeklyfull(onsite)
Support:
Platformsupportavailable24 x 7 x 365 (onsite,offshore
and on call)
Entry Condition  Support team available to make back ups
 Data store available to make back ups
Exit Condition --

43. 42
6.6.7 Data Architecture standards
Thisuse case helpsinthe descriptionof the requiredDataArchitecture standards.These standardsare
derivedfromthe SIDframework.
Use Case Name Data Architecture standards
Use case ID UC- 30
Participating Actors System
Flow Of Events No flow of events
Constraints System stores data per defined standards

44. 43
Standards – XSD
example
Standards – Entity
Relation example
Refer example figure in section 3.6.7
Entry Condition  Data designed per standards
Exit Condition
 Data communicated per set standard as referred in XSD standard
example

45. 44
7.0 Gantt Chart

46. 45
8.0 FunctionPoint Cost Analysis

47. 46
9.0 Software Architecture
9.1 Software
The HRS systemapplicationwillbe writteninJava.Itwill be deployedto2differentapplicationservers,
one as the primaryand one as a failover.The systemwilluse adatabase,asdescribedinthe next
section.The applicationwill be able torunonWindows,OSx andLinux.
9.2 Database
Thissystemwill use MicrosoftSQL2014 Database.The systemdoessimple transactions/queriesand
doesnotneedany advanceddatabase capabilities.

48. 47
10.0 Category InteractionDiagram
Category Classes
Reservation
CreateReserv()
PayReserv()
Reception
CheckIn()
CheckOut()
Cleaning
CheckRoomStatus()
EditRoomStatus()
Guest
CreateProfile()
EditReserv()
CancelReserv()
ViewReserv()
Reporting
RunReport()
ExportReport()
Tracking
WriteToFile()
DeleteFromFile()
Admin
login()
CreateStaff()
DeleteStaff()
CreateRooms()
EditRooms()
DeleteRooms()

49. 48
11.0 Object DesignDocument
11.1 Introduction
ThisObjectDesignDocument(ODD) depictsthe object-level designof the system tobe developed.The
HRS applicationconsistsof subsystemsthatmake upthe complete system.The subsystemswill work
separately.Theyinteractwitheachotherandcan be calledbyon another.Inthe objectdesignof the
system,eachsubsystemisconsideredindividuallyandconsiderationsmustbe madfor the whole
system.
11.1.1 Objectdesigntrade-offs
The designphase bringsforwardsome tradeoffsthatmayhave tobe made inthe designof the system.
11.1.1.1 Memory Space vs. Response Time
Typicallyaquickas possible response timeisideal inanapplicationlike HRS.Inorderto achieve thisa
quickerresponse time,more memorymustbe used.Althoughcomputersnowadayshave alarge about
of memory,itisnotunlimited.A large operationis expectedtotake a longertime.Buta little operation
needstotake little time.More memoryusage mightbe neededinordertoachieve this.
11.1.1.2 Developmental Costvs. Functionality
The HRS isintendedtohave asmuch functionalityasdeemednecessary.The more functionalitythatis
addedto the system,the more developmenttime thatisneeded,whichinturnraisesthe
developmental costs.More functionalitycouldbe addedasthe requestof the customer,butthe
customerwouldalsobe increasingdevelopmentalcosts.
11.1.1.3 Buy vs. Build
There are applicationalreadyoutthere thatprovide some of the functionalitythatthe HRSapplicationis
to provide.The HRSapplicationcombines all thisfunctionalityintoone package.Itispossiblethatsome
of the modulesinthissystemcouldbe purchasedtodecrease developmenttime.Thatwouldallowfor
more time to focuson othermodules.Onthe otherhand,all the modulescouldbe built,whichwould
increase developmenttime/cost,butverifyamore consistentapplication.
11.1.2 Interface documentationguidelines
The interface documentationguidelineshelpwithcommunicationbetweenobjectdevelopersduring
the objectdesignphase.

50. 49
11.1.2.1 Naming Conventions
Identifier Type Rules for Naming Examples
Packages
singular noun,
first letter of all words uppercase
letters only
package
ReservationManagement;
Classes
singular nouns
first word capitalized
internal words capitalized.
letters only
class Admin;
class Receptionist;
Interfaces
first word capitalized
internal words capitalized.
letters only
interface CreateReserve;
Methods verbs,
first word not capitalized
internal words capitalized.
letters only
login();
createRoom();
Variables
starts with letter
one-character variable names avoided
except for temporary "throwaway"
variable
int i;
string guestname;
float price;
Constants all uppercase
words separated by underscores ("_")
static final int
MAX_ROOMS;
Comments Begin with /**
End with **/
Prefaces each class
/**This is a comment.**/
11.2. Packages
The HRS applicationwill consistof one package.Thispackage will embodythe entire HRSapplication.

51. 50
Reservation
-fname : String
-lname : String
-address : String
-city : String
-state: String
-zip : String
-ccnum : String
-ccexpmon : int
-ccexpyear : int
-cccvvcode: int
-createReservation() : boolean
11.3. Class interfaces
11.3.1 Reservation
Thisclass will allowforanexternal usertocreate a reservation.The usercaninputthe information
whichwill getsavedtoa textfile.
11.3.2 Availability
Thisclass allowsforanexternal usertocheckthe availabilityof the roomsneeded.Theywill inputthe
datesneeded,roomtype (standard,double,etc),numberof roomsand smokingpreference.The class
will thenquerythe textfilestodetermine if theyhave the correctnumber/typesof roomsavailable.
Availability
-numRoms : int
-roomType: String
-smoking : boolean
-datestart : date
-datestart : date
-checkAvailability() : List

52. 51
11.3.3 Admin
Thisclass will allowan admintoinputtheirusername andpassword,checkthe accuracyand allowthem
to see the adminmenuuponcorrect credentials.The itemsshowninthe menuuponlogin(methods)
will be:manage staff,viewreports,addroom, andeditroom.
11.3.4 Guest
Thisclass will allowforanexternal usertologinand view existingreservations.Theywillalsobe able to
editandcancel theirexistingreservations.
11.3.5 Receptionist
Thisclass will allowthe receptionisttologintothe system.Uponsuccessful login,theywill be able to
checkin and checkout guests.Theywill alsobe able toextendthe datesof areservation.Once aguest
has beencheckedinorcheckedout,a new statuswill be writtentoa file.
Admin
-adminid : int
-adminname : String
-password : String
-username : String
-adminLogin(username : String, password : String) : boolean
-viewReports()
-addStaff(): boolean
-editStaff(staffId : int) : boolean
-deleteStaff(staffId : int) : boolean
-addRoom() : boolean
-editRoomInfo(roomid : int) : boolean
-deleteRoom(roomid : int) : boolean
-changeRoomStatus(roomid : int, newstatus : String) : boolean
Guest
-username : String
-password : String
-guestLogin(username : String, password : String) : boolean
-viewPastRes(): List
-editFutureRes(resvnum : int) : boolean
-cancelFutureRes(resvnum : int): boolean
Receptionist
-recId : int
-recName : String
-password : String
-username : String
-recLogin(username : String, password : String) : boolean
-checkIn(resvnum : int) : boolean
-checkOut(resvnum : int) : boolean

53. 52
11.3.6 House keeping
Thisclass will allow the housekeepingstaff tologintothe system.Once loggedin,theywill be able to
viewanyroomsthat needcleaningandupdate the statusonany roomsthat have beencleaned.Upon
updatingthe status,the newstatuswill be writtentothe file.
11.3.7 Room
Thisclass isfor eachroom. It hasthe attributes:id,type,smokingandprice.
Housekeeping
-hkid : int
-hkname : String
-username : String
-password : String
-hkLogin(username : String, password : String) : boolean
-checkRoomStatus(): List
-editRoomStatus(roomid : int): boolean
Room
roomid : int
roomtype : String
smoking : boolean
price : double

54. 53
12.0 Object Design Diagram

55. 54
13.0 Interface Design Screenshots

56. 55

57. 56

58. 57

59. 58

60. 59
14.0 Project Rationale
This section is a comprehensive list of rationales covering all the major phases included in the
projects deliverables.
14.1 Conceptualization Rationale:
Hotel Reservation System as a concept, for the purpose of the Software Engineering
class seemed apt. It had segments that were comprehensive enough to allow us to fulfil
all the requirements for the deliverables towards the project. Some of the criteria’s used
in the determining the concept were that it needed to be feasible enough so the data in
it could be written on to a text file given the constraint of not using a database for the
purpose of the implementation. Similarly, the topic was also evaluated against the
potential use cases and requirements it could generate.
Whilst the scope of the content that would go into build of the Hotel Reservation
System was brainstormed. The concept at first with Hotel Reservation systemas the
only scope seemed conventional and so therefore was enhanced by adding additional
scope for it to not just to contain a Hotel Reservation System but also have a fully

61. 60
functional Hotel Management System. This included creating subsystems for Internal
Staff. An example of a subsystem included after the scope was enhanced is the Cleaning
Management System. This allows cleaning staff access to the rooms to be able to make
rooms ready for occupancy.
14.2 Scope Rationale
When the team began brainstorming the requirements and use cases, the primary
elements of project planning were kept in mind to determine the feasibility of what
could be delivered in the due course of the project. Since the Cost determined for the
project was solely virtual, the underlying rationale that drove the magnitude of the
scope was time (schedule) and resources available. Given the skill set of the team and
the time available the scope of the project was thus determined.

62. 61
14.3 Project Charter Rationale:
An overall Project Charter was planned and created for the implementation of the
project. To wholly understand all the deliverables and their delivery, a project plan was
created. The rationale behind creating a project plan was to plan for the successful
delivery of the project, understand the interdependencies between deliverables and to
be able to match skill sets with available people resources. Albeit virtual, this also
helped in determining the total Cost (page 43) of the project given the timelines and
resources.
14.4 Requirements Analysis Rationale:
To enhance conceptual understanding and to drive this understanding towards
holistic implementation and further, to be able to tally what was elicited against what
would be designed, the project team elicited a comprehensive list of Requirements. A

63. 62
Requirements Traceability Matrix was also drafted, this elicited requirements in ‘Shall’
statements. This provided a deeper insight into what was to be built and designed.
14.5 Use Cases Rationale:
Use cases were extrapolated from the Requirements elicited in the Requirements
Analysis Document. A use case was further determined from a Use case scenario. The
use cases comprised of the description of the case, systeminteraction diagrams, flow of
events, entry and exit conditions if applicable. The interaction diagrams helped in the
visual understanding of the systeminteractions and flow of data between systems
and/or classes. Flow of events helped in connecting scenarios all the way from what
was to trigger the event to ultimately being able to determine the implementation of
what needed to be done in a step by step manner. Finally, the entry and exit conditions
helped in understanding at what point the use case would be initiated and all the
possibilities of what could happen post the use case scenario as it related to the state of
the system. The rationale behind individual use cases was covered in the first section of
every use case.

64. 63
14.6 Design and Implementation Rationale
The rationale behind the design and development phase of the project is to be
able to demonstrate a prototype of what was conceptualized based on the
communicated scope and the elicited requirements. The design factors in constraints
such as using text files to store data as opposed to using a data base for the purpose of
the prototype.
14.7 Testing Rationale
Testing as phase is planned to be accomplished to be able to tally what was
supposed to be designed against the actual design. The prototype is planned to be unit
tested and regression tested. This will help in the determination of reliability and
scalability of the prototype before it is ready to be presented.

65. 64
15.0 Test Cases
Thissectiondocumentsall the identifiedtestcasesandtheirresults.
PC-REQ-1000 Test Case Identifier
PC-REQ-1010 TC-UC-01
PC-REQ-1020 Test Location
PC-REQ-1030 HotelReservationSystem.jar
PC-REQ-1040 Feature to be tested
PC-REQ-1050 All users can access main page of system
PC-REQ-1060 Feature pass/fail criteria
Application opens to main page upon double click
PC-REQ-1070 Means of control
PC-REQ-1080 The application systemis opened
PC-REQ-1090 Data
PC-REQ-1100 N/A
PC-REQ-1110 Test Procedure
PC-REQ-1120 The test is started by double clicking the .jar file. The test will run
without further intervention.
PC-REQ-1130 Special requirements
PC-REQ-1140 N/A
PC-REQ-1150 Log
PC-REQ-1160 Application opened main screen upon double click.

66. 65
PC-REQ-1170 Test Case Identifier
PC-REQ-1180 TC-UC-02
PC-REQ-1190 Test Location
PC-REQ-1200 HotelReservationSystem.jar
PC-REQ-1210 Feature to be tested
PC-REQ-1220 Internal users access internal systemupon login
PC-REQ-1230 Feature pass/fail criteria
The user is taken to the internal application section after putting in a
username and password and submitting.
PC-REQ-1240 Means of control
PC-REQ-1250 The log in page is accesses via the sign in button on the main
application page
PC-REQ-1260 Data
PC-REQ-1270 The application will verify accurate login information saved in an input
file
PC-REQ-1280 Test Procedure
PC-REQ-1290 The test is started by double clicking the Sign in button on the main
page and then either the admin or user login button on the next page.
PC-REQ-1300 Special requirements
PC-REQ-1310 N/A
PC-REQ-1320 Log
PC-REQ-1330 Internal HRS system accessed. (no username/password needed)

67. 66
PC-REQ-1340 Test Case Identifier
PC-REQ-1350 TC-UC-03_04_05
PC-REQ-1360 Test Location
PC-REQ-1370 HotelReservationSystem.jar
PC-REQ-1380 Feature to be tested
PC-REQ-1390 Users can select dates, number of rooms and room type to create a
reservation
PC-REQ-1400 Feature pass/fail criteria
The user should be able to input a future start and end date of their
reservation, select the number of rooms needed and a room type and
smoking preference
PC-REQ-1410 Means of control
PC-REQ-1420 This page is accessed as soon as the application is launched.
PC-REQ-1430 Data
PC-REQ-1440 N/A
PC-REQ-1450 Test Procedure
PC-REQ-1460 The test is run by starting the application and putting in a future start
date and future end date, a number of rooms, a room type and a
smoking preference.
PC-REQ-1470 Special requirements
PC-REQ-1480 N/A
PC-REQ-1490 Log
PC-REQ-1500 The systemallowed future dates to be both typed in and selected from
a calendar. It also allowed for past dates to be entered. It defaulted to
1 room, but more could be selected. It allowed a types and a smoking
preference to be selected.

68. 67
PC-REQ-1510 Test Case Identifier
PC-REQ-1520 TC-UC-06
PC-REQ-1530 Test Location
PC-REQ-1540 HotelReservationSystem.jar
PC-REQ-1550 Feature to be tested
PC-REQ-1560 The systemwill show the user the amount of their reservation once all
input information is entered.
PC-REQ-1570 Feature pass/fail criteria
The test passes if the system returns the amount of the reservation.
PC-REQ-1580 Means of control
PC-REQ-1590 This information should be shown once a user enters all necessary
criteria and submits.
PC-REQ-1600 Data
PC-REQ-1610 The application will have to check the ‘rooms’ text file to make sure
the number of rooms is available and also get the room rates. It will
have to use that information in order to calculate the total cost.
PC-REQ-1620 Test Procedure
PC-REQ-1630 The test is run by inputting a start and end date, the number of rooms,
type of room and smoking preference and submitting.
PC-REQ-1640 Special requirements
PC-REQ-1650 N/A
PC-REQ-1660 Log PC-REQ-1670 The systemdid not show the cost to reserve the rooms selected.

69. 68
PC-REQ-1680 Test Case Identifier
PC-REQ-1690 TC-UC-07
PC-REQ-1700 Test Location
PC-REQ-1710 HotelReservationSystem.jar
PC-REQ-1720 Feature to be tested
PC-REQ-1730 The systemshall allow for the user to input their credit card
information.
PC-REQ-1740 Feature pass/fail criteria
The test passes if the user can enter their information and the card is
validated.
PC-REQ-1750 Means of control
PC-REQ-1760 An
PC-REQ-1770 Data
PC-REQ-1780 N/A
PC-REQ-1790 Test Procedure
PC-REQ-1800 The test is run by inputting the information needed to verify the credit
card.
PC-REQ-1810 Special requirements
PC-REQ-1820 N/A
PC-REQ-1830 Log
PC-REQ-1840 The user was able to enter information, but it was not verified (nothing
happened upon submit.

70. 69
PC-REQ-1850 Test Case Identifier
PC-REQ-1860 TC-UC-08
PC-REQ-1870 Test Location
PC-REQ-1880 HotelReservationSystem.jar
PC-REQ-1890 Feature to be tested
PC-REQ-1900 The systemshould allow for a user to register after making
reservation.
PC-REQ-1910 Feature pass/fail criteria
The test passes if the user is able to log into the systemafter making a
reservation.
PC-REQ-1920 Means of control
PC-REQ-1930 This information should be shown once a user enters all necessary
criteria and submits.
PC-REQ-1940 Data
PC-REQ-1950 The application should write the users information to a data file so that
the user can log in in the future.
PC-REQ-1960 Test Procedure
PC-REQ-1970 The test is run by inputting credit card information and then selecting
‘submit’.
PC-REQ-1980 Special requirements
PC-REQ-1990 N/A
PC-REQ-2000 Log
PC-REQ-2010 The systemdid not allow for the user to input user information in
order to log in later.

71. 70
PC-REQ-2020 Test Case Identifier
PC-REQ-2030 TC-UC-09
PC-REQ-2040 Test Location
PC-REQ-2050 HotelReservationSystem.jar
PC-REQ-2060 Feature to be tested
System sends out automated email with reservation dates, room type
and payment confirmation to the provided user email id and sends out
confirmation number in the email
PC-REQ-2070 Feature pass/fail criteria
The test passes if the system sends out an email confirmation.
PC-REQ-2080 Means of control
PC-REQ-2090 This should happen once a user enters all necessary information and
submits.
PC-REQ-2100 Data
PC-REQ-2110 N/A
PC-REQ-2120 Test Procedure
PC-REQ-2130 The test is run by inputting all necessary information and submitting.
PC-REQ-2140 Special requirements
PC-REQ-2150 N/A
PC-REQ-2160 Log PC-REQ-2170 The systemdid not send an email.

72. 71
PC-REQ-2180 Test Case Identifier
PC-REQ-2190 TC-UC-10
PC-REQ-2200 Test Location
PC-REQ-2210 HotelReservationSystem.jar
PC-REQ-2220 Feature to be tested
The systemshall allow the user to see a booking given a confirmation
number.
PC-REQ-2230 Feature pass/fail criteria
The test passes if the user is able to see all the booking information of
the confirmation number input.
PC-REQ-2240 Means of control
PC-REQ-2250 This should happen once a user enters their confirmation number.
PC-REQ-2260 Data
PC-REQ-2270 The systemshould read the confirmation number form a file and
return all of the reservation information.
PC-REQ-2280 Test Procedure
PC-REQ-2290 The test is run by inputting all necessary information and submitting.
PC-REQ-2300 Special requirements
PC-REQ-2310 N/A
PC-REQ-2320 Log PC-REQ-2330 There is nowhere for a user to enter their confirmation number.

73. 72
PC-REQ-2340 Test Case Identifier
PC-REQ-2350 TC-UC-11
PC-REQ-2360 Test Location
PC-REQ-2370 HotelReservationSystem.jar
PC-REQ-2380 Feature to be tested
The systemshould allow a user to log in and see all of their past,
present and future reservations.
PC-REQ-2390 Feature pass/fail criteria
The test passes if the system allows the user to see their past present
and future bookings.
PC-REQ-2400 Means of control
PC-REQ-2410 This should happen once a user enters all necessary information and
submits.
PC-REQ-2420 Data
PC-REQ-2430 The systemshould read all of that users booking information from the
file.
PC-REQ-2440 Test Procedure
PC-REQ-2450 The test is run by inputting login information and then hitting submit.
PC-REQ-2460 Special requirements
PC-REQ-2470 N/A
PC-REQ-2480 Log
PC-REQ-2490 The systemdid not show any past/present/future reservations.

74. 73
PC-REQ-2500 Test Case Identifier
PC-REQ-2510 TC-UC-12
PC-REQ-2520 Test Location
PC-REQ-2530 HotelReservationSystem.jar
PC-REQ-2540 Feature to be tested
A user can delete a future reservation.
PC-REQ-2550 Feature pass/fail criteria
The test passes if the system allows the user to cancel a future
reservation.
PC-REQ-2560 Means of control
PC-REQ-2570 This should happen once a user selects a future reservation and selects
Cancel’.
PC-REQ-2580 Data
PC-REQ-2590 The systemshould change the reservation status to ‘cancelled’ in the
text file.
PC-REQ-2600 Test Procedure
PC-REQ-2610 The test is run by selecting a future reservation and selecting ‘Cancel’.
PC-REQ-2620 Special requirements
PC-REQ-2630 N/A
PC-REQ-2640 Log
PC-REQ-2650 The systemdid not show any reservation, so ‘Cancel’ could not be
selected on and reservation.

75. 74
PC-REQ-2660 Test Case Identifier
PC-REQ-2670 TC-UC-13
PC-REQ-2680 Test Location
PC-REQ-2690 HotelReservationSystem.jar
PC-REQ-2700 Feature to be tested
System allows user to get to help and support pages.
PC-REQ-2710 Feature pass/fail criteria
The test passes if the system shows the help/support page.
PC-REQ-2720 Means of control
PC-REQ-2730 This should happen once a user selects the link for help/support.
PC-REQ-2740 Data
PC-REQ-2750 N/A
PC-REQ-2760 Test Procedure
PC-REQ-2770 The test is run by selecting the help/support link.
PC-REQ-2780 Special requirements
PC-REQ-2790 N/A
PC-REQ-2800 Log
PC-REQ-2810 This feature has not been implemented.

76. 75
PC-REQ-2820 Test Case Identifier
PC-REQ-2830 TC-UC-14_15
PC-REQ-2840 Test Location
PC-REQ-2850 HotelReservationSystem.jar
PC-REQ-2860 Feature to be tested
User is able to register in order to track reservations.
PC-REQ-2870 Feature pass/fail criteria
The test passes if the user is shown their reservations after logging in.
PC-REQ-2880 Means of control
PC-REQ-2890 This should happen once a user enters all necessary information and
submits.
PC-REQ-2900 Data
PC-REQ-2910 N/A
PC-REQ-2920 Test Procedure
PC-REQ-2930 The test is run by inputting all necessary information and submitting.
PC-REQ-2940 Special requirements
PC-REQ-2950 N/A
PC-REQ-2960 Log
PC-REQ-2970 The system allowed the user to input their username and password
and submit (any username and password-including blank- works).

77. 76
PC-REQ-2980 Test Case Identifier
PC-REQ-2990 TC-UC-16
PC-REQ-3000 Test Location
PC-REQ-3010 HotelReservationSystem.jar
PC-REQ-3020 Feature to be tested
Internal staff should be able to check in and out guests.
PC-REQ-3030 Feature pass/fail criteria
The test passes if the system provides a confirmation that the guest
has been checked in.
PC-REQ-3040 Means of control
PC-REQ-3050 This should happen once a staff member inputs a reservation number
and checks the guest in.
PC-REQ-3060 Data
PC-REQ-3070 The systemshould find the confirmation in the text file and pull up the
guest’s information.
PC-REQ-3080 Test Procedure
PC-REQ-3090 The test is run by inputting the confirmation number and checking
in/out the quest.
PC-REQ-3100 Special requirementsPC-REQ-3110 N/A
PC-REQ-3120 Log
PC-REQ-3130 This has not yet been implemented.

78. 77
PC-REQ-3140 Test Case Identifier
PC-REQ-3150 TC-UC-17
PC-REQ-3160 Test Location
PC-REQ-3170 HotelReservationSystem.jar
PC-REQ-3180 Feature to be tested
Internal staff should be able o access the cleaning status of each room
PC-REQ-3190 Feature pass/fail criteria
The test passes if the internal staff is able to see the cleaning status of
each room.
PC-REQ-3200 Means of control
PC-REQ-3210 This should happen once a staff member logs in and selects Room
Status.
PC-REQ-3220 Data
PC-REQ-3230 The systemwill pull the room status data in from a text file.
PC-REQ-3240 Test Procedure
PC-REQ-3250 The test is run by selecting the Room Status button.
PC-REQ-3260 Special requirements
PC-REQ-3270 N/A
PC-REQ-3280 Log
PC-REQ-3290 The systemdoes not show any rooms. When a room is added, it does
not remain when exiting the screen and going back in.

79. 78
PC-REQ-3300 Test Case Identifier
PC-REQ-3310 TC-UC-19_20
PC-REQ-3320 Test Location
PC-REQ-3330 HotelReservationSystem.jar
PC-REQ-3340 Feature to be tested
The systemshould allow the administrator to add new rooms to the
system, edit existing rooms, and delete existing rooms. The system
should auto increment the room number.
PC-REQ-3350 Feature pass/fail criteria
The test passes if new rooms are able to be added to the system.
PC-REQ-3360 Means of control
PC-REQ-3370 This should be initiated by the admin logging in and selecting the
button to add new rooms.
PC-REQ-3380 Data
PC-REQ-3390 The systemshould write the new room information to a text file.
PC-REQ-3400 Test Procedure
PC-REQ-3410 The test is run by putting in the information for the new room and
submitting. Next, the new room entered is selected, information
changed and ‘Edit’ selected. Lastly, the new room entered is
highlighted and Delete is selected.
PC-REQ-3420 Special requirements
PC-REQ-3430 N/A
PC-REQ-3440 Log
PC-REQ-3450 Rooms can be added to the system. Rooms can also be edited and
deleted. Nothing is written to a text file. All rooms are cleared out
when exiting the screen.

80. 79
PC-REQ-3460 Test Case Identifier
PC-REQ-3470 TC-UC-21
PC-REQ-3480 Test Location
PC-REQ-3490 HotelReservationSystem.jar
PC-REQ-3500 Feature to be tested
Administrator should be able to create internal users accounts.
PC-REQ-3510 Feature pass/fail criteria
The test passes if user accounts are able to be created.
PC-REQ-3520 Means of control
PC-REQ-3530 This should happen upon the admin saving the input information.
PC-REQ-3540 Data
PC-REQ-3550 The system should write the user data to a text file upon submitting.
PC-REQ-3560 Test Procedure
PC-REQ-3570 The test is run by inputting the user information and submitting.
PC-REQ-3580 Special requirements
PC-REQ-3590 N/A
PC-REQ-3600 Log
PC-REQ-3610 User information can be input, but no information is written anywhere
for the user to log back in.

81. 80
PC-REQ-3620 Test Case Identifier
PC-REQ-3630 TC-UC-22
PC-REQ-3640 Test Location
PC-REQ-3650 HotelReservationSystem.jar
PC-REQ-3660 Feature to be tested
Administrator should be able to update and delete staff profiles.
PC-REQ-3670 Feature pass/fail criteria
The test passes if the admin is able to update and delete user profiles.
PC-REQ-3680 Means of control
PC-REQ-3690 This should happen upon the admin saving the input information.
PC-REQ-3700 Data
PC-REQ-3710 The systemshould write the data to a text file upon submitting.
PC-REQ-3720 Test Procedure
PC-REQ-3730 The test is run by inputting the user information and submitting.
PC-REQ-3740 Special requirements
PC-REQ-3750 N/A
PC-REQ-3760 Log
PC-REQ-3770 This has not yet been implemented.

82. 81
PC-REQ-3780 Test Case Identifier
PC-REQ-3790 TC-UC-23
PC-REQ-3800 Test Location
PC-REQ-3810 HotelReservationSystem.jar
PC-REQ-3820 Feature to be tested
Administrator/Internal users should be able to update the cleaning
status of each room. .
PC-REQ-3830 Feature pass/fail criteria
The test passes if admin and staff are able to update the cleaning
status of each room.
PC-REQ-3840 Means of control
PC-REQ-3850 This should happen upon the admin/staff selecting the room, changing
the status and selecting Edit.
PC-REQ-3860 Data
PC-REQ-3870 The systemshould write the updated room data to a text file.
PC-REQ-3880 Test Procedure
PC-REQ-3890 The test is run by inputting the user information and submitting.
PC-REQ-3900 Special requirements
PC-REQ-3910 N/A
PC-REQ-3920 Log
PC-REQ-3930 User information can be input, but no information is written anywhere
for the user to log back in.

83. 82
16.0 Definitions andAcronyms
16.1Acronyms
RTM Requirements traceability matrix
HRS Hotel Reservation System
CMS CleaningManagement System
ITIL Information Technology InfrastructureLibrary,is a setof practices for IT serviceanagement
SID Shared Information/ Data Model
16.2Definitions
The followingdefinitionsare utilizedwithinthisdocumentwithparticularmeaning:
Internal: A userrole intendedtobe usedbyusersthatare eitheradminsorstaff belongingtothe HRS
External: A user role intendedtobe usedbyusersthat
System: Applicationthatisbeingbuilttosupportthe HRS.
User:A party or a party role that intendstouse the systemorits functionality
Client:A customerrole that isresponsibletospecifyingrequirements.
Work product: The software Team‘GSU innovators’developsunderspecifiedrequirementsof the
client.[1]
Gantt chart: Commonlyusedinprojectmanagementisone of the mostpopularanduseful waysof
showingactivities(tasksorevents) displayedagainsttime.[1]
Confirmationnumber:a numberrandomlygeneratedfromworkproductthatgetsdisplayedtothe
customera reservationiscompleted.
Administrator: the personwhohas total accessto the workproduct.
Staff: A userwhobelongstothe internal usergroup,whomayhave limitedaccesstothe workproduct.
Tester: personwhoisresponsible fortestingthe workproductbefore delivertothe client.
Customer:personwhopays hotel operatortostay inthe hotel.
CMS interface:The frontGUI to the CMS
Active reservation:A reservationthatismade fora future date.
Portal: A frontendgatewaytothe HRSprogram

84. 83
OrganizationChart: A visual depiction(example–an relational table)of how anthe HRS organization is
structured.Itoutlinesthe roles,responsibilitiesandrelationshipsbetweenindividualswithinan
organization.
17.0 References
[1] Bruegge,Bernd,andAllenH.Dutoit. Object-orientedSoftwareEngineering:UsingUML, Patternsand
Java.Upper Saddle River,NJ:Prentice Hall,2003.Print.
[2] "TM ForumInformationandData Architecture Overview." TMFORUM.N.p.,n.d.Web.18Feb.2015.
[3] Images - N.p.,n.d.Web. http://deiskinlab.com/images/conceptualization.jpg Web.25 Mar. 2015