Ironwood Self Service Terminals And Intranet Functional Specification - Phase1 v1 2016-02-08

of 122
Ironwood Self Service Terminals And Intranet - Phase 1
GOLIATH
FUNCTIONAL SPECIFICATION
FEBRUARY 8, 2016

of 122
Goliath
Functional Specification – Ironwood Self Service Terminals And Intranet - Phase 1
Document Control
Project Ironwood Observation Deck Ticketing System
Sponsor Shaun Kerry
Project Manager Craig Davids
Title Functional Specification: Ironwood Self Service Terminals And Intranet – Phase 1
Document References Ironwood Ticketing System Business Case 2015-07-01 v2.0
Ironwood Ticketing System Initial Scoping Document 2015-08-31 v1.0
Ironwood Self Service Terminals And Ironwood Intranet Kick-off Meeting 2015-09-04
Ironwood Self Service Terminals And Ironwood Intranet Project Definition 2015-10-
09 v4.0
Ironwood Ticketing System User Specification Document 2015-10-18 v2.0
Ironwood Ticketing System MRI Integration Specification 2015-11-05 v1.0
Created by Brendan Butt
Creation date 12 August 2015
Document History
Version Date Amended By Summary of Changes
1 2015/02/08 Brendan Butt First version.
Distribution List
Name Position Signed Comments
Shaun Kerry Chief Technical Officer: Goliath
David Willis Compliance & Legal Manager: Goliath
Samantha Kerr IT Director: Ironwood Building
Louis Marker IT Manager: Ironwood Building
Susan Williams Operations Manager: Ironwood Building
Shaun Frost Marketing Manager: Ironwood Building
Jerome Thudder Senior Accountant: Ironwood Building
Stakeholder Approval
Name Position Signed Date
Shaun Kerry Chief Technical Officer: Goliath
David Willis Compliance & Legal Manager: Goliath
Samantha Kerr IT Director: Ironwood Building
Louis Marker IT Manager: Ironwood Building
Susan Williams Operations Manager: Ironwood Building
Shaun Frost Marketing Manager: Ironwood Building
Jerome Thudder Senior Accountant: Ironwood Building

of 122
Goliath
Contents
1 EXECUTIVE SUMMARY...........................................................................................................................10
2 BACKGROUND.......................................................................................................................................11
2.1 DOCUMENT PURPOSE ............................................................................................................................. 11
2.2 TERMS OF REFERENCE............................................................................................................................ 12
2.3 WORK METHOD FOLLOWED ...................................................................................................................... 12
2.4 BUSINESS PROBLEMS ............................................................................................................................. 13
2.5 GOALS .............................................................................................................................................. 14
2.6 OBJECTIVES ........................................................................................................................................ 14
3 SCOPE AND CONTEXT ...........................................................................................................................16
3.1 STAKEHOLDERS .................................................................................................................................... 16
3.3 SOLUTION SCOPE.................................................................................................................................. 18
3.4 EXCLUSIONS ....................................................................................................................................... 19
3.5 ASSUMPTIONS ..................................................................................................................................... 20
4 SOLUTION ARCHITECTURE OUTLINE ....................................................................................................22
4.1 INTRODUCTION .................................................................................................................................... 22
4.2 BUSINESS AREA SCOPE .......................................................................................................................... 22
4.3 HIGH LEVEL PROCESSES.......................................................................................................................... 23
4.3 SOLUTION DEFINITION ........................................................................................................................... 28
4.4 TECHNICAL ARCHITECTURE ...................................................................................................................... 29
4.5 DATA MODELS ..................................................................................................................................... 31
4.6 SOLUTION INTEGRATION PLAN .................................................................................................................. 32
5 REQUIREMENTS LISTING......................................................................................................................33
5.1 FUNCTIONAL REQUIREMENTS .................................................................................................................... 33
5.2 INFORMATIONAL REQUIREMENTS................................................................................................................ 34
5.3 NON-FUNCTIONAL REQUIREMENTS ............................................................................................................. 36
6 FUNCTIONAL REQUIREMENTS SPECIFICATION.....................................................................................37
6.1 SELECT AND RESERVE GUEST TICKET (FR1) ................................................................................................. 37
6.2 PAY FOR GUEST TICKET (FR2) ................................................................................................................. 56
6.3 MANAGE TICKET ADMINISTRATION (FR3)..................................................................................................... 69
6.4 MANAGE SYSTEM ADMINISTRATION (FR4).................................................................................................... 84

of 122
Goliath
6.5 ADMIN GUEST (FR5)............................................................................................................................. 84
6.6 MRI INTEGRATION (FR6)........................................................................................................................ 84
6.7 GACS INTEGRATION (FR7) ..................................................................................................................... 85
7 INFORMATIONAL REQUIREMENTS SPECIFICATION..............................................................................86
7.1 TICKET AVAILABILITY REPORT (IR1)........................................................................................................... 87
7.2 DAILY SALES REPORT (IR2)..................................................................................................................... 89
7.3 MONTHLY SALES REPORT (IR3) ................................................................................................................ 89
7.4 CREDIT CARD SALES REPORT (IR4) ........................................................................................................... 89
7.5 CREDIT CARD EXCEPTION REPORT (IR5) ..................................................................................................... 91
7.6 CREDIT CARD REFUNDS REPORT (IR6)........................................................................................................ 91
7.7 ADVANCED SALES MOVEMENT REPORT (IR7) ................................................................................................ 91
7.8 GUEST LANGUAGE REPORT (IR8) .............................................................................................................. 91
7.9 MRI UPLOAD AUDIT REPORT (IR9)............................................................................................................ 92
7.10 MRI RECONCILATION REPORT (IR10) ....................................................................................................... 92
7.11 SYSTEM VARIABLES AUDIT REPORT (IR11)................................................................................................. 92
8 NON-FUNCTIONAL REQUIREMENTS SPECIFICATION ............................................................................95
8.1 LEGISLATION (NFR1) ............................................................................................................................ 95
8.2 SCALABILITY (NFR2)............................................................................................................................. 95
8.3 PERFORMANCE (NFR3)........................................................................................................................... 95
8.4 AVAILABILITY (NFR4)............................................................................................................................ 95
8.5 AUDITABILITY (NFR5) ........................................................................................................................... 96
8.6 USABILITY (NFR6) ............................................................................................................................... 96
8.7 RELIABILITY (NFR7) ............................................................................................................................. 97
8.8 SECURITY (NFR8) ................................................................................................................................ 97
8.9 TECHNOLOGY (NFR9) ............................................................................................................................ 97
9 BUDGETING AND RESOURCING ............................................................................................................98
9.1 FINANCIAL COSTS AND TIME BREAKDOWN.................................................................................................... 98
9.2 OTHER RESOURCING ISSUES ...................................................................................................................100
10 SYSTEM RISKS AND CONTROL REQUIREMENTS ................................................................................101
10.1 RISK IDENITIFCATION AND PROFILE .........................................................................................................101
10.2 RISK CONTAINMENT PLAN .....................................................................................................................102
11 PRODUCT QUALITY ASSURANCE .......................................................................................................105

of 122
Goliath
12 PROJECT AND IMPLEMENTATION PLAN ............................................................................................109
APPENDIX 1 - GLOSSARY ...........................................................................................................................111
APPENDIX 2 - DATA DICTIONARY ................................................................................................................113
APPENDIX 3 - LANGUAGE TRANSLATION ......................................................................................................114
APPENDIX 4 - TICKET AVAILABILITY CALCULATION .......................................................................................116
APPENDIX 5 - TEST SCENARIOS..................................................................................................................117
APPENDIX 6 - CHANGE MANAGEMENT..........................................................................................................120
ISSUE RESOLUTION PROCESS........................................................................................................................120
SCOPE AND BUDGET CHANGE AUTHORIZER .......................................................................................................120
APPENDIX 7 - REFERENCES ........................................................................................................................121
APPENDIX 8 – ENTITY MATRIX (CRUD)........................................................................................................122

of 122
Goliath
List of Figures
Figure 1: Ironwood Ticketing System Context Diagram ................................................................................... 18
Figure 2: Goliath High Level Business Units.................................................................................................... 23
Figure 3: High Level Ticket Sales Process ...................................................................................................... 24
Figure 4: High level Payment Process............................................................................................................ 26
Figure 5: Solution Architecture..................................................................................................................... 28
Figure 6: Technical Architecture ................................................................................................................... 29
Figure 7: Entity Relationship Diagram - Ironwood Observation Deck Ticketing System ........................................ 31
Figure 8: Cancel Transaction Popup Window .................................................................................................. 38
Figure 9: Welcome screen ........................................................................................................................... 39
Figure 10: Out Of Order screen .................................................................................................................... 41
Figure 11: Status screen ............................................................................................................................. 42
Figure 12: Tickets Sold Out screen................................................................................................................ 44
Figure 13: Select Language screen ............................................................................................................... 45
Figure 14: Select Tickets screen ................................................................................................................... 47
Figure 15: Upgrade Tickets Option screen...................................................................................................... 49
Figure 16: Upgrade Tickets screen................................................................................................................ 50
Figure 17: Select Timeslot screen ................................................................................................................. 52
Figure 18: Sale Summary screen.................................................................................................................. 55
Figure 19: Insert/Remove Credit Card screen................................................................................................. 57
Figure 20: Remove Credit Card screen .......................................................................................................... 58
Figure 21: Signature Capture screen............................................................................................................. 60
Figure 22: Signature Captured screen ........................................................................................................... 61
Figure 23: Credit Card Authorization screen................................................................................................... 63
Figure 24: Print Tickets screen ..................................................................................................................... 66
Figure 25: Printed Ticket Design................................................................................................................... 67
Figure 26: Transaction Complete screen........................................................................................................ 69
Figure 27: Login screen............................................................................................................................... 70
Figure 28: Ticket Sales Search screen ........................................................................................................... 71
Figure 29: View Sale Information screen ....................................................................................................... 74
Figure 30: Payment Information Popup Window ............................................................................................. 76
Figure 31: Manage Tickets screen................................................................................................................. 81

