YA Sailboat Reservation System Specification

This system specification document provides comprehensive requirements for the Sailboat Reservation System for Yacht Australia (YA). It includes the purpose, scope, overview of SRS, specific requirements, external interfaces, user interface, functional requirements, IT acquisition strategy, context, best lessons and practices learned.

System Specification 1
System Specification
Name
Institutional Affiliation

System Specification 2
Table of Contents
System Specification.......................................................................................................................3
Purpose.........................................................................................................................................3
Scope............................................................................................................................................3
Overview of SRS.............................................................................................................................4
The General Description..............................................................................................................4
YA Sailboat Reservation System Functions....................................................................................5
Booking and Reservation Module................................................................................................5
Payment Module..........................................................................................................................6
General Management...................................................................................................................6
Specific Requirements.....................................................................................................................6
External Interfaces.......................................................................................................................6
User Interface...........................................................................................................................6
Functional Requirements.............................................................................................................7
IT Acquisition Strategy....................................................................................................................9
Context.........................................................................................................................................9
Best Lessons and Practices Learned..........................................................................................10
Architectural Design......................................................................................................................14
User Interface Design....................................................................................................................15
Default Home Page....................................................................................................................15
Registration Screen....................................................................................................................16
Login Screen..............................................................................................................................16
Customer Home Screen.............................................................................................................17
Reservation Screen.....................................................................................................................17
Reservation Details Screen........................................................................................................18
Administrator/Management Home Screen.................................................................................18
Add Company Asset Screen......................................................................................................19
Business Process Models using BPMN 2.0...................................................................................19
Physical Data Storage Design........................................................................................................20
Reference List................................................................................................................................21

System Specification 3

System Specification 4
System Specification
Purpose
System specification provides comprehensive requirements for the Sailboat Reservation
System for Yacht Australia (YA). This document will offer great ad deeper understanding of the
expectation of the YA Sailboat Reservation System to be deployed. Complete and clear
knowledge of the system expectation will facilitate development of correct YA Sailboat
Reservation System for the end user and can be used as a referral document during the later
stages of the development process. System specification document provides the project
foundation, which act as the basis to design, develop, and test the system (Kuklin, Zemskov and
Nikulina, 2011 p.277). The system requirement specification (SRS) will be used by the
development team to fully understand the system expectations so as to develop appropriate YA
Sailboat Reservation System. SRS will be used by the end users as referral during testing stage to
determine if the correct system has been developed to their expectations. If the system does not
meet YA management expectations (end user), the development team will review the SRS and
modify the system accordingly.
Scope
The information to be developed is a reservation system that will automate operation of
the YA. The YA Sailboat Reservation System will have several sub systems in it. First is the
booking and reservation system to manage and keep track of sailboat reservations. The second
sub system is the payment module which gives the customers several options to choose from.
The third sub system is the management module which facilitates employee, company assets,
and other managerial tasks such as report generation (GAO and LUO, 2011 p.2503). This

System Specification 5
module allows the system administrator to add company assets, employees, and carry out other
tasks such as confirming reservations, checking if the requested boat is available, and generating
reports.
The system is made up of two end users the management (Administrator) and the
customers. Bothe users should be able to access the booking and reservation module and check
the status of the reservation. The management module is restricted to administrators only. One of
the objective of the YA Sailboat Reservation System is to meet the increased and complex
company needs. Managing the needs of YA will become more unwieldly without automation.
The system should be easy to use, user appropriate, detect invalid input and prompt on what
should be done, and ultimately have high level of user satisfaction.
Overview of SRS
The system requirement specification is made up of two parts; general description and
specific requirements (Viswam and Karattil, 2013 p.16). The general description will give the
overall high-level perspective of the YA Sailboat Reservation System while specific and in-depth
requirement details is described by the specific requirements part.
The General Description
This section identifies the overall aspects that affect the system and its requirements
(Benabbou, Bahloul and Dhaussy, 2016 p.893). However, specific details are not stated in this
section, instead it gives a background of the requirements so as to make it understandable. Some
of the aspect include:

