Hotel Management System: Semester Project

Software Requirement Specification Document
Software Engineering
Semester Project
HOTEL MANAGEMENT SYSTEM
NS AHMAD FAROOQ
PC AAFREEN NAWAZ GONDAL
NS NOOR UL AIN SHUJA
NS NIDA IBRAHIM
DE 32 CE Syndicate B
January 21, 2013 [HOTEL MANAGEMENT SYSTEM]
CHAPTERS
SOFTWARE REQUIREMENT SPECIFICATION FOR HOTEL MANAGEMENT SYSTEM
 Introduction to HOTEL MANAGEMENT SYSTEM

 Proposed System & Overall Description
 Functional and Non-Functional Requirements
 Use Cases for Hotel Management
 Coding Standards
 Quality Management
 Risk Management
 Change Control Process
 Project Management Plan
 Work Breakdown Structure
 Cost Management Plan
 Test Cases
2|Page
Table of Contents
Chapter 1....................................................................................................................................................... 8
INTRODUCTION TO HOTEL MANAGEMENT SYSTEM .................................................................................... 8
Introduction: ............................................................................................................................................. 8
Scope:........................................................................................................................................................ 9
Purpose: .................................................................................................................................................. 10
Definition: ............................................................................................................................................... 10
Intended Audience:................................................................................................................................. 10
Existing Systems: ..................................................................................................................................... 11
Advantages in Implementations: ............................................................................................................ 11
Objectives: .............................................................................................................................................. 12
Constraints .............................................................................................................................................. 12
Chapter 2..................................................................................................................................................... 13
The Overall Description and the Proposed System .................................................................................... 13
Objectives: .............................................................................................................................................. 13
Preliminary Requirement Analysis: ......................................................................................................... 13
Benefits: .................................................................................................................................................. 14
Technical Requirements: ........................................................................................................................ 15
Overall System: ....................................................................................................................................... 15
Hardware Requirements: ........................................................................................................................ 15
Software Requirement:........................................................................................................................... 15
User Characteristics: ............................................................................................................................... 15
Product Features:.................................................................................................................................... 16
Operating Environment: ......................................................................................................................... 17
Design and Implementation Constraints: ............................................................................................... 18
Interface Requirements: ......................................................................................................................... 18
Assumptions & Dependencies: ............................................................................................................... 18
Chapter 3..................................................................................................................................................... 19
The Functional and Non-Functional Requirements .................................................................................... 19
Definition: ............................................................................................................................................... 19
Functional Requirements: ....................................................................................................................... 20
Non-Functional Requirements: ............................................................................................................... 24
3|Page
Chapter 4..................................................................................................................................................... 25
The USE CASE Diagrams .............................................................................................................................. 25
Introduction: ........................................................................................................................................... 25
Why Use Cases are important? ............................................................................................................... 26
What Use Cases Do ................................................................................................................................. 26
What Use Cases Do Not Do ..................................................................................................................... 26
Definitions of key words used in Use Cases:........................................................................................... 26
Chapter 5..................................................................................................................................................... 30
The Quality Management ........................................................................................................................... 30
Introduction: ........................................................................................................................................... 30
Customer focus ....................................................................................................................................... 31
Leadership ............................................................................................................................................... 32
Involvement of people ............................................................................................................................ 33
Process approach .................................................................................................................................... 33
System approach to management .......................................................................................................... 34
Continual improvement .......................................................................................................................... 34
Factual approach to decision making ..................................................................................................... 35
Mutually beneficial supplier relationships.............................................................................................. 35
Chapter 5..................................................................................................................................................... 36
The Coding Standards ................................................................................................................................. 36
Introduction: ........................................................................................................................................... 36
Purpose ................................................................................................................................................... 36
Scope:...................................................................................................................................................... 36
 Feedback: ........................................................................................................................................ 36
 Terminology & Definitions: ............................................................................................................. 37
C# Golden Rules ...................................................................................................................................... 38
 Coding Style: ................................................................................................................................... 39
The most inconsistencies and controversies between developers are caused by different coding styles.
Each developer has a preference of his own, and rarely are two the same. However, consistent
layout, format, and organization are key to creating maintainable code. ............................................. 39
 Class Layout:.................................................................................................................................... 41
 Guidelines: ...................................................................................................................................... 41
4|Page
 Indicating Scope: ............................................................................................................................. 42

 Guidelines: ...................................................................................................................................... 42
 Indentation & Braces: ..................................................................................................................... 42
 White space .................................................................................................................................... 43
 Long lines of code: .......................................................................................................................... 43
 Commenting.................................................................................................................................... 44
Intellisense Comments:........................................................................................................................... 44
End-Of-Line Comments: .......................................................................................................................... 44
Single Line Comments: ............................................................................................................................ 44
C-Style Comments:............................................................................................................................ 44
Constants:............................................................................................................................................ 44
Chapter 7..................................................................................................................................................... 46
RISK MANAGEMENT.................................................................................................................................... 46
FOR THE HMS SOFTWARE ........................................................................................................................... 46
Purpose ................................................................................................................................................... 46
Scope ....................................................................................................................................................... 46
Roles and Responsibilities ....................................................................................................................... 46
Definitions and Acronyms ....................................................................................................................... 47
Risk Management Process ...................................................................................................................... 47
PLANNING .............................................................................................. Error! Bookmark not defined.
IMPLEMENTATION .............................................................................................................................. 48
Qualitative Analysis ................................................................................................................................. 48
Quantitative Analysis .............................................................................................................................. 49
Risk Response Development ................................................................................................................... 50
Chapter 8..................................................................................................................................................... 51
CHANGE AND .............................................................................................................................................. 51
CONTROL PROCESS ..................................................................................................................................... 51
INTRODUCTION ....................................................................................................................................... 51
SCOPE: ..................................................................................................................................................... 51
8.3-CHANGE REQUEST PROCESS ............................................................................................................. 52
8.3.1-INITIATED BY CUSTOMER: ......................................................................................................... 52
5|Page
8.3.2- INITIATED BY COMPANY ........................................................................................................... 53

8.4- PRIORITISING: .................................................................................................................................. 54
8.5- STATUS REPORTS: ............................................................................................................................ 54
Chapter 9..................................................................................................................................................... 56
The PROJECT ............................................................................................................................................... 56
MANAGEMENT PLAN .................................................................................................................................. 56
Project overview ..................................................................................................................................... 56
Purpose ................................................................................................................................................... 56
Project Deliverables ................................................................................................................................ 57
Evolution of the plan............................................................................................................................... 57
Roles and responsibilities ....................................................................................................................... 58
Start-up plans .......................................................................................................................................... 59
Estimation plan ....................................................................................................................................... 59
Control plan ............................................................................................................................................ 60
Risk Management Plan ........................................................................................................................... 61
Project Close-out Plan ............................................................................................................................. 62
Chapter 10................................................................................................................................................... 63
WORK BREAKDOWN ................................................................................................................................... 63
STRUCTURE ................................................................................................................................................. 63
WBS Outline View ................................................................................................................................... 64
Hierarchal Structure ................................................................................................................................ 65
Tabular View ........................................................................................................................................... 66
WBS Dictionary ....................................................................................................................................... 68
Glossary ................................................................................................................................................... 69
Chapter 11................................................................................................................................................... 70
COST MANAGEMEMT PLAN ........................................................................................................................ 70
Introduction ............................................................................................................................................ 70
Effort ....................................................................................................................................................... 70
Costs ........................................................................................................................................................ 71
Hardware estimate checklist .................................................................................................................. 72
Software Estimate Checklist ................................................................................................................... 73
Chapter 12................................................................................................................................................... 74
6|Page
TEST CASES FOR THE ................................................................................................................................... 74

HMS PROJECT.............................................................................................................................................. 74
12.1- TEST CASE FOR ROOM RESERVATION: .......................................................................................... 74
18.2- TEST CASE FOR ADMIN LOG IN ...................................................................................................... 75
18.3- TEST CASE FOR ADMIN LOG OUT................................................................................................... 76
18.4- PAYMENT OPTIONS ....................................................................................................................... 77
7|Page
Chapter 1
INTRODUCTION TO HOTEL
MANAGEMENT SYSTEM
_____________________________________________________________________________________
Since the start of human history, Traveling has a vital importance. No one owns some relatives
or property in every corner. But work often leads one to far away locations. Hotels are of prime
importance in these and other cases. Hotels constitute of Restaurants, Guest Houses and
Resorts. Usually a hotel consists of rooms and Halls to be rented and restaurants on eat-away
terms for customers. Big Hotels constitute hundreds of halls, thousands of rooms and dozens of
restaurants inside them. Big hotels involve hundreds of employs who serve different posts.
Hotels involve waiters, laundry, chefs, hosts, managers and managers of managers on one hand
to CEOs on the other. The management of such a heavy staff and to assign everybody his job is
very tough.
Management of such a big structure is not a piece of cake. However Software like other fields,
serves here as well to ease mankind. Hotel Management Systems provide an easy and effective
way to execute the tasks of Hotel Management.
All the hotels around the world use different efficient software to help them in their managerial
tasks. All big Hotel chains in PAKISTAN also rely on management Software. Management
software allows one to have a better connection with his customers as well as presents a better
access to people around the world to explore them. On the other hand it also enables one to
have a better management and a better control over the employs.
Introduction:
Every big organization relies on some management scheme. Without proper management
nothing in this world can go on. To do the managerial tasks properly and effectively one needs
highly efficient tools. These tools not only helps one to do his/her work properly but also
8|Page
reduces the chances of error. Because human can forget things, Software cannot. So every
organization relies on different database software to perform their respective tasks.
In Hotels there are a number of activities going on in a single time. Hundreds of halls,
Thousands of rooms are all being used of evacuated at a time. To manage such a large system
we need some efficient tool. Hotel management system helps us in this regard. It not only
provides the management facility to the organization but also provides the customers and
other people to get exact information about the hotel (with the consent of hotel).
These systems enable people around the world to make reservations for rooms, hall etc. The
management system helps one to check the menus in different restaurants of the hotel and
check prices and other information about the hotel. Hotels on the other hand are able to keep
record of their each item sold in the restaurant, any room reserved and an accurate guess of
the revenue which should be gathered and what is gathered. This helps the owners a lot to
keep a check and balance of such a huge system which on the other hand is not possible.
The Accounts are managed easily i.e. the salaries of workers and the revenue generated by the
customers can be easily managed. Moreover the most important task, “CUSTOMER
SATISFACTION” is truly achieved. As the management provides an efficient access and
everything is available to the customer on a single click through the web (for web based
systems).
Our Hotel Management System also provides satisfactory functionality to all of its users.
Scope:
The scope of our project is to make a management system relevant to Hotels. This management
system will serve the need of different people. Anonymous people around the world can get
information about the hotel through PEOPLE dedicated section. They are also allowed to book a
room for them using e-reservations. The customers on the other hand can book Table, Hall or
room and get their bills paid by front desk.
The admin management on the other hand has different sections. Human Resource
Department deals in vacancies, Employ relevant problems and security plans. They can set
orders and the HR head can access the reports using a single click on his monitor. The
Restaurant manager on the other hand manages his menu, waiter’s duty and check relevant
reservations record on his seat. Similarly Room Division has their maintenance. The Accounts
department checks all reservations and other data and maintains the billing section enabling a
better and more reliable revenue generating mechanism. While every manager or head of a
department has access to their relevant information, the CEO of the Hotel or other major share
holders have access to all the databases to check every entry and position of every person as he
9|Page
desires. He can look through all the details and Revenue guess and actual revenue generated
using the software.
Thus a single system serves the need of all the users from general public to the employs of the
hotel.
Purpose:
The main purpose of the system as described above is better management. This system
provides an easy access to the management issues and one can easily get where the relevant
person could be found. The world has changed to databases to keep record of everything. The
basic need here is to record the data about reservations of room/table/hall and to calculate the
relevant revenue and save its data as well.
Definition:
HMS- Hotel Management System as described previously is meant to perform the management
tasks of a Hotel including the HR, Reservations (basically DATABASE) and customer relevant
issues.
SRS- Software Requirement Specification: This is a document which describes completely the
system of software. It may include the use cases as well. It includes functional and non-
functional requirements, Quality and risk management etc.
Intended Audience:
The intended audience of this system is a variety of people who in different aspects will interact
with the system. A list of proposed audience is maintained below:
 General Public
 Customers
 Restaurant Managers
 Room Block Department (Managers)
 Human Resources (Managers)
 Security Department
 Employ/Job Center
 Accounts Department
 Front Desk (Staff)
 CEO