of 122
Goliath
Figure 32: Manage Ticket Availability screen .................................................................................................. 83
Figure 33: Reports screen............................................................................................................................ 87
Figure 34: Ticket Availability Report.............................................................................................................. 88
Figure 35: Credit Card Sales Report.............................................................................................................. 90
Figure 36: System Variables Audit Report...................................................................................................... 94
Figure 37: Project Plan...............................................................................................................................109
Figure 38: Language Translation Logic Example ............................................................................................114
Figure 39: Entity Matrix (CRUD) ..................................................................................................................122

of 122
Goliath
List of Tables
Table 1: Internal Stakeholders ..................................................................................................................... 16
Table 2: External Stakeholders..................................................................................................................... 17
Table 3: Technologies / Tools Used ............................................................................................................... 30
Table 4: Project Hardware Used ................................................................................................................... 30
Table 5: Functional Requirements................................................................................................................. 34
Table 6: Informational Requirements ............................................................................................................ 35
Table 7: Non-Functional Requirements .......................................................................................................... 36
Table 8: Cancel Transaction Popup Window Details ......................................................................................... 38
Table 9: Out Of Order Email Notification........................................................................................................ 41
Table 10: Status Screen Test Details............................................................................................................. 42
Table 11: Maintenance Email Notification....................................................................................................... 43
Table 12: Upgrade Tickets Popup Window Details ........................................................................................... 50
Table 13: Timeslot Unavailable Popup Window Details..................................................................................... 53
Table 14: Unsupported Credit Card Popup Window Details ............................................................................... 59
Table 15: Unable To Read Card Popup Window Details .................................................................................... 59
Table 16: No Signature Captured Popup Window Details.................................................................................. 62
Table 17: Payment Authorization Failed Popup Window Details......................................................................... 63
Table 18: Payment Authorization Declined Popup Window Details ..................................................................... 64
Table 19: Maximum Payment Retry Attempts Exceeded Popup Window Details: Failed ........................................ 64
Table 20: Maximum Payment Retry Attempts Exceeded Popup Window Details: Declined .................................... 65
Table 21: Out Of Paper Popup Window Details................................................................................................ 68
Table 22: Manage Ticket Sales Search Criteria Details..................................................................................... 72
Table 23: Search Results Information ........................................................................................................... 73
Table 24: Search Results Popup Window Details............................................................................................. 73
Table 25: Manage Ticket Sales: Sale Information Details ................................................................................. 75
Table 26: Manage Ticket Sales: Ticket Information Details............................................................................... 75
Table 27: Manage Ticket Sales: Payment Information Details........................................................................... 76
Table 28: Cancel Sale Popup Window Details ................................................................................................. 77
Table 29: Sale Refund Reason Popup Window ................................................................................................ 78
Table 30: Confirm Sale Refund Popup Window Details..................................................................................... 79
Table 31: Sale Refunded Popup Window Details ............................................................................................. 79

of 122
Goliath
Table 32: Sale Not Refunded Popup Window Details........................................................................................ 79
Table 33: Ticket Availability Report Details .................................................................................................... 87
Table 34: Ticket Availability Report Filter Criteria............................................................................................ 88
Table 35: Daily Sales Report Details ............................................................................................................. 89
Table 36: Monthly Sales Report Details ......................................................................................................... 89
Table 37: Credit Card Sales Report Details..................................................................................................... 89
Table 38: Credit Card Sales Report Filter Criteria............................................................................................ 90
Table 39: Credit Card Exception Report Details .............................................................................................. 91
Table 40: Credit Card Refunds Report Details................................................................................................. 91
Table 41: Advanced Sales Movement Report Details ....................................................................................... 91
Table 42: Guest Language Report Details ...................................................................................................... 92
Table 43: MRI Upload Audit Report Details..................................................................................................... 92
Table 44: MRI Reconciliation Report Details ................................................................................................... 92
Table 45: System Variables Audit Report Details ............................................................................................ 92
Table 46: System Variables Audit Report Filter Criteria.................................................................................... 93
Table 47: Project Costs Summary................................................................................................................. 98
Table 48: Development & Implementation Costs ............................................................................................ 99
Table 49: Hardware Costs...........................................................................................................................100
Table 50: Project Risks...............................................................................................................................101
Table 51: Risk Containment Plan .................................................................................................................104
Table 52: List of Definitions ........................................................................................................................112
Table 53: Data Dictionary...........................................................................................................................113
Table 54: Language Translation Example......................................................................................................115
Table 55: Testing Scenarios ........................................................................................................................119

of 122
Goliath
1 EXECUTIVE SUMMARY
The iconic Ironwood Building in New York City has suffered from maladministration and miss-
management in the recent past. As one of Goliath’s opportunistic investment strategies they acquired
the building in 2010 and are in the process of redeveloping, refurbishing and revitalizing it.
One of the key initiatives identified in the redevelopment of the building is the reopening of its
observation deck, the Ironwood Observation Deck project. The drivers and goals identified for this
project are aligned with, and support Goliath’s core business drivers. The Ironwood Observation Deck
project is broken up into three main sections: Building renovations, marketing drive and technological
ticketing system to support the attraction. The focus of this particular document is the ticketing system.
From the business case document which was produced, the decision was made to develop the ticketing
system in-house. Since then further analysis has been completed and the requirements have been
unpacked. During this process it was found that the initial estimation of the work required to complete
the project were too low. The decision was therefore made by the executive committee to split the
ticketing system into two phases:
1. Self Service Terminals And Intranet
2. Public Facing Website
Phase 1 of the ticketing system project has been detailed in this document, included with the updated
project estimates, costs and timeline. As it stands, 350 hours have been logged against this project.
This equates to $28,000. Based on the updated estimates and costs, this project is expected to
consume a further $280,892 over a period of three months. Based on the updated project timeline, the
expected go-Live date for phase 1 of the project is the 1st
of July, 2016.
Once phase 1 of the project has been deployed to the Live environment and the system has been in use
for 12 months. The executive committee will evaluate the progress of the project by measuring the
actuals verse the figures initially defined within the project objectives. If the executive committee is
satisfied with the progress, they will give the go ahead to proceed with phase 2 of the project, the
public facing website.

of 122
Goliath
2 BACKGROUND
Goliath is one of the leading owners, developers, operators and fund managers of first-class real estate
worldwide. Up until now their focus has been on real estate, from project development to the leasing
and management of properties.
One of their most successful acquisition and development projects has been the Ironwood Building in
New York City in 2010. This iconic building was built in the 1929 where it remained the tallest building
in the world until the Empire State Building was completed in 1931. The Ironwood Building is an
American household name and is visited by guests from all over the world.
Before Goliath acquired the building in 2010 it was suffering from ineffective management and
deteriorating property markets. Tenant occupancy was at an all-time low and the building was
approaching bankruptcy. Since Goliath acquired the building they have undertaken a massive
redevelopment program to refurbish and revitalize the building.
Based on the massive success the Empire State Building and One World Trade Center observation decks
have seen, one of the key initiatives has been to reopen the Ironwood Observation Deck which was
closed down in 1989 to make way for commercial tenants. It is envisioned that the success of the
Ironwood Building Ironwood Observation Deck will not only significantly increase the buildings
profitability, but also the reputation and credibility of Goliath.
The Ironwood Observation Deck project has been broken up into three main parts: The building
renovations, marketing drive and technological ticketing system to support the attraction. This
document focuses on the development and implementation of the ticketing system, the Ironwood
Observation Deck Ticketing System.
The Ironwood Observation Deck Ticketing System project received traction during the first quarter of
2015 when Shaun Kerry, the Chief Technical Officer of Goliath, gave his approval to proceed with a
business case. A business case was subsequently completed which was reviewed and approved by the
executive committee on the 1st
of August, 2015.
Since the business case was approved, the decision was made by the executive committee to split the
project into two phases due to an underestimation of the effort required to complete it.
2.1 DOCUMENT PURPOSE
This document details the functionality of the proposed application. In doing so, this document
translates the User Requirements Specification into a detailed design for the application. This document
will act as a blueprint for the development team from which they will build the solution, while at the
same time articulating the business needs in way which is recognized and understood by all
stakeholders.
For more information on the acronyms or industry/company specific jargon mentioned in this document
please refer to the glossary under Appendix 1. Where an item in the glossary is mentioned for the first
time in this document it has been hyperlinked for ease of readability.