System Specification 6
Product Perspective: The YA Sailboat Reservation System is self-contained, independent,
and scalable. The front-end part which is the user interface will be accessed over the internet via
a browser. The backend (database) is accessed remotely via remote desktop connection. Oracle
8i will be used to configure all the databases of YA Sailboat Reservation System (Chen and
Chen, 2011 p.778). The databases include customer information, employee details, boat
information, and company financial records. The information can only be modified by authorized
users. The customer information will include customer first name, last name, address, phone
number, reserved sailboat, name of sailboat, credit card number, number of occupants,
confirmation number, automatic cancellation, check-in time and date, checkout time and date,
amount paid, and balance. The employee information will include employee_ID,
employee_name, designation, job_category (part time, permanent), and sailboat_assigned. The
sailboat information will include sailboat name, status, location, and sail_rates (Xie, 2013 p.296).
YA Sailboat Reservation System Functions
Booking and Reservation Module
 Should allow customers to register
 Has default sailboat categories and rates.
 Should have description of the sailboats
 When a sailboat is booked the sailboat, status should change to booked.
 Allow the administrator to change reservation details.
 Allow the customer to browse for other available sailboats if their choice is booked.
 When customer checkouts, the system should display amount owed.
 Allow customer to see reservation status.

System Specification 7
Payment Module
 Allow customers to choose the payment method
 Allows administrator to generated receipts and invoices
General Management
 Allow company assets to be added
 Allow reports to be generated to audit YA bookings, future bookings, and sailboat
revenues.
 Allows modification, deletion, addition of information on sailboat, rates, and user
profiles.
 Creation of users and generation of passwords.
Specific Requirements
This part provides all the system requirements in details, that when combined with use
case, ERD, context diagram, and use case description gives enough information for the
developers to design, develop, and test the system to meet those requirements (WANG and
LONG, 2018 p.72).
External Interfaces
YA Sailboat Reservation System will utilize the standard I/O devices like the mouse,
keyboard, printer, and monitor to interact with the system.
User Interface
The various screens that the user will interact with are described in the table below
(Cannon, 2008 p.238).

System Specification 8
Name of the screen Description
Register Allows the users to register by keying in the details required by
the system.
Sign in Sign in to the system as a customer, administrator
Booking and Reservation Includes save/ update, retrieve button, cancel reservation, adjust
booking rates, change reservation, accept payment method.
Check-in Check-in customer, modify sailboat stay, adjust reservation rates,
special requests, accept payment method.
Checkout Generate bill, check-out customer
Sailboat Payment Accept payment for food and boat
Sailboat Service New order, cancel, view, modify order, generate bill.
Customer Profile Update, add customer details.
Administer Sailboats Rates and availability
Administer User Add, delete, and modify users, change password.
Reports View, select, generate, and print reports.
Functional Requirements
The information system is categorized into three major sectors, booking/reservation,
Payment, and management (Jogada and Warad, 2016 p.141).
1. Booking/Reservation

System Specification 9
The system shall:
 Record customer details
 Record reservations
 Record Sailboat category, type, and status
 Record number of occupants
 Display sailboat rate
 Display whether the boat is guaranteed or not
 Generate reservation confirmation number which is unique.
 Automatically cancel unconfirmed reservation.
 Record expected check-in and checkout time and date.
 Check-in and checkout customers
 Allow modification of reservation details without altering or reentering customer details
2. Payment
The system shall:
 Record payment method
 Record total amount owed to customer
 Record amount paid
 Record balance
 Display invoice
3. Management
The system shall:
 Display sailboat occupancy for a period specified
 Display boat revenue for a period specified

System Specification 10
 Display exception report
 Allow addition, modification, and deletion of information concerning customers,