10 | P a g e
Everyone listed above will have different restricted access to the data. For example, the
customers are allowed to reserve ROOM, HALL or TABLE but they are not allowed to check who
is staying where or who else is residing in the hotel. Admin (For room block) on the other hand
is allowed to check all the data about room reservations. Room Block admin on the other hand
is not allowed to view the reservation database of the restaurant and vice versa. CEO indeed
has access to all the databases.
Existing Systems:
The world is moving towards automation, so is the Hotel Management. The Hotel management
systems around the globe are using different techniques to make their services better. There
are many companies who work only for Hotel Management system development. One of
known ones in PAR-Solutions for Hospitality, According to who the major requirement of a
Hotel Management system is providing the best feeling to their customers. Existing systems are
built on many important facts. The major Factors are:
1) Guests
2) Management
3) Revenue (Accounts)
Many of the systems now use an ERP system including text message service to contact any
employ any time and spread all the news easily.
Our system keeps these conditions in mind and we provide easy and legal access to everyone
around the globe.
Advantages in Implementations:
Previously the systems were not so efficient but with the advent of latest technology, a faster
and better functionality is available. Some of the advantages in implementing the system are
listed below:
 Better visibility of the Hotel to general public.

 Flexible options availability to the customers.
 Better and more reliable management
 In-time spread of news as per requirement.
 Less chance of errors with the use of DATABASES
 Overall efficiency increases with better every department functioning at its best.
11 | P a g e
Objectives:
The objectives of our Hotel Management system are as follows:
1) Providing better management of ROOM/HALL/TABLE etc using the DATABASES. This will
enable the management to keep a record of their customers and will lessen the chance
of any error e.g. the allotment of a single room to more than one customer.
2) Enable the customers to get better access to the hotel. Facilitating them to reserve a
room for them through distance using e-reservations. This eases customers on one edge
and provides business to hotel on the other hand.
3) Enabling accounts department to keep record of all reservations and other selling and
hence make the fare revenue. The enable the generation of detailed bills for their
customers to satisfy their concerns as well. At the best this system enables the CEO and
other share holders to check the records and get the revenue estimate; enabling them
to find black sheep out if anyone involved.
4) Overall a better “Management” of resources, Assigning duty points each day for
different workers and assigning everyone his work! This will be done by generating the
report showing everyone’s tasks which can be viewed over the system by relevant
people.
5) Least, enabling general public to know in detail about the hotel, its customs, food and
living standards and attractions it can offer.
Constraints
The devised constraints of our system can be to implement the system in such a way that it
causes least crashes and the system exceptions are handled properly. The Data security issue
must be handled carefully so that privacy is maintained and no one can access the hotel data
from outside.
12 | P a g e
Chapter 2
The Overall Description and the

Proposed System
_____________________________________________________________________________________
The proposed system includes the explanation to the basic structure of the system. Here we
look in detail about how different requirements of the organization are accomplished. We also
explain the structure of the system about the usage of different options available for relevant
people. We also present a detail of the Software Engineering principles which basically is the
managerial theme for the development of software itself.
Objectives:
The basic objective of the hotel management system includes fast access to the data to make
decisions in no time. Thus we provide a system which works out the solution in seconds. This
enables finding the room reservation records, adding new records and at that time checking
correctly that the reservation made is unique. The system will include the past data about
guests and system will maintain the present reservations record as well. The system is designed
basically to solve the problems on the issue of reservations and management regarding those
reservations. The primary objectives include “CUSTOMER SATISFACTION” and the system must
present all the ways to keep the customer happy.
Preliminary Requirement Analysis:

This involves the collection of requirements which the project must fulfill. This includes the
following details.
1) We will require a database system. The database is a major need as it interprets the
requirement of storing the data chunks which need to be managed according to
proposed standards. The basic need here is speed. As user always requires an efficient
13 | P a g e
and fast system and the other requirement is intact and crash free system. This can run
without even a single second of being down! It must fulfill the following requirements:
 Make Reservations for a Room/Table/Hall
 Cancel a reservation for Room/Table/Hall
 Store a data base for all kinds of reservations
 Store payment details
 Store Room and other information.
2) The other major requirement is interface. Interface enables the user to make
interactions and usage about the system. The system must present an easy Graphical
user interface because most of the users usually are unaware with the use of such
systems and complicating them will restrict their usage in proper way this on one hand
creates problem for the hotel management and on the other hand is a problem for the
developer. The major strongholds kept in this regard are:
 Allow receptionist to Make/Cancel Reservations
 Allow receptionist to maintain the guest lists
 Allow the receptionist to provide the user with bill payments.
 Allow the HR department to post jobs, look for new employs maintain employ
list, maintain guard list for security purpose.
 Allow the higher managers to keep a look on accounts and other details.
 Allow the basic information access for general public.
 Allow online reservations for rooms with payment mechanism ensured.
Benefits:
The system will have many benefits over the paper data used previously in the world or some
ordinary systems available around. A few of its important benefits are listed below:
1) It provides privacy & security of the data. Not everyone is allowed to view every aspect
of the system. Only concerned people can view their relevant data base.
2) Security is ensured with the use of passwords on the admin side. Keeping every employ
restricted to his own domain so that interruption is never heard around.
3) It provides speedy access along the databases. Usage of latest algorithms enables data
checking in seconds so that customer gets his answers in without any waste of his time.
4) The chances of any mistake over the allotment of rooms/halls/tables are reduced with
the usage of record of every reservation saved and checked over before making any
reservations.
14 | P a g e
Technical Requirements:
The technical aspect of the system is covered with the use of VISUAL STUDIOS 2008. The
programming aspects of the systems are designed in c# and .net frame works. The GUI is
designed by making the usage of Windows Form Application available in C#. The data relevant
requirement is accomplished by the usage of text files to store and copy the data from. The
application on major involves the usage of stream reading/writing and on the GUI side it
involves the usage of Buttons/Tab controls and text boxes.
Overall System:
The overall system includes the Software and the relevant hardware to deal in the software.
The System mainly requires the databases which are on the software side and the hardware is
general one. The overall system is based on following subsystems:
Hardware Requirements:
The hardware requirements are simple and include PCs on which the system will be installed to
run. The Software datasheets can be printed up using printers on the hardware side.
Software Requirement:
The software requirements basically include the DATABASES which are of key importance of
SRS. Here DATABASES will be included to save the data about the ROOM/HALL/TABLE
reservations, Record of employs, record of duty points for Guard and waiters. The HR
Department will include easy access to post job on their monitors who will become available to
the public in general and anyone can apply to it. A database will be maintained for Jobs posted,
and applicants who applied for the job so that interviews could be conducted. The system will
include a feedback tab as well so that the customers can play their role in making the hotel
better.
User Characteristics:
The Software will include the basic user requirements i.e. a GUI based system that will require
low educational level for the users so that anyone can use it easily. There should be ZERO LEVEL
technical expertise requirement for the users as to make it user friendly. System should be such
that the user needs little or no experience to use the system.
The audio visual alerts should be less in number because they make the user confused and
exception handling should be handled carefully to avoid application crash.
15 | P a g e
Product Features:
The product will be used by a number of users each of which will have different interactions
with the systems. There are 3 major users of systems, they are:
1) General Public who will be accessing the system online.

2) Customers residing inside the Hotel or in restaurants.
3) Admin: this will include many users inside its hierarchy a few being the Restaurant
managers, the Room-Block managers, HR Managers, Security department officials, HR
Job sector officials, HR employ manager, Front Desk staff and the accounts department.
The features available to the General public are:
1) Getting all sorts of information about the hotel. From events to location and history to
activities.
2) Make online reservation of hotels along with Credit card info for billing purposes.
3) The availability of photo gallery to view the hotel from inside.
4) Career tab to apply for various job openings inside the hotel and check for their criteria
as well.
The features available for the Customers are:
1) Reservations of Hall/Table and Rooms without prior billing information along with the
option to cancel any reservation previously made.
2) Check the menu available in different restaurants over the hotel; helping one to make
his mood beforehand.
3) Make a check out and collect the billing information available on the desks of each
restaurant and the front desk.
4) All these functionalities are available over the FRONT DESKs inside the hotel which can
guide the customer over these issues utilizing the system that is developed.
5) Customers are allowed to give feedback as well.
The Admin Side Features; these are divided into 4 major categories.
HUMAN RESOURCE DEPARTMENT: this consists of following features.
1) The upper HR Manager is allowed to see the work of all the sub departments which
include Security, Job Vacancies department and the main Employ center.
16 | P a g e
2) The Job Vacancies Dealers are allowed to post jobs and check applicants list to short-list
them for interview purpose. Security personals are allowed to assign work for each
person over system; issuing orders and the employ center maintains its list of employs.
Restaurants:
1) Restaurants are allowed to reserve or cancel tables and Halls which they deal in, this
functionality is not available in Banquet (which is its sub-branch) who are allowed only
to cancel the reservations of particular.
2) The Restaurant is allowed to view all records from waiter associations as well who
themselves are allowed only to assign the duties as per done by some waiter associated
manager.
3) The Restaurant is allowed to edit the menu as well which will become available to the
Banquet and via banquet to the kitchen.
Room-Division & Accounts:
1) The room division deal in reservation/Non reservation of rooms alone.