of 122
Goliath
2.2 TERMS OF REFERENCE
There are a number of additional key constraints which will need to be considered for this project to be
classified as successful. These constraints were raised by the executive committee during the first
project initiation meeting, and are as follows:
 The system (phase 1) is ready for implementation before the renovations to the Ironwood
Building are complete, which is currently scheduled to be the last quarter of 2016.
 The structural changes required to MRI for it to integrate with the new Ironwood Ticketing
System are complete before the first ticket to the Ironwood Observation Deck is ready to be
sold.
 The existing Ironwood information technology systems must function as per normal while the
new system is being developed and implemented.
 The existing Goliath employees’ business timetables and deliverables must not be disrupted
during the course of the project.
 All Ironwood functions outside the scope of this project must be able to continue functioning, as
before, once the new system is implemented.
 The total cost of developing and implementing phase 1 of the project must not exceed
$400,000.
 The solution must satisfy all business requirements in order to provide guests will a complete
experience.
2.3 WORK METHOD FOLLOWED
The following information gathering techniques were used to elicit the functional, informational and
non-functional requirements specified within this document:
 Initial workshops with key stakeholders to help delineate their envisioned solution and elicit the
business requirements. The main business requirements were discussed at length to ensure
that the business analyst has a deep and complete understanding of what is expected. The
outcomes of the workshops were documented and distributed to all the attendees for them to
review. One last final workshop was held with them to go through the document. Once
consensus was reached and all stakeholders were satisfied, the User Specification Document
(URS) was compiled based on the discussions and outcomes.
 The URS was distributed to all stakeholders for them to review the business requirements one
last time, allowing them to make comments, raise concerns or request clarity on any point.
Once they were satisfied with the document they provided their official approval by signing-off
on it.
o Artifact outcome: Ironwood Ticketing System User Specification Document 2015-10-18
v2.0.
 Regular meetings with the project manager and key stakeholders to review the scope and
budget of the project. From these meetings it was agreed to separate the project into two

of 122
Goliath
separate phases. Phase 1 is detailed in this document and includes the Self Service terminals
and Ironwood Intranet. Phase 2 will include the public-facing ticket sales website.
o Artifact outcome: Ironwood Ticketing System Initial Scoping Document 2015-08-31
v1.0.
 Once the URS was signed-off, Joint Application Definition workshops were held with the
marketing and operations stakeholders and the development team to determine the functional,
non-functional and informational requirements.
 Due to the public facing component of the Self Service application and its importance, a front-
end to backend approach was adopted. Workshops were held with the business analyst,
marketing team and operations team to create screen mockups for all the Self Service screens;
these will be used to drive the development. The business analyst ensured that the screen
designed satisfied both the business and functional requirements. The final versions of the
screen designs are included in this document, and the PSD (Photoshop file extension type) files
are available for the development team here.
 Review sessions with the development team to ensure all members have a clear and shared
understanding of the requirements and what is expected.
 Meetings with the existing Ironwood IT staff to discuss and detail the integration of the
proposed ticketing system with MRI.
o Artifact outcome: Ironwood Ticketing System MRI Integration Specification 2015-11-05
v1.0.
 Meetings with the technical architect and development team to discuss the data entity
relationship design and other data and reporting requirements. The outcomes of these meetings
are detailed in this document.
 For a list of the names and representatives of the stakeholders listed in this project please refer
to the 3.2.1 Internal Stakeholders section.
2.4 BUSINESS PROBLEMS
The following business problems were identified through interviews, market research and the review of
the Ironwood Building's financial statements. For a list of the references used to complete this section
please refer to Appendix 7.
2.2.1 GLOBAL RECESSION
The gross domestic product (GDP) of the global economy continues to slowly decrease. Over the
last 5 years it has fallen from 4.5% in 2010 to 2.5% in 2015 (World Bank 2015). There are many
reasons for this global recession, such as the gradual slowdown of China’s economy as demand for
their exports continues to decrease. Even the world’s strongest economy, the United States, is
predicted to struggle to grow above 2% next year (Rapoza 2015).
These trends are having a negative effect on the commercial property industry as companies look
for ways to cut costs. As companies downsize their workforce and look for cheaper spaces to
operate in, investing in commercial property becomes more risky as tenant vacancy increases.

of 122
Goliath
According to the New York Times (Susman 2013) the tenant occupancy rate in New York is the
lowest it has been in over two decades. In this time of economic deterioration and uncertainty,
renting out property to businesses is a risky choice.
2.2.2 INCREASED COMPETITION IN COMMERCIAL PROPERTY LEASING
New York City continues to be one of the global hubs for business. In 2013 it had a total of
429,830,253 square feet of rentable office space (Susman 2013). This has led to fierce competition
between commercial property holding companies in a race to sign tenants. This increased
competition has driven down the average rent price by 8.9% over the last 5 years (Alvarez 2013).
The Ironwood Building has not been able to avoid this downward trend as they have only been able
to increase their rent by 1% for last 3 years, compared to the usual 5% increase.
2.2.3 DECREASED DEMAND FOR HIGH QUALITY RENTABLE OFFICE SPACE
Over the past decade New York has seen a slow but steady decrease in the demand for high quality
rentable office space (Alvarez 2013). There are a number of factors which have contributed towards
this downward trend, including economic uncertainty and advances in technology.
The advancement in technology has reduced tenants need for on-site storage and server rooms,
and has increased the opportunity for employees to work remotely. Furthermore, there has been a
growing practice of office hoteling where employees use workspaces on an as-needed basis (Alvarez
2013).
The Ironwood Building has experienced this decrease in demand first hand, with the overall tenant
occupancy rate of the building remaining below 70%; another good reason for Goliath to use the
space for an observation deck over rentable office space.
2.5 GOALS
The following goals have been identified for this project:
 To generate an increased and consistent revenue stream by reopening the Ironwood Building
observation deck.
 Implement a system with the ability to sell, manage and admit tickets for an observation deck.
 Become one of the most visited and highly rated tourist attractions in New York.
The goals of this project are consistent with, and support, Goliath’s business drivers and strategic drive.
2.6 OBJECTIVES
In order to achieve the goals of this project and to provide a way to measures its success, the following
objectives have been identified:
 Increase the amount of funds invested in the Ironwood Property Investment Portfolio, once the
system is deployed to the production environment:
o 5% by the end of 2017

of 122
Goliath
 Increase the profitability of the Ironwood Building, once the system is deployed to the
production environment:
 Provide a return on investment of 20% to all investors who are responsible for funding the
project over a five year period, starting from when the system is deployed to the production
environment.
 Increase the amount of guests who visit the Ironwood Building, once the system is deployed to
the production environment:
 Provide a high quality experience to guests who visit the Ironwood’s observation deck, once the
system is deployed to the production environment:
o Less than 0.1% of guests complain about their experience while at the Ironwood
observation deck.
o The averaging waiting time for a guest to purchase tickets onsite is less than five
minutes.
 The ticketing system is never down for more than six hours during the standard operating time,
per a year, once the system is deployed to the production environment.
The aforementioned objectives are aligned with the business drivers and provide a transparent way to
measure the outcome of the project.

of 122
Goliath
3 SCOPE AND CONTEXT
The section below outlines the project in terms of the stakeholders involved, the business areas under
consideration, and the scope of the solution.
3.1 STAKEHOLDERS
The internal stakeholders of the project and their interests in it are summarized in Table 1 below:
3.2.1 INTERNAL STAKEHOLDERS
Name Position Interests/Needs Metrics
Shaun Kerry Chief Technical Officer:
Goliath
The technologies and processes used in
the implementation of the project. Best
practices and standards adopted.
Solution Definition
Technical Architecture
David Willis Compliance & Legal
Manager: Goliath
Ensure ticket sales and payments are
compliant with legislation. NFR1, NFR5, NFR6
Samantha Kerr IT Director: Ironwood
Building
Oversees all ICT infrastructures within
the Ironwood Building.
NFR1, NFR3, NFR9,
IR9, IR10
Louise Marker IT Manager: Ironwood
Building
Day to day functioning of IT within the
Ironwood Building.
NFR1, NFR3, NFR9,
IR9, IR10
Susan Williams Operations Manager:
Ironwood Building
Day to day functioning of all operations
within the Ironwood Building.
NFR1, NFR3, NFR9,
IR9, IR10
Shaun Frost Marketing Manager:
Ironwood Building
The look and feel of the Self Service
application and any language
translation required.
FR1, IR8
Appendix 3
Jerome Thudder Senior Accountant:
Ironwood Building
The accounting of ticket sales from the
observation deck and corporate
governance.
FR6, IR4, IR5, IR6,
IR9, IR10
Brendan Butt Business Analyst Ensure the solution meets the relevant
business requirements.
Solution meets the
relevant business
requirements
Craig Davids Project Manager The successful implementation of the
project in terms of time and budget.
Implementation Plan
Appendix 6
Mark Berndt Technical Architect The technical architecture and
technologies used to implement the
solution. Industry standards adopted.
Solution Definition
Technical Architecture
Data Models
Table 1: Internal Stakeholders