employees, and sailboats
IT Acquisition Strategy
The acquisition strategy is an integrated, detailed plan established as part of acquisition
planning operations (Sabato, 2010 p.63). It defines the firm, support and technical strategies to
meet objectives of the program and manage program risks. The strategy act as a guide to the
acquisition program implementation across the whole system or program life cycle. It describes
the connection phases of acquisition and work efforts, and major program events such as
reviews, test activities, decision points, contracts awards, delivery quantities or production lot,
and functional deployment goals. The strategy expands over time and should constantly mirror
the desired goal and current status.
Context
Implementing and developing an efficient acquisition strategy needs systems thinking to
make sure that the different strategy elements are connected and that interrelationships are
accounted for and understood during strategy execution (Hiremath, 2008 p.34). Besides,
schedule, cost and capability (the performance of the system) agreement is needed, and managers
of the program will require the intuitiveness to make sound decisions based on recognizing the
possible risks that may cause hindrances while achieving desired results. As such, systems
engineering performs a major role in executing and planning the acquisition strategy.
How Yacht Australia acquire services and products they need to implement their mission
or carry out their functions differs depending on the urgency or criticality of the service or

System Specification 11
product to the company’s mission. Another factor that Yacht Australia should consider is
whether acquisition involve the assignment of large amounts of the resources of the company.
Acquisition planning for key, complex efforts needs formality and comprehensiveness and has
an earlier, greater need for system engineering. Acquisition management at such a level regularly
needs balancing the investments of several shareholders by executing and establishing a process
of governance that influence a balance between the desire for a general agreement and the agility
required to make tradeoffs among schedule, cost and system performance delivered to handle
priorities and changing need. Because of the basic difficulties in such an environment of
acquisition (operational or organizational, technical, political and economic), Yacht Australia
needs program directors to document and develop an acquisition strategy to clearly state the
technical and business concepts of management for achieving the objectives of the program
within set constraints of resource. System engineers of Yacht Australia are normally called to
assist in executing and developing the acquisition strategy.
Best Lessons and Practices Learned
Concentrate on total strategy: Yacht Australia should avoid concentrating on the aspects
of contract of an acquisition strategy. In most organizations, the acquisition strategy term means
the aspects of contract on an acquisition effort. Such a view appears to assume other factors such
as cost, technical and schedule that may affect a successful result and normally have
interrelationships that must be put into consideration to identify how to obtain required
capabilities. The overall strategy will be influenced and shaped by several factors that must be
put into consideration collectively and individually in executing and planning the acquisition
effort.

System Specification 12
Document it: Yacht Australia needs program managers to establish an acquisition
strategy adjusted to the specifics of their program. Besides, it describes acquisition strategy as
the overall plan of the program manager for satisfying the need of the mission I the most
economical, efficient and timely manner. An acquisition strategy is unwarranted or unnecessary
for an acquisition effort. For key acquisition programs of a system, a documented or written
acquisition strategy may be utilized to satisfy Yacht Australia needs for acquisition plan.
Employ early systems engineering: essentially, the Yacht Australia needs to have
formality and greater detail in the process of planning for acquisitions that are more costly and
complex (Lin, Ho and Lin, 2015 p.64). Besides, these large-scale and major acquisition efforts
have a larger need for the employment of appropriate system engineering practices and
principles, both among the suppliers and within the government of the services and products. A
familiar principle of project management or program is that many programs are unsuccessful at
the start. Such a perception can be associated to insufficient system engineering, which when
conducted efficiently clearly states what the government requires, translate those requirements
into solicitation or procurement needs, and determines, risks, issues and opportunities that
influence and shape the healthiness of the acquisition strategy.
An acquisition strategy entails several elements: an acquisition strategy is not one body but
involves several element parts that joins together to create an overall approach or strategy for
acquiring through contract services or supplies/products required to accomplish the needs of the
company (DJEBRANI, ABDESSEMED and BENALI, 2010 p.339). These components appear
to vary depending on the acquisition effort nature on whether the effort is properly controlled as
a program, and on the acquisition procedures, policies and governance regulations and policies
of the company being supports. Nevertheless, a common component of most acquisition

System Specification 13
strategies (program) is designing the program in terms of when and how required capabilities
will be created, examined and delivered to the consumer. There exist two fundamental
approaches to capability deliverance:
 Altogether, in one step (sometimes known as big bang or grand design) to accomplish
unchanging, well-defined need.
 Incrementally in spirals (or series of steps) to adapt to updates and changes to
