Embed Size (px)
Citation preview
1
TABLE OF CONTENT
DOCUMENT REVISION HISTORY . . . . . . 2
1. INTRODUCTION . . . . . . . 3
BUSINESS BACKGROUND . . . . . 3
PURPOSE OF THIS PROJECT . . . . . 3
PROJECT STATEMENT . . . . 3
DEFINITIONS, ACRONYMS AND ABBREVIATIONS . . 4
2. PROBLEM ANALYSIS . . . . . . . 5
OVERVIEW OF THE CURRENT SYSTEM . . . 5
REQUIREMENTS GATHERING . . . . . 5
PIECES ANALYSIS . . . . . . 7
PROBLEM STATEMENT MATRIX . . . . 8
USE CASE DIAGRAM . . . . . . 9
3. REQUIREMENTS SPECIFICATION . . . . . 10
REQUIREMENTS MASTER LIST . . 10-13
INTRODUCTION . . . . . . . 14
REQUIREMENTS . . . . . . . 14 - 18
4. MODELS . . . . . . . . . 19
DATA FLOW DIAGRAM (DFD) . . . . . 19
ENTITY RELATIONSHIP DIAGRAM (ERD) . . . 20
APPENDIX: SOURCE DOCUMENTS . . . . . . 21
2
DOCUMENT REVISION HISTORY
REVISION DATE SECTION DESCRIPTION OF CHANGES
Introduction 12 MARCH 2013 1 and 2
Formulating business background,
purpose, scope(project chatter)
definitions, abbreviations, acronyms
basically sections 1 and 2
Requirements
Specification 18 MARCH 2013 3 Drafting the requirements specification
Models 1 APRIL 2013 4 Preparing the ERD, DFD
Introduction 4 APRIL 2013 1 and 2
Amending PIECES, Problem Matrix
Statement, definitions, abbreviations,
acronyms and the Use Case Diagram.
Requirements
Specification 11 APRIL 2013 3
Adding Vehicle registration, Technical and
User login requirements
Models 11 APRIL 2013 4 Amending the ERD, DFD,Data Dictionary
The
whole documentation 30 APRIL 2013 1, 2, 3, 4 Preparing the final documentation.
3
SECTION 1- INTRODUCTION
INTRODUCTION
The Contents of this document describe the development of a management information system
for the sales process for CONNIE’S GUESTHOUSE.
BUSINESS BACKGROUND
CONNIE’S GUESTHOUSE started in the year 2006 with only one employee, renting rooms to
students, Now it has expanded to a guest house for everyone above the age of 18, it has 12
employees, and now rents 20 rooms, Each employee has their own job specification, there is
one who cleans the rooms, and others cook for guests while there are others who take turns as
receptionists. They also provide internship programs for Tourism students. The target market for
CONNIE’S GUESTHOUSE is mostly people who work.
PURPOSE OF THIS PROJECT
o To develop a system that records information of the guest for CONNIE’S
GUESTHOUSE and also improve on the current system which currently issues
incomplete receipts to guests.
o To draft a formal documentation for the above mentioned information system.
PROJECT STATEMENT
The purpose of this project is to develop a management information system for the booking
process for CONNIE’S GUESTHOUSE for an existing business that is currently operating on a
manual file processing system and also receptionists issue incomplete receipts to guests.
4
DEFINITIONS, ACRONYMS AND ABBREVIATIONS
Acronym/
Abbreviation
Description Definition Page
Number
ERD Entity Relationship
Diagram
A data modelling technique used in software
engineering to produce a conceptual data model of
an information system.
24
DFD Data Flow Diagram A graphical representation of the flow of data
through information systems, modelling its process
aspects often preliminary step used to create an
overview of a system which can later be elaborated.
22
PIECES Performance
Information
Economy
Control
Efficiency
Services
The PIECES framework is used for identifying
operational problems to be solved. It consists of the
following:
o Performance: It indicates whether the current
throughput and response time are adequate.
o Information: It indicates whether the end
users get timely, accurate, and useful
information.
o Economy: It indicates whether services
provided by the current system are cost-
effective.
o Control: It indicates whether there are
effective controls to provide accurate and
secure information.
o Efficiency: It indicates whether the current
system makes good use of resources.
o Services: It indicates whether the current
services are reliable, flexible, and
expandable.
6
USE-CASE A USE-CASE is a sequence of actions that provide a
measurable value to an actor; it describes a way in
which a real world actor interacts with the system.
10
5
LIST OF EVENTS BASED ON THE PROJECT STATEMENT
NO: INSTIGATE EVENT OUTCOME
1. Guest Guest information is captured Captured guest
2. Guest Book a room Receipt with order
number
4. Guest Book a room Receive receipt
5. Receptionist Issue keys Booked rooms
SECTION 2- PROBLEM ANALYSIS
CURRENT SYSTEM OVERVIEW
On the current system the guest places makes a booking which is processed by the
receptionist and receives a receipt which doesn’t have a booking number. This makes
the issuing of rooms difficult because there are no booking numbers on the receipt to
show which guest came first or which guest came last. They currently store their guest
details manually as they do not have a database system to store the data so they lose
important guest details.
WHAT THE NEW SYSTEM IS INTEDED TO DO
The new system is intended to help CONNIE’S GUESTHOUSE to record its guest
information and to rent rooms to guests with a receipt that has a booking number to
show which guest came first or which guest came last.
REQUIREMENS GATHERING
We decided to have a meeting with the user because we would get a chance to have
eye contact with the manual system and the users. We had a meeting with the user to
collect information about the business background, current system and which
requirements she wants for the new system to be developed. We also used the
observation technique where we got to see what challenges they face for their day to
day business transactions.
6
PIECES FRAMEWORK
o PIECES SUMMARY
The PIECES framework is used for identifying operational problems to be solved.it consists of
the following:
P PERFOMANCE :
It indicates whether the current throughput and response time are adequate.
I
INFORMATION:
It indicates whether the end user gets timely, accurate and useful information.
E
ECONOMY:
It indicates whether services provided by the current system are cost-effective.
C
CONTROL:
It indicates whether there are effective controls to provide accurate and secure
information.
E
EFFICIENCY:
It indicates whether the current system makes good use of resources.
S SERVICES:
It indicates whether the current services are reliable, flexible, and expandable.
o PIECES ANALYIS
PIECES PROBLEM SOLUTION
PERFOMANCE o RESPONSE TIME: The manual system
processes receipts slow due to the fact
that the manual system is not very user
friendly.
o Have an electronic
system that works
faster and is easy to
use.
INFORMATION o OUTPUTS: The manual system does
not print receipts with booking numbers
o INPUTS: Guest information is not
captured.
o STORED DATA: Guest information is
stored manually.
o Have a system that
prints out receipts
with an booking
number.
o Have a System that
captures guest
information.
o Store Guest
Information
7
electronically.
ECONOMICS o COSTS: Managing the database
manually is expensive
o PROFITS: Bookings can be increased if
a proper receipt is printed to avoid the
confusion of guests.
o Cut down costs by
managing the
system
electronically.
o Have a system that
prints a booking
number.
CONTROL AND
SECURITY
o TOO LITTLE SECURITY OR
CONTROL: Due to unrestricted access
to the system, receptionists can take
advantage of the system and manipulate
it.
o Authenticate each
receptionist who
uses the system.
EFFICIENCY o EFFORT REQUIRED FOR TASKS IS
EXCESSIVE: Manually filling is time
consuming and labour intensive.
o Managing the
system
electronically to
save time
SERVICE o THE SYSTEM IS NOT EASY TO USE:
The current system is not user friendly,
particularly when rooms have to be
issued to guests.
o Have a system that
works faster and is
easy to use.
8
PROBLEM STATEMENT MATRIX
Brief statement of
Problem, Opportunity or
Directives
Urgency Visibility Benefits Priority
or Rank
Proposed
Solution
The receipt written
receptionist does not
show the booking number.
12 MONTHS High Valuable to
guests
2 The receipt will
show the
booking number
The current system does
not store guest’s
information which makes it
difficult to track down
guests.
12 MONTHS High Valuable to
CONNIE’S
GUESTHOUSE
3 Develop a
system that will
store guest’s
information
Due to receptionist’s
unrestricted access to the
system, the receptionists
can take advantage and
manipulate the system on
their own benefits
12 MONTHS High The company
will gain more
security
1 Security
implementation
Manual filling makes it
difficult to keep guest
records
12 MONTHS Low Valuable to
CONNIE’S
GUESTHOUSE
4 Develop a
system to keep
guest records
There is currently no
backup recovery plan
12 MONTHS High Valuable to
CONNIE’S
GUESTHOUSE
5 Implement
information back
up plan
9
USE CASE
Call
Check
available
room
Present
Available room
Book Room
Make
payment
Rent room
Return
key
CONNIE’S BOOKING SYSTEM
Receptionist
Guest
Guest
10
SECTION 3- REQUIREMENTS
REQUIREMENTS MASTER LIST
FUNCTIONAL REQUIREMENTS
1. REQ 1 –GUEST INPUT
The system will allow the receptionist to enter guest’s information.
2. REQ 2 –GUEST BOOKING
The system will allow the receptionist to place a booking from the guest and
the booking receipt will be generated from processing the booking.
3. REQ 3–RECEPTIONIST INPUT
The system will allow the receptionist to enter guest’s information.
4. REQ 4- BOOKING ROOM
The system will allow the receptionist to retrieve the guest’s information in
order to contact the guest and make a booking.
5. REQ 5 -INFORMATION STORAGE
The system will allow the receptionist to store information about the guest
and the guest details.
6. REQ 6 – PERFOM CALCULATION
The system will be able to calculate the total price of bookings or booked
rooms
7. REQ 7–GENERATE REPORT
The system should be able to generate daily or monthly reports.
NON-FUNCTIONAL REQUIREMENTS
8. REQ 8 – SECURITY ON THE SYSTEM
The system should provide the user login interface that will have textboxes
for username and password which will be authenticated.
11
9. REQ 9 – GRAPHIC USER INTERFACE
The system must be user friendly for any registered receptionist who is to use
the system.
10. REQ 10 – Technical Requirements
The system will require certain devices for it to function in its entirety.
REQUIREMENTS DEFINITION
INTRODUCTION
The requirements are things to be done on a system for it to be considered successful.
Requirements Definition:
o A condition or capability that must be met or possessed by a system, results or
component to satisfy a contract, standard, specification, or another formal
document.
Functional Requirements:
o They are main functions the system must do and considered number one priority
functions.
Non-functional Requirements:
O All functions that the system does but not considered number one priority
requirement.
REQUIREMENTS GATHERING
FUNCTIONAL REQUIREMENTS
1. REQ 1 - GUEST INPUT
1.1. Description
The system will allow the receptionist to enter guest information.
1.2. Input
The guest provides the receptionist with personal details including the Guest_ID,
Last_Name, First_Name, Physical_address, and Contact Number. The
receptionist will enter the guest information in the table “Guest”. All fields will be
12
required. The Guest ID will be unique as it identifies the guest. The first name,
last name, and the address will consist of String characters (A-Z). The guest
Contact number will be in the format (### ### ####) where the # represent
numbers from (0 -9) and will be the input for that field.
1.3. Processing
The system will be running while the receptionist is inputting guest information.
When the Receptionist presses the “Save” button, then the system determines
whether the Receptionist has filled all the required fields. If the Receptionist has
skipped any field, the system will pop up a red asterisk next to the field with a
message saying “Field required”. After the information is taken by the system,
then the system will save the Guest information into the “Guest” Table in the
database.
1.4. Output
The system will then show a message box saying “The Guest is Successfully
Registered” then the Home screen will be displayed.
1.5. Constraints
Depends on the speed at which the guest information is inputted and saved
depends on the receptionist’s typing speed
2. REQ 2 – GUEST BOOKING
2.1. Description
The system will allow the receptionist to place a booking from the guest and the
booking receipt will be generated from processing booking.
2.2. Input
The system will have different text fields which represents different rooms rented.
Receptionist will specify the number of rooms in the text box labelled “Quantity”,
and then the Receptionist will press the “Process Booking” button.
2.3. Processing
When the Receptionist presses the “Process Booking” button, then the system
will calculate the total cost, and print the booking receipt. And these rooms are
13
lookups from the database which is automatically updated by this process; the
information is then saved in the system database.
2.4. Output
After the processing of booking is done, the system will then print a booking
receipt with a company name, Receptionist name, Guest ID, Price, , Date &
Time and the amount paid, change, Room_Number and capacity.
2.5. Constrains
Depends on the speed at which the guest’s information is inputted and saved
depends on the receptionist’s typing speed.
3. REG 3 – Receptionist Input
3.1. Description
The system will allow the receptionist to enter guest information.
3.2. Input
The guest provides the receptionist with personal details including the Guest_ID,
Guest_Name, Physical_address, and Contact Number. The receptionist will enter
the guest information in the table “Guest”. All fields will be required. The guest ID
will be unique as it identifies the guest. The Guest_Name and the address will
consist of String characters (A-Z). The guest Contact number will be in the format
(### ### ####) where the # represent numbers from (0 -9) and will be the input
for that field.
3.3. Processing
The system will be running while the receptionist is inputting guest information.
When the receptionist presses the “Save” button, then the system determines
whether the receptionists has filled all the required fields. If the receptionist has
skipped any field, the system will pop up a red asterisk next to the field with a
message saying “Field required”. After the information is taken by the system,
then the system will save the guest information into the “Guest” Table in the
database.
3.4. Output
The system will then show a message box saying “The Guest is Successfully
Registered” then the Home screen will be displayed.
14
3.5. Constraints
Depends on the speed at which the guest information is inputted and saved
depends on the receptionist’s typing speed.
4. REQ 4 – Make Booking
4.1. Description
The system will allow the receptionist to retrieve the guest’s information in
booking to contact the guest and place an booking.
4.2. Input
The system will have a text field which represent the search field. The
receptionist will search the guest name, in booking to retrieve the guest details in
the text box labelled “Search”, and then the receptionist will press the “Search”
button.
4.3. Processing
When the receptionist presses the “Search” button, then the system will search
for the guest and preview full details of the guest. And the guests are lookups
from the database which is automatically updated by this process.
4.4. Output
After the retrieving the details is done, the system will then print the guest’s
details a guest ID, Guest_Name, address, contact number.
4.5. Constrains
Depends on the speed at which the receptionist enters the information on the
search engine and the typing speed.
5. REQ 5 – Information storage (Database)
15
5.1. Description
The system will provide Database to allow for quick accessing of information
and to ensure that the information is protected.
5.2. Input
The Receptionist will input information about each booking into the system
user interface. This information is then stored into a related table in the
database.
5.3. Processing
Once the Receptionist clicks the “Process Booking” button, after they have
logged on the relevant information from the guest. The information is then
sent to the database.
5.4. Output
The database will record all system events to the log files on the database.
System events include errors, data access time and backup times. This
output will be accessible to the system administrators so they determine if the
database is functioning correctly.
5.5. Constraints
The amount of traffic a database can handle is determined by the speed of
the server. A dedicated server or multiple servers are necessary if the
number of calls the Receptionist receives on average is very large.
6. REQ – Perform Calculations
6.1. Description
The system should perform all calculations required in the running of the day to
day business processes.
6.2. Input
The system will input the payment amount of the guest.
16
6.3. Processing
The system will perform calculations about the purchased or booked rooms.
6.4. Output
The system will display the payments made by the guest and the payment
balance.
.
7. REQ 7 – GENERATE MANAGEMENT REPORTS
7.1. Description
The system will provide the user interface to allow the receptionists to view
financial business reports.
7.2. Input
The receptionist can view different daily, weekly, monthly and yearly financial
reports which can be specified for which dates are needed.
7.3. Processing
The system will then query the database from relevant related tables for the
desired information and compute calculations if necessary for example the total
number of transactions occurred in a single business day.
7.4. Output
The system will provide printing options in case the management would like to
print the report.
NONFUNCTIONAL REQUIREMENTS
8. REQ 8 – Security on the system
8.1. Description
17
The system will provide a Login user Interface that will have textbox’s for the
username and password. The system will do authentication on the entered
credentials against the stored values in the database.
8.2. Input
.
The user must insert credentials, and click the “Login” button.
8.3. Processing
Once the “Login” button is clicked, the entered credentials will be sent to the
database. The server will then validate the credentials against those, which are
pre-defined in the database.
8.4. Output
If the system matched the credentials to those stored in the database, the
system’s Home user interface will appear, else if the system couldn’t match the
entered user credentials, the system will display an error message saying that
the entered credentials is incorrect and also ask the user to re-enter the correct
credentials.
8.5. Constrains
Access to the user interface depends on the credentials entered.
9. REQ – Graphic User Interface
9.1. Description
The system must be user friendly for any registered receptionist who is to
use the system.
9.2. Input
The user will be required to navigate through the system using buttons,
text fields, labels that are going to be provided on each form.
9.3. Processing
Buttons are clickable events that will perform a certain task as required by
the user. Text fields will require the user to input or display data, and
labels will also display a user’s required output will help the user to
navigate through the system.
18
9.4. Output
The system shall prompt a user with a red asterisk next to the field with a
message saying “Field required” when a user skips a required text field.
The system will allow user to move from displaying the appropriate
information.
9.5. Constrains
The navigation speed through the forms will depend on the user
navigation speed and on how big the computer ram and processor.
10. REQ 10 – Technical Requirements
10.1. Description
The system will require certain devices for it to function in its entirety.
10.2. Input
For the system to operate entirely, the system will require a computer to capture
information of business activities
10.3. Processing
For this system, the minimum hardware requirements are:
320 Gigabytes Hard drive,
Intel Core i3 Processor,
2 Gigabytes RAM
Windows 7 and 8 Operating System.
These are reasons why the above hardware is required:
Core i3 one of the fast processors.
10.4. Output
The system will then precede the user to Home Screen once the system has
validated the user login credentials.
19
Section4
DFD
Call
Check
available
room
Present
available
room
Book room
Make
payment
Rent room
Return keys
GUEST
RECEPTIONIST
GUEST
RECEPTIONIST
PAYMENT
ROOM
ROOM
RECEPTIONIST
RECEPTIONIST
GUEST
GUEST
Guest details Guest info
Room details
Room info
If available
Available room
details
Guest details guest
Payment infoPayment detais
Room infoRoom details
Room details
Key info
Key details
Payment details
20
ERD
CALL
PK Caller_ID
Date
Time
FK1 Booking_ID
FK1 Receptionist_ID
FK1 Room_ID
BOOKING
PK Booking_ID
PK,FK1 Room_ID
PK,FK2 Receptionist_ID
Time
Date
Duration
FK3 Guest_ID
PAYMENT
PK Invoice_ID
Date
Time
FK1 Booking_ID
FK2 Reciept_ID
RENTROOM
PK Rent_ID
Key_Number
Room_Number
FK1 Invoice_ID
FK2 Receptionist_ID
FK3 Guest_ID
RECEPTIONIST
PK Receptionist_ID
Receptionist_Name
Receptionist_
Receptionist_
Cell_Number
GUEST
PK Guest_ID
Guest_Name
Guest_Address
Cell_Number
ROOM
PK Room_ID
Capacity
Type
Description
CASH
PK Reciept_ID
Amount
Date_Of_payment
Time
FK1 Receptionist_ID
21