of 122
Goliath
3.2.2 EXTERNAL STAKEHOLDERS
The external stakeholders and their interests are summarized in Table 2 below:
Name Interests Metrics
Provisio Software
Engineering (vendor)
SiteKiosk used on the Self Service terminals. Licensing
and implementation.
Service Level Agreements
NFR8
Guest
Able to gain access to Ironwood Observation Deck by
purchasing a ticket for admission. Amazing views of New
York City.
FR1
FR2
Deloitte (Auditors) Traceable audit trail from request through to payment
IR11
NFR1
Table 2: External Stakeholders

of 122
Goliath
3.3 SOLUTION SCOPE
The context diagram below depicts the key interfaces with other systems and application users. The full
scope of the solution is unpacked in detail under the requirements specification sections.
Figure 1: Ironwood Ticketing System Context Diagram
Please note that there have been a few changes to the solution scope since the Business Case
document was produced. The requirements which have been removed from the scope are not depicted
above; however, items which fall under phase 2 of the project have been included. The phase 2 items
can be identified by the red outlining.
As depicted above, the application will interface with the following systems and users:
Guest – An individual guest makes an enquiry about ticket prices and availability, in one of the four
language options available. The system returns a list of available ticket types with their prices; the
ticket availability is displayed in quantity per a timeslot. A guest may reserve tickets by selecting the
type, quantity and timeslot they wish to visit the Ironwood Observation Deck. In order to permanently
reserve tickets a successful payment is required by the guest. On the day of the guest’s visit they will
Guest
Ironwood Ticketing
System
Ticket Prices Request
Proposed
Solution
KEY
System that
integrates with
the solution
Website
Self Service
Terminals
Ironwood Intranet
Admissions Site
Ticket Prices Result
Ticket Availability Request
Ticket Availability Result
Tickets Request
Tickets Reserved
Ticket Payment
Confirmation Email
Ticket Admission
Post Visit Survey
Accounting
Manager
MarketingTicket Sales Report
PayPal Credit Card Status
Credit Card Details
Financial Reports
Ticket Forecast Reports
Ticket Availability
Updated System Variables
Post Visit Survey Answers
Post Visit Survey
Ticket Information
MRI
Ticket Sales Information
System
Interaction
GACS
Internal
AuditorSystem Information
System Information Request
User Rights
Access Control
Sale Summary
Printed Tickets
Post Visit Survey Answers
Language Selection
Language Translations
Ticket Prices
Sale Information
Self Service Terminal Restart
Request
Phase 2
Sale Refund Requested
Sale Cancellation Requested
Sale Cancellation Request
Sale Refund Request
Self Service Email Notification

of 122
Goliath
be granted access to the Ironwood Observation Deck by having their tickets scanned through the
admissions site. The guest will also have the ability to cancel their ticket and request a refund.
MRI – Management Reports International is an existing accounting system used by Goliath to manage
and process all their financial accounting. The relevant information from all ticket sales which are
complete (payment is successful) will be uploaded into MRI through a nightly job. The Ironwood
Ticketing System will therefore integrate with MRI.
PayPal – A third party credit card payment processor used to facilitate credit card transaction
processing within the Ironwood Ticketing System. The system will act as a payment gateway which will
be responsible for handling communication between the system and banks.
GACS – Global Access Control System, an existing application that is used by Goliath to administer
access and user rights across a number of applications. The Ironwood Ticketing applications will rely on
integrating with GACS to manage security; the system will fetch security information from GACS
through a nightly job. GACS integrates directly with Microsoft Active Directory which is used by Goliath
to manage user accounts.
Manager – This user will oversee the day-to-day operations of the Ironwood Observation Deck through
the use of system reports. Their responsibilities include, but are not limited to, the configuration of
ticket types, ticket prices, ticket availability, system variables, cancelling tickets, refunding tickets and
the general overseeing of the Iron Observation Deck.
Marketing – This user will reply on the information available to them through the Ironwood Intranet
reports. They will use this information to help them create marketing campaigns and improve the
experience of future guests.
Accounting – This user will have the ability to run reports which relate to ticket sales and any other
pertinent financial information. They will use these reports in conjunction with the reports in MRI to
perform their accounting responsibilities and duties, such as account reconciliation.
Internal Auditor – On request, internal auditors will be able to access system information in order to
ensure processes and protocols are being adhered to and that there is control of the financial
information. They will work with external auditors who will perform yearly full system audits.
3.4 EXCLUSIONS
The following exclusions have been made for this project:
 Any changes to the translatable text used throughout the system will be performed by Goliath
through a direct update to the database. It will not be possible to rename any of the text
displayed on the application through the front-end.
 Vouchers (qualify for tickets) are excluded from this project and will be implemented as part of
a future enhancement to the system.
 The system will not have the ability to reissue tickets to another timeslot. This will be
implemented as part of a future enhancement to the system.
 Travel agent website: the ability for travel agents to purchase tickets on credit and receive a
discount on tickets. This will be implemented as part of a future enhancement to the system.

of 122
Goliath
 Ticketing website: the ability for guests to purchase tickets through a website. This will be
implemented during phase 2 of the project.
 Managing the physical flow of guests to and from the Ironwood Observation Deck will be the
responsibility of the operational team and falls outside the scope of the system. The system has
no impact on the duration for which guests decide to remain on the Observation Deck and
therefore cannot make an impact if the Deck is overcrowded.
 There will be no counting or interaction with any systems that count people accessing or leaving
the observation deck.
 The Ironwood Ticketing System will not involve any merchandising systems or software to sell
and distribute merchandise or services other than tickets in anyway. This will be handled in a
separate project.
 Admission control exceptions will be handled manually (for example, where someone has been
admitted and is required to leave the facility and then return).
 The system will not cater for nor handle personal check processing in anyway. Should this be
required, it will be handled outside of the system.
 The Ironwood Ticketing System will not take into account transaction charges levied by
merchant banks, processors and payment gateways.
 No recording of names, photographing of visitors or checking of personal identification will be
facilitated by the Ironwood Ticketing System.
 There are no data migration requirements from any existing systems other than already
identified.
 All legal and tax implications will be handled outside of this project by Goliath’s lawyers and tax
department.
 The Self Service application will not accept cash payments, only credit card payments.
 It will not be possible to purchase tickets for a future date; this will be implemented during
phase 2 of the project.
 The content of the Service Level Agreements (SLA) being drawn up for this project will not be
detailed in this document. The first versions of the SLAs are currently being drafted; Samantha
Kerr (Ironwood IT Director) is responsible for the overseeing of them.
3.5 ASSUMPTIONS
The following exclusions have been made for this project:
 MRI can be used as an accounting database for the ticketing system.
 GACS can be used as the user access control system.
 The changes required to MRI to integrate to with the new ticketing system will be done in a
timely manner. Slow turn-around times on required MRI changes could negatively impact
project timelines.

of 122
Goliath
 Goliath will provide the necessary resources for the project, where required.
 Stakeholders will review deliverables in the agreed upon time; late sign-off on deliverables
could negatively impact project timelines.
 The system will be able to leverage Goliath’s existing email service to send emails.
 There is buy-in from the existing Goliath employees who will be affected or involved in this
project.
 Any changes to the requirements that will affect the scope will be dealt with through a change
request process.
 The Ironwood Ticket system will have its own environment, consisting of webservers and
databases in order to meet the requirements of PCI Compliance.
 There is sufficient capacity available on existing application and database hosting platforms.
 The system is not required to limit credit card transactions in any way. This is with reference to
international and local cards.
 SLAs will be drawn up and subsequently signed and enforced on any vendors involved.
 The distribution and stock levels of the gift souvenir and photo which the guest is entitled to
when they purchase an Iron Class Pass package will be a manual process, and will be the
responsibility of the Goliath employees.
 While peripheral input devices such as a mouse and keyboard may be connected to the Kiosk,
the application is designed to function without these and assumes that any such devices will not
be accessible to a guest.
 The SiteKiosk application, to assist in the management and locking down of the Self Service
terminals, will be implemented and managed by the existing Ironwood infrastructure team.
 It is assumed that the hardware devices detailed in this document provide for the functionality
required of them, including self-tests.
 All users which have access to the reports section on the Ironwood Intranet have Microsoft
Excel installed on their machines.
 There will be no need for the Ironwood ticketing solution to be compliant with the Generally
Accepted Accounting Principles (GAAP), as MRI will be responsible for the accounting aspect of
the system.
 The training required to upskill the staff who will be using the system falls within the scope of
this project.

of 122
Goliath
4 SOLUTION ARCHITECTURE OUTLINE
This section offers a high level overview of the organizational structure, proposed technology, data
models and solution integration plan of the system.
4.1 INTRODUCTION
An internal project team has been assembled from within Goliath to design, build, test and implement
the system. If further available resources are required, Goliath will look outward to bring in the required
resources. Priority will be given to Goliath employees from other sectors over new hires.
Office space has been made available to the development team within the Ironwood Building. The
development team will work closely with the business analyst, project manager and existing Ironwood
Building IT staff.
The project will follow Goliath’s standard waterfall project delivery methodology.
4.2 BUSINESS AREA SCOPE
As stated in the Business Case document, there is no current business unit to handle the introduction of
a guest entertainment observation deck. As depicted in the diagram below (Figure 2), a new
entertainment business unit will therefore be added to the property management function within
Goliath’s organization structure. The core functions of the Ironwood Observation Deck will operate in
this new space.