requirements based on response from capability incremental delivery (Okuyama, 2017
p.127). The approach is usually called agile or evolutionary acquisitions.
Select a proper strategy: choosing which delivery approach of capability to utilize relies on
various factors such as the maturity level of enabling technology, requirements stability or the
emerging nature of the requirement that is being addressed by the acquisition effort, what is
being acquired and the rate of change of technology. For many IT (information technology)
acquisition effort, experience has demonstrated that an incremental/evolutionary/agile strategy is
favorable to planning and accommodation for changes fundamental in software-intensive
systems (Su, 2016 p.235). Nevertheless, including an agile or evolutionary approach into the
capability delivery does not assure that an acquisition strategy is appropriate. Other factors also
influence the efficiency of a particular strategy (Wang, Liang and Qian, 2013 p.102). These
aspects include whether the strategy is established on a valid evaluation of the risks associated in
accomplishing the acquisition effort objectives, knowledge-driven or meaningful event
milestones analysis and verification strategy and realistic test to evaluate progress towards
accomplishing acquisition goals, and realistic schedule, cost and delivered capability
(performance) baselines.

System Specification 14
Architectural Design

System Specification 15
User Interface Design
Default Home Page

System Specification 16
Registration Screen
Login Screen

System Specification 17
Customer Home Screen
Reservation Screen

System Specification 18
Reservation Details Screen
Administrator/Management Home Screen

System Specification 19
Add Company Asset Screen
Business Process Models using BPMN 2.0

System Specification 20

System Specification 21
Physical Data Storage Design

System Specification 22
Reference List
Benabbou, A., Bahloul, S. and Dhaussy, P. (2016). An Automated Transformation Approach for
Requirement Specification. Procedia Computer Science, 91, pp.891-900.
Cannon, S. (2008). Computer Reservation System. Journal of Access Services, 5(1-2), pp.233-
242.
Chen, S. and Chen, M. (2011). A Semantical Approach for Automatically Transforming Software
Requirement Specification into Formal Presentation. Advanced Materials Research, 225-226,
pp.776-779.
DJEBRANI, S., ABDESSEMED, F. and BENALI, A. (2010). A MULTI-AGENT STRATEGY FOR
A SIMPLE COOPERATIVE BEHAVIOR. International Journal of Information Acquisition,
07(04), pp.331-345.
GAO, Z. and LUO, S. (2011). Dynamic Grid Resource Reservation Mechanism Based on Resource-
Reservation Graph. Journal of Software, 22(10), pp.2497-2508.
Hiremath, M. (2008). Systems Engineering in Acquisition Strategy: Change Needed. INSIGHT,
11(5), pp.32-34.
Jogada, P. and Warad, V. (2016). Effective Car Parking Reservation System Based on Internet of
things Technologies. Bonfring International Journal of Software Engineering and Soft
Computing, 6(Special Issue), pp.140-142.
Kuklin, A., Zemskov, A. and Nikulina, N. (2011). Theoretical and methodological approaches to the
diagnosis of the region's state material reservation system status. Economy of Region, pp.277-
280.
Lin, L., Ho, Y. and Lin, W. (2015). Post-acquisition Performance: Contingency of Acquisition
Strategy. Procedia - Social and Behavioral Sciences, 207, pp.59-69.

System Specification 23
Okuyama, R. (2017). Importance of tacit knowledge in incremental innovation. Journal of Strategy
and Management, 10(1), pp.118-130.
Sabato, G. (2010). Setting Acquisition Strategy for Retail Customers. SSRN Electronic Journal.
Su, A. (2016). Information Acquisition and the Equilibrium Incentive Problem. Journal of Economics
& Management Strategy, 26(1), pp.231-256.
Viswam, S. and Karattil, S. (2013). A Novel Approach for Software Requirement
Specification. International Journal of Computer Applications, 84(17), pp.14-18.
Wang, F., Liang, J. and Qian, Y. (2013). Attribute reduction: A dimension incremental
strategy. Knowledge-Based Systems, 39, pp.95-108.
WANG, Z. and LONG, L. (2018). Design of Intelligent Reservation Parking Platform System Based
on Microcontrollers. DEStech Transactions on Engineering and Technology Research,
(ecame).
Xie, L. (2013). Design of Vehicle Reservation System in Manufacturing Engineering. Applied
Mechanics and Materials, 340, pp.292-297.