2) The accounts can check the check in/out for each department and maintains the billing
for everyone.
CEO/HOTEL:
This is one of higher authority access area, who is allowed to:
1) View record of all kinds of reservations and menu and other stuff.
2) They are allowed to check the records of the accounts and estimate money from it.
3) Check the feedback from different customers.
Operating Environment:
The operating environment of the system includes Microsoft Windows 7/XP professional or
above. The GUI size taken is 720 x580 but maximization option is available. The RAM should be
greater than 512MB and hence the hardware required is not so extra ordinary.
The memory requirement of the application is not so high. A 100 GB Hard-drive will play an
enough role.
17 | P a g e
Design and Implementation Constraints:

The following software & hardware equipments are required for making models and for the
coding practice involved in its implementation:
1) Microsoft Visual Studio 2008 and the Coding language used is C #

2) Microsoft Word for documentation purpose.
3) Microsoft Visio for designing issue.
4) While a keyboard and a mouse will be required for interaction with the application.
Interface Requirements:
The basic requirement of the software is to make use of user friendly interface. This requires
the usage of Windows like format of the application and windows as the platform for the
application to work as most of the people are used to Windows. There should be following
properties for the system interface:
1) The system should be presented simple and easy to use.

2) There should be use of c# for good visual design.
3) There should be clearly labeled controls. This helps user in performing their tasks easily.
4) The designing should be consistent i.e. all the forms and tabs involved should have the
same design and nearly same color and text standards to make the user feel
familiarized.
5) There must be use of pop-up windows and menus to guide the user. The use of standard
controls is made sure again to make the user feel familiarized.
6) Efficiency, Security and privacy are three important concerns in GUI that must be
fulfilled.
Assumptions & Dependencies:

The system is not as such dependent on any other system. However for databases it will be
dependent on the SQL servers and the other dependency is Internet based servers for its
web-based features to be displayed over the website. The development of the product is
carried out in C# and hence Microsoft Visual Studio 2008 is among the dependencies for
development of the product. The Assumptions made during the coding are:
We assumed that inside the Hotel, Customers will make payments on the front desk alone
and no “Cellular based” payment methodology is implemented with the system. The system
is storing all the data at one place but the access is restricted among its users as per prior
knowledge about the requirements.
18 | P a g e
Chapter 3
The Functional and Non-Functional

Requirements
_____________________________________________________________________________________
The Requirements of the system are mainly divided into two main streams, one being the
Functional Requirement and the other one being non-functional requirement. The two of them
are explained in general in the section below and in particular with respect to the Hotel
management system through the next portions of this chapter.
Definition:
A Functional Requirement is a requirement that, when satisfied, will allow the user to perform
some kind of function. For example:
“The customer must place an order within two minutes of registering”
For the most part, when people are talking about Business Requirements, they are referring to
Functional Requirements which are generally referred to as “requirements”. Functional
Requirements have the following characteristics:
 uses simple language

 not ambiguous
 contains only one point
 specific to one type of user
 is qualified
 describes what and not how
Now the Non-Functional requirements are described as below:
**Reference: http://www.requirementsauthority.com/functional-and-non-functional.html
19 | P a g e
A Non-Functional Requirement is usually some form of constraint or restriction that must be

considered when designing the solution. For example:
“The customer must be able to access their account 24 hours a day, seven days a week.”
For the most part when people are talking about Constraints, they are referring to Non-
Functional Requirements. Non-Functional Requirements have the same following
characteristics:
 uses simple language

 not ambiguous
 contains only one point
 specific to one type of user
 is qualified
 describes what and not how
Non-Functional requirements tend to identify “user” constraints and “system” constraints.

Business requirements should be kept pure and not reflect any solution thinking.
A system constraint is a constraint imposed by the system and not dictated by a Business Need.
Since system constraints are part of a “solution”, they should be documented in the System
Specifications document. For example:
“The system must be unavailable from midnight until 1:00am for backups.”
This is a restriction imposed by the system and not a user request.
Some people like to further classify the Non-Functional Requirements into such categories as
“Performance Constraints, Design Constraints, Quality Constraints, etc.. This classification can
be used if there is deemed to be a benefit.
Functional Requirements:
The functional requirements involve all the functionality relevant requirements of the system.
This includes all the functionality, from GUI on one edge to Database handling on the other.
The Overall functionalities of the system are described below:
1) Reservations & Bookings:

 The System is able to allow reservations of Room from internet via the
functionality named as e-reservations. The Customers on the other hand are
allowed to make reservations on Front Desk as well. The Front Desk hosts a
**Reference: http://www.requirementsauthority.com/functional-and-non-functional.html
20 | P a g e
couple of staff members who can make reservations for known customers on
Phone as well as on the arrivals.
 The Reservations can be done for Rooms/ Halls/ Tables on the Front Desk by
using the “FRONT DESK” tab which is the one available on the monitors of the
Front Desk.
 The Reservations For ROOM involve the arguments like:
 Record Customers Name.
 Record Customers Requested Room Number. This function then check
the availability of Room, if the room is not available the system will
prompt to make some other choice for the room.
 The system will demand users Telephone number to ensure contact with
the user.
 The system will take the period of stay in DAYS.
 The system then generates an Id for the customer to ensure that any
customer with the same name might not get other person’s payment/Bill.
 For those using e-reservations will have to submit their VISA card number
as well for online payment details with a period of 15 days before stay.
 For better, Front Desk can also assign the Rooms for those with no choice
of room number.
 To cancel the Reservation for any room, Only Room number is taken as an input.
 The Reservations of TABLE/HALL require the following functionality before they
get registered.
 The Customer Name is taken as an input.
 The Customer requested Table number is taken as an input; In this case
the database for table reservations is checked to ensure that such a table
number is not yet occupied.
 The number of people for table is also asked to look for the capacity of
the customers.
 This functionality is available only over the Front Desk while the Table
cancellation functionality is available over Front Desk and Restaurant
Desk. The Cancelation requires only the Table number.
 The Reservations of HALL requires the information about Hall name/number and
the capacity for the people you are hiring the hall. The basic functionality for the
reservations are listed below:
 The Customer Name is taken as an input.
 The Hall number is also taken as an input and usually the Front Desk
administration might do this them as customers don’t know much about
hall capacity with numbers. In case of a selected number for the hall, the
21 | P a g e
database for table reservations is checked to ensure that such a table

number is not yet occupied.
 The number of people for Hall is also asked to look for the capacity of the
customers.
 This functionality is available only over the Front Desk while the Hall
cancellation functionality is available over Front Desk and Restaurant
Desk. The Cancelation requires only the Table number.
2) Accounts & Checkouts:
The billing is done by the Accounts department. This department works out with the
following functionality:
 The records for Table/HALL/Room reservations are checked by this department
to make out the money. For Room Reservations the department takes the name
of the user as an input and the record for the ROOM RESERVATIONS is checked,
if the name is found, then the period for stay, type “ROOM” or “SUITE” is
checked. After checking the list, Bill is made for the ROOM and displayed on the
checkout screen of the FRONT DESK ALONE! And the staff member available
there, then prints out the bill using print command.
 The Billing is done for TABLE and HALL reservations in a similar way as for ROOM.
The only difference here is that the bill can be taken from either the HOTEL
FRONT desk or the Restaurant Front Desk. The number for table or Hall is taken
as an input and name of customer is searched with it and respective bill is
generated.
 Once the billing for the ROOM/HALL/TABLE is done an archive file for each is
maintained for each and the reservation list is emptied for the name.
 The Billings list for past and due billings can be checked from the ACCOUNTS
department. The hotel manages the billing information inside the class with its
separate database.
 The Accounts restricted database is also visible on CEO tab for the higher
authorities of the hotel.
 The Adman’s accounts tab also shows a history file to view all the accounts
relevant details made ever.
3) Admin Relevant Functions:
The admin is responsible for making the entire Hotel function; We have divided the
admin into a number of blocks to deal in HR Department, Restaurants, room block and
other areas the functionalities involved are as follows:
 Inside the HR Department the HR Manager is allowed to view a complete report
of his department, He can view a list of the Jobs posted by the Job Vacancy
22 | P a g e
dealing department, he can view the applicant’s info who are interested in the
hotel and a report on employ ID and security issues.
 Inside HR Department is housed JOB Vacancy dealing, Employ center and
Security department who are allowed only to post relevant jobs and check the
work of employs, maintain employ list and check out if there are difficulties
amongst them and lastly issue security relevant orders per day. Each of these
requires 2 parameters to make the button function.
 The Restaurant higher admin who sit in the Admin block is allowed only to view
the statistics of restaurant usage, waiter relevant list maintained and menu. They
are also allowed to make changes in the menu off and on as per requirement.
Inside the restaurants is housed a banquet who actually deals in restaurants
under the higher authority and a waiter dealing department. The banquet is
allowed to cancel any reservation if they want and check reservation records.
Waiter dealing department is allowed to assign duties to waiters online. For
editing the menu you only need to mention the item and its relevant price. For
making waiter’s list you need to mention the name and position before pressing
the button.
 Similar to Restaurant authority sits a ROOM relevant authority, who deals in
viewing room’s records and cancel reservations.
 The accounts department as stated previously is allowed to view payments of
any single personal and they can also view the entire accounts records using the
history file.
 Lastly is an access to FEEDBACK which is open for entire admin blocks.
4) Lastly is a Feedback tab available for any customer or online visitor to make comments
on the Hotel which are made available to the entire admin block.
23 | P a g e
Non-Functional Requirements:
The non functional requirements of the system are listed below:
1) The software should be speedy and it must fulfill its required operations very fast.
2) It must not use large amount of memory during run time so that there are less chances
of getting hanged when running.
3) It should maintain a proper security guide so that there are no issue of privacy and
leakage of any customer relevant private data which is not allowed to publicize due to
laws.
4) The databases made should be of the form that gives them the ability of a quick access.
5) For web based activities the servers used should be of good quality and should be in
such numbers that anyone can make use of them without getting the error for server is
busy and other such stuff.
6) Most importantly the software must give the outputs correct. I.e. the functions must
work properly and all the related outputs should be correct and in-time.
7) System should be maintainable and useable, it should be made in the form that later on
if required it can be improved by adding more classes using polymorphism more
functionalities.
8) The design should be portable and capable of working in multiple operating
environments to ease users.
9) Error and pop-up commands should inform the user about the statistics of some
function being performed.
24 | P a g e
Chapter 4
The USE CASE Diagrams

_____________________________________________________________________________________
Introduction:
Use case diagrams are an important part of Unified modeling language (UML), which are used
to show interaction between a system and different users or another external system.
Actors can be different users or external systems: in our case users are customers,
administrators, managers, employs etc. while use cases are used at higher levels in systems
engineering within software engineering even to represent missions or goals of stakeholders.
So, basically a use case is helpful to the end-user to understand the system functionalities and
services. It is a systematic representation of requirements, interactions and actions between
the system and the users.
The role of use case diagrams in UML is clearly shown in the following figure:
(the figure has been taken from www.sts.tu-harburg.de)
25 | P a g e
Why Use Cases are important?