of 122
Goliath
Figure 2: Goliath High Level Business Units
As the diagram legend indicates, certain business units will be affected by the implementation of this
project while some will have no change.
4.3 HIGH LEVEL PROCESSES
The purpose of this section is to provide a high level overview of the key processes involved in the
guest ticket sales process.
Open Box
Goliath
Organization
Structure
Fund
Management
Raise Capital
Investment
Internal Audit
Maintenance
Legal
Tenant
Acquisition
Market
Anaylsis
Analyse
Operational
Cost
Investment
Strategy
Tenant
Management
Environmental
Consultancy
Legal Counsel
Sustainability
Entertainment
Leasing
Property
Management
Investment
Management
Acquisitions &
Development
Affected
Business
Unit
KEY
No Change
New
Business
Unit

of 122
Goliath
4.3.1 TICKET SALES PROCESS
The diagram below outlines the high level flow of the main processes involved for a guest purchasing
tickets through a Self Service terminal.
Figure 3: High Level Ticket Sales Process
Ticket Sales Process
Guest PayPalSelf Service Application
Start
Upgrade Ticket
to Package?
Perform Pre-
Sale Functions
End
Select Guest
Language
Select Ticket
Type and
Quantity
Select Ticket
Timeslot
Select Package
Quantity
Yes
Confirm Ticket
Sale
Pay For Guest
Ticket
No
Credit Card
Payment
Successful?
Yes
No
FR1.1
FR1.2
FR1.3
FR1.4
FR1.6
FR1.4
FR2
FR1.5
Process
KEY
X.X Section Reference

of 122
Goliath
As shown in Figure 3 above, the process is broken down into the following steps:
1. The guest will start the process by touching the self-service terminal screen.
2. FR1.1: The application will perform a number of pre-sale functions in order to ensure that the
guest will be able to complete a sale.
3. FR1.2: The application will display a list of languages to the guest from which they will select
one to complete the ticket sales process in.
4. FR1.3: The application will display the ticket types and prices available for purchase. The
guest will select the ticket type and quantity they would like to include in the sale.
5. FR1.4: The application will present the guest with the option to upgrade any of their tickets to
a package.
6. FR1.4: If the guest obliges, they will select the quantity of tickets they wish to upgrade. If
they do not decide to upgrade they will proceed to the timeslot selection process.
7. FR1.5: The application will display the available timeslots and their ticket capacity. The guest
will select the timeslot they would like to visit the Ironwood Observation Deck.
8. FR1.6: The application will allow the guest to review the decisions, made during the ticket
sales process, by displaying a summary of the sale.
9. FR2: The guest will pay for their tickets using a credit card. This requirement is detailed at a
high level in the High level Payment Process.
10. If the credit card payment process is successful, or unsuccessful, the process will end.

of 122
Goliath
4.3.2 PAYMENT PROCESS
The diagram below outlines the high level flow of the main processes involved for a guest paying for
tickets using a credit card.
Figure 4: High level Payment Process
Payment Process
Guest PayPalSelf Service Application
Start
End
Insert / Remove
Credit Card
Capture Guest
Signature
FR2.1
Add Details to
Gateway
Processor
Queue
FR2.2
Transmit
Details to
PayPal
Authorization
Payment
Authorized?
Retry Limit
Reached?
Yes
Print Sale
Tickets
No No
FR2.3 FR2.3
FR2.4
FR2.3
Process
KEY
X.X Section Reference
Yes

of 122
Goliath
As shown in Figure 4 above, the process is broken down into the following steps:
1. FR2.1: The guest will insert and remove their credit card into the card reader device to start
the process. At this point the application will read the credit card information.
2. FR2.2: The guest will capture their signature digitally on the screen.
3. FR2.3: The credit card details will be added to the payment gateway processer queue in
encrypted format.
4. FR2.3: The application will transmit the details to PayPal for authorization.
5. FR2.3: PayPal will perform authorization on the process:
a. If authorization fails or is declined, the application will confirm whether the retry limit
has been reached.
i. If the retry limit has not been reached, the process will restart at step 1.
ii. If the retry limit has been reached, the process will end.
6. If authorization is successful, the application will print the tickets.
7. FR2.4: Once the tickets have finished the process will end.

of 122
Goliath
4.3 SOLUTION DEFINITION
The outline of the proposed solution is depicted below (Figure 5):
Figure 5: Solution Architecture
The solution architecture will be designed using the ASP.NET MVC application framework. This
architecture will consist of the following three layers:
 Presentation Layer: The guests and Ironwood staff will interact with the layer which will consist
of the front-end design and controls.
 Business Layer: This layer will house the business rules and any shared logic between the
applications. This layer will be responsible for fetching data and displaying it on the presentation
layer. It will also be responsible for communicating with PayPal where credit card transactions
are involved. The data exchanged with PayPal will pass through Goliath’s firewall.
 Data Access Layer: This layer will be responsible for abstracting the implications of accessing
the data from the GACS and primary database. This layer will be responsible for interacting and
calling all the stored procedures which will be stored in the database.
The MVC architecture will allow the website (phase 2) to easily be added, as once its own presentation
layer is built it will be able to leverage the existing business and data access layers. Please note that
phase 2 is not included as part of the deliverables for phase 1. The purpose of including phase 2 in the
diagram above (Figure 5) is to paint the complete picture for the development team. This deeper
understanding will aid them with their development over phase 1 and 2 of the project. All elements
within the red oval are part of phase 2.
Internet
Presentation Layer
Business Layer
Data Access layer
PayPal
Bank
Primary
Database
Backup
Database
Replication
Self Service
Kiosks
Guest
Manager Marketing Accounting AdministratorAdmissions
Clerk
GACS
Browser Browser Browser Browser
Mobile
PDA
Browser
Booking
Agent
Booking
Agent
laptop
Desktop
Booking
Agent
Booking
Agent Tablet
Google
Analytics
Mobile
Phone
Browser
PHASE 2
Firewall

of 122
Goliath
4.4 TECHNICAL ARCHITECTURE
The Ironwood Ticketing System will consist of a number of applications, a web cluster, two web servers
and two databases. Applications will be accessed by users using a combination of internet browsers,
Self Service application and portable wireless devices. The solution will require its own independent
network environment in order to meet the standards of PCI Compliance (NFR8.1). It will also integrate
with a number of existing applications and databases to provide the complete solution.
Please note that the website element of the project is part of phase 2. All references to the website are
marked as red, or have a red block around them. The purpose of the including the website is to paint
the complete picture, and ensure the system and environment are scalable. The proposed technical
architecture is depicted below (Figure 6):
Figure 6: Technical Architecture
Goliath Co-location
World Wide Web - Browser
Ironwood Building
MS .NET 4.5 Framework
Website/Intranet/Admissions
IIS
Web/ApplicationServer1
Platform
MS Windows Server 2012 R2
PayPal Payflow Pro
Self Service
Dual Xeon CPU 4 gig RAM, 500 Gig
HDD
Microsoft Network Load Balancing
(Website, Self Service & Intranet)
SQL Server 2012 (SP2)
Windows 7
MS SQL Server Primary
Database
Dual Xeon CPU 16 gig RAM, 2
TB SSD HDD RAID6
SQL Server 2012 (SP2)
Windows 7
SQL Backup/Reporting Server
Dual Xeon CPU 16 gig RAM, 2
TB SSD HDD RAID6
Transactional
Replication
Shared Logic Layer
IIS
Platform
PayPal Payflow Pro
Self Service
HDD
Shared Logic Layer
Ironwood Building - Browser
Marketing Accounting Manager Self-ServiceGuest Travel Agent
SSLSSL
IIS
Platform
PayPal Payflow Pro
Self Service
HDD
Microsoft Network Load Balancing
(Website, Self Service & Intranet)
Shared Logic Layer
IIS
Platform
PayPal Payflow Pro
Self Service
HDD
Shared Logic Layer
MRI Server
Download
Upload
PayPal
Payflow Pro
Gateway
Firewall
SSL
Mobile PDA

of 122
Goliath
Technologies / Tools Used
Database Microsoft SQL Server 2012
Source Control Microsoft Team Foundation Server
Microsoft Visual Studio 2015 (Enterprise Edition)
Languages C#, JavaScript, HTML5, CCS3, TypeScript, JQuery, Razor
Framework Microsoft.NET 4.6, Bootstrap, ASP.NET MVC, Web API
Table 3: Technologies / Tools Used
Hardware
Workstations The Standard Goliath machine (Dell Otiplex 790)
Self Service
KR403 kiosk printer, ELO toucher E700813 1515L 15-inch IntelliTouch surface wave POS touch
screen monitor, credit card reader UX300,
Admissions EKEMP touch screen portable data collector/android PDA with barcode scanner
Table 4: Project Hardware Used

