Professional Practice Project: Booking System

This article discusses the non-functional requirements for a booking system, including documentation, hardware considerations, performance characteristics, error handling, system interfacing, quality issues, system modifications, physical environment, security issues, and resource issues. The article also provides a detailed description of the project requirements and the characteristics and requirements of the product.

Running head: BOOKING SYSTEM
Professional Practice Project: Booking System
(Student’s Name)
(Professor’s Name)
(Course Title)
(Date of Submission)

BOOKING SYSTEM 2
Non-Functional Requirements
Non-functional requirements (NFR) are important to the success of any system. If these
requirements are not addresses, it results in undesirable results like unsatisfied clients, users, and
developers. Without a list of well-defined NFR, it also results in confusing definitions and
inconsistent terminologies and confusing definitions. The database of his booking system must
be well –designed so any query by any of the user can be processed and returned in a reasonable
amount of time (Fernandes & Machado, 2005).
Documentation
One of the NFR requirement is documentation. In the booking system, this requirement
describes the behavior and the features of the system. The main aim of documentation in this
system is to specify the overall booking system requirement. In addition, documentation
establishes initial training, system architecture requirements and the system acceptance criteria.
Another major aim of documentation in the booking system to act as a manual to the end users of
the system and to the system administrators and to Murdoch’s support staff.
Hardware consideration
The booking system is a mission-critical application to the Murdoch University. This
means that choosing the most appropriate hardware equipment is very essential. Upcoming
technology is also a factor to consider while outlining the hardware specification of the system.
The minimum hardware requirements for the end-user computer is a RAM of 1 GB or greater, a
CPU processor of 1 GHz or higher, a hard-drive of 40GB or larger, a monitor 17’’ flat panel with
a 1024 by 768 or even a higher resolution and a backup device which can either be an external
USB or a compact disk. The server hardware consideration ought to have a 2GB RAM, have a
UPS back-up, CPU to have a minimum of 3GHz, and have a hard drive of over 80GB. The

BOOKING SYSTEM 3
system will run on a server 2012 R2 so that the response time of booking request is not
constrained (Stallings, 2015)
Performance characteristics
The server ought to process queries very first since there will be a lot of users. The
information that is to be transmitted and received ought to be kept at a minimum so as to avoid
any form of delay or overloading the university network. Due to large number of users of the
system, the network speed should be at 8Mbps Ethernet or higher.
Error handling and extreme conditions
The database component of this booking system communicates only with the Application
Server; this means that the database component only needs to handle only erroneous input from
the Application Server component; erroneous input means passing invalid command objects to
the database component. When a command object is said to be invalid, one condition has to be
met; when the database component does not know how to interpret the command either because
the required parameters are not included or invalid parameters are used. The extreme conditions
in this system will be defined as database overload (Coronel & Morris, 2017).
System interfacing and compatibility
The database of this system will only interact with the application server on a repeated
basis but not directly to the system users. In addition, the interactions are wholly self-defined as
the interaction is within the overall system.
Quality issues
The booking system ought to be reliable. Also, the system ought to be accurate so that it
returns the correct result for each query inputted. In case of an error, the booking system will trap
the error and notify the Application Server (AS) of the error. In addition, this system ought to be

BOOKING SYSTEM 4
robust and have very minimal downtime. If any downtime is to be experienced is only for back-
ups and updates which ought to be handled not more than an hour (Berk, 2013).
System modifications
The booking system data will be on Microsoft access which have limitations. It is
expected that the database will change in near future. This ought not to be a problem since the
database will use standard JDBC and SQL. It is also very like that more functionality will added
as the booking system matures so as to increase flexibility. If the system is properly documented
and all methods are included then it should not be a problem to upgrade the system in near
future.
Physical environment
The booking system database server ought to run a monitored environment or in a
computer machine room or in the university server room. The end user computer can be
anywhere within the university environment
Security issues
The database server for this system ought to have sufficient protection. This is so to
prevent the system users from making any unauthorized changes to information stored or having
any form of direct access to the system database. In addition, the booking system ought to be
resilient to any form of network attack. As data server is expected to be in the university server
room, the university should establish physical access procedures to this room. Only the
university system administrators ought to access the room.
Resource issues
The booking system should have a quarterly daily backup schedule. As said before the
database and the Application Server (AS) will be located in the server room, procedures by the

BOOKING SYSTEM 5
system administrators ought to be in place to backup data. It is also important to have a
redundant server which must be synchronized with the master server. Lastly, any form of
installation or maintenance that may be required should be done by a trained computer
technician.
Scope definition
Narrative description of the system
This system is a web-based system which allows multiple calendars schedule. The system
is used to make university bookings more efficient. The system allows the organizers of the
meeting to upload excel sheets of any student who require an interview where the system auto-
generate personalized emails for each student where they can view the available slots.
Overall objectives and justifications
One of the objectives of this project is to make booking more efficient. This means that
the system users need to interact with the system without facing any form of difficulty. Another
objective for this system is to save booking time. This is done by generating a personalized email
for each student where the student can click the link for the available slots. This in turn saves
time (Adams, 2016).
A detailed description of project requirements
One of the functional requirement of this system is to provide a very well-defined API
which the Application Server (AS) uses to query the database. Upon receiving the query by the
database server from the Application Server (AS) component, the database component ought to
then analyze the state of the query, then execute the query which then returns the queried page in
a form that is readable to the user which is XML format.

BOOKING SYSTEM 6
Based on the provided process above, some of the project requirements are Application
Server, Microsoft products such as Access, Excel, Database server, and a UPS which is used for
power back-up. The system also requires system administrators for an update of the application
servers and computer technicians.
Characteristics and requirements of the product
One of the features and requirement for this system is email automation. Once an
organizer uploads an excel sheet, sending out emails is a standard procedure in this system. The
email notification and follow-up should not take too much time. Another feature in this system
which is also a requirement is providing a detailed report to the system administrators on the
booking done which will be used for the upgrade of the system. Integration with E-mail
application service is also a requirement; this enables it to meet the objective of saving time
(Kendall & Kendall, 2017).

BOOKING SYSTEM 7
References
Adams, K. (2016). Non-functional requirements in systems analysis... by Kevin Adams .
Newyork: Springer international .
Berk, J. (2013). Systems failure analysis by Joseph Berk . Ohio: ASM International.
Coronel, C., & Morris, S. (2017). Database systems : design, implementation, and management.
Boston: Cengage Learning.
Fernandes, J. M., & Machado, R. J. (2005). Requirements in Engineering Projects by Joāo M
Fernandes . Chicago: Springer International Publishing .
Kendall, K. E., & Kendall, J. E. (2017). Systems analysis and design by Kenneth E Kendall .
New Jersey: Pearson.
Stallings, W. (2015). Operating systems : internals and design principles. NewYork: Harlow
publishers.