Use cases are important because they make it easy to identify the functional requirements and
also indicate the possible interactions with different users of the system.
Use cases are descriptive. Therefore they successfully show the importance of an interaction
between the actors and the system. They help in understanding the system functionality during
the development life cycle.
What Use Cases Do

1. Use cases use a tracking format to hold the readability of functional requirements.
2. Use cases show interactions between actors and the system representing their goals.
3. They are multi-level, one use case can use the functionality of another.
What Use Cases Do Not Do

1. Use cases can not specify user interface design. They specify the aim, not the action Detail.
2. They also don't specify implementation detail.
Definitions of key words used in Use

Cases:
1. Actor:
An actor is something with behavior, such as a person, computer system, or
organization.
(definition taken from internet)
2. Scenario:
A scenario is a specific sequence of actions and interactions between actors and the
system under discussion; it is also called a use case instance. It is one particular story of
using a system, or one path through the use case; for example, the scenario of
successfully using an ATM machine to withdraw cash.
(definition taken from internet)
Now that I have introduced what a use case is, what they do, what they do not do, and
provided the definition of an actor and scenario, let us look at some of the possible use
cases of hotel management system which have been developed in C#.
26 | P a g e
27 | P a g e
HR manager administrator
28 | P a g e
Front Desk data base management use case:
29 | P a g e
Chapter 5
The Quality Management

_____________________________________________________________________________________
Introduction:
The term ‘Quality Management’ may refer to different meanings in different business sectors. It
is the act of overseeing all activities and tasks needed to maintain a desired level of excellence.
The aim of Software quality management is to manage the quality of software and its
development process. This includes this includes three main components: quality control,
quality assurance and quality improvement.
This also incorporates measuring all process elements, the analysis of performance and the
improvement of the products which will be taking place, all services and processes which help
in delivering them to the customer and maintenance. It is sometimes referred as integrated
management.
It is also referred to as total quality management (TQM).
 Software Quality Control

Quality control is to ensure that the developing team is following proper standard
methods of software engineering to plan, design and document the software being
developed.
It mentors how to make well-defined engineering documents using standard processes.
It also mentors how to conduct standard processes such as quality reviews to verify and
evaluate artifacts like engineering documents.
 Software Quality Assurance

It provides the guide to rules and regulations, procedures and standards which are used
to verify and evaluate the work products during the software development life cycle.
It also provides guidance to the already included knowledge base of best practices and
selects different software tools to implement the above steps which might be needed
apart from the one which is already being used.
30 | P a g e
 Software Quality improvement

This includes the improvement in the quality of the software with the changes in it
which might be needed later on.
The role of the software quality management is to ensure that the required level of quality is
achieved in the software and encourage everybody in the company to be responsible for the
quality of its products.
This reduces the learning curve in case anybody changes his position within the organization.
This helps in avoiding in-process faults and ultimately reduces the risk of faults through proper
development.
Following are the main principles which have been kept in mind for the quality assurance while
our software (Hotel management system) was being developed:
Customer focus
The success of any Organizations depends mainly on their customers and therefore the
needs of the current and future customers should be considered very seriously while
developing the system. The functionalities and services provided by the system should
meet all customer requirements and endeavor to exceed customer expectations.
This will not only result in the satisfaction of the present customers but also will help
attract new customers.
Keeping in mind all the above mentioned points, we have to try our level best to provide
all possible services to the customers and all other individuals who are linked with the
system in one or the other way.
This will be a web based system, which will not only make it easier for all the employs
and manager to run the hotel smoothly but also should provide many online services to
the customers which would help them save their time and get any information about
the hotel easily and also avail all the services provided by the hotel online.
The e-reservation is one of the unique properties of the system, through which one can
reserve a room of his choice online. One can see the available room, unreserved tables,
available halls, rooms, menu etc. they can send online payment through credit card to
confirm the reservations. The efficiency of the system should make it clear that it is
flexible enough and not only be restricted to the e-reservations. So the whole of this
process should also be made available to the customer ones he has reached to the front
counter without any pre-reservations. The customer should also be given the privilege
31 | P a g e
to cancel the reservations at any time before checking in. Before leaving, they will have
to check out online from the system to assure that all the payments have been made.
This is unique software unlike the traditional systems, where the customer has to go the
front counter and tells each and every detail of what he needs. And the employs
manually provide them all the services. This is not only an overhead for all the employs
of the hotel but also a hectic procedure to go through for the customers. All this
overhead will be minimized and the quality of the system will be assured using web
based hotel management system. The system should also provide an option where the
customers can give their feedback and comments, which can be considered to improve
the quality of the system as well as the overall performance of the hotel.
Leadership
Leaders establish unity of purpose and direction of the organization. They should create
and maintain the internal environment in which people can become fully involved in
achieving the organization’s objectives.
(Definition taken from www.iso.org)
People will able to understand the goals and objectives of the organization (in this case
the hotel). We have to incorporate the system with services which encourages
leadership in every level. This will not only help in minimizing the communication gap
between the customers and employs, employs and manager, and the manager and the
whole administration or the owner. The system will make sure that the evaluation and
implementation of the activities are being done in a proper way. While developing the
software system we have to critically consider the needs of all involved individuals
which are a part of the system in one way or the other. Like customers, employees,
financiers, administrators, managers, local communities and societies all are part of the
system in some way. And everyone plays an important role in the development of the
hotel business.
Incorporating leadership as a main principle of the system will lead us setting
challenging goals and objectives, which ultimately will lead to the creation and
provisions of shared values and ethical role models at all levels of the organization.
One other vital role of this principal will be providing people with training and resources
and giving them the freedom of working with responsibility and accountability.
The system should also encourage and recognize people’s contribution and also inspire
them.
32 | P a g e
Involvement of people
An organization’s success is dependent on the fact that People who are a part of the
system at all levels are the core of the system and their full involvement allows them to
use their abilities for the organization’s benefit.
Keeping in mind full involvement of people in the system while developing it, will make
sure that people would understand the importance of their role in the organization. This
will help them identifying the limitations to their performances and this will help them
being accountable for their own performances.
One other main benefit of involvement of people is their personal development. They
will eager to participate in the continual progress of the organization and will put
creativity, innovation and commitment in it, which will enrich their personalities with
different skills. They will be able to share knowledge and experiences openly and also
discuss their problems openly.
Team building and leadership skills will help them put their best possible efforts in any
kind of job they do for the system.
Process approach
Process approach means all activities which are to be done and related resources are
dealt as a process to get the desired result more efficiently.
It is necessary to define the activities systematically in order to gain a preferred result. It
can be done by establishing clear responsibility and accountability for managing all key
activities. And to ensure it the capabilities of the working group should be analyzed and
measured carefully.
All the factors which have impacts on the main activities like resources, materials and
methods should be focused upon to improve the overall quality of activities. Most
importantly the risks, impacts and consequences of these activities on the customers
should be considered and evaluated carefully.
The process approach will lower costs and shorter cycle times through effective use of
resources. It will also help us in getting regular and expected results providing more
improvement opportunities.
33 | P a g e
System approach to management

In system approach management the interrelated processes are identified and managed
as a system, which contributes to the efficiency and effectiveness of the organization in
achieving its goals.
The system has to be structured in such a way that the organization would be able to
meet its goal in an efficient and effective way. For this the most important thing is to
identify and understand the inter-dependencies and inter-connections of the processes.
And then we have to define and target how a specific activity has to be done. This will
minimize the cost as well.
In general the structured approach creates harmony and integration between the
processes.
The hotel management system software will be divided into processes according to the
working parties. Services availed and provided by the admin, by the customers, by the
financiers, by employs, and by the manager will be taken as separate processes, which
will then be integrated and homogenized as a system. This will provide confidence to
the interested parties and will ultimately add to the effectiveness, efficiency and
consistency of the organization.
Continual improvement
Continual improvement in the overall performance in any organization should be a
permanent objective of any organization.
First of all we need to establish goals and tracks to continual improvement of our
system. Then we should be able to recognize and acknowledge the improvements which
are being taken place.
Improvements in processes, systems and products for every individual involved in the
system should be made. And the organization should be providing people with training
and innovative tools of continual improvement. And there should be consistency in
making continual improvements.
34 | P a g e
Factual approach to decision making

In this kind of approach effective decisions are based on the analysis of available
information and data.
Before taking any decisions it should be ensured that the data and information are
accurate and reliable enough to be considered. This data and information should be
analyzed using valid methodologies. The data should be available to all those who need
it. Ones a decision is made, the organizations should be taking actions based on analysis
of facts, balanced with experiences and expected future outcomes.
Factual approach will make the system flexible by giving enhanced ability to review,
challenge and change opinions and decisions.
It will be easier to demonstrate the positive impacts of past decisions through reference
to factual records.
Mutually beneficial supplier

relationships:
Supplier-organization relationship increases the ability of both to create value. Supplier
and organization are interlinked and interdependent.
The organization should establish relationships that balance short-term gains with long-
term considerations. The key suppliers need to be identified and selected first.
The organization should be sharing future plans and other information with the supplier
consistently in order to minimize the communication gaps which could possibly occur.
The improvements and achievements of the supplier should be inspired and encouraged
to develop a friendly bond and also a clear understanding between the organization and
the supplier.
This will optimize costs, incorporate flexibility and speed of joint responses to changing
market of customers’ needs and expectations, which may change with time.
35 | P a g e
Chapter 5
The Coding Standards

_____________________________________________________________________________________
Introduction:
This document contains coding rules and regulations, and conventions, and style guidelines for
developing applications in C#. It includes general coding guidelines as well as discussions on
naming conventions, formatting, and language usage patterns which will help developers avoid
mistakes.
Purpose
The purpose of this document is to provide coding style standards for the development of
source code written in C#. Following common coding standards not only makes it easier to work
in a team more efficiently but also help in cost-effective maintenance of the application.
Adhering to common coding standards is considered a good practice in industry. Because
changes might be required after some years of the launch of software, and the developers may
not be the same. So the new developers can make their work easier by following the same
coding standards which had been used before.
Scope:
This document is applicable to component libraries, client applications, database systems,
management systems.
It provides guideline on usual conventions of C# in formatting, naming, programming style, and
other conventions. Particularly of those which have been used in the hotel management
system.
 Feedback:
Feedback on any application is of great importance. Your feedback may provide guidelines to
the developer for future improvements and maintenance. So your feedback is highly
encouraged. Do send your feedback, queries and any other suggestions to the development
36 | P a g e
team.
 Terminology & Definitions:
Following are the terminologies which may be referenced throughout this document:
i. Access Modifier:
Access modifiers are C# keywords public, protected, internal, and private which declare the
accessibility of code.
Classes and most other types use the default private. Prominent exceptions are interfaces and
enums which both default to public.
ii. Camel Case:

Camel Case refers to word with the first letter lowercase, and the first letter of each subsequent
word-part capitalized.
For Example: customer Name
In this example ‘c’ of ‘customer’ is lowercase and ‘N’ of ‘Name’ is capitalized.
Similarly “enterCriticalSection” is another example with three words. Where ‘e’ of enter is
lowercase while ‘C’ of ‘critical’ and ‘S’ of ‘section’ are both capitalized.
iii. Common Type System:

The .NET Framework common type system (CTS) defines how types are declared, used, and
managed. All native C# types are based upon the CTS to ensure support for cross-language
integration.
iv. Identifier :
An identifier is a developer defined token used to uniquely name a declared object or object
instance.
Example: public class MyClassName NameIdentifier { … }
37 | P a g e
v. Magic Number:
A magic number is any numeric literal used within an expression (or to initialize a variable) that
does not have an obvious or well-known meaning. This usually excludes the integers 0 or 1 and
any other numeric equivalent precision that evaluates as zero.
vi. Pascal Case:

A word with the first letter capitalized, and the first letter of each subsequent word-part
capitalized.
Example: CustomerName
vii. Premature Generalization:

Premature generalization is the act of creating abstractions within an object model not based
upon concrete requirements or a known future need for the abstraction. It applies to object
model design.
In simplest terms: “Abstraction for the sake of Abstraction.”
C# Golden Rules
The following guidelines are applicable to all aspects C# development:
Follow the style of existing code. Strive to maintain consistency within the code base of
an application. If further guidance is needed, look to these guidelines and the .NET
framework for clarification and examples.
Make code as simple and readable as possible. Assume that someone else will be
reading your code.
Prefer small cohesive classes and methods to large monolithic ones.
Use a separate file for each class, struct, interface, enumeration, and delegate with the
exception of those nested within another class.
Write the comments first. When writing a new method, write the comments for each
step the method will perform before coding a single statement. These comments will
become the headings for each block of code that gets implemented.
Use liberal, meaningful comments within each class, method, and block of code to
document the purpose of the code.
38 | P a g e
Mark incomplete code with // TODO: comments. When working with many classes at
once, it can be very easy to lose a train of thought.
Never hard code “magic” values into code (strings or numbers). Instead, define
constants, static read-only variables, and enumerations or read the values from
configuration or resource files.
Prefer while and foreach over other available looping constructs when applicable. They
are logically simpler and easier to code and debug.
Use the StringBuilder class and it’s Append(), AppendFormat(), and ToString() methods
instead of the string concatenation operator (+=) for much more efficient use of
memory.
Be sure Dispose() gets called on IDisposable objects that you create locally within a
method. This is most commonly done in the finally clause of a try block. It’s done
automatically when a using statement is used.
Never present debug information to yourself or the end user via the UI (e.g.
MessageBox). Use tracing and logging facilities to output debug information.
Gaps and exceptions to these guidelines should be discussed and resolved with your
application architect.
(these rules have been taken from se.inf.ethz.com)
 Coding Style:
The most inconsistencies and controversies between developers are caused by different coding
styles. Each developer has a preference of his own, and rarely are two the same. However,
consistent layout, format, and organization are key to creating maintainable code.
In order to make the code easy to understand and maintain, C# uses the following common
styles of coding:
 Code Formatting
1. Always declare only one namespace for a single file.
2. Avoid putting multiple classes in a single file.
3. Always place curly braces ({ and }) on a new line.
4. Always use curly braces ({ and }) in conditional statements.
5. Always use a Tab & Indention size of 4.
6. Do not declare variables in the same statement; declare each variable independently.
39 | P a g e
7. Place namespace “using” statements together at the top of file. Group .NET namespaces
above custom namespaces.
8. Group internal class implementation by type in the following order:
a. Member variables.
b. Constructors & Finalizers.
c. Nested Enums, Structs, and Classes.
d. Properties
e. Methods
9. Sequence declarations within type groups based upon access modifier and visibility:
a. Public
b. Protected
c. Internal
d. Private
10. Segregate interface Implementation by using #region statements.
11. Append folder-name to namespace for source files within sub-folders.
12. Recursively indent all code blocks contained within braces.
13. Use white space (CR/LF, Tabs, etc) liberally to separate and organize code.
14. Only declare related attribute declarations on a single line, otherwise stack each attribute as
a separate declaration.
Example:
// Bad!
[Attrbute1, Attrbute2, Attrbute3]
public class MyClass
{…}
// Good!
40 | P a g e
[Attrbute1, RelatedAttribute2]
[Attrbute3]
[Attrbute4]
public class MyClass
{…}
15. Place Assembly scope attribute declarations on a separate line.
16. Place Type scope attribute declarations on a separate line.
17. Place Method scope attribute declarations on a separate line.
18. Place Member scope attribute declarations on a separate line.
19. Place Parameter attribute declarations in-line with the parameter.
20. If in doubt, always err on the side of clarity and consistency. Lance Hunt C# Coding
Standards for .NET
 Class Layout:
Classes should be organized into regions within an application using a proper layout. These may
be based on accessibility, type, or functionality. The application architect may help in
determining the layout.
Example:
// Class layout based on accessibility
class Purchasing
{
#region Main
#region Public
#region Internal
#region Protected
#region Private
#region Extern
#region Designer Generated Code
}
 Guidelines:
o Use the same layout consistently in all classes in an application.
41 | P a g e
o remove regions if their associated class elements which are not needed.
o The Designer Generated Code region created by Visual Studio’s Visual Designer should
never be modified by hand. It should contain only code generated by the designer.
 Indicating Scope:
o Scope should be indicated while accessing all static and non-static class members. This
provides the idea of the intended use of the data member. VisualStudio.NET intel-lisense is
automatically invoked when using this practice, providing a list of all available class
members. This helps prevent unnecessary typing and reduces the risk of typographic errors.
Example:
string connectionString = DataAccess.DefaultConnectionString;
float amount = this.CurrentAmount;
this.discountedAmount = this.CalculateDiscountedAmount( amount,
this.PurchaseMethod );
 Guidelines:
a) Include the ‘this’ keyword before all member fields, properties and methods.
b) Include the name of the class before all static fields, constants, fields, and
methods.
 Indentation & Braces:

Statements should be indented (using tabs) into blocks that show relative scope of execution. A
consistent tab size should be used for all indentation in an application. Braces, when necessary,
should be placed directly below and aligned with the statement that begins a new scope of
execution. Visual Studio.NET includes a keyboard short-cut that will automatically apply this
format to a selected block of code.
Example:
float CalculateDiscountedAmount( float amount, PurchaseMethod purchaseMethod )
{
// Calculate the discount based on the purchase method
float discount = 0.0f;
switch( purchaseMethod )
{
case PurchaseMethod.Cash:
// Calculate the cash discount
discount = this.CalculateCashDiscount( amount );
Trace.Writeline( “Cash discount of {0} applied.”, discount );
break;
case PurchaseMethod.CreditCard:
// Calculate the credit card discount
discount = this.CalculateCreditCardDiscount( amount );
Trace.WriteLine( “Credit card discount of {0} applied.”, discount );
break;
default:
// No discount applied for other purchase methods
42 | P a g e
Trace.WriteLine( “No discount applied.” );

break;
}
// Compute the discounted amount, making sure not to give money away
float discountedAmount = amount – discount;
if( discountedAmount < 0.0f )
{
discountedAmount = 0.0f;
}
LogManager.Publish( discountedAmount.ToString() );
// Return the discounted amount
return discountedAmount;
}
 White space
Using white spaces in the program enhances readability and is extremely helpful during debugging and code
reviews. The indentation example above shows an example of the appropriate level of white space.
 Long lines of code:

Very long lines of code weaken the readability of code. Comments and statements that extend beyond 80
columns in a single line can be broken up and indented for readability. But while breaking the lines proper care
should be taken. If we are passing large number of parameters, we can group related parameters in the same
line.
Example:
string Win32FunctionWrapper(
int arg1,
string arg2,
bool arg3 )
{
// Perform a PInvoke call to a win32 function,
// providing default values for obscure parameters,
// to hide the complexity from the caller
if( Win32.InternalSystemCall(
null,
arg1, arg2,
Win32.GlobalExceptionHandler,
0, arg3,
null )
{
return “Win32 system call succeeded.”;
}
else
{
return “Win32 system call failed.”;
}
}
Guidelines:
o When we break parameter lists into multiple lines, each line should be indented one tab
further than the starting line that is being continued.
o Related parameters should be appropriately grouped on the same line.
o When breaking comments into multiple lines, match the indentation level of the code that
is being commented upon.
o Consider embedding large string constants in resources and retrieving them dynamically
43 | P a g e
using the .NET ResourceManager class.
Commenting
Intellisense Comments:
Use triple slash ‘///’ comments for documenting the public interface of each class. This will
allow Visual Studio.Net to pick up the method’s information for Intellisense. These comments
are required before each public, internal, and protected class member and optional for private
members.
End-Of-Line Comments:
Use End-Of-Line comments only with variable and member field declarations. Use them to
document the purpose of the variable being declared.
Example:
private string name = string.Empty; // Name of control (defaults to blank)
Single Line Comments:

Use single line comments above each block of code relating to a particular task within a method
that performs a significant operation or when a significant condition is reached. Comments
should always begin with two slashes, followed by a space.
Example:
// Compute total price including all taxes
float stateSalesTax = this.CalculateStateSalesTax( amount, Customer.State );
float citySalesTax = this.CalculateCitySalesTax( amount, Customer.City );
float localSalesTax = this.CalculateLocalSalesTax( amount, Customer.Zipcode );
float totalPrice = amount + stateSalesTax + citySalesTax + localSalesTax;
Console.WriteLine( “Total Price: {0}”, totalPrice );
// TODO: Comments:
Use the // TODO: comment to mark a section of code that needs further work before release.
Source code should be searched for these comments before each release build.
C-Style Comments:
Use c-style /*…*/ comments only for temporarily blocking out large sections of code during
development and debugging. Code should not be checked in with these sections commented
out. If the code is no longer necessary, delete it. Leverage your source control tools to view
changes and deletions from previous versions of the code. If code must be checked in with large
sections commented out, include a // TODO: comment above the block commented out
describing why it was checked in that way.
Constants:
Constants and static read-only variables should be declared using the following template:
Adjective(s) + Noun + Qualifier(s)
44 | P a g e
Example:
public const int DefaultValue = 25;
public static readonly string DefaultDatabaseName = “Membership”;
Guidelines:
o Use Pascal casing when naming constants and static read only variables.
o Prefer the use of static readonly over const for public constants whenever possible.
Constants declared using const are substituted into the code accessing them at compile
time. Using static readonly variables ensures that constant values are accessed at runtime.
This is safer and less prone to breakage, especially when accessing a constant value from a
different assembly.
45 | P a g e
Chapter 7
RISK MANAGEMENT FOR THE HMS

SOFTWARE
_____________________________________________________________________________________
Purpose:
There are several purposes of risk management for the system under consideration:
1. Identification of risks in hotel management system

2. Prioritizing the identified risks in terms of their impact
3. Devising risk handling strategies for the top most risks
Scope:
All possible risks involved in the project at hand will be discussed, and strategies to tackle them
will be developed.
Roles and Responsibilities:

1. Identification of risks may be carried out by the:
 Project development team

 End user representatives
 Stakeholders
46 | P a g e
2. A risk committee will be put together for the risk management phase of the project. Said
committee will include:
 Project Manager
 Quality Control managers
 Representative(s) from the project development team
 Stakeholders
 Representative(s) from among end users
Definitions and Acronyms:

 OM: Operational Manager; responsible for all the operations carried out during
software development.
 QM: Quality Manager; responsible for quality assurance.
 ROI: Return on investment
 PMO: Project Management Officer; responsible for heading the project management
plan.
Risk Management Process:

The process to be employed for risk management involves two basic stages:
1. Planning
2. Implementation
47 | P a g e
Planning:
This stage mainly involves:
 Identification of risk(s).
Identified risks will be stored in a risk register.
 Analysis of the identified risk(s), qualitative and/or quantitative (see sections 7.5.3 and
7.5.4)
 Ranking the risk in order of significance
 If found to have low significance, putting the risk on a watch list (which is then referred
back to periodically)
 In case of high significance, preparing for risk response
Implementation:
This stage mainly involves:
 Implementation of the risk management plan

 Monitoring the risk response previously initiated
 In case of identification of a new risk, modification of the risk management plan
Qualitative Analysis:
Keeping in mind, Risk Exposure = Probability of occurrence * Impact,
this analysis will include:
 Calculation of probability of occurrence of the risk(s)
 Impact(s) of the risk(s) on the project development and success (such as impact on the
time schedule, budget and quality)
48 | P a g e
From the probabilities calculated, the likelihood of the occurrence of each risk is determined.
For our benefit, we will be using the following criteria:
PROBABILITY LIKLIHOOD F OCCURRENCE

81 to 99 percent Highly likely
61 to 80 percent Likely
41 to 60 percent Moderately likely
21 to 40 percent Unlikely
1 to 20 percent Highly unlikely
Similarly, for each risk, its impact(s) will be categorized as major, medium and minor. A
complete record of this information will be kept in the Risk Response Register.
Quantitative Analysis:
Quantitative analysis is performed for the risks that require to be assessed under additional
criteria for their priority to be determined.
Here, the following basic rule is kept in mind:
Cost Exposure = Probability * Cost impact
 Cost Exposure: cost of risk
 Cost impact: estimation of any additional costs incurred, in case the risk surfaces.
49 | P a g e
Risk Response Development:
The expected output of the analysis phase (as described in the sections above) will be a list of
all potential risks, arranged in order of significance. The next step is to develop response
strategies for the identified risks, beginning with the ones with the highest priority.
The said strategies are expected to be among the following:
 Transference: shifting of the risk impact to a third party.
 Avoidance: method involving the eradication of the expected risk altogether.
 Contingency: comes into play only after a risk surfaces. Appropriate moves are made to
lessen the impact caused by the occurrence of the risk.
Recommended to be devised during the planning phase, in order to minimize reaction

time in the event of risk occurrence.
50 | P a g e
Chapter 8
CHANGE AND CONTROL PROCESS

_____________________________________________________________________________________
INTRODUCTION:
 It is the only official procedure for the call and endorsement in the existing system.
 The certified people to make and approve the call for change will be listed in the formal
contract for the change control process.
 The aforementioned people will be from among the development team as well as
customers.
 It is the responsibility of the project manager to effectively convey and explain the
change control process to all involved parties (mainly the customer representatives as
well as the development team).
SCOPE:
The scope of this section is to lay down the basic framework of the change management
process to be employed during the development and maintenance of the system at hand.
51 | P a g e
8.3-CHANGE REQUEST PROCESS:

8.3.1-INITIATED BY CUSTOMER:
 Request for change made by the customer will be forwarded to the contracts manager
for further processing.
Note that, if request is forwarded to a party other than the contracts manager, the said
party shall immediately redirect it to CM.
 At the time of appeal for a change, the customer(s) must also include its impact on the
cost and schedule of the project (relative to the parameters set previously).
If the customer(s), for some reason, are unable to comply with the aforementioned, the
proposal must be forwarded to the concerned team which will then make the required
estimations, and direct it back to the customers for their consent.
 Each change request will be stored in the change request register, with a unique
identification number.
Appointed members among the team working under the contracts manager will be
responsible for regularly updating the change register.
 The immediate job of the contracts manger will then be to provide a thorough analysis
of the impact of the requested change upon the following aspects of the project:
 Budget
 Timeline
 Resources
52 | P a g e
 The contracts manager must then forward the proposal with the attached details to the
project manager, whose task will be to decide if and why to accept or reject it.
 In case of adjustments made to the original request by the project manager or his
deputed team, the adjusted document will be forwarded to the customers for approval
or otherwise.
In case of acceptance, the approved document will be resent to the project manager or
the contracts manager for the change to be officially incorporated in the system.
8.3.2- INITIATED BY COMPANY:

 Request for change may be filed by the development team, which will then be
forwarded to the customer representatives for approval/rejection.
 Each request will be recorded with a unique identification number in the change
register.
 Upon taking a decision (acceptance/refusal), the customer will redirect the change
proposal to the project manager.
 In case of acceptance, it is the job of the project manager to inform the development
team to proceed with the incorporation of the requested change in software
development.
 In the event of rejection of the change request, the customer(s) shall have to forward to
the PM a detailed explanation of the reasons of refusal.
A meeting might also be arranged between the concerned person(s) from both parties
to debate on the issue, and reach a conclusion favorable to all.
53 | P a g e
8.4- PRIORITISING:
Each request for change recorded in the change register will be ranked in order of
importance. This ranking will base on the following criteria:
 Are there any significant repercussions (in terms of business and development)
in the event of non-implementation of the requested change?
 Are there any significant repercussions (in terms of business and development)
in the event of implementation of the requested change?
 How does the requested change affect the performance requirements of the
project?
 How does the requested change affect the quality of the software being
produced?
 Is it feasible to implement the requested change within the pre-defined time

limit?
 Are resources available for the implementation of the proposed change?
 Is the implementation possible within the constraints of the presently available

technical skills?
 Does the proposed change contradict with any of the system requirements
outlined initially?
8.5- STATUS REPORTS:
During and after the implementation of each change, regularly updated status reports must be
generated. This task must be dealt with by the change control board. Note that the said board
must be composed of at least one representative from among the following:
54 | P a g e
 Requirements collection and analysis department

 Software Development team
 Testing team
 User representatives
 Project management team
 Publications department (responsible for putting together the user documentation)
 Quality control department
 Quality assurance team
55 | P a g e
Chapter 9
The PROJECT MANAGEMENT PLAN

_____________________________________________________________________________________
Project overview
This section provides an overview of the purpose, scope and objectives of the assigned project
for which the plan has been written. The plan essentially outlines the project assumptions and
constraints, a list of project deliverables, a summary of the project schedule and budget, and
the plan for evolving the Project Management Plan.
Purpose
The purpose of the project is to design and implement Hotel Management System to ensure
efficient running of all the events and tasks associated with successful running of a hotel.
The project would provide software based application and associated hardware. The customer
would find it feasible to login from a remote location and gather information about hotel, check
room and party packages. Reserve rooms, halls or tables and check menu without visiting the
hotel. Admin can easily handle and edit menu, job vacancies, billing, duties of workers etc.
The stake holders in this project will find it absolutely convincing to implement the project and
they will judge it by way of its performance and handling of routine work.
Some main characteristics of this project are:
 The project shall only aid to enhance the working system of the organization, and not, in
any way be responsible for affecting business rules or policies of the organization in
general or particular.
 The project shall be delivered to the organization as per the requirements and
specifications provided by the user organization. Any amendment or change to the final
56 | P a g e
design shall be taken up only after due consultation with a member of user organization
not below the rank of an executive.
 The consideration for up-gradation of the project to include all hotels in the world under
one umbrella has been excluded from the present development. However, the same
may be incorporated by intelligent re-use of the project.
 The business needs to be satisfied by the project include all those as provided in the
requirements and specifications from the organization. The overall aim is to enhance
the existing management system by providing an online system for handling day to day
activities of the hotel. It also includes refining and improving the existing structure of
the organization with a view to improve the business strategies, goals, profits and image
in the open market of competition.
Project Deliverables
The project deliverables include following:
 Feasibility report. Project will start once the report is final.

 Project team meetings to analyze the requirements, validate and finalize them and
determine project prototype.
 Customer meetings to clarify the requirements with them and gather their
requirements.
 Necessary hardware required dedicated for the software based application developed
for the purpose e.g. receipt printer.
 First version of the project deployed for reviewing purposes and testing phase.
 Final project deployment on hotel computer.
 Technical support given for the purpose of training and to remove issues in running the
system.
The project shall be handed over to the user organization at their premises and first time
installation and integration of the project with existing system of the organization is the
responsibility of the developing team. However, subsequent installations shall be charged
separately and shall not be included in the budget of the project development.
Evolution of the plan

 The project shall be developed starting at modular levels, incremental development and
integration plan and testing at every stage of integration.
 The planned updates and progress of the project shall be submitted to the user
organization in a weekly summary, electronically mailed to the representative of the
57 | P a g e
organization as nominated. The details shall be discussed in person in the fortnightly

meetings.
 The unplanned aspects relating to the project development shall be intimated to the
user organization immediately on occurrence and may be discussed with the
development team on required basis. However, it is the responsibility of the user
organization to address the unplanned aspects and queries of the development team
within 24 hrs of the intimation, failing which the development team shall not be
responsible for any delay.
 The initial version of this plan shall be placed for configuration management of the
development team and user organization before the commencement of the project and
shall be considered final should both the development and user side agree to the details
of the initial version of the plan.
 Subsequent changes to this plan shall only be allowed upon mutual agreement of both
sides. However, any change affecting the development of the project shall be discussed
in detail, reviewing various aspects and their implications on the development cost,
schedule etc. This would require approval of executives from both sides. Any change in
plan once approved shall be entered in the original document with relevant details of
amendments, and amended copy provided to the user organization in the subsequent
week for information.
Roles and responsibilities

The development team shall comprise of the following individuals:
 Project director: Responsible for making available all required resources. He shall remain
in close contact with user organization for clarity in statement of requirement and
specification. He shall also be responsible for making finances available for the project
as per the contract details with the user organization. He will make sure that the
subordinate team comprising the developer, system analyst and risk analyst are
available and present in the fortnightly meetings and any other discussion as deemed
necessary.
 Project manager: He shall act as the middle man between the individual
developers/analysts and the project director and shall be responsible for
implementation and execution of assigned tasks as per schedule. Any interaction for
purpose of clarity shall be addressed to project director and routed through the project
manager.
 Software developer: The developer shall be responsible for developing the project
application along with various interfaces. He shall be responsible for completion of work
within the allotted time as instructed by the project director, and the timeline outlined
58 | P a g e
in the feasibility study already carried out by system analyst. The evolutionary
development of project and integration of modules after testing shall be carried out by
the developer. He shall prepare the software for the application in line with the
international standards and ethics, and ensure the source code is well documented for
subsequent maintenance by the developing team. He shall aid system analyst in
preparation of necessary documents related to the project. He shall also be responsible
for submitting weekly reports regariding respective assignments and progress to project
manager.
 Risk analyst: He shall be responsible for analysing the various aspects of the project
including indentification, responsibiltities assessment and contigency planning. He shall
also recommend ways to reduce the risks by suggesting alternate ways to contigency
planning. He shall aid the system analyst in preparation of various documents related to
the project for handing over to the user organization.
 System analyst: He shall be responsible for carrying out the feasibility study of the
complete project based on the user requirement, resources and skills available with the
developing team, and the market trends. System analyst shall also be responsible to
monitor the development of the project from financial point of view and carry out re-
estimation of the project, should there be any change in the initially agreed-upon plan.
He shall also be responsible for preparation of the user manual and necessary
documentation to be provided to the user organization related to the project. In
consultation with the risk analyst and developer.
Start-up plans
Estimation plan
 Specify the estimated cost, schedule and resource requirements for conducting the
project and specify the associated confidence levels for each estimate.
 The estimated cost to be incurred on the project shall include the expenditure
incurred on making the resources available for development, pays of development
team assigned to develop and complete the project as well as miscellaneous
administrative expenditures.
 The cost incurred on transportation and other allied administrative expenditures
incurred on making the resources available for development shall contribute to the
cost of resources.
 The estimates also include the pay of the development team for the duration of the
project development as mutually agreed upon.
59 | P a g e
 The estimates shall also include various expenditures incurred on meetings,

transportation, and support services as deemed feasible and necessary and required
by the development team from time to time.
 The estimates of various aspects of the project shall be principally based on the
estimates worked out in the feasibility study.
 Re-estimates shall be worked out based on the amendments to actual user
requirements and their implications to the design and development of project.
System analyst shall be responsible for carrying out detailed re-estimation and the
re-estimates shall be shared with the user organization for necessary availability of
funding.
Control plan
Requirements control
 User shall be cautioned for requirements change and their implications to the
development of the project.
 Any change in requirement shall be scrutinized and analyzed in detail to assess its
implications on project development as a whole and design and budgeting in
specific. The change in requirements and their resulting impact and implications on
the scope and objective of the project shall be deliberated with the user
organization.
 Risk factors associated with the requirements change shall be identified and shared
with the user organization.
 Any change recommended should strictly conform to specifications of change
control process (chapter 8).
Schedule Control
 The project shall be closely monitored for measuring, reporting and controlling
schedule of the project.
 The project manager shall hold a 15 min meeting daily at the start of the day and at
the end of the day.
 The start of the day meeting shall be used to provide guidelines for the day’s work
and reiterate an aspect considered important.
 The end of the day meeting shall be used to confirm achieving of the day’s targets
and communicate faults, failures or shortfalls.
 These meetings shall be coordinated by the project manager.
60 | P a g e
Budget Control
 The budget shall be controlled by the project director and managed by the project
manager. An end-of-week summary shall be prepared and put to the project
director to intimate the weekly expenditures and required funds for subsequent
week.
 Where the activities are exceeding the budget allocation the issue shall be
addressed on priority to identify the variations and if required, user organization be
intimated for additional grants.
Quality Control
 The entire project shall be developed in accordance with international quality

standards.
 Strict ethic codes for software developers shall be followed in development of the
project.
 The project shall be well documented and commented for ease of maintenance and
reusability.
Reporting
 The staff involved in the development shall strictly follow the daily 15-min meeting
for reporting and feedback.
 A weekly progress report shall be submitted to the project director by the project
manager incorporating all aspects of development, including schedule, budget,
resources etc.
 Where required the individuals shall communicate directly with the project manager
on issue pertaining their domain.
Risk Management Plan

This plan processes procedures that will be followed to manage and control events that
could have a negative impact on the Hotel Management System project.
It is the controlling document for managing all the project risks.
The risk management plan shall address following aspects of risk analysis:-
61 | P a g e
 Risk identification
 Risk responsibilities
 Risk assessment
 Risk mitigation
 Risk contingency planning
 Risk tracking and reporting
Detailed aspects of risk management plan are elaborated in chapter 7.
Project Close-out Plan

 The project shall be handed over to the user organization upon completion. The
project deliverables shall include the system as well as necessary documentation.
 Following the completion and handing over, the staff shall be reassigned to
subsequent project.
 The necessary project material shall be archived in the team’s business project
database.
 An internal in house debriefing shall be carried out, where the team individuals shall
share their personnel experiences and provide valuable lessons learnt from the
project development.
62 | P a g e
Chapter 10
WORK BREAKDOWN STRUCTURE

_____________________________________________________________________________________
The work breakdown structure (WBS) shows what the project covers. It is a tool that provides
information about work and processes involved in the project. WBS is used by the project
manager and project team for development of project schedule, resource requirements and
costs.
WBS for this project is presented below and is strictly and purely followed in accordance with
this schedule of activities.
2013 February March April May

Tasks 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 5
Requirements 12 12 8 4
Project
Management 6 8 4
Plan
Design 4 6 12 8
Code & Unit 4 8 12 6
test
Integrate & 4 6 12 12 12 12 8
test
Write Users 6 8
manual
Write final 6 12 12
report
Demonstrate 4
Hours 12 18 20 16 16 16 16 12 12 12 12 12 14 14 12 12 4
63 | P a g e
The project schedule spanning over a period of 4 months was developed by initial task
completion estimates from each member of the group. The plan was reviewed by project
manager and approved by project director.
WBS Outline View

Hotel Management System
 Project management activities

 Evaluation
 Complete project charter
 Complete project management plan
 Conduct monitoring activities
 Initiation
 Project sponsor reviews project charter
 Project charter signed and approved
 Concept/planning
 Create initial scope statement
 Decide project team
 Initial meeting with project team
 Develop plans: project and cost
 Project plan submission and approval
 Requirements analysis
 Starting project meeting
 Validate and verify user requirements by prototype
 Design
 Development
 Obtain hardware/software
 System deployed and installed
 Testing
 User Training
 Control
 Project management
 Project status meetings
 Risk management
 Updating project management plan
 Project close-out
64 | P a g e
 Necessary material archived

 Lessons learnt from debriefings
Hierarchal Structure
Level WBS Element name

code
1 1 Hotel Management System
2 1.1 Project Management activities
3 1.1.1 Evaluation
3 1.1.2 Complete project charter
3 1.1.3 Complete project management plan
3 1.1.4 Conduct monitoring activities
2 1.2 Initiation
3 1.2.1 Project sponsor reviews project charter
3 1.2.2 Charter signed and approved
2 1.3 Concept/planning
3 1.3.1 Create initial scope statement
3 1.3.2 Decide project team
3 1.3.3 Initial meeting with project team
3 1.3.4 Develop plans: project and cost
3 1.3.5 Project plan submission and approval
2 1.4 Requirements analysis
3 1.4.1 Starting project meeting
3 1.4.2 Validate and verify user requirements by prototype
2 1.5 Design
2 1.6 Development
3 1.6.1 Obtain hardware/software
3 1.6.2 System deployed and installed
2 1.7 Testing
2 1.8 User training
2 1.9 Control
3 1.9.1 Project management
3 1.9.2 Project status meetings
3 1.9.3 Risk management
3 1.9.4 Updating project management plan
2 1.10 Project close-out
65 | P a g e
3 1.10.1 Necessary material archived

3 1.10.2 Lessons learnt from debriefings
Tabular View
Level 1 Level 2 Level 3

1 Hotel 1.1 Project 1.1.1 Evaluation
Management Management 1.1.2 complete project charter
System 1.1.3 Complete project management plan
1.1.4 Conduct monitoring activities
1.2 Initiation 1.2.1 Project sponsor reviews project charter
1.2.2 Charter signed and approved
1.3 Concept/Planning 1.3.1 Create initial scope statement
1.3.2 Decide project team
1.3.3 Initial meeting with project team
1.3.4 Develop plans: project and cost
1.3.5 Project plan submission and approval
1.4 Requirements 1.4.1 Starting project meeting
analysis 1.4.2 Validate and verify user requirements by
prototype
1.5 Design
1.6 Development 1.6.1 Obtain hardware/software
1.6.2 System deployed and installed
1.7 Testing
1.8 User training
1.9 Control 1.9.1 Project management
1.9.2 Project status meetings
1.9.3 Risk management
1.9.4 Updating project management plan
1.10 Project close-out 1.10.1 Necessary material archived
1.10.2 Lessons learnt from debriefings
66 | P a g e
Hotel Mgmt. Sys.
Initiation Design Development Testing User training
1.6 1.8
1.2 1.5 1.7
Project Mgmt. Req. analysis Project close-out

Planning Control
1.10
1.1 1.4
1.3 1.9
Evaluation Create init. Scope Init proj meeting Project Mgmt. Necessary
statement material archived
1.4.1 1.9.1
1.1.1 1.3.1 1.10.1
Complete project Decide project Validate and Project status Lessons learnt
charter team verify user req. meetings from debriefings
1.1.2 1.3.2 1.4.2 1.9.2 1.10.2
Complete project Init meeting with Risk Mgmt.

mgmt plan proj. team
1.1.3 1.3.3
1.9.3
Obtain
hrdware/sftware
Conduct monitoring Develop plans: Updating proj.

1.6.1
activities proj. and cost mgmt. plan
1.1.4
1.3.4 1.9.4
System deployed
and installed
Proj. plan submt
and approval 1.6.2
Proj. sponsor
reviews charter
1.3.5
1.2.1
Charter signed
and approved
1.2.2
67 | P a g e
WBS Dictionary
Level WBS Element name Definition

code
1 1 Hotel Management System All work to implement a new Hotel
Management system.
2 1.1 Project Management activities Activities prior to project kickoff devising
regulations.
3 1.1.1 Evaluation Group for evaluating solutions.
3 1.1.2 Complete project charter Manager will develop charter.
3 1.1.3 Complete project management Manager makes plan on how to manage
plan project throughout the period.
3 1.1.4 Conduct monitoring activities Monitor all the pros and cons and keep
eye on management work.
2 1.2 Initiation Work to start the project.
3 1.2.1 Project sponsor reviews project Charter reviewed by the sponsor.
charter
3 1.2.2 Charter signed and approved Sponsor authorizes the manager to move
to next stage i.e. planning.
2 1.3 Concept/planning Work for planning process of the project.
3 1.3.1 Create initial scope statement Project manager creates this statement.
3 1.3.2 Decide project team Project manager determines who will
work on project and resources are
requested.
3 1.3.3 Initial meeting with project Official start of planning process marked
team by this meeting in presence of manager
and team. Sponsor may or may not be
present.
3 1.3.4 Develop plans: project and cost Team develops a plan for project and cost
under supervision of manager.
3 1.3.5 Project plan submission and Approval of plan allows the manager to
approval start with next stage of the project.
2 1.4 Requirements analysis Requirements of the project analyzed.
3 1.4.1 Starting project meeting Formal meeting for kick off of the project
involving manager, team, sponsor and
project stakeholders.
3 1.4.2 Validate and verify user Project manager and team review the
requirements by prototype original user requirements and
users/stakeholders then consulted for
validation. There may be a need for
additional clarification.
68 | P a g e
2 1.5 Design New hotel management system is

designed by the technical resources.
2 1.6 Development Proper development of the system
begins.
3 1.6.1 Obtain hardware/software All hardware/software and facilities
needed for the project are obtained.
3 1.6.2 System deployed and installed Team installs a development system for
testing and customizations of user
interfaces.
2 1.7 Testing A selected set of users test the system.
2 1.8 User training Users and managers are provided with
training classes.
2 1.9 Control Work involved with control processes.
3 1.9.1 Project management Overall project management for the
project.
3 1.9.2 Project status meetings Weekly meetings for checking team
status.
3 1.9.3 Risk management Efforts defined in risk management plan.
3 1.9.4 Updating project management Project progress updated in the project
plan management plan by the manager.
2 1.10 Project close-out Concluding work to close the project.
3 1.10.1 Necessary material archived Files and documents related to project
are formally archived.
3 1.10.2 Lessons learnt from debriefings Meetings held for discussion of lessons
learnt from the project by manager and
team and these lessons are documented.
Glossary
WBS code: identifier assigned to each element in WBS to designate its hierarchal location.
WBS element: single WBS component and its associated attributes located anywhere within a
WBS.
69 | P a g e
Chapter 11
COST MANAGEMEMT PLAN

_____________________________________________________________________________________
Introduction
Cost management is responsibility of project manager throughout the duration of project.
During monthly project status meetings, project manager meets management to present and
review cost performance of the project in the past month. Performance is measured using
earned value. The Project Manager is responsible for accounting for cost deviations and
presenting the Project Sponsor with options for getting the project back on budget. The Project
Sponsor has the authority to make changes to the project to bring it back within budget.
Effort
A team of five highly motivated individuals is set who would work dedicatedly on the project.
The roles and responsibilities of these members are given in a previous chapter. Table below
estimates the pay of the group members during the project.
Project members pay estimate

Pay per month Number of months Sub-total
Project director PKR 45,000 4 PKR 180,000
Project manager PKR 35,000 4 PKR 140,000
Project developer PKR 30,000 3 PKR 90,000
Risk manager PKR 20,000 2 PKR 40,000
Project analyst PKR 15,000 2 PKR 30,000
TOTAL PKR 480,000
70 | P a g e
Costs
Software cost estimating has been an important but difficult. Since the project proposed
consists of software along with the supported hardware and a database which has to be
connected and maintained over servers, the cost has been broken down into smaller pieces.
This splitting makes each component easily verifiable.
Both hardware and software estimated costs for the project are given below.
Total “Hardware Cost Estimate” PKR 189,000
Server Hardware Price per unit Quantity Total
For development PKR 8,000 1 PKR 8,000

For test PKR 2,500 1 PKR 2,500
For training PKR 1,500 3 PKR 4,500
For production PKR 5,000 1 PKR 5,000
Total PKR 17,000 7 PKR 20,000
System Hardware Price per unit Quantity Total

For production PKR 5,000 0 PKR -
Total PKR 25,000 9 PKR 50,000
PKR 70,000
71 | P a g e
Hardware estimate checklist
Item Estimated Not estimated*
Cpu hardware PKR 15,000

Servers PKR 45,000
Modem PKR 1,500
Extraordinary power supply needs PKR 5,000
Backup systems PKR 5,000
Disaster recovery systems PKR 5,000
Additional memory PKR 2,000
Processing services
Disk storage PKR 5,000
Tape backup PKR 5,000
UPS PKR 10,000
Switching services PKR 1,000
Routers
Racks PKR 4,500
Local taxes
Shipping, handling(delivery)
Installation PKR 15,000
TOTAL PKR 119,000
Total “Software Cost Estimate” PKR 257,000
Server Software Price per unit Quantity Total

For training PKR 100 5 PKR 500
For production PKR 100 5 PKR 500
Total PKR 18,500
72 | P a g e
System Software Price per unit Quantity Total

For production PKR 35,000 5 PKR 175,000
Total PKR 220,000
PKR 238,500
Software Estimate Checklist
Item Estimated Not estimated*
Application licenses PKR 10,000

Security PKR 1,500
Project specific software tools PKR 2,500
Application mods – vendor
Archiving
Communication software
Userid administration PKR 500
Number of licenses PKR 2,500
Installation costs PKR 1,500
TOTAL PKR 18,500
73 | P a g e
Chapter 12
TEST CASES FOR THE HMS PROJECT

_____________________________________________________________________________________
12.1- TEST CASE FOR ROOM

RESERVATION:
 Test case id: TC_HS_001
 Test Case Name: Room Reservation
 Test Item: Room reservation form
 Date of documentation: 1/6/13
 Description: to test if the system successfully reserves room(s) as per user requirements
 Procedure:
1. Go to the HMS home page
2. Select room reservation
3. Fill the required fields
74 | P a g e
Input 1: enter information in all fields correctly
Expected Output 1: user successfully reserves a room
Input 2: enter a room number that has already been reserved
Expected output 2: generates a message proclaiming, “Room has already been reserved. Select
another room”.
Input 3: fill any of the fields incorrectly. (E.g. input alphabets in the field requiring the room
number)
Expected output 3: generates an error message, pointing out the field in which error has
occurred.
Input 4: provide incomplete information (leave a few fields blank)
Expected output 4: generates a message proclaiming, “Incomplete information provided”.
18.2- TEST CASE FOR ADMIN LOG IN:
 Test Case ID: TC_HMS_002
 Test Case Name: Admin log in
 Description: this test is designed to check if authorized admin members can log into the
designed system as per the outlined requirements.
75 | P a g e
 Procedure:
1. Go to HMS home page
2. Select login
3. Enter username
4. Enter and verify password
Input 1: enter correct username and password
Expected output 1: successful log in
Input 2: enter correct username and incorrect password
Expected output 2: access is denied.
Message generated, displaying: “Incorrect password. Try again”.
Input 3: enter correct password and incorrect username
Expected Output 3: Access is denied.
Message generated, displaying: “Incorrect username. Try again”.
18.3- TEST CASE FOR ADMIN LOG OUT:
 Test ID: TC_HMS_003
 Test Case Name: admin log out
 Test Item: log out form
76 | P a g e
 Documentation date: 1/6/13
 Description: this test case will check if the system successfully logs out the user as per
requirement.
 Procedure:
1. Go to the HMS homepage

2. If not already logged in, do so
3. Select the log out tab
Input: click on the log out tab
Expected Output: User is logged out.
Message proclaiming, “You have been logged out”, is displayed.
18.4- PAYMENT OPTIONS:
 Test case ID: TC_HMS_004
 Test Case Name: Payment
 Test Item: payment form
 Description: this test case will check if the payment is successfully made and received
77 | P a g e
 Procedure:
1. Go to the HMS home page

2. Click on the payment tab
3. Choose one of the payment options
4. Provide required information
5. Click submit
Input 1: Provide all information correctly and select ‘submit’.
Expected output 1: Payment is accepted.
Message displays: “Amount has been successfully submitted”.
Input 2: Provide incomplete information.
Expected Output 2: Submission fails.
Message displays: “Submission failed. Incomplete information provided”.
78 | P a g e

Hotel Management System: Semester Project

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Hotel Management System: Semester Project

Enviado por

Direitos autorais:

Formatos disponíveis

Software Requirement Specification Document

HOTEL MANAGEMENT SYSTEM

 Introduction to HOTEL MANAGEMENT SYSTEM

 Indicating Scope: ............................................................................................................................. 42

8.3.2- INITIATED BY COMPANY ........................................................................................................... 53

TEST CASES FOR THE ................................................................................................................................... 74

 Better visibility of the Hotel to general public.

The Overall Description and the

Preliminary Requirement Analysis:

1) General Public who will be accessing the system online.