of 122
4.5 DATA MODELS
The diagram below (Figure 7) is the high level Entity Relationship Diagram that has been developed to support the Ironwood Observation
Deck Ticketing System. This diagram helps identify the relationships between the different entities and some of the data which they will
store. For a more detailed view of the data that the system will store and how they will interact, please refer to the Data Dictionary and
Entity Matrix (CRUD) respectively. Please note that for the purpose of this assignment, the ERD below only contains a subset of the entities
required for this system.
Figure 7: Entity Relationship Diagram - Ironwood Observation Deck Ticketing System
Guest
SaleLineItems
PK SaleLineItemID
SaleID (FK)
TicketID (FK)
Date
Sale
PK SaleID
PaymentID (FK)
ChannelID (FK)
SelfServiceTerminalID (FK)
SaleDate
Total
IsComplete
TicketType
PK TicketTypeID
TicketName
TicketDescription
Date
Makes
Belongs
to
Contains
Ticket
PK TicketID
TicketTypeID (FK)
TicketPriceAllocationID(FK)
TicketTimeslotAvailabilityID (FK)
TicketStatusAllocationID (FK)
PackageTypeID
TicketDate
Defines
Is Described by
Is associated
to
Payment
PK PaymentID
SaleID (FK)
Sub Total
Sales Tax
Total
CreditCardType
CardHolderName
CardPrefix
ExpiyDate
PaymentDate
Timeslot
PK TimeslotID
Timeslot
TimeslotAvailability
Completes
Requires
Equates to
Is linked to
Consumes
Applies
to
TicketTimeslotAvailability
PK TicketTimeslotAvailabilityID
TimeslotID (FK)
TicketID (FK)
TicketAvailablility
Date
Is linked to
Is associated
to
TicketStatusAllocation
PK TicketStatusAllocationID
TicketStatusID (FK)
TicketID (FK)
Date
TicketStatus
PK TicketStatusID
TicketStatus
TicketStatusName
TicketStatusDescription
Date
Receives
Categorizes
Is associated to
Refers to
PackageType
PK PackageTypeID
PackageName
PackageDescription
TicketID
Date
Defines
Is Described by
TimeslotAdjustment
PK TimeslotAdjustmentID
AdjustmentAmount
AdjustmentDate
TimeslotAdjustmentAllocation
PK TimeslotAdjustmentAllocation
TimeslotAdjustmentID (FK)
TimeslotID (FK)
Date
Applies to
Adjusts
Is affected by
Is associated
to
TicketPriceAllocation
PK TicketPriceAllocationID
TicketPriceID (FK)
Date
TicketPrice
PK TicketPriceID
TicketPrice
TicketPriceDate
UserID
Date
TicketTypeID
Is priced by
Prices
Defines
Is linked to
SelfServiceTerminal
PK SelfServiceTerminalID
ChannelID
TerminalHostName
TerminalLocation
TerminalIP
Completed
through
Is linked to
AlertAllocation
PK AlertAllocationID
AlertID (FK)
SelfServiceTerminalID (FK)
Date
Alert
PK AlertID
AlertName
AlertHeading
AlertDescription
Sent to
Receives
Describes
Is linked to
Channel
PK ChannelID
ChannelName
ChannelDescription
Is linked to
Describes
PackagePrice
PK PackagePriceID
PackagePrice
PackagePriceDate
UserID
Date
PackageTypeID
Defines
Is linked to

of 122
4.6 SOLUTION INTEGRATION PLAN
All the different requirements, interfaces and technological elements will be integrated with one another
as part of the implementation plan. The integration strategy which has been adopted for the project is
to ensure all functionality developed is integrated into the main solution as soon as it is built. This
approach will prevent the situation where the solution consists of many separate and disjointed parts
which require one massive integration exercise towards the end of the project.
Solution integration will be the responsibility of the entire development team, and for each section of
the system developed a separate task for it will be created and assigned to the section. For more detail
on the solution integration plan please refer to the Solution Integration Plan document which was
compiled by the development team.

of 122
Goliath
5 REQUIREMENTS LISTING
The main requirements and sub requirements are listed in this section. This section helps provide a
quick overview of the requirements and scope of the project.
5.1 FUNCTIONAL REQUIREMENTS
The table below (Table 5) contains a list of all the requirements which have been identified for this
project. These requirements are specified in more detail under section 6.
Req ID Functional Requirement
FR1 Select And Reserve Guest Ticket
FR1.1 Perform Pre-ticket Sale Function
FR1.2 Select Guest Language
FR1.3 Select Ticket Type and Quantity
FR1.4 Upgrade Ticket to Package
FR1.5 Select Ticket Timeslot
FR1.6 Update Available Tickets and Timeslot
FR1.7 Confirm Ticket Sale
FR2 Pay For Guest Ticket
FR2.1 Insert/Remove Credit Card
FR2.2 Capture Guest Signature
FR2.3 Process Credit Card Payment
FR2.4 Print Sale Ticket
FR3 Manage Ticket Administration
FR3.1 Login To Ironwood Intranet
FR3.2 Search For Ticket Sale
FR3.3 View Ticket Sale
FR3.4 Cancel Ticket
FR3.5 Reprint Ticket Sale
FR3.6 Refund Ticket Sale
FR3.7 Manage Guest Ticket
FR3.8 Manage Guest Package
FR3.9 Manage Ticket Availability
FR4 Manage System Administration

of 122
Goliath
FR4.1 Manage System Variable
FR4.2 Kick-off Manual Process
FR4.3 Restart Self Service Application
FR4.4 Take Self Service Terminal Offline
FR5 Admit Guest
FR5.1 Scan Ticket
FR5.2 Validate Ticket
FR5.3 Update Ticket Status
F6 MRI Integration
FR6.1 Automatic MRI Upload
FR7 GACS Integration
FR7.1 Automatic GACS Import
Table 5: Functional Requirements
5.2 INFORMATIONAL REQUIREMENTS
The table below (Table 6) contains a list of all the information requirements which have been identified
for this project. These requirements are specified in more detail under section 7.
Req
ID
Report Name Purpose Description (contents, sequence,
grouping)
Stakeholder
OperationsManager
Accounting
Marketing
ITManager
IR1 Ticket
Availability
Report
Identify how many tickets
are available for purchase;
help with forecasting and
planning.
Date, Quantity, Timeslot, ordered by
Timeslot ascending.
X
IR2 Daily Sales
Report
Monitor ticket sales for a
day; determine how busy
the observation deck will
be for the day; help plan
operations for the day.
Date, Tickets Type, Quantity, Value
($), ordered by Timeslot,
grouped by Ticket Type. X
IR3 Monthly Sales
Report
Track ticket sales per
month; identify busy
periods; help with
forecasting and planning.
Year, Month(s), Ticket Type,
Quantity, Value ($), Total Quantity,
Total Value ($), ordered by Month
descending, grouped by Channel
(Website or Self Service)
X X

of 122
Goliath
IR4 Credit Card
Sales Report
Track, monitor and
compare the different
types of credit cards used.
Help the Accounting team
perform reconciliations
tasks.
Date, Credit Card Type, Value ($),
Percentage (%), Sub Total ($), Sales
Tax ($), Total ($), ordered by Credit
Card Type ascending.
X X
IR5 Credit Card
Exception
Report
Display all credit card
transaction status activity
over a specified date
range; help resolve guest
issues with regards to
credit card payments.
Transaction Date, Channel, Card
Suffix, Card Type, Request Status,
Request Type, Payment reference,
Sale Barcode, Card Holder, Address,
Total, ordered by Transaction Date
descending.
X
IR6 Credit Card
Refund Report
Keep track of all credit
card refunds which assists
with guest enquires and
audit trails. The
accounting department will
also use this report for
month end reconciliations.
Date, Guest Name, Refund Reason,
Credit Card Type, Refund Value ($),
Refund Percentage (%), Total ($),
ordered by Credit Card Type
ascending.
X X
IR7 Advanced
Sales
Movement
Report
Track tickets status;
identify trends; identify
the percentage of tickets
which expire.
Date, Ticket Type, Ticket Status,
Quantity, Value ($), ordered by Date
descending, grouped by Ticket Status
(Valid, Used, Refunded, Expired).
X X
IR8 Guest
Language
Report
Identify the most popular
languages.
Date From, Date To, Channel,
Language, Total Sales,
ordered by Date descending, grouped
by Language Selected.
X
IR9 MRI Upload
Audit Report
Help ensure all
transactions have been
successfully uploaded to
MRI.
Date, Total Sales Income Uploaded,
MRI Journal Account Number,
Ordered by Date descending.
X X
IR10 MRI
Reconciliation
Report
Compares transactions in
MRI and the Ironwood
Ticket System and
identifies any
discrepancies.
Date, Discrepancy, MRI Journal
Account Number, Total Discrepancy
for Period, ordered by Date
descending.
X X X
IR11 Systems
Variables
Audit Report
Keeps a record of changes
made to System Variables
and the name of the user
who made the change.
Date and Time, Variable Name, User,
Original Value, New Value, ordered
by Date descending.
X X
Table 6: Informational Requirements
The operations manager will provide figures and updates when they report to the executive team; this
meeting occurs once a quarter. The executive team will therefore not execute any of the reports
themselves, or require access to the Ironwood Intranet.

of 122
Goliath
5.3 NON-FUNCTIONAL REQUIREMENTS
The table below (Table 7) contains a list of all the non-functional requirements which have been
identified for this project. These requirements are specified in more detail under section 8.
Req ID Non-functional Requirement
NFR1 Legislation
NFR2 Scalability
NFR3 Performance
NFR4 Availability
NFR5 Auditability
NFR7 Reliability
NFR8 Security
NFR9 Technology
Table 7: Non-Functional Requirements

