Hotel Self Check‐in Kiosk Software Software Requirements Document 1
Introduction One way to reduce costs in the highly competitive domain of hospitality is to reduce the staff working in the front desk and reducing the time intensive check‐in (and checkout) process. One way to do so is to setup self check‐in kiosks comparable to those at airports. The check‐in kiosks increase customer convenience and satisfaction, reduce time spent in waiting queues and help reducing costs by maximizing employee’s effectiveness. 1.1
Overview This requirements document only contains the requisites for the software part of the system. The hardware of the terminals will be supplied by a third party vendor. 2
Requirements Description 2.1
The self check‐in software and its environment The self check‐in kiosk software will be deployed on a terminal with a 17’ touch screen running Windows XP and connected to the hotel chain’s backend booking and accounting system. The check‐
in kiosk contains a credit card reader for identification and payment purposes, a magnetic card writer to issue door keys as well as a printer to issue receipts and print out room directions for the guest. 2.2 Product functions 





To check‐in to the hotel, guests with a reservation can follow a set of on‐screen instructions and use the touch screen to select their preferred room from the set of available rooms in the price class they booked. To identify themselves, customers use the credit card they used for the booking of their room. Customers with no reservation can make a room reservation and check‐in if rooms are available. The self check‐in kiosk issues one or multiple door keys to the traveler. After check‐in, the system will print out room directions. At the end of their stay, customers can check‐out at the kiosk by returning their door keycards. They will be asked to review and confirm their bill. The customer may print out a receipt of their bill for their records. The due amount of their stay will be tendered from the credit card they used for check‐in. ‐ 1 ‐ 3
Additional considerations 








The hotel check‐in kiosk shall be easy to use for customers of all age and experience. The time required for check‐in and check‐out shall be reduced to a minimum. The required availability of the kiosk is 99,5%. This means that a downtime of 1,83 days per year is acceptable. The application will be developed in Java. The kiosk software is not responsible for the billing process. It forwards the customer information including the credit card data to the hotel’s booking system, which is responsible for insuring the customer’s ability to pay for his stay and to tender the money from his/her credit card on check‐out. The communication with the hotel’s booking system will be implemented using webservice technology. The necessary interfaces on the hotel’s booking system are already implemented and need no adaptation. It is not necessary to develop drivers to integrate the credit card reader, the hotel door key issuer or the printer. These devices all provide well documented easy to access drivers which encapsulate the low‐level technical details of the hardware implementation of these devices. The system should capture the duration of the check‐in for every customer and report possible problems and drop‐outs to the backend system. The data to configuration the self check‐in kiosk is stored on the backend booking server. The kiosk loads a customized hotel profile from the server. A password protected menu enables the kiosk administrator to store the login credentials required by the self check‐in kiosk to connect to the backend booking system. 4
Logical structure & system overview
The following list gives you a summarized hierarchic logical structure of the self check‐in kiosk’s functionality. The figure below gives you a graphical top‐level overview of the system. 1. Graphical User Interface 1.1. 5 simple screens 1.2. 5 medium screens 1.3. 2 complex screens 1.3.1.Visualization of hotel map with available rooms 1.3.2. Enter customer information 2. Credit‐Debit Card Reader Interface 2.1. Read credit card 3. Room keycard Issuer 3.1. Issue room key card 3.2. Read room key card on check‐out 4. Communication with backend system 4.1. Send customer information & preferences 4.2. Send credit card information ‐ 2 ‐ 4.3. Receive information of the credit card was accepted by the backend system as valid payment method. 4.4. Retrieval of a list of rooms and prices as well as a hotel map displaying the free rooms. 4.5. Retrieval of configuration and customization properties for the kiosk 5. Printing 5.1. Generate and print directions to the room. 5.2. Generate and print customer receipts of the room bill. 6. Miscellaneous 6.1. Administration console 6.2. Loading configuration information from the backend booking system. 6.3. Print room directions 6.4. Recording of customer behavior and duration of the login
‐ 3 ‐ Project settings and development environment characteristics The following data gives you an idea about the project settings and development skills of the employees in the development company. It is supposed to give you some basis for the selection of the Technical Complexity Factor and the COCOMO scale and effort drivers. 







The development company is rated at CMM Level 3. There are defined and documented standard processes which are in place and which are used to establish consistency of process performance across the organization. The company uses state of the art tools for Java development. The company has many years of experience in using configuration‐, build‐ as well as automated testing tools. The company has more than five years of experience in developing software in Java and they are familiar with many Java frameworks which can be used to develop standalone applications (like the kiosk software). The development company has already worked together with the hotel chain in other projects. Their business relationship is in good shape and the development company has gained a lot of knowledge in the domain of the customer. The development company has a personnel turnover of approximately 20% per year. The development team is composed of some extraordinary talented software professionals; but most of the developers have average skills. The team members get along well, and accordingly the atmosphere in the team is good. A usability task force has been established two years ago. Members of this group of developers have the theoretical background and practical experience in developing user friendly software. ‐ 4 ‐