The features available to the General public are:

The features available for the Customers are:

HUMAN RESOURCE DEPARTMENT: this consists of following features.

Room-Division & Accounts:

1) The room division deal in reservation/Non reservation of rooms alone.

This is one of higher authority access area, who is allowed to:

Design and Implementation Constraints:

1) Microsoft Visual Studio 2008 and the Coding language used is C #

1) The system should be presented simple and easy to use.

Assumptions & Dependencies:

The Functional and Non-Functional

“The customer must place an order within two minutes of registering”

 uses simple language

Now the Non-Functional requirements are described as below:

A Non-Functional Requirement is usually some form of constraint or restriction that must be

 uses simple language

Non-Functional requirements tend to identify “user” constraints and “system” constraints.

This is a restriction imposed by the system and not a user request.

The Overall functionalities of the system are described below:

1) Reservations & Bookings:

database for table reservations is checked to ensure that such a table

The USE CASE Diagrams

(the figure has been taken from www.sts.tu-harburg.de)

Why Use Cases are important?

What Use Cases Do

What Use Cases Do Not Do

Definitions of key words used in Use

Front Desk data base management use case:

The Quality Management

 Software Quality Control

 Software Quality Assurance

 Software Quality improvement

System approach to management

Factual approach to decision making

Mutually beneficial supplier

The Coding Standards

 Terminology & Definitions:

ii. Camel Case:

iii. Common Type System:

vi. Pascal Case:

vii. Premature Generalization:

2. Avoid putting multiple classes in a single file.

3. Always place curly braces ({ and }) on a new line.

4. Always use curly braces ({ and }) in conditional statements.

5. Always use a Tab & Indention size of 4.

8. Group internal class implementation by type in the following order:

b. Constructors & Finalizers.

c. Nested Enums, Structs, and Classes.

10. Segregate interface Implementation by using #region statements.

11. Append folder-name to namespace for source files within sub-folders.

12. Recursively indent all code blocks contained within braces.

[Attrbute1, Attrbute2, Attrbute3]

public class MyClass