of 122
Goliath
6 FUNCTIONAL REQUIREMENTS SPECIFICATION
This section details the business processes, business rules and day-to-day functioning of the proposed
Self Service and Ironwood Intranet applications. This section should be read in conjunction with the
User Requirements Specification document which lists the capabilities that the user expects the
application to perform.
6.1 SELECT AND RESERVE GUEST TICKET (FR1)
The guest will be presented with the choice of three ticket types, each of which will have the option to
be upgraded to an Iron Class Pass package type. They will then decide on the time they wish to visit the
Ironwood Observation Deck by selecting a timeslot, after which they will be presented with a summary
of their choices, which they will be asked to confirm.
The following functionality will apply throughout the Self Service application:
1. The application will be designed to accept input from a touch screen.
2. The default user interface will be in English (U.S).
3. All monetary values will be:
a. Preceded by a $ symbol.
b. Displayed to the nearest 2 decimal places.
c. Right aligned.
4. Ticket amounts will be displayed inclusive of sales tax. The tax portion of a sale will be visible
on the Sale Summary screen as well as the individually printed tickets.
5. All time will be displayed in the 24 hour format.
6. All user interface controls, with the exception of the Status screen, will be positioned on the
bottom half of the screen in conformance with the Americans with Disabilities Act (ADA)
requirements.
7. Two types of popup windows will exist in the application:
a. Warning – This popup window will be preceded by an icon, indicating an error or
warning scenario.
b. Info – This popup window will be preceded by an icon, indicating a notice.
8. Each popup window detailed in the specification will follow the same style.
9. Popup windows will be displayed and function as illustrated in the Status screen below.
a. The current screen will be darkened. The background screen and controls will be
visible but inactive.
b. The popup window will be displayed in a white box overlaid on the screen.

of 122
Goliath
c. The buttons displayed on the popup window will depend on which popup window is
displayed.
10. If the guest selects the ‘Cancel’ button at any time in the ticket sales process, the application
will display a popup window with the following values:
Popup Type Warning
Heading Cancel Transaction
Message Are you sure you want to cancel your transaction?
Buttons No / Yes
Table 8: Cancel Transaction Popup Window Details
a. Selecting ‘No’ will close the popup window; selecting ‘Yes’ will cancel the
transaction and return the guest to the Welcome screen.
Figure 8: Cancel Transaction Popup Window
11. In order to prevent malicious activities and to ensure that the guest is unable to close,
minimize or manipulate the Self Service application, SiteKiosk will be installed and configured
on each terminal.
12. The only way a user will be able to exit the Self Service application is if they press a unique
combination of keys and enter in a password (as configured on SiteKiosk).
Vertically aligned
Vertically aligned
Triggers Cancel popup window
Popup type

of 122
Goliath
6.1.1 PERFORM PRE-TICKET SALE FUNCTION (FR1.1)
The Self Service application will perform a number of functions before and when the guest initiates the
ticket sales process. These functions will ensure that the application is available and ready for ticket
sales to be processed.
6.1.1.1 REQUIREMENTS ADDRESSED
1. The Self Service application will cache the following information when it is launched (NFR3.8):
a. Ticket availability
b. Ticket types available
c. Ticket prices
d. Package type price
e. System variables
2. The screen below (Figure 9) illustrates the Welcome screen for the application, and is
considered the default landing screen.
Figure 9: Welcome screen
3. The guest will be directed to this screen at the following times:

of 122
Goliath
a. The Self Service application is launched.
b. The application has passed all tests (detailed under point 4 below).
c. The guest has selected to cancel the ticket sales process.
d. At the end of a successful sale.
e. The credit card payment fails more than the maximum number of allowed times, as
defined by the [CreditCardRetryLimit] system variable.
f. The application is left idle (receives no user input when expected) for longer than the
duration defined by [SessionTimeout] system variable.
g. If an unexpected error occurs within the system which forces the transaction to be
cancelled.
4. The application will perform the following tests when the guest taps the Welcome screen, as
well as the checks detailed under point 8 and 9:
a. Is able to connect to the web servers over the network.
b. Is able to connect with the card reader device.
c. Is able to connect to PayPal.
d. Is able to connect to the printer.
e. The printer has paper in it.
f. There is no paper jam in the printer.
5. If all of the above tests pass, the guest will advance to the first step on the Select Language
screen.
6. If one of the above tests fail the following will occur:
a. An email notification will be sent to an email address, as defined by the
[TerminalTestFailedAddress] system variable. The format of the email will be as
follows:
Subject Out Of Order – Terminal X
Body Terminal X has failed the following tests:
 Unable to connect to web servers.
 Unable to connect to card reader device.
 Unable to connect to PayPal.
 Unable to connect to printer.
 Printer out of paper.
 Paper jam in printer.

of 122
Goliath
Please attend to the terminal immediately.
Table 9: Out Of Order Email Notification
b. Each terminal will have its own number; X will be replaced with the number of the
terminal which has failed the test.
c. Only tests which have failed will be included in the email.
d. The application will display the below Out Of Order screen (Figure 10):
Figure 10: Out Of Order screen
7. Where the Out Of Order screen is displayed:
a. The application will repeat the tests (listed under point 4) every 30 seconds. If all tests
pass the application will return to the Welcome screen.
b. The guest will be unable to interact with the application.
c. A Goliath employee will be able to check which tests are failing by holding down on the
top right corner (as indicated by the red square) of the screen for 5 seconds to bring
up the Status screen, as illustrated below (Figure 10):
Status screen

of 122
Goliath
Figure 11: Status screen
8. The Status screen will help identify which test(s) is/are preventing ticket sales on the terminal,
by displaying the following text and icons which correspond to the tests performed:
Test Text Displayed on Screen Icon
Unable to connect to the web server Web Server Test
Unable to connect to card reader device Card Reader Test
Unable to establish a connection with PayPal PayPal Test
Issue with printer (this applies to all printer tests
listed under point 4).
Printer Test
Table 10: Status Screen Test Details
a. Where a test has passed when it was last run, a tick will be displayed next to it.

of 122
Goliath
b. Where a test has failed when it was last run, a cross will be displayed next to it and
the section’s opacity will be decreased, as illustrated in Figure 11.
9. The application will check the diameter of the remaining paper roll (separate to the checks
performed in point 4).
a. If the diameter of the paper roll is low, the application will send an email notification to
an email address, as defined by the [TerminalMaintenanceWarningAddress] system
variable. The format of the email will be as follows:
Subject Maintenance – Terminal X
Body Terminal X has the following warning:
 Low paper in printing roll (less than 1 inch of diameter remaining).
Please restock the terminal immediately.
Table 11: Maintenance Email Notification
i. A paper roll which has a diameter of less than 1 inch will trigger the email
notification.
ii. Each terminal will have its own number; X will be replaced with the number of
the terminal which has failed the test.
10. The application will check ticket availability for the current day.
a. If there are no available tickets for a future timeslot, for the current day, the
application will display the below Tickets Sold Out screen.

of 122
Goliath
Figure 12: Tickets Sold Out screen
b. The application will display the Sold Out screen for 10 seconds. Thereafter, the
application will return to the Welcome screen.
6.1.1.2 BUSINESS RULES
1. Only one Out Of Order email notification will be sent where a terminal has initially failed a test,
(as listed under point 4) and triggers the Out Of Order screen. In other words, if the Out Of
Order screen is currently displayed and any test continues to fail, the email notification will not
be sent a second time.
2. Only one Maintenance email notification will be sent where a terminal has initially failed a test
listed under point 6. For example, the diameter of the paper roll in terminal X reaches 0.8
inches and therefore triggers the maintenance email notification. If the application returns
back to the Welcome screen and the diameter of the paper roll in terminal X is now a 0.5
inches, the maintenance email notification will not be sent a second time.
3. The only way to exit the Self Service application once it started will be through the use of
SiteKiosk features.
6.1.2 SELECT GUEST LANGUAGE (FR1.2)
The guest will be presented with the option to complete the ticket sales process in four different
languages. This will allow easy usability of the system for a wide range of different guests.

of 122
Goliath
1. The requirements detailed in this section relate to the Select Language screen below:
Figure 13: Select Language screen
2. The guest will have the option to purchase tickets in any one of the following four languages:
a. English
b. Spanish
c. German
d. French
3. The language options will be displayed in both text and illustration.
a. In text - The name of the language using the native spelling of the language.
b. Illustration - The associated flag of the country:
i. English – The flag of the Unites States of America.
ii. Spanish – The flag of Spain.
iii. German – The flag of Germany.

of 122
Goliath
iv. French – The flag of France.
4. Each language option will have a corresponding checkbox next it to help the guest identify the
language which is currently selected.
a. The English language option will be selected by default.
b. It will only be possible to have one language option selected at a time.
c. It will not be possible to deselect a language option. The application will deselect the
currently selected option if another language is selected.
d. All languages which are currently not selected will be slightly transparent.
5. Selecting the flag or corresponding checkbox will select the language.
6. The language of the ‘Select Language’ heading and ‘Next’ button will be translated, in real-
time, to match the selected language.
7. If the application is left idle (receives no user input when expected) for longer than the
duration defined by the [SessionTimer] system variable, the application will automatically
cancel the current sale and return to the Welcome screen. The Session Timer will apply from
this screen and onward, unless explicitly stated otherwise.
8. Selecting the ‘Next’ button will advance the guest to the next step on the Select Tickets
screen; the rest of the text throughout the ticket sales process will be displayed in the
language selected. For more information on how the application will store and source its
language translations please refer to Appendix 3.
1. The guest will only be able to use the application in one of the languages displayed on the
Select Language screen at any given time.
2. The language translations will be static and there will be no option to update them on the
front-end. An update to the backend will be required in order to update them.
6.1.3 SELECT TICKET TYPE AND QUANTITY (FR1.3)
The guest will be presented with the choice of three ticket types, each of which will have the option to
be upgraded to an Iron Class Pass package.
1. The requirements detailed in this section relate to the Select Tickets screen below:

of 122
Goliath
Figure 14: Select Tickets screen
2. All text displayed will be translated and displayed in the language selected by the guest on the
Select Language screen.
3. The guest will have the option to purchase from the following three ticket types:
a. Adult
b. Child
c. Senior
4. The ticket prices will be sourced and defined from the Manage Tickets screen on the Ironwood
Intranet.
a. If the ticket prices are changed, the application will need to be restarted in order for
them to be re-cached and therefore displayed.
5. The guest will be able to select tickets by:
a. Selecting the button to increase the number of tickets selected by one.
b. Selecting the button to decrease the number of tickets selected by one.
6. When the screen initially loads, no tickets will be selected by default. It will not be possible to
decrease the quantity of any ticket below 0.

of 122
Goliath
7. The decrease button, for a ticket, will be inactive and grayed out where the quantity of
tickets selected for that specific ticket is equal to 0.
8. The increase button will be inactive and grayed out where the total quantity of tickets selected
is equal to the [MaximumTicketsPerSale] system variable.
9. The ‘Next’ button will be inactive and slightly transparent (like the unselected languages on
the Select Language screen), where the total quantity of tickets selected to be included in the
sale is equal to 0.
10. If the guest has selected to include at least one ticket in the sale the ‘Next’ button will be
available for selection; selecting it will advance the guest to the next step on the Upgrade
Tickets Option screen.
11. Selecting the ‘Back’ button will return the guest to the previous step on the Select Language
screen.
1. The three tickets listed will be inserted into the system through the backend once
development has been completed. There will be no option to update their names on the front-
end. An update to the backend will be required to change them.
2. The guest must select at least one ticket to purchase before they are able to proceed to the
next screen.
3. The total quantity of tickets that a guest can request to purchase for any one sale will be
defined by the [MaximumTicketsPerSale] system variable.
4. All three tickets will contribute evenly towards the total count. I.e. each ticket will contribute
exactly 1 towards the count.
6.1.4 UPGRADE TICKET TO PACKAGE (FR1.4)
The guest will be presented with an option to upgrade their tickets to a package titled the Iron Class
Pass. This will entitle them to receive a souvenir gift and souvenir photo.
1. The monetary values displayed on the two screens in this section ($10 in the example
screenshots provided) will be sourced and defined by the [PackageUpgradePrice] system
variable.
2. All text displayed on the two screens in this section will be translated and displayed in the
language selected by the guest on the Select Language screen.

of 122
Goliath
Figure 15: Upgrade Tickets Option screen
3. The guest will be presented with two options on the above screen (Figure 15):
a. Do not upgrade any tickets to an Iron Class Pass package.
i. Selecting the ‘No’ button will skip the next step and continue the process on the
Select Timeslot screen.
b. Upgrade any number of the tickets which have been selected on the previous screen
(Select Tickets screen).
i. Selecting the ‘Yes’ button will continue the process at the next step on the
upgrade Tickets screen below:

of 122
Goliath
Figure 16: Upgrade Tickets screen
4. The guest will have to ability to choose how many tickets they would like to upgrade by using
the increase and decrease buttons. The increase and decrease buttons will operate the same
way as on the Select Tickets screen.
5. The process of upgrading tickets will involve adding one Iron Class Pass package type to the
sale equal to the number selected.
6. Selecting the ‘Back’ button will return the guest to the Select Tickets screen and not the
Upgrade Tickets Option screen.
7. If the number of tickets selected to be upgraded is equal to 0 when the guest selects the
‘Next’ button, a popup window with the following values will be displayed (Table 12):
Popup Type Info
Heading Upgrade Tickets
Message Are you sure you want to proceed without upgrading any tickets?
Buttons No / Yes
Table 12: Upgrade Tickets Popup Window Details
a. Selecting the ‘No’ button will close the popup window.

of 122
Goliath
8. If the guest has selected at least one ticket to upgrade, or selects ‘Yes’ in the popup window
detailed above (Table 15), they will advance to the next step on the Select Timeslot screen.
1. If the guest chooses to upgrade to a package, all tickets will be selected to be upgraded by
default when the Upgrade Tickets screen initially loads. For example, if 1 Adult and 3 Child
tickets were selected on the Select Tickets screen, 4 Iron Class Pass package types will be
selected when the Upgrade Tickets screen loads.
2. The guest will only be able to upgrade an amount which is equal to the number of tickets that
they originally selected to purchase on the Select Tickets screen.
3. The guest will be able to continue from screen Upgrade Tickets screen without selecting any
tickets to upgrade.
4. The Iron Class Pass package type will consist of a gift souvenir and photo souvenir. The
distribution and maintenance of these items will be a manual process, and will fall outside of
the scope of this project; the Goliath employees will be responsible for this process.
5. The Iron Class Pass package type will not consume available ticket capacity. In other words, it
will not be factored in when the system calculates the available ticket capacity.
6. It will not be possible to purchase an Iron Class Pass package by itself.
7. The Iron Class package heading will be static text and will not be dynamically sourced.
6.1.5 SELECT TICKET TIMESLOT (FR1.5)
The guest will be presented with a list of all the remaining timeslots for the day. Timeslots which have
no remaining tickets available will be marked as sold out, and the guest will be unable to select it.
1. The requirements in this section relate to the Select Timeslot screen below:

of 122
Goliath
Figure 17: Select Timeslot screen
2. When the screen initially loads the following will occur:
a. The next available timeslot will automatically be displayed and reserved.
i. For example, in the screen above, the application will automatically select the
15:00 – 15:30 timeslot and reduce the quantity of available tickets under the
Availability column by the amount selected on the Select Tickets screen.
b. All timeslot availability information for the day will be cached locally on the terminal.
c. Translate and display information on the screen in the language selected by the guest
on the Select Language screen.
3. When changing the selected timeslot (through use of the direction arrows), the availability of
the timeslot will be determined by the cached values. The database will not be queried in real
time.
4. If the timeslot has not changed and the guest selects the ‘Next’ button they will immediately
advance to the next step on Sale Summary screen.
5. If the timeslot has changed and the guest selects the ‘Next’ button, the system will confirm
whether the newly selected timeslot is still available.
6. If the timeslot is still available, it will be reserved and the guest will advance to the next step
on the Sale Summary screen.
Sale Timer
‘Previous
Timeslot’
Indicates
selection

of 122
Goliath
7. If the timeslot is no longer available, a popup window with the following information will be
displayed (Table 13):
Popup Type Info
Heading Timeslot unavailable
Message The selected timeslot is no longer available. The next available timeslot has
automatically been selected.
Buttons Ok
Table 13: Timeslot Unavailable Popup Window Details
a. Selecting the ‘Ok’ button in the above popup window (Table 13) will:
i. Close the popup window and refresh the screen and cached availability
information.
ii. Select and reserve tickets from the next available timeslot which has sufficiently
available capacity for the guest’s transaction.
8. If after the popup window (Table 13) is displayed and there is not enough available capacity
for the sale, the guest will be redirected to the Welcome screen.
9. If after the popup window (Table 13) is displayed and there is zero available capacity for the
day, the Welcome screen will be displayed.
10. A timeslot which is sold out (as defined below) will be grayed out, inactive, and therefore not
selectable.
a. For example, the 14:30 – 15:00 and 15:30 – 16:00 timeslots in the screen above.
11. A timeslot will be classified as sold out under any of the following circumstances:
a. The start of the timeslot falls in the past (for e.g. the 14:30-15:00 timeslot in the
screen above).
b. The quantity of available tickets for the timeslot is less than the quantity of tickets
selected by the guest on the Select Tickets screen.
12. The ‘previous timeslot’ will always be displayed, even though it will always be classified as sold
out.
a. For example, the 14:00 – 14:30 timeslot in the screen above.
b. The guest will be unable to cycle through timeslots early than the previous timeslot.
13. The guest will be able to cycle through the available timeslots by selecting the downward
and upward directional arrows , respectively.
14. A white rectangle will be displayed around the timeslot which is currently selected.
15. Where the guest selects a directional arrow, all timeslots will shift simulatenously in the
direction of the arrow selected, while the directional arrows will remain in the same place.

Ironwood Self Service Terminals And Intranet Functional Specification - Phase1 v1 2016-02-08

Ironwood Self Service Terminals And Intranet Functional Specification - Phase1 v1 2016-02-08

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to Ironwood Self Service Terminals And Intranet Functional Specification - Phase1 v1 2016-02-08

Similar to Ironwood Self Service Terminals And Intranet Functional Specification - Phase1 v1 2016-02-08 (20)

Ironwood Self Service Terminals And Intranet Functional Specification - Phase1 v1 2016-02-08