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

Page 1 of 122

Ironwood Self Service Terminals And Intranet - Phase 1

GOLIATH

FUNCTIONAL SPECIFICATION

FEBRUARY 8, 2016

Page 2 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

Page 3 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

Page 4 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

Page 5 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

Page 6 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

Page 7 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

Page 8 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

Page 9 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

Page 10 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.

Page 11 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.

Fake%20hyperlink%20to%20URS%20for%20the%20purpose%20of%20this%20FTI%20project

Page 12 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

Page 13 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.

Page 14 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

Page 15 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.

Page 16 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

Page 17 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

Fake%20Link

Page 18 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

MRITicket 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

Page 19 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.

Page 20 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.

Page 21 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.

Page 22 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.

Page 23 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 BoxGoliath

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

LeasingProperty

ManagementInvestment

Management

Acquisitions & Development

Affected Business

Unit

KEY

No ChangeNew

Business Unit

Page 24 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

Page 25 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.

Page 26 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

Page 27 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.

Page 28 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 AdministratorAdmissionsClerk

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

Page 29 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/AdmissionsIIS

Web/A

pplication S

erv

er

1

PlatformMS 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

TransactionalReplication

Shared Logic Layer



Web/A

pplication S

erv

er

2


PayPal Payflow Pro

Self Service


Shared Logic Layer

Ironwood Building - Browser

Marketing Accounting Manager Self-ServiceGuest Travel Agent

SSLSSL



Web/A

pplication S

erv

er

3


PayPal Payflow Pro

Self Service


Microsoft Network Load Balancing

(Website, Self Service & Intranet)

Shared Logic Layer



Web/A

pplication S

erv

er

4


PayPal Payflow Pro

Self Service


Shared Logic Layer

MRI Server

Download

Upload

PayPal Payflow Pro

GatewayFirewall

SSL

Mobile PDA

Page 30 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

https://www.zebra.com/us/en/products/printers/kiosk/kr400-series.html

http://www.newegg.com/Product/Product.aspx?Item=N82E16824217082

http://www.newegg.com/Product/Product.aspx?Item=N82E16824217082

http://www.verifone.com/products/hardware/unattended/ux-300/

Page 31 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

Page 32 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.

Fake%20link%20to%20Solution%20Integration%20document%20for%20the%20purpose%20of%20FTI

Page 33 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

Page 34 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

Opera

tions M

anager

Accounting

Mark

eting

IT M

anager

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

Page 35 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.

Page 36 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

Page 37 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.

Page 38 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

Page 39 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:

Page 40 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.

Page 41 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

Page 42 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.

Page 43 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.

Page 44 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.

Page 45 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.

Page 46 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:

Page 47 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.

Page 48 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.

Page 49 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:

Page 50 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.

Page 51 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:

Page 52 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

Page 53 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.

Page 54 of 122

Goliath


16. Where the earliest available timeslot is selected the upward directional arrow will be inative

and grayed out .

17. Where the latest available timeslot is selected the downard directional arrow will be inative

and grayed out .

18. The current time in New York (EST) will be displayed after the ‘Current Time’ label.

a. For example, 14:45 in the screen above.

19. A Sale Timer will be displayed top right of the screen. This timer will begin counting down as

soon as the screen loads. The guest will need to complete the rest of the ticket sales process

before this timer reaches zero. If the Sale Timer reaches zero before the guest completes the

transaction they will automatically be redirected to the Welcome screen, and the sale will be

cancelled. The start value of this Sale Timer will defined by the value of the [SaleTimer]

system variable.

20. If by the time the guest arrives on this screen, the only tickets which were available at the

start of the transaction (when available capacity was first cached) are no longer available, this

screen will not be displayed and instead the Out Of Order screen will be displayed.

21. Selecting the ‘Back’ button will return the guest to the previous step on the Upgrade Tickets

screen.

22. Selecting the ‘Next’ button will advance the guest to the next step on the Sale Summary

screen.

23. For more information on how the ticket availability will be calculated, please see Appendix 4.


1. The ‘previous timeslot’ will always be displayed, even though it will always be sold out;

therefore will not be selectable. With the exception of the first available timeslot of the day.

2. With the exception of the ‘previous timeslot’ being displayed, all timeslots earlier than it will

not be displayed; therefore will not be selectable.

3. All future sold out timeslots will be displayed so that the guest is provided with a visual

explanation for not being able to select it.

4. The Session Timer and Sale Timer will function independently of each other.

5. It will not be possible to purchase tickets from two different timeslots during the same

transaction.

6.1.6 CONFIRM TICKET SALE (FR1.6)

The application will display a summary of the sale to the guest. This will allow them the opportunity to

review their decisions and confirm their purchase. Once the guest has confirmed their purchase they

will be required to pay for the tickets.


Page 55 of 122

Goliath


1. The requirements in this section relate to the Sale Summary screen below:

Figure 18: Sale Summary screen

2. All text displayed will be translated and displayed in the language selected by the guest on the


3. The timeslot which was selected on the Select Timeslot screen will be displayed at the top,

after the ‘Timeslot’ label.

4. All of the tickets and upgrade options selected for purchase will be displayed, and in the

following order:

a. Adult

b. Child

c. Senior

d. Iron Class Pass

5. If a specific ticket type, for example Child, was not selected to be included in the sale, it will

not be displayed.

6. Under the list of tickets to be included in the sale will be the following items:

Page 56 of 122

Goliath


a. Sub Total – calculated as the sum of the ticket amounts (exclusive of tax) multiplied

by their quantity included in the sale. The system automatically calculates the ticket

amount (exclusive of tax) by using the following formula:

i. Ticket Amount = Total Amount / (1 + [SalesTaxRate]).

b. Sales Tax - calculated as the sum of all tax amounts in the sale.

i. The tax amount of each ticket will be calculated as the tax rate multiplied by the

ticket amount.

i. The tax rate will be sourced and defined by the [SalesTaxRate] system variable.

c. Total – calculated as the sum of the Sub Total (tax exclusive ticket amounts) and Sales

Tax amounts.

7. As an example, the guest selects to purchase the following items and quantities (The New

York sales tax of 8.875% has been used):

a. 2 Adult tickets at $30 each = $60

b. 2 Child tickets at $20 each = $40

c. 4 Iron Class Pass packages at $10 each = $40

i. Sub Total = $ 127.57 ($140 - $12.57)

ii. Sales Tax = $12.43 ($140 x 8.875%)

iii. Total = $140 ($127.57+ $12.43)

8. The Sale Timer will apply to this screen and will be displayed.

9. Selecting the ‘Back’ button will return the guest to the Select Timeslot screen.

10. Selecting the ‘Next’ button will advance the guest to the next step on the Insert/Remove

Credit Card screen.


1. Individual ticket amounts (exclusive of tax) and individual tax amounts will not be displayed

by the application (with the exception of sales containing only one ticket).

2. All amounts displayed on the front-end will be rounded to 2 decimal places. The backend will

not round any figures.

6.2 PAY FOR GUEST TICKET (FR2)

Once the guest has selected their tickets, timeslot and reviewed the sale summary, they will be

required to pay for the tickets using their credit card. Once the payment is successful their tickets will

be printed.

Page 57 of 122

Goliath


6.2.1 INSERT/REMOVE CREDIT CARD (FR2.1)

Once the guest has advanced past the Sale Summary screen they will be presented with the

Insert/Remove Credit Card screen. They will be required to insert their credit card into the credit card

reader device, and then remove it.


1. The following requirements relate to the Insert Credit Card screen below:

Figure 19: Insert/Remove Credit Card screen

2. The card reader will only read the magnetic strip of the card and not a chip, in the case of

chipped cards.

3. The guest will need to insert and remove their credit card in order for the device to read the

magnetic strip.

4. The Sale Timer will apply and be displayed on this screen.

5. The application will display three downward-facing arrows which will be animated:

a. The arrows will move slightly up and down within the white box.

b. The purpose of the animation is to provide visual assistance to the guest to insert their

credit card.

Page 58 of 122

Goliath


6. Once the card is inserted the Remove Credit Card screen below will be displayed until the card

is removed:

a. This screen will be displayed as soon as the card reader has read all of the required

data from the magnetic strip.

b. The direction of the arrows graphic will be inverted and still animated.

Figure 20: Remove Credit Card screen

7. Only the credit cards types that are defined and enabled on the Ironwood Intranet under

Administration tab will be supported by the Self Service application.

8. If the guest inserts an unsupported credit card the application will display the following popup

window:

Popup Type Warning

Heading Unsupported Credit Card

Message Please note only the following credit cards are supported: <CreditCardTypes> (Where <CreditCardTypes> will be the list of supported credit cards in alphabetical, comma-delimited format e.g. ‘American Express,

Discover, MasterCard, Visa.’ sourced from the Administration tab).

Page 59 of 122

Goliath


Button Ok

Table 14: Unsupported Credit Card Popup Window Details

a. Selecting the ‘OK’ button will close the popup window.

9. If the application detects that a card has been inserted but is unable to read it, the following

popup window will be displayed (Table 15):

Popup Type Info

Heading Unable To Read Card

Message Please ensure a valid credit card has been inserted with the magnetic stripe facing the correct direction.

Button Ok

Table 15: Unable To Read Card Popup Window Details

a. Selecting the ‘OK’ button will close the popup window.


11. Selecting the ‘Back’ button will return the guest to the previous step on the Sale Summary

screen.

12. As soon the credit card is removed from the device and the application was able to

successfully read it, the guest will automatically advance to the next step on the Signature

Capture screen.


1. The credit card types that the Self Service application accepts will be limited to the ones

configured on the Ironwood Intranet under the Administration tab.

6.2.2 CAPTURE GUEST SIGNATURE (FR2.2)

Once the guest has inserted and removed their credit card they will be required to capture their

signature digitally.


1. The following requirements relate to the Signature Capture screen below:

Page 60 of 122

Goliath


Figure 21: Signature Capture screen

2. The guest will be required to sign using their finger on the dotted line displayed within the

circle.

Page 61 of 122

Goliath


Figure 22: Signature Captured screen

3. As the guest signs, a real-time visualization of their signature will appear behind their finger,

in the color black, on the screen.

4. The guest will be unable to capture their signature anywhere outside of the red block. The red

block is not part of the final screen design, and is purely there to indicate to the development

team where the guest is allowed to capture their signature.


6. The application will save all signatures captured against sales which have been completed.

These signatures will be viewable on the Ironwood Intranet on the Payment Information Popup

Window.

7. Selecting the ‘Back’ button will return the guest to the Insert/Remove Credit Card screen and

not the Remove Credit Card screen.

8. Selecting the ‘Next’ button will validate whether the guest has captured a signature.

9. If no signature was captured, the following popup will be displayed (Table 16):

Popup Type Warning

Heading No Signature Captured

Page 62 of 122

Goliath


Message Please capture your signature on the dotted line using your finger.

Button Ok

Table 16: No Signature Captured Popup Window Details

a. Selecting the ‘Ok’ button will close the popup window.

10. If a signature was captured, the application will save the signature against the transaction and

advance the guest to the next step on the Credit Card Authorization screen.


1. The guest’s signature will only be saved permanently within the database if the sale receives a

successful payment.

6.2.3 PROCESS CREDIT CARD PAYMENT (FR2.3)

Once they have signed, the system will communicate with PayPal in order to authorize and process the

credit card payment.


1. The Credit Card Authorization screen below will be displayed while the application attempts to

transmit the guest’s credit card information to PayPal for authorization.

Page 63 of 122

Goliath


Figure 23: Credit Card Authorization screen

2. While the system is authorizing the payment the following will occur:

a. The ellipses after the Authorizing heading will animate between displaying one to three

dots.

b. The clock hands displayed within the circle will rotate clockwise for the duration of the

authorization process.

3. Once the authorization process with PayPal is complete, one of the following outcomes will

occur:

a. Failed response received, the following popup window will be displayed (Table 17):

Popup Type Warning

Heading Failed

Message Your transaction could not be processed at this time. Please wait a few seconds and then try again.

Button Ok

Table 17: Payment Authorization Failed Popup Window Details

Page 64 of 122

Goliath


b. Declined response received, the following popup window will be displayed (Table 18):

Popup Type Warning

Heading Declined

Message Your transaction could not be authorized. If you would like to complete this

transaction please reattempt using another card, or alternatively contact your bank to verify the validity of your credit card and account.

Button Ok

Table 18: Payment Authorization Declined Popup Window Details

c. Selecting the ‘Ok’ button for either of the above two popup windows will:

i. Close the popup window.

ii. Return the guest to the Insert/Remove Credit Card screen.

iii. Increment the count of payment attempts by one.

d. Approved response received:

i. The guest’s account will be charged the total amount of the transaction.

ii. The application will flag the transaction as complete in the system.

iii. The guest will advance to the next step on the Print Tickets screen.

4. In the event that the credit card payment is unsuccessful (by receiving either a ‘Failed’ or

‘Declined’ response from PayPal), the application will keep a count of this for each transaction.

5. The guest will be allowed to retry the payment for each transaction up to a limited number of

times, as defined by the value of the [CreditCardRetryLimit] system variable.

6. The count of credit card payment retry attempts will be set to zero when this screen initially

loads.

7. If the number of credit card payment attempts exceeds the value of the

[CreditCardRetryLimit] system variable, one of the following popup windows will be displayed:

a. The last attempt received a Failed response (Table 19):

Popup Type Warning

Heading Failed

Message Your payment could not be processed. The maximum number of retry attempts has been reached and you will now be directed back to the home screen. Please reach out to a Goliath employee for further assistance.

Button Ok

Table 19: Maximum Payment Retry Attempts Exceeded Popup Window Details: Failed

b. The last attempt received a Declined response (Table 19):

Page 65 of 122

Goliath


Popup Type Warning

Heading Declined

Message Your payment could not be processed. The maximum number of retry attempts has been reached and you will now be directed back to the home screen. Please contact your bank to verify the validity of your credit card and account.

Button Ok

Table 20: Maximum Payment Retry Attempts Exceeded Popup Window Details: Declined

c. Selecting the ‘Ok’ button for either of the above two popup windows will cancel the

transaction and redirect the guest to the Welcome screen.


1. While the authorization is in progress it will not be possible to return to a previous step, cancel

the transaction or otherwise interact with the application.

2. The application will not validate the signature against anything, other than the guest captured

something within the signature box.

3. If the guest returns to the Signature Capture screen after they have already captured a

signature (for example, if payment authorization fails and they reattempt with another card)

the application will not display the signature previously captured for the transaction.

4. Once the Credit Card Authorization screen is displayed, the Sale Timer will be stopped, and the

Session Timer paused.

5. The count of the credit card payment retry attempts will persist across screens up until the

point where the guest navigates back to the Select Tickets screen; at this point the count will

reset to zero.

6. It will not be possible to enter credit card details manually into the system.

7. Signature capture will be performed by the application on the touch screen.

8. The application will not queue and allow for delayed credit card transactions.

9. Partial credit card payments will not be allowed.

6.2.4 PRINT SALE TICKET (FR2.4)

Once the guest has captured their signature and the payment has been successfully completed, the

application will automatically print their tickets.

Page 66 of 122

Goliath



1. The following requirements relate to the Print Tickets screen below:

Figure 24: Print Tickets screen

2. The screen will be displayed while the guest’s tickets are being printed.

3. The application will begin printing the tickets immediately.

4. The guest will have no further options available to them while the application prints the

tickets.

5. While the tickets are being printed the following will occur:

a. The image of the paper coming out of the printer will animate.

b. The ellipses after the Printing heading will animate between displaying one to three

dots.

6. The Sale Timer and Session Timer will not apply to this screen.

7. The layout and design of the printed tickets will be as follows:

Page 67 of 122

Goliath


Figure 25: Printed Ticket Design

8. The printed tickets will contain the following information, as illustrated above (Figure 25):

a. A pre-printed Ironwood Observation Deck logo within the top 0.5 inches of the ticket.

b. The label ‘Guest:’ followed by the ticket type.

c. The label ‘Date:’ followed by the timeslot date.

d. The label ‘Time’ followed by the timeslot time.

e. A total count of tickets (including Iron Class Pass packages) to be printed as well as

the current ticket number (e.g. 1 of 8 Tickets).

f. The value of the [PrintedTicketNote] system variable.

g. The QR code corresponding with the unique ticket number.

Page 68 of 122

Goliath


h. The unique ticket number.

i. The sub-total of the sale.

j. The tax amount of the sale.

k. The total amount of the sale.

l. The credit card number used to pay for the transaction, with only the last four

numbers being visible and the rest masked by an ‘x’.

m. The cardholder name as captured from the credit card.

n. The label ‘Sale Number’.

o. The unique sale number in barcode format.

p. The unique sale number.

9. Each ticket will contain sale information (such as sale number, amounts and card data).

a. There will be no separate sales receipt printed.

10. The printer will cut the paper after each printed ticket.

11. If the printing paper runs out during the printing operation the following popup window will be

displayed (Table 21):

Popup Type Info

Heading Out Of Paper

Message The terminal has unfortunately run out of paper before it could finish printing your tickets. Please reach out to a Goliath employee for assistance.

Button Ok

Table 21: Out Of Paper Popup Window Details

a. Selecting the ‘Ok’ button will advance the guest to the Transaction Complete screen

below.

12. When the last ticket has been printed, or the guest selects the ‘Ok’ button on the above popup

window, they will automatically and immediately advance to the next and final screen of the

ticket sale process; the Transaction Complete screen, which is displayed below:

Page 69 of 122

Goliath


Figure 26: Transaction Complete screen

13. The text displayed at the bottom of the screen will only be displayed if the guest selected to

include at least one Iron Class Pass package in their sale. This text will be static and there will

be no option to update it on the front-end. An update to the backend will be required in order

to update this text.

14. The Sale Timer and Session Timer will not apply to this screen.


1. The guest will not have the option to reprint their tickets from the Self Service application. If a

reprint is required, it will need to be performed by a Goliath staff member through the

Ironwood Intranet.

2. The names of all ticket and package types will be printed as they are saved and displayed

within the Ironwood Intranet.

3. The tickets will always be printed in English.

6.3 MANAGE TICKET ADMINISTRATION (FR3)

The functionality detailed in this section will enable the effective management and monitoring of all

ticket sales which take place. This functionality is designed for the managers who will oversee the

operations of the Ironwood Observation Deck.

Page 70 of 122

Goliath


6.3.1 LOGIN TO IRONWOOD INTRANET (FR3.1)

The user will be required to enter their GACS credentials in order to access the Ironwood Intranet. The

level of access will depend on how the user is configured in GACS.


1. The user will be required to enter their GACS username and password into the popup window

below in order to access the Ironwood Intranet.

Figure 27: Login screen

2. This requirement will be designed in conjunction with the security non-function requirements.

3. They application will prompt the user to enter their GACS credentials each time they access it,

within a new session through a browser, or clear the browsers cookies and website data.

a. For example, if the user opens the application within the same session in another

browser tab, they will not be required to re-enter their GACS credentials.

4. The system will limit the user’s access and rights to the Ironwood Intranet based on their

account setup in GACS.


1. There are no business rules for this requirement. For a list of the business rules which apply to

GACS and therefore indirectly to this system, please refer to the GACS Functional

Specification.

6.3.2 SEARCH FOR TICKET SALE (FR3.2)

A manager user will have the ability to search for a particular sale using a range of available search

criteria which will be available for them.

Page 71 of 122

Goliath



1. The following requirements relate to Ticket Sales Search screen below. Please note that the

screen designs provided in this section are wireframes. The final screens will differ and will

match Goliath’s corporate image and brand. The user will access this screen by selecting the

‘Sales’ tab.

Figure 28: Ticket Sales Search screen

2. The Ticket Quantity column will include both tickets and packages.

3. The user will have the option to search for a specific sale or group of sales by using the

following controls and selecting the ‘Search’ button (Table 22):

Field Name Field Type Description Validation

Sale # /

Ticket #

Text The sale or ticket number,

as printed on the tickets.

Allows the user to search for a specific sale, or ticket.

If a ticket number is entered, the sale which the ticket falls under will be displayed in the search

results.

Only accepts numeric characters.

If 8 characters are entered the

application will search through the sale numbers.

If 10 characters are entered the application will search through the ticket numbers.

A limit of 10 characters will be applied (the length of a ticket

number).

Search criteria

Search results

GACS username

NFR 6.4

Select to View Sale Information screen(FR3.3)

Page 72 of 122

Goliath


For the purpose of this

field, a ticket and package number will be used

interchangeably.

If less than 8 characters are

entered and the ‘Search’ button is selected the following error

message will be displayed: ‘An incorrect ticket or sale number was entered.’

Date From

Date To

Date The date on which the sale

took place.

The application will only return sales which took place on, and between the dates captured.

Date From default value =

today’s date.

Date To default value = today’s date.

The date format will be MM-DD-

YYYY.

Only accept numeric characters.

Values greater than 12 entered for the month and 31 for the day will automatically be cleared.

If the date selected in the ‘Date From’ field is later than the value

selected in the ‘Date To’ field, the following message will be displayed: ‘The value of the Date From field cannot be later than the value of the Date To field.’

Timeslot From

Timeslot To

Single–select dropdown list

The timeslot selected during the sales process.

A list of all the timeslots will be displayed in these fields.

The application will only

return sales which are for, and between the timeslots selected.

Timeslot From default value = 09:00.

Timeslot To default value = 22:00.

If the Date From and Date To values are equal, the following validation will apply:

If the value selected in the ‘Timeslot From’ field is greater than the value selected in the

‘Timeslot To’ field, the following message will be displayed: ‘The value of the Timeslot From field cannot be later than the value of the Timeslot To field.’

Table 22: Manage Ticket Sales Search Criteria Details

4. None of the above search criteria fields will be mandatory.

5. If the ‘Search’ button is selected, and no results are returned, the following text will be

displayed in the search results section: ‘No sales were found for the selected search criteria’.

6. The search results section will display the following information (Table 23):

Field Name Description

Date The date on which the sale was completed.

Timeslot The timeslot selected during the ticket sale process.

Guest Name The name on the credit card which was used to purchase the tickets.

Page 73 of 122

Goliath


Sale Number The sale number, as printed on the tickets.

Ticket Quantity The quantity of tickets selected during the ticket sales process.

Channel The source from where the ticket sale originated.

Table 23: Search Results Information

7. The results of the search will be filtered by date and then timeslot, in descending order.

8. All fields displayed in the search results section will be read-only.

9. A maximum of 500 sales will be displayed in the search results. If the search criteria returns

more than 500 results, only 500 will be displayed and the application will inform the user

through the following popup window (Table 24):

Popup Type Info

Heading Search Results

Message Please note, for performance reasons only the first 500 sales which match your search criteria have been displayed. It is recommended that you refine

your search.

Button Ok

Table 24: Search Results Popup Window Details

a. Selecting the ‘Ok’ button will close the popup window.

b. The purpose of this functionality is to prevent the user from having to wait a long time

for all the results to be displayed. The application will also be unusable during this

period which will frustrate the user.

10. The user will be able to view more information about a particular sale by selecting the sale line

item; this will display the View Sale Information screen (FR3.3).


1. Only complete sales will be viewable through the Ironwood Intranet. A sale will be regarded as

complete where it has a successful payment linked to it. The reasoning for this is that if

something goes wrong before the guest’s credit card has been charged, they can simply

restart the process, reselect their tickets and pay for them. However, if something goes wrong

after their credit card has been charged they cannot restart and repeat the process as their

card will then be charged twice. In this scenario they would contact the manager on duty who

would be able to find their sale through the Ironwood Intranet and reprint the tickets.

6.3.3 VIEW TICKET SALE (FR3.3)

Once the user has selected to perform a search which has returned results, they will have the ability to

view more information about a specific sale by selecting it.


Page 74 of 122

Goliath


1. Once the user has selected to drilldown into a particular sale the View Sale Information screen

below will be displayed:

Figure 29: View Sale Information screen

2. For the purpose of this section a package will be regarded as a ticket. In other words, any

package which was selected during the sales process will be displayed under the Ticket

Information section.

3. Each ticket in the sale will have a checkbox associated to it. This will allow the user to perform

certain functions to tickets on an individual level.

4. Selecting the checkbox at the top, next to the Ticket Price heading, will check all the

checkboxes within the sale which are allowed to be checked. Unselecting this checkbox will

uncheck all the checkboxes which are currently checked.

5. A ticket checkbox will only be selectable if the ticket is in the Valid status.

6. Any chances made on this screen will not be saved if the user navigates away from this

screen.

7. Selecting the ‘Back’ button will undo any selection of the ticket checkboxes are return the user

to the Ticket Sales Search screen.

8. The following information pertaining to the selected sale will be displayed:

a. Sale information (Table 25):

(FR3.4)

(FR3.6) (FR3.5) Indicates disabled Indicates disabled

Page 75 of 122

Goliath



Sale # The sale number, as printed on the tickets.

Date The date on which the guest selected to visit the Ironwood observation deck.

Timeslot The timeslot selected by the guest during the sales process.

Channel The source from where the guest purchased the tickets.

Sub Total The sum of the ticket amounts (exclusive of tax) multiplied by their quantity included in the sale.

Sale Tax The sum of all tax amounts in the sale.

Total The sum of the Sub Total and Sales Tax amounts.

Table 25: Manage Ticket Sales: Sale Information Details

b. Ticket information (Table 26):


Ticket Type The name of the ticket or package which was selected during the ticket sales process.

Ticket # A 10 digit number which helps identify a specific ticket, as printed on the tickets.

Ticket Status The current status of the ticket. For more information about the different ticket statuses please refer to the Ticket entity in the data dictionary.

Where a valid ticket has been used, refunded, cancelled or expired, the date and time that the ticket changed to this status will be displayed (as illustrated in the View Sale Information screen for the last three tickets).

Channel The source from where the guest purchased the tickets.

Ticket Price The price of the ticket at the time it was purchased.

Table 26: Manage Ticket Sales: Ticket Information Details

c. Payment Information (Figure 30):

i. The user will be able to view payment information pertaining to the sale by

selecting the ‘View Payment’ button.

ii. The ‘View Payment’ button will only be selectable if the sale has a payment

associated to it.

iii. Selecting this button will display the popup window below:

Page 76 of 122

Goliath


Figure 30: Payment Information Popup Window

iv. The above popup window will contain the following information:


Name The name on the credit card which was used to pay for the sale.

Card Prefix The last 4 digits of the credit card number which was used to pay for the sale.

Expiry Date The expiry date of the credit card.

Payment Date The date on which the payment was made.

Is Refunded Indicates whether the sale has been refunded, or not.

A indicates the sale has been refunded.

A cross indicates the sale has not been refunded.

Refund Reason A refund reason is required to be captured where a sale has been refunded. The refund reason captured will be displayed here.

Signature The digital signature captured by the guest on the Signature Capture screen through the Self Service application.

Table 27: Manage Ticket Sales: Payment Information Details

v. Selecting the ‘Close’ button will close the popup window.

6.3.3.2 BUSINES RULES

1. There are no business rules for this section.

Page 77 of 122

Goliath


6.3.4 CANCEL TICKET (FR3.4)

A manager user will have the ability to cancel tickets within a sale.


1. The following requirements relate to the View Sale Information screen.

2. The user will make use of the ticket checkbox functionality described here to select which

tickets they would like to cancel.

3. The ‘Cancel’ button will only be available for selection if at least one ticket is selected.

4. Selecting the ‘Cancel’ button will display a popup window with the following information:

Popup Type Info

Heading Cancel Ticket

Message Are you sure you want to cancel these the following tickets:

X

Y

…

Please note that once a sale is cancelled it cannot be reversed.

Button Yes / No

Table 28: Cancel Sale Popup Window Details

a. X, Y, … = ticket type/package type names and ticket/package numbers.

i. Each ticket/package will be displayed separately, on a new line, bullet pointed.

b. Selecting the ‘Yes’ button will:


ii. Mark the ticket as cancelled.

c. Selecting the ‘No’ button will close the popup window and do nothing.


1. Only tickets with a status of Valid can be cancelled.

2. Once complete, the process of cancelling a ticket cannot be reversed.

6.3.5 REPRINT TICKET SALE (FR3.5)

A manager user will have the ability to reprint tickets from a sale.

Page 78 of 122

Goliath



1. The following requirements relate to the View Sale Information screen.

2. Selecting the ‘Reprint’ button will reprint all the tickets within the sale which are selected.

3. The application will use the standard windows printing service; the tickets will be printed

through the printing device which is currently connected to the manager’s workstation.


1. It will be possible to reprint only a subset of the tickets within a sale.

6.3.6 REFUND TICKET SALE (FR3.6)

A manager user will have the ability to refund a sale.


1. The following requirements relates to the View Sale Information screen.

2. The ‘Refund’ button will only be available if all the tickets in the sale are in the status of Valid.

As soon as one ticket in the sale is not in the Valid status it will be grayed out and disabled.

Selecting this button will automatically check all of the checkboxes which are currently not

checked.

3. Selecting the ‘Refund’ button will display a popup window with the following information:

Popup Type Info

Heading Sale Refund Reason

Message Please enter a reason for the refund.

Dropdown List A list of all the refund reasons saved will be displayed in this dropdown list. This list will be maintained under the Administration tab.

Button Cancel / Ok

Table 29: Sale Refund Reason Popup Window

a. Selecting the ‘Cancel’ button will close the popup window and perform no further

action.

b. The ‘Ok’ button will be grayed out and inactive until the user selects a reason from the

dropdown list. Selecting this button will display another popup window, which is

detailed below:

Popup Type Info

Heading Confirm Sale Refund

Page 79 of 122

Goliath


Message Are you sure you want to refund sale X for $Y? Please note that once a sale

is refunded it cannot be reversed.

Refund reason: Z

Button Yes / No

Table 30: Confirm Sale Refund Popup Window Details

c. X = sale barcode.

d. Y = total amount of the sale.

e. Z = refund reason captured on the Sale Refund Reason Popup Window.

f. Selecting the ‘Yes’ button will:


ii. Send the refund payment to the payment gateway.

g. If the refund process is successful:

i. The sale will be marked as refunded.

ii. The refund reasoned captured on the Sale Refund Reason Popup Window will be

saved against the refund.

iii. A popup window with following information will be displayed:

Popup Type Info

Heading Sale Refunded

Message The refund was successful and the following refund reason was captured:

X

Button Ok

Table 31: Sale Refunded Popup Window Details

h. X = refund reason captured on the Sale Refund Reason Popup Window.

i. If the refund process is unsuccessful:

i. A popup window with following information will be displayed:

Popup Type Warning

Heading Sale Not Refunded

Message The refund was unsuccessful. Please try again later.

Button Ok

Table 32: Sale Not Refunded Popup Window Details

Page 80 of 122

Goliath


j. Selecting the ‘Ok’ button on any of the above two Refund popup windows will close the

popup window.

4. All refund reasons captured for successful refunds will be viewable through the Payment

Information Popup Window and Credit Card Sale Refund Report.


1. Refunds will only be to the credit card that made the initial purchase.

2. No partial refunds will be allowed.

3. It will be the responsibility of a Goliath manager user to manually verify that the guest

requesting the refund is in fact the guest who made the initial purpose. They will do this by

asking the guest requesting the refund to repeat some of the information displayed on the

Payment Information Popup Window.

6.3.7 MANAGE GUEST TICKET (FR3.7)

A manager user will have the ability to edit the price of the tickets available for purchase through the

Self Service application.


1. The following requirements relate to the Manage Tickets screen below. The user will access

this screen by selecting the ‘Tickets’ tab.

Page 81 of 122

Goliath


Figure 31: Manage Tickets screen

2. All website elements inside the red block are not part of phase 1, the system will be designed

in scalable manner so that the website can easily be added as part of phase 2. This section

has been added to help illustrate what the empty white space on the right will be used for.

3. The three tickets available for purchase on the Self Service application will be added to the

system during development, with the following prices:

a. Adult - $30

b. Child - $20

c. Senior - $25

4. The user will be able to edit prices by updating the price text box. Once they have made any

changes they will need to select the ‘Save’ button pertaining to the channel in order to save

them.

5. If the user removes a price and selects the ‘Save’ button, the application will save a value of 0

against the ticket type as the price.

6. The ‘Price’ field will only accept four numeric characters (not including the decimal point). If

the user attempts to enter a non-numeric character the application will automatically remove

it and replace it with a value of 0.

7. Ticket prices will only be allowed to be captured to 2 decimal places.

8. The ‘Active’ column represents whether the ticket is available for purchase, or not.

GACS username

Phase 2

Indicates selection

Page 82 of 122

Goliath


a. Icon represents that the ticket is active and available for purchase through the

respective application.

b. Icon represents that the ticket is inactive and unavailable for purchase through the

respective application.

i. This will not apply to phase 1 since all three ticket types available through the

Self Service application are required to be active at all times. This functionality

will be used to hide tickets from the website.

9. The user will be able to collapse and un-collapse each channel information by selecting the

and buttons, respectively.

10. Any chances made on this screen will not be saved if the user navigates away from this tab.

11. Any change to ticket prices on this screen will only take effect on the Self Service application

when the terminal re-caches the ticket prices.


1. The names and active status of the ticket types available through the Self Service application

will be locked and therefore not editable (This is due to the limitation of the Self Service

application where language translations will not be editable from the front-end).

2. A full history of any ticket type name and price changes will be stored, as well as the date on

which it was updated and user who made the update. This information will be available on

request through a data extract of the database.

6.3.8 MANAGE GUEST PACKAGE (FR3.8)

For the purpose of this assignment I will not cover this requirement in this document.

6.3.9 MANAGE TICKET AVAILABILITY (FR3.9)

A manager user will be able to configure the quantity of tickets available for sale on the Self Service

application, per a timeslot.


1. The following requirements relate to the Manage Ticket Availability screen below. Please note

that the screen designs provided in this section are wireframes. The final screens will differ

and will match Goliath’s corporate image and brand. The user will access this screen by

selecting the ‘Timeslots’ tab.

Page 83 of 122

Goliath


Figure 32: Manage Ticket Availability screen

2. The timeslots will be static, and will not be editable from the font-end. The timeslots displayed

on this screen will be the same timeslots displayed on the Select Timeslot screen.

3. The user will have the ability to update the amount of tickets available for purchase, per a

timeslot, by updating the amounts in the ‘Available’ columns.

4. The amount displayed in the ‘Available’ column will be the maximum number of tickets which

can be purchased for that particular timeslot. This amount is exclusive of all the tickets which

have been purchased for that timeslot. In other words, where a ticket is purchased through

the Self Service application, the amount displayed for that timeslot on the above screen will

not be reduced.

5. Selecting the ‘New Adjustment’ button will bring up the Adjustment section on the right hand

side of the screen.

a. When this section is displayed, the rest of the elements on the page will be

repositioned closer to one other and shifted to the left in order to make space for the

Adjustment section.

6. The Adjustment section will allow the user to easily update multiple timeslots at once.

a. The ‘Time From’ and ‘Time To’ dropdown lists will contain all timeslots between 9:00

and 22:30.

b. All timeslots will be updated with the value captured in the ‘Amount’ field.

c. The ‘Amount’ field will:

Indicates selection

Page 84 of 122

Goliath


i. Only accept integers.

ii. Only allow 3 digits to be captured.

iii. Allow a negative number to be captured.

d. For example, the user makes an adjustment of -20 tickets for the 13:00 timeslot to

the 17:00 timeslot.

i. The adjustment will include the 13:00 and 17:00 timeslot in the adjustment.

ii. If the current value saved for the 13:00 timeslot is 100, the new value will be

80. This same logic will apply to all the timeslots affected by the adjustment.

7. Selecting the ‘Fill Timeslots’ button will automatically increase the quantity of available tickets,

for all timeslots, to the value of the [MaximumTicketsPerTimeslot] system variable.

8. Selecting the ‘Empty Timeslots’ button will allow the user to quickly reduce the available

tickets for the day to 0. Selecting this button will update the amount in every timeslot to 0.

9. Selecting the ‘Cancel’ button will undo all previous changes made on the screen, up until the

point where the user arrived on the screen, or last selected the ‘Save’ button.

a. The cancel button under the timeslot section will apply to all changes made to the

timeslot section.

b. The cancel button under the adjustment section will hide the adjustment section and

undo all changes made to the adjustment section.

10. The user will be able to collapse and un-collapse each of the three timeslot columns by

selecting the and buttons, respectively.

11. Any updates made on the screen will need to be saved by selecting the ‘Save’ button before

they take effect.

12. Any chances made on this screen will not be saved if the user navigates away from this tab.


1. The maximum amount tickets which can be allocated to a timeslot is 300, as this is the

maximum amount of people which the elevators can safety transport up to the Ironwood

Observation Deck, in one trip.

6.4 MANAGE SYSTEM ADMINISTRATION (FR4)


6.5 ADMIN GUEST (FR5)


6.6 MRI INTEGRATION (FR6)

Page 85 of 122

Goliath


All ticket sale information will be uploaded to MRI through a nightly job. An administrator user will also

have the option to manually kick off the job from the Ironwood Intranet.

6.6.1 AUTOMATIC MRI UPLOAD (FR6.1)

All ticket sale information will be uploaded to MRI through a nightly job scheduled to run at 02:00 AM

EST. The job will include any refunds. An administrator user will also have ability to manually kick off

the job through the Ironwood Intranet under the Administration tab. Where the job fails to run, both

through automatic or manual kickoff, an email notification will be sent. The recipient of this email will be

determined by the email address saved against the [AdministratorEmailAddress] system variable.

All transactions whether sales or refunds will only ever be uploaded once, and will be flagged as

uploaded upon the successful execution of the job. The job will upload all outstanding transaction up to

and including the previous day when executed. Unless the job has failed for more than a day, this

implies that the job will typically upload all of the previous day’s transactions.

If the job has failed, a manual, back-end support investigation will be required to identify and correct

the issue. This will be treated on a case-by-case basis.

Only the following areas of the MRI system will be integrated with:

Journal

Corporate AR

The MRI integration is detailed further in the MRI Integration Specification.

6.7 GACS INTEGRATION (FR7)

All user access and rights will be imported from GACS through a nightly job. An administrator user will

also have the option to manually kick off the job from the Ironwood Intranet.

6.7.1 AUTOMATIC GACS IMPORT (FR7.1)

User access and rights will be imported from GACS through a nightly job scheduled to run at 01:00 AM

EST. Where the job fails to run, both through automatic or manual kickoff, an email notification will be

sent. The recipient of this email will be determined by the email address saved against the

[AdministratorEmailAddress] system variable. The integration will take the form of a cross database

SQL query that will pull new data and update existing data in the local GACS database tables.

Page 86 of 122

Goliath


7 INFORMATIONAL REQUIREMENTS SPECIFICATION

The informational requirements will consist of a number of reports which will be available to users

depending on their GACS access. All reports detailed in this section will be accessed through the

Ironwood Intranet under the Reports tab. The system and reports will be designed scalable so that the

website can easily be incorporated during phase 2.

The following will apply to all reports:

The ability to be exported to browser or Microsoft Excel.

It will not be possible for users to save default report parameters.

All dates will be displayed in the format mm/dd/yyyy.

All negative values will be displayed in parenthesis.

All monetary values will be preceded by a $ symbol.

All filter criteria used to generate reports will be displayed in the report output.

A red asterisk (*) will be used to indicate a field which is mandatory in order for the report to be

generated.

Where a report is generated to browser, it will always be displayed in a new browser window.

All reports exported to browser will have the option to be printed; all reports printed through

this option will automatically be printed in landscape mode.

All reports exported to browser will have the option to be closed by selecting the ‘Exit’ button.

The reports will only read from the database, in other words, no updates can be made through

the reports.

All validation messages will be displayed in a popup window with an ‘Ok’ button to close it.

Access to each report will be governed by the user’s configuration in GACS.

If there are no results where a report is generated, the following text will be displayed in the

report output: ‘There are no results based on the selected report filter criteria.’

For the purpose of designing the system in a scalable manner, the term ‘Channel’ will be

included so that when the website is built (phase 2), the reports will require minimal rework as

the development team would have designed the system with phase 2 in mind.

Below is an example of the how the reports will be structured (Figure 33):

Page 87 of 122

Goliath


Figure 33: Reports screen

7.1 TICKET AVAILABILITY REPORT (IR1)

1. The details of this report are tabulated below (Table 33):

Purpose Used to indicate the quantity of available tickets, per a timeslot, for a

particular day, to the Ironwood Observation Deck; help with forecasting and planning.

Contents, Sequence, Grouping

Date, Quantity, Timeslot, ordered by Timeslot ascending.

Audience Operations Manager

Table 33: Ticket Availability Report Details

2. The report filter criteria are tabulated below (Table 34). Please see Reports screen for a visual

illustration.

Field Name Field Type Description Mandatory Default Value

Date Datepicker The date for which to display ticket

availability.

Yes Today’s date

Timeslot From

Dropdown

list

Contains all timeslots from 09:00 to

22:00 in ascending order.

No 09:00

Timeslot To Dropdown Contains all timeslots from 09:30 to No 22:30

Filter criteria Filter criteria Filter criteria

Indicates selected report

Page 88 of 122

Goliath


list 22:30 in ascending order.

Validation If no date is selected when the user attempts to generate the report, it will

not be generated and the following message will be displayed: ‘Please select

a date before generating the report.’

If the value selected in the ‘Timeslot From’ field is greater than the value

selected in the ‘Timeslot To’ field, the report will not be generated and the

following message will be displayed: ‘The value of the Timeslot From field

cannot be later than the value of the Timeslot To field.’

Table 34: Ticket Availability Report Filter Criteria

3. The output of this report will be as follows (Figure 34):

Figure 34: Ticket Availability Report

4. The quantity of available tickets will be displayed, per a timeslot, for the date selected.

5. Only the timeslots which have been included in the report filter criteria will be displayed in the

report. For example, if the user selects 15:00 for the Timeslot From and 17:30 for the

Timeslot To, only timeslots 15:00 to 17:30 and their ticket availability will be displayed.

6. The timeslots will be displayed in ascending order from top left downwards.

4. For more detail on how the ticket availability will be calculated please see Appendix 4.

Selected filter criteria Selected filter criteria Selected report filter criteria

Page 89 of 122

Goliath


7.2 DAILY SALES REPORT (IR2)

1. The details of this report are tabulated below (Table 35: Daily Sales Report Details):

Purpose 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 ($), Timeslot, ordered by Timeslot, grouped by Ticket Type.

Audience Operational Manager

Table 35: Daily Sales Report Details

For the purpose of this assignment I have not further detailed this report.

7.3 MONTHLY SALES REPORT (IR3)


Purpose Track ticket sales per month; identify busy periods; help with forecasting and planning.


Year, Month, Ticket Type, Quantity, Value ($), Total Quantity, Total

Value ($), ordered by Month descending, grouped by Channel (Website

(phase 2) or Self Service).

Audience Operations Manager, Marketing

Table 36: Monthly Sales Report Details


7.4 CREDIT CARD SALES REPORT (IR4)


Purpose Track, monitor and compare the different types of credit cards used to purchase tickets. Help the Accounting team perform reconciliations tasks.


Credit Card Type, Channel, Sales Tax ($), Channel Total ($), ordered by

Credit Card Type ascending, grouped by Channel.

Audience Operations Manager, Accounting

Table 37: Credit Card Sales Report Details

2. The report filter criteria are tabulated below (Table 38):


Date From Datepicker The date from which to include

credit card sales.

Yes 4 months in

the past

Date To Datepicker The date up until credit card sales No Today’s date

Page 90 of 122

Goliath


should be included.

Channel Single-select

Dropdown list

The source from where the ticket

sale originated.

No All

Credit Card Type

Multi-select

Dropdown list

Contains all credit card types

available through the system. As

configured under the

Administration section.

No All

Validation If no ‘Date From’ is selected when the user attempts to generate the report,

it will not be generated and the following message will be displayed: ‘Please

select a ‘Date From’ value before generating the report.’

If the value selected in the Date To field is greater than the value selected

in the Date From field, the report will not be generated and the following

message will be displayed: ‘The value of the Date From field cannot be later

than the value of the Date To field.’

Table 38: Credit Card Sales Report Filter Criteria


Figure 35: Credit Card Sales Report

Page 91 of 122

Goliath


4. All refunds which take place will be deducted from the sales total. For example, if two sales

occur for $50 and $25 respectively, the Credit Card Sale Report will display $75 as the total.

However, if the sale for $25 is refunded the total displayed in the report will be $50.

7.5 CREDIT CARD EXCEPTION REPORT (IR5)


Purpose 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

Audience Operations manager

Table 39: Credit Card Exception Report Details


7.6 CREDIT CARD REFUNDS REPORT (IR6)


Purpose 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.

Contents, Sequence,

Grouping

Date, Guest Name, Refund Reason, Credit Card Type, Refund Value ($),

Refund Percentage (%), Total ($), ordered by Credit Card Type

ascending.


Table 40: Credit Card Refunds Report Details

7.7 ADVANCED SALES MOVEMENT REPORT (IR7)


Purpose 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, Cancelled,

Expired).

Audience Operations Manager, Marketing

Table 41: Advanced Sales Movement Report Details


7.8 GUEST LANGUAGE REPORT (IR8)


Page 92 of 122

Goliath


Purpose Identify the most popular languages.


Date, Channel, Language, Total Sales, ordered by Date descending,

grouped by Language Selected.

Audience Marketing

Table 42: Guest Language Report Details


7.9 MRI UPLOAD AUDIT REPORT (IR9)


Purpose Ensure all transactions have been successfully uploaded to MRI.


Date, Total Sales Income Uploaded, MRI Journal Account Number,

ordered by Date descending.


Table 43: MRI Upload Audit Report Details


7.10 MRI RECONCILATION REPORT (IR10)


Purpose Compares transactions in MRI and the Ironwood Ticket System and

identifies any discrepancies.

Contents, Sequence,

Grouping

Date, Discrepancy, MRI Journal Account Number, Total Discrepancy for

Period, ordered by Date descending

Audience Operations Manager, Accounting, IT Manager

Table 44: MRI Reconciliation Report Details


7.11 SYSTEM VARIABLES AUDIT REPORT (IR11)


Purpose Keeps a record of all 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.

Audience Operations Manager, IT Manager

Table 45: System Variables Audit Report Details

2. The report filter criteria are tabulated below (Table 46):

Page 93 of 122

Goliath



Date From Datepicker The date from which to include any

updates to system variables.

Yes 3 months in

the past

Date To Datepicker The date up until any updates to

system variables should be included.

No Today’s date

System Variable

Multi-select

Dropdown

list

Contains all system variable names,

listed in alphabetically order.

No All

User Multi-select

Dropdown

list

Contains all usernames, alphabetical

order, who have ever updated a

system variable.

No All

Validation If no ‘Date From’ is selected when the user attempts to generate the report,

it will not be generated and the following message will be displayed: ‘Please

select a Date From value before generating the report.’

If the value selected in the ‘Date To’ field is greater than the value selected

in the ‘Date From’ field, the report will not be generated and the following

message will be displayed: ‘The value of the Date From field cannot be later

than the value of the Date To field.’

Table 46: System Variables Audit Report Filter Criteria

3. The ‘Date To’ value will default to today’s date, if none is selected when the report is

generated.


Page 94 of 122

Goliath


Figure 36: System Variables Audit Report

5. If the same system variable is updated twice, each update will be listed and displayed in a

separate row.

Page 95 of 122

Goliath


8 NON-FUNCTIONAL REQUIREMENTS SPECIFICATION

The following non-functional requirements for the solution have been identified:

For the purpose of the FTI assignment, only a sample of the non-functional requirements has been

specified.

8.1 LEGISLATION (NFR1)

1. PCI Compliant: The system must be compliant with the Payment Card Industry Data Security

Standard (PCI DSS) (NFR1.1).

2. ADA Compliant: The system must comply with the Americans with Disabilities Act (ADA) –

(NFR1.2).

8.2 SCALABILITY (NFR2)

1. The system must be able to handle a 100% increase in the volume of ticket sales per a year,

for the first 10 years.

8.3 PERFORMANCE (NFR3)

1. System Response Time: The system response time must not exceed 5 seconds for any

transaction and 10 seconds for any report request (NFR3.1).

2. Clustered Web Hosting: The system must make use of a web cluster to spread the load

between servers and provide automatic failover protection should one server suffer failure.

(NFR3.2). For more information on this requirement refer to the Technical Architecture

section.

3. Concurrency: The system must be able to handle up to 500 users simultaneously executing

the same request. The system will automatically queue and action simultaneous requests on a

first-in first-out basis (NFR3.3).

4. Load: The system must be able to handle up to 50,000 users using the system at the same

time (NFR3.4).

5. Blocked Process: The system must immediately notify the system administrator if any

database deadlocks are occurring. The notification must contain the details of where the lock is

occurring and what it is affecting in the database (NFR3.5).

6. The MRI upload job must not take longer than 5 minutes to complete (NFR3.6).

7. The GACS import job must not take longer than 2 minutes to complete (NFR3.7).

8. The Self Service application must cache system information to increase performance, where

possible (NFR3.8).

8.4 AVAILABILITY (NFR4)

1. The system must be available for ticket sales 16 hours a day, 7 days a week, 365 days a year.

This excludes the time for standard maintenance work during the 1:00 AM and 6:00 AM EST.

This must be included in the SLA (NFR4.1).

Page 96 of 122

Goliath


2. The Ironwood Intranet must be accessible through the Internet Explorer (version 11+) and

Google Chrome browser types (NFR4.2).

3. All system maintenance, with the exception of emergency maintenance, must occur between

1:00 AM and 6:00 AM EST. This must be included in the SLA (NFR4.3).

4. Data replication must occur every 15 minutes from the primary to the secondary database

server. The replication database must be located in a different building which is at least 10

miles away (NFR4.4). For more information on this requirement refer to the Technical

Architecture section.

5. It must be possible to recover the system after a large scale-disaster in approximately 3 days

(NFR4.5).

6. Restoration of data within one business day must be the recovery objective when restoring

data upon system recovery. The recovery objective is 2 to 3 hours (NFR4.6).

7. In the event the system goes down, a notification must be sent to the IT support team

(NFR4.7). This email address will be provided to the development team when the system is

deployed to the UAT environment.

8. All informational reports detailed under section 6 must be available in a CSV format when

exported to Excel (NFR4.8).

9. All informational reports detailed under section 6 must have the ability to be printed; they

must be printed in landscape mode by default (NFR4.9).

8.5 AUDITABILITY (NFR5)

1. Any change made to any administration feature must be recorded in the database and must

include the date, time, user-id and details of change (NFR5.1). Some of this information will

be available from the front-end, for example the System Variables Audit Report. However,

information pertaining to any system update must be able to be extracted from the audit

tables within the database; this would happen on request.

2. Any system error experienced by an employee user must be recorded in the database,

containing the timestamp, error description, area of system and user-id. If an error is

experienced by a guest, they must have the option to email the error to a system

administrator (NFR5.2).

8.6 USABILITY (NFR6)

1. Effective Navigation: Users must be provided with consistent, comprehensive and usable

navigation aids (NFR6.1).

2. Accessibility: The system must comply with the Web Accessibility Initiative (WAV) and most

human interface guides, where possible (NFR6.2).

3. Onsite Touch Screens: The Self Service application must be designed to run on touch screen

devices (NFR6.3).

Page 97 of 122

Goliath


4. The Self Service application must be available in the following languages: English, Spanish,

French and German (NFR6.4). For more information on how the language translations should

be stored and sourced, please refer to Appendix 3.

5. User Documentation: The system must provide all users with documentation to assist them

achieve their desired outcome. A training manual for the Ironwood Intranet must be available

by selecting the ‘Help Manual’ tab (NFR6.5).

8.7 RELIABILITY (NFR7)

1. Acceptable Error Rate: The system must not experience more than 0.001% of its total

transactions in error.

8.8 SECURITY (NFR8)

1. Lockdown Self Service Application: When the application is open, guests must not be able to

close it or perform malicious activities. SiteKiosk will be purchased from Provisio Software

Engineering to lockdown the terminal (NFR8.1).

2. Transport Layer Security (TLS) Certificate: All sensitive information, such as credit card

details, must be encrypted when it travels between the client, webserver, payment gate way

and PayPal using the latest, industry standard TLS 1.2. Outdated security protocols and

cyphers will be disabled on all servers to ensure these are not available to be used for

communication (NFR8.2).

3. User Authentication: Only authenticated users must be granted access to the Ironwood

Intranet and admissions site. Users must be required to enter their GACS credentials when

they attempt to access the sites (NFR8.3). Please refer to FR3.1 for more information.

4. Hide User Passwords: All passwords must not be displayed in a readable format on any

application screen. Passwords must not be captured in audit logs and must be stored in an

encrypted format in the database (NFR8.4).

5. System Timeout: All sessions on the Ironwood Intranet and admissions site must expire after

15 minutes of user inactivity, and the user must be forced to re-login. The Self Service

application must expire after 3 minutes of user inactivity (NFR8.5).

6. System Firewall: All incoming traffic into the Ironwood network must pass through its firewall

(NFR8.6).

8.9 TECHNOLOGY (NFR9)

1. The Self Service application must be able to integrate with the printer and credit card device

listed in the Technical Architecture section (NFR9.1).

2. The mobile PDA device used by the admissions clerk to scan the tickets must be able to

connect to the network over wireless in order to inform the system that tickets have been

used. This device is listed under the Technical Architecture section (NFR9.2).

Page 98 of 122

Goliath


9 BUDGETING AND RESOURCING

This section details all the costs involved in the full systems development life cycle. A summary of all the costs are tabulated below (Table 47):

Project Costs Amount

Hours Logged Against Project So Far – 350 hours $28,000

Development Costs $151,292

Hardware Costs $120,000

Training $9,600

Total Once-off Project Costs $308,892

Table 47: Project Costs Summary

For a more detailed breakdown and explanation of each cost please see the corresponding sections below.

9.1 FINANCIAL COSTS AND TIME BREAKDOWN

The estimated further project costs are detailed in this section. Please note the figures are estimates

and may differ from the actuals as the project progresses. As per the project scope, the cost and

estimates will be revisited on a regular basis and continuously presented to the relevant stakeholders

for review.

The hourly rate of $80 used in this section is the agreed upon figure as per discussions with the human

resources department; this rate has also been sign-off on by senior management. The rate is an

average based on the varying levels of expertise from within the projects team.

9.1.1 DEVELOPMENT COSTS

The estimates of all sub requirements are rolled up into the main requirements and are measured in

man hours. The estimates tabulated below are all-encompassing and include time for all activities and

tasks involved in developing and implementing the requirements, such as database design, writing test

cases, functional specification and waiting on feedback from stakeholders.

The implementation estimates include time for all deployments, UAT, environment setup and

configuration. The project management estimates are calculated at 35% of the total estimates for each

phase, as per Goliath’s policy. Please note the figure is 35% because all time logged for the weekly and

ad-hoc project update meetings are logged against project management. A project contingency range

driver of 10% has been applied, as per Goliaths standard recommendation for a project at this stage in

the development life cycle.

The detailed breakdown of the development costs are tabulated below (Table 48):

Req ID Requirement Name Analysis Design Develop Test Total

FR1.1 Perform Pre-tickets Sale Functions 1 1 35 15 52

FR1.2 Select Guest Language 1 2 40 20 63

FR1.3 Select Ticket Type and Quantity 1 2 35 10 48

FR1.4 Upgrade Ticket To Package 1 1 10 3 15

FR1.5 Select Ticket Timeslot 4 4 85 40 133

FR1.6 Confirm Ticket Sale 1 1 8 3 13

Page 99 of 122

Goliath


FR2.1 Insert/Remove Credit Card 0.25 1 15 4 20.25

FR2.2 Capture Guest Signature 2 2 5 5 14

FR2.3 Process Credit Card Payment 1 1 15 3 20

FR2.4 Print Sale Ticket 0.25 2 15 8 25.25

FR3.1 Login to Ironwood Intranet 0.25 0.25 10 2 12.5

FR3.2 View Ticket Sale 1 2 20 5 28

FR3.3 Cancel Ticket Sale 0.25 1 5 3 9.25

FR3.4 Reprint Ticket Sale 0.25 1 7 3 11.25

FR3.5 Refund Ticket Sale 0.5 1 8 3 12.5

FR3.6 Manage Guest Ticket 1 1 15 5 22

FR3.7 Manage Guest Package 1 1 5 2 9

FR3.8 Manage Ticket Availability 3 2 20 8 33

FR4.1 Manage System Variable 0.5 1 20 8 29.5

FR4.2 Kick-off Manual Process 0.5 0.25 2 3 5.75

FR4.3 Restart Self Service Application 0.5 0.25 5 2 7.75

FR5.1 Scan Ticket 1 2 10 4 17

FR5.2 Validate Ticket 0.5 1 4 2 7.5

FR5.3 Update Ticket Status 0.5 0 3 2 5.5

FR6.1 Automatic MRI Upload 0.5 0.25 15 2 17.75

FR6.2 Automatic GACS Import 0.5 0.25 10 2 12.75

IR1 Ticket Availability Report 1 1 10 8 20

IR2 Daily Sales Report 1 2 10 5 18

IR3 Monthly Sales Report 1 3 10 5 19

IR4 Credit Card Sales Report 1 3 10 5 19

IR5 Credit Card Exception Report 1 3 10 5 19

IR6 Credit Card Refunds Report 0.5 1 8 4 13.5

IR7 Advanced Sales Movement Report 1 5 15 8 29

IR8 Guest Language Report 0.5 3 8 4 15.5

IR9 MRI Upload Audit Report 0.5 3 8 4 15.5

IR10 MRI Reconciliation Report 0.5 2 8 4 14.5

IR11 Systems Parameters Audit Report 1 1 8 5 15

NFR1 Legislation 1 2 20 6 29

NFR2 Scalability 1 2 16 15 34

NFR3 Performance 2 1 20 20 43

NFR4 Availability 1 2 10 15 28

NFR5 Auditability 1 1 10 10 22

NFR6 Usability 2 2 12 15 31

NFR7 Reliability 1 4 10 15 30

NFR8 Security 1 1 25 15 42

NFR9 Technology 1 0 40 40 80

Implementation 20 10 60 15 105

Sub Total 62.25 81.25 745 385 1273.5

Project Management (35% of phase) 22 28 261 135 446

Contingency Range Drive 8 11 101 52 172

Phase Total (hours) 92 121 1106 572 1891

Total Development & Implementation Cost + Contingency (hours * $80)

$7,395 $9,653 $88,506 $45,738 $151,292

Table 48: Development & Implementation Costs

The figures provided in the above columns are displayed in hours, with the exception of the last row

which is displayed in dollars.

Page 100 of 122

Goliath


9.2 OTHER RESOURCING ISSUES

Other resourcing issues include all costs besides the development and implementation costs which are

required for this project.

9.2.1 HARDWARE COSTS

Two clusters will be required consisting of two web servers and a database server in each. Due to the

nature of the product, the database servers will need to be powerful in order to handle the expected

usage. The cost of the hardware required for the project is tabulated below (Table 49):

Hardware Costs Cost Quantity Total

Web Server $10,000 4 $40,000

Database Server $15,000 2 $30,000

Additional Infrastructure1 $50,000 - $50,000

Total Hardware Cost $120,000

Table 49: Hardware Costs

9.2.2 TRAINING

In order to get the Goliath employees familiar with the system a month of training has been estimated.

The decision was made to include training within the scope of this project. It has therefore been

included on the Project And Implementation plan. An hourly rate of $60 has been used, which is an

average of the varying employees hourly rates involved in this system.

160 hours * $60 = $9,600

1Includes all costs such as network cables, switches, routes, and touch screen devices for the Self Service application, mobile and wireless PDAs for admissions and workstations for project team.

Page 101 of 122

Goliath


10 SYSTEM RISKS AND CONTROL REQUIREMENTS

This section details any risks to the project and formulates contingency plans to help mitigate them.

10.1 RISK IDENITIFCATION AND PROFILE

In order to build a risk profile for this project the following risks, along with their probability, impact and

factor have been tabulated below (Table 50):

No. Risk Probability Impact Factor7

1 Requirements are not accurate or clearly defined 3 9 27

2 Project team misunderstand requirements 3 7 21

3 Learning curves lead to delays and cost overrun 4 4 16

4 Lack of resources, expertise or experience 3 7 21

5 Low team motivation 1 7 7

6 Loss of key resources before the end of the project 2 7 14

7 Lack of key stakeholder buy-in 2 8 16

8 The scope of the project is not clearly defined 6 8 48

9 Scope creep 7 7 49

10 Loss of potential revenue due to business interruption 2 4 6 7 12 28

11 Lack of a change management process 1 8 8

12 Estimates are incorrect which affected timelines 7 8 56

13 Project cost is under estimated 6 8 7 8 42 64

14 Benefits are over estimated 5 7 35

15 Delay on data provision 5 8 40

16 Slow turnaround on stakeholder review 6 7 6 7 36 49

17 Environment not PCI DSS compliant 4 9 36

18 Architecture is infeasible 4 7 28

19 Failure to integrate with systems 2 8 16

20 Delays to required infrastructure 3 6 18

21 Lack of thorough UAT 6 7 42

22 Design is not fit for purpose 6 9 54

23 Solution delivered is of a low quality 4 10 40

24 Solution negatively affects reputation 4 10 40

25 Employees do not know how to use the new system 3 7 21

Table 50: Project Risks

7Calculated by: probability * impact.

Page 102 of 122

Goliath


The project risks are continuously reviewed and discussed during the weekly project management

meeting. It has been found that since the creation of the business document, as indicated in the

Projects Risk table above, the probability and impact of the following three risks have changed:

Loss of potential revenue to business interruptions.

o More business users than originally expected were required during the analysis phase of

this project. The sessions including the business users have also been taking more time

than originally estimated. Based on this trend, the probability and impact of this risk has

been adjusted accordingly.

Project cost is underestimated.

o As the requirements have been unpacked further during the analysis phase and the

creation of this document, more work and a higher level of complexity has been

uncovered. This has led to an increase in the estimates, and therefore an increase in the

cost of the project. Based on this, the probability and impact of this risk has been

adjusted accordingly.

Slow turnaround on stakeholder review.

o There has been a slow turnaround from a number of stakeholders with regards to the

review and sign-off on project artifacts. Unfortunately many of them were heavily

involved in last year’s end of quarter budget reforecasting which occupied most of their

time over. Since it appears that there were some issues with the budget reforecasting,

it’s likely they will need to be roped in again. Based on this, the probability and impact

of this risk has been adjusted accordingly.

Meetings have since been held to discuss the above changes to the risks. The business analyst, project

manager and project sponsor were included in these meeting. The new mitigation strategies that were

formulated from these meetings are documented in the risk containment plan below.

10.2 RISK CONTAINMENT PLAN

The risk containment plan includes preventative measures which can be taken to avoid the risks listed

in the section above, or at the very least reduce their impact should they occur.

No. Risk Preventative And Mitigation Strategy

1 Requirements are not

accurate or clearly defined

A senior business analyst will be used for this project; their work will be

reviewed by another senior business analyst. Review sessions will be held with

stakeholders to go over requirements. Stakeholders will sign-off on

requirements. If any key requirements are missed they should be estimated

and amended into the project plan. If they have a significant impact on the

project schedule, additional resources may be added to the projected, other

work can be scoped out or they can be handled by the change management

process. This decision will be made by the project manager in conjunction with

key stakeholders, and will be communicated to all stakeholders timeously.

2 Project team

misunderstand

requirements

A senior business analyst will be used for this project; their work will be

reviewed by another senior business analyst. The entire projects team will be

involved in the project from the analysis phase to increase their

understanding, both at an individual level and a team level. The projects team

will sit together allowing quick and easy collaboration. Developers will demo

their work to the team on a weekly basis.

Page 103 of 122

Goliath


3 Learning curves lead to

delays and cost overrun

Sufficient time will be allocated to the development team to skill up on any

technologies and devices they have not used before. This time will be allocated

to developers before development actually starts (analysis phase), this will

allow to them to run through proof of concepts.

4 Lack of resources,

expertise or experience

A senior business analyst and senior project manager will be used for this

project. In the development team at least half of the team will consist of

senior developers; the other half will be spread between intermediate and

junior. All work will be reviewed by seniors. Resources from outside Goliath

will be brought in if required.

5 Low team motivation This is a big and exciting project different to the usual Goliath projects; it

should be easily for the project manager and business analyst to excite the

team. All team members will discuss and agree on the sections they will

complete, so that members are not stuck will the ‘boring’ work. Set clear goals

for the team and offer incentives for diligent work.

6 Loss of key resources

before the end of the

project

Ensure team’s annual leave is booked well in advanced to help plan around.

Involve human resources to help identify any members which are currently not

happy and demonstrate signs of leaving. Create strong team dynamics further

encouraging members not to abandon each other. Ensure everything is well

documented in order to maintain continuity should a resource leave.

Encourage transparency and collaboration amongst team to prevent

knowledge silos.

7 Lack of key stakeholder

buy-in

Application demos to ensure stakeholders are part of the journey. Weekly

meetings with stakeholders to keep them updated and encourage meaningful

dialog, which will also allow any issues to be picked up and addressed sooner.

8 The scope of the project is

not clearly defined

Senior business analyst will run scoping meetings to ensure stakeholders all

agree and sign-off on the scope. Document scope deviations and present to

stakeholders for their review and approval.

9 Scope creep The scope of the project will be clearly defined and sign-off by stakeholders;

deviations from the scope will be handled by Goliath’s change management

process.

10 Loss of potential revenue

due to business

interruption

Since a new business unit and system which currently does not existing within

Goliath is being developed, there should not be any major interruptions to

existing staff. Budget and time has been set aside for any training required;

business will be made aware of this well in advanced in order to plan around

it.

11 Lack of a change

management process

Goliath’s change management process will be strictly enforced.

12 Estimates are incorrect

which affected timelines

Estimates will be revised at each phase in the systems development lifecycle.

All estimates will be reviewed. Contingency will be added appropriately

depending on the phase of the project.

13 Project cost is under

estimated

Emergency budget will be set aside for worst case scenario. Project costs will

be revised at each phase of the project and communicated to stakeholders,

any significant changes addressed and dealt with by the project manager and

key stakeholder. A contingency buffer will be added to help account for any

hidden costs. The project has also been broken up into two phases to help

reduce the initial cost required.

14 Benefits are over

estimated

The benefits have been heavily under estimated which decreases the likelihood

of them being over estimated. Additional budget can be assigned to the

project to maintain it until it breaks even.

Page 104 of 122

Goliath


15 Delay on data provision The date on which the system data is due will be clearly and regularly

communicated to relevant stakeholders. The project team will be made

available to assist stakeholders if they require help. The data required will be

broken up per a section which will each have its own deadline. This will help

manage the workload by ensuring parts of the data are completed earlier on,

rather than leaving it all to the last moment. The due date will be brought

forward a week to create a week of contingency, should the stakeholders fail

to make the deadline.

16 Slow turnaround on

stakeholder review

A project escalation line will be established so that the project team can

escalate stakeholders who continuously have slow turnaround. Deliverable

dates will be clearly and communicated in weekly meetings. The effect of slow

stakeholder turnaround on the project schedule will be emphasized.

Contingency time will be added.

Due to other commitments and responsibilities of a number of the

stakeholders, a number of them have been replaced with new representatives

who have available capacity to execute on the project tasks. Meetings with the

managers of the stakeholder representatives were held to discuss their current

workload and to make special arrangements for the project work.

17 Environment not PCI DSS

compliant

Allocate sufficient time for projects team to familiarize themselves with the

requirements of PCI DSS. Get external party who specialize in PCI DSS to

review proposed architecture design of the system.

18 Architecture is infeasible Architecture will be reviewed by senior resources outside of the projects team

including the Ironwood Building’s IT department.

19 Failure to integrate with

systems

Although the impact of this risk is high, the probability of it occurring is low;

Goliath has successfully completed many integration projects with MRI and

GACS. Resources and work from previous projects can therefore be used or

consulted with to reduce the likelihood of this risk occurring. Goliath will

become a merchant with PayPal and if needed can receive assistance from

them.

20 Delays to required

infrastructure

A schedule will be developed for the infrastructure acquisition, setup and

configuration; hard deadlines will be enforced. Contingency time will be added.

Backup plans will be made for any hardware issues, such as vendor fails to

provide touch screens for Self Service application in time.

21 Lack of thorough UAT User stories and test cases written by the business analyst will be given to

stakeholders to assist them in their testing; the UAT dates will be clearly and

regularly communicated. The UAT process will be made as effortless as

possible for stakeholders by providing them with the correct links to the

applications and a platform for them to log and query issues. Public users will

be invited to perform testing.

22 Design is not fit for

purpose

All documents will be signed-off. Application demos will be given to

stakeholders; feedback will be incorporated. Significant time will be spent on

the non-functional requirements. Public will be invited to perform testing and

encouraged to give meaningful feedback.

23 Solution delivered is of a

low quality

The project will adhere to Goliath’s quality assurance process.

24 Solution negatively affects

reputation

Public will be invited to perform testing and encouraged to give meaningful

feedback. The results from the post visit surveys which are sent out will be

analyzed to help identify the main areas of concern guests have with the

system. The marketing and public relations team will perform a damage

control exercise; reaching out to guests who have had a bad experience and

offer compensation in the form of gift vouchers.

25 Employees don’t know how

to use the system

A parallel training project will be run. A help manual will be completed as one

of the deliverables. Resources will always be available to assist as the project

will be built in-house.

Table 51: Risk Containment Plan

Page 105 of 122

Goliath


11 PRODUCT QUALITY ASSURANCE

In order to ensure the final product is of the highest quality and satisfies all requirements, quality

assurance will be enforced throughout the lifecycle of the project and will be the responsibility of the

team and not only the testers. The phases of the systems development life cycle are listed below along

with the tasks and processes which have been, and will be, performed at each phase to improve quality.

Analysis / Design

All interviews and review sessions will be recorded and replayed to ensure nothing is missed or

over looked. This will also allow the analyst to focus more on listening and asking the right

questions, over having to scribe or take notes.

Sufficient time will be given to stakeholders to review documentation and artifacts.

All deliverables throughout the lifecycle of the project to be signed-off by relevant stakeholders.

The business analyst will work with web designers to help design screens from which the

developers can work off.

All documentation will be stored on Goliath's repository (SharePoint).

Development

The development team will be given sufficient time to familiarize themselves with the hardware

(printers, credit card devices).

User stories will be written by the business analyst which will help the developers more easily

understand the requirements and implement Test Driven Development.

Sufficient time will be allocated to developers to build in unit tests.

Weekly team meetings will be held to ensure development is on track to meet milestones.

All developers will perform a certain level of testing before they deploy their work to the testing

environment.

Developers will review each other’s code on a weekly basis.

Developers will demo their work to the testers and the business analyst before they deploy their

work, this will help identify any bugs, cosmetic issues or missing requirements earlier on. This

will reduce the amount of deployments required which will save time.

All deployments will follow Goliath’s strict deployment process. This includes, but is not limited

to the following, database backups, data integrity, source control and post-deployment testing.

Developers will ensure all coding conforms to industry best practices and internal coding

standards.

All changes requested that deviates from the signed–off requirements will be subjected to

Goliath’s change control process.

fake%20link%20to%20Goliath's%20SharePoint

Page 106 of 122

Goliath


Separate and independent environments so that development and testing can occur

simultaneously. The following environments will be setup:

o Development

o Testing

o Staging (UAT).

o Production

Testing

User stories written by the business analyst will be used by the testers to validate that the

product is functioning according to user expectations and satisfies the core requirements.

The business analyst will also compile a comprehensive list of initial test scenarios which he, in

conjunction with the quality assurance analyst, will use to validate the success of the

development work. For a list of these test scenarios please refer to Appendix 5.

Integration testing: Ensure all applications involved in the project are able to communicate and

perform the necessary tasks for one another.

Functional testing: Ensure the solution meets all the requirements as detailed in the functional

specification.

Public testing: Members of the public will be invited to play with and use the Self Service

terminals. Their interactions and experience with the application will be recorded and reviewed

by the business analyst.

Extensive user experience and interface/cosmetic testing will be performed on the Self Service

application.

Automated user interface tests; these automated tests will be run after each deployment to

ensure no completed work is broken.

Significant performance testing will be performed as the product is expected to handle a large

amount of users. The following performance testing techniques will be used:

o Stress: Find the systems breaking point and ensure its far exceeds its expected use.

o Load: Ensure the system can handle a large amount of users and a substantial level of

concurrent user requests.

o Volume: Ensure the system can handle large amounts of data.

o Soak/Endurance: Ensure the system can sustain the continuous expected load over a

period of time.

o Spike: Ensure the system can handle a sudden increase in load generated by a large

number of users.

Significant security testing will be performed as the product deals with money and sensitive

information such as credit card numbers. The following security testing techniques will be used:

Page 107 of 122

Goliath


o Injection

o Broken Authentication and Session Management

o Cross-Site Scripting (XSS)

o Insecure Direct Object References

o Security Misconfiguration

o Sensitive Data Exposure

o Missing Function Level Access Control

o Cross-Site Request Forgery (CSRF)

o Using Components with Known Vulnerabilities

o Un-validated Redirects and Forwards

Tools will be used to help perform the automated user interface testing, performance testing

and security testing, where possible.

Weekly testing review sessions to discuss testing strategy, approach, use of tools and for

testers to review each other’s work.

Team collaboration: The entire projects team will sit near each other and work as a cohesive

unit; team members will not work in isolation and will avoid knowledge silos using Goliath’s

existing processes.

All test cases and checklists will be created and stored in Goliath’s Team foundation Server

(TFS).

All issues found by the testers will be logged to TFS.

User Acceptance Testing (UAT)

The Staging environment, used for UAT, will mimic the production environment in terms of

hardware and network infrastructure to help prevent any unforeseen issues only replicable on

the production environment.

High level smoke tests will be performed by the testers and business analyst once the product is

deployed to the UAT environment and before the stakeholders begin their testing.

The user stories written by the business analyst will be used by stakeholders to help them

perform their testing.

Training sessions will be given to the employees who will be using the Ironwood Intranet.

Production

High level tests will be performed by the testers and business analyst once the product is

deployed to the production environment. This includes creating, completing and then refunding

four sales using the four different credit cards which are accepted by the system.

Page 108 of 122

Goliath


The tickets which are printed from the above sales will be reviewed and scanned by the

admissions clerk to ensure that guests can gain access to the observation deck.

Post Implementation

Project review; determine what went well and what can be improved for the next project.

Lessons learnt will help improve quality of future projects.

Developer handover session; the developers from the project team will hand over the project to

a supports team. This will include a demo of the front-end, backend, integration points and a

technical document containing any quirks or important things to know.

Page 109 of 122

12 PROJECT AND IMPLEMENTATION PLAN

Phase 1 of the project has been broken down and split between the different function, non-functional and informational requirements. The

project plan is outlined below (Figure 37: Project Plan):

Figure 37: Project Plan

Page 110 of 122

Goliath


Please note that the above project plan illustrates the project duration, and not the effort required. For

a breakdown of the effort required for each requirement please refer to the Financial Costs And Time

Breakdown section.

The development team will consist of three developers, two quality assurance analysts and a project

manager. The work will be split between the team, allowing for different sections of the project to be

worked on concurrently. Once each requirement has been developed it will be integrated within the

main solution. This will prevent the need for one long and complicated solution integration exercise

towards the end of development phase.

The business analyst will be available during the development cycle of the project to assist with any

items which require Change Management, handle general queries that the development team may

have, assist with testing, and facilitate the UAT process. A one week buffer has been included in the

project plan, week 13. This week will allow the development team to deal with any unforeseen issues.

The training required will run concurrently during the UAT phases. As depicted above, the current

estimated go-Live date for phase 1 is scheduled for the 1st of July, 2016. This is in line with the terms of

reference of this project.

Once the project is developed to the Live environment the business analyst and development team will

monitor the solution and handle any issues that may arise.

Please note that the timeline above is subject to change and will be continuously monitored by the

project manager. Any issues which affect the timeline significantly will be discussed with the

stakeholders. The project manager will be responsible for keeping track of the project progress and will

provide weekly updates to the stakeholders.

Page 111 of 122

Goliath


APPENDIX 1 - GLOSSARY

The following is a list of industry/company specific jargon, acronyms and definitions (Table 52):

Term Definition

[] Denotes a system variable. System variables are a set of dynamic named values that can affect the

way running processes will behave on a computer.

ADA The Americans with disabilities Act (ADA) is a wide-ranging civil rights law that prohibits

discrimination based on disability.

AD Microsoft Active Directory, used to manage user accounts and integrated with GACS.

EST Eastern Standard Time.

GACS Global Access Control System (GACS), this is an existing application that is used by Goliath to

administer access and user rights across a number of applications.

GAAP The standard framework of guidelines for financial accounting used in any given jurisdiction;

generally known as accounting standards or standard accounting practice.

Guest /

User

Throughout this document the terms ‘Guest’ is used to refer to members of the public who will be

the day-to-day users of the application, whereas the term ‘User’ refers to Ironwood management

and administrative staff.

MRI Management Reports International (MRI) is an existing accounting package used by Goliath. It is

envisaged that this will be used as the primary accounting package for the solution.

MVC The ASP.NET MVC is an open source web application framework that implements the model–view–

controller (MVC) pattern.

PayPal PayPal Holdings, Inc. is an American company operating a worldwide online payments system.

Online money transfers serve as electronic alternatives to traditional paper methods like checks and

money order.

PCI DSS The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security

standard for organizations that handle branded credit cards from the major card schemes including

Visa, MasterCard, American Express, Discover, JCB, and China UnionPay.

‘Previous

Timeslot’

This term refers to the timeslot which is currently being used by guests to experience the view from

the top of the Ironwood Building. The ‘previous timeslot’ will always be the timeslot where the

current time falls into. For example, if the current time is 18:23, the ‘previous timeslot’ will be the

18:00 – 18:30 timeslot. Or, if the current time is 10:04, the ‘previous timeslot’ will be the 10:00 –

10:30 timeslot. It will not be possible to purchase tickets for the ‘previous timeslot’, unless it is

earlier in the day, but then at that point the timeslot will not be classified as the ‘previous timeslot’.

SiteKiosk A kiosk software application used to secure public access computers as well as information and Internet terminals.

Sold Out Where there is zero available ticket capacity for the rest of the day.

Standard

Operating

time

The standard operating time of the Service terminals will be from 07:00 to 23:00, 7 days a week.

System

‘Down’

The system is down due to errors within the solution. This excludes system down time for all

maintenance work such as deployed during the maintenance window, 1:00 AM to 06:00 AM EST.

https://en.wikipedia.org/wiki/Value_(computer_science)

https://en.wikipedia.org/wiki/Computer_process

https://en.wikipedia.org/wiki/Financial_accounting

https://en.wikipedia.org/wiki/Standard_accounting_practice

Page 112 of 122

Goliath


UAT User Acceptance Testing (UAT) - also called beta testing, application testing, and/or end user testing

- is a phase of software development in which the software is tested in the ‘real world’ by the

intended audience or a business representative.

Table 52: List of Definitions

Page 113 of 122

Goliath


APPENDIX 2 - DATA DICTIONARY

The following is the data dictionary that supports the Entity Relationship Diagram for the Ironwood

Observation Deck Ticketing System. Please Note that for the purposes of this FTI assignment, only a

few of the data entities have been placed into the data dictionary.

Entity Name

Description Attributes Data Type Example Mandatory

Sale A guest makes a sale which consists of a number of tickets and packages.

SaleID (PK) PaymentID (FK) ChannelID (FK) SelfServiceTerminalID (FK) SaleDate Total IsComplete

Int(8) Int(8) Text(20) Int(10) Smalldatetime(16) Money(30) Text(3)

87578976 43253256 Self Service 4 08/02/2016 210.00 Yes

Yes No Yes Yes Yes No Yes

Ticket A ticket is of a certain type with a certain price allocated to it.

TicketID (PK) TicketPriceAllocationID (FK) TicketTimeslotAvailabilityID(FK) TicketStatusAllocationID (FK) PackageTypeID TicketDate

Int(10) Int(10) VarChar(5) VarChar(2) Int(10) Smalldatetime(16)

7863223435 4688765323 115 2 65545654 08/02/2016

Yes Yes Yes Yes Yes Yes

TicketStatus

Used to help categorize a

ticket so that the system may apply rules to it.

TickeStatustID (PK) TicketStatusName

TicketStatusDescription Date

Int(2) Text(15)

Text(80) Smalldatetime(16)

4 Expired

Description… 08/02/2016

Yes Yes

No Yes

Table 53: Data Dictionary

Page 114 of 122

Goliath


APPENDIX 3 - LANGUAGE TRANSLATION

The Language Translation Logic Example screen below has been used as an example of how the

language translation will function. Every text field on the screen has been allocated a corresponding

key. The system will display the words depending on which language is selected by the user on the


A spreadsheet (Table 54) detailing all of the English language phrases used throughout the system will

be submitted as an addendum to this Functional Specification. It will be the responsibility of Shaun

Frost (marketing manager) to complete the spreadsheet by filling in the equivalent phrases in each of

the three other languages supported by the system – French, German, and Spanish – and submit this

to Brendan Butt (business analyst) by no later than June 7th, 2016 (UAT date).

In the event that changes to the language translations as recorded in the Ironwood data dictionary are

required after the application has been delivered, Shaun Frost will communicate such changes to the

Ironwood application support team who will schedule to have these implemented as isolated

enhancements to the application. Such changes will require data base changes only, and not application

deployments.

Figure 38: Language Translation Logic Example

Page 115 of 122

Goliath


For the purpose of this assignment I have added not completed the table below.

Key English German Spanish French

1 SELECT

TICKETS

Tickets Seleccionar boletos sélectionner des billets

2 ADULT Etc. Etc. Etc.

3 CHILD

4 SENIOR

5 GENERAL

6 AGES 6 - 12

7 AGE 62+

8 BACK

9 CANCEL

10 NEXT

Table 54: Language Translation Example

Page 116 of 122

Goliath


APPENDIX 4 - TICKET AVAILABILITY CALCULATION

The ticket availability model will be built as shared logic so that when the website (phase 2), or any

other future enhancement is implemented, it will be able to leverage this logic.

Ticket availability will be calculated as follows:

1. The system will fetch the value saved against each timeslot on the Manage Ticket Availability

screen, for that day. This value will serve as the base value.

2. The system will then deduct the quantity of tickets which have been purchased for each timeslot

from the base value. Only tickets with a status of Is Complete = 1 (successful payment) will be

deducted. Tickets that have been refunded or cancelled will therefore be excluded.

3. The value of the above will be the quantity of available tickets for that timeslot. This will be the

value displayed on the Select Timeslot screen against the timeslot.

For example, the manager decides to allocate 100 tickets on the Manage Ticket Availability screen for

the 15:00 - 15:30 timeslot. During the course of the day a guest purchases 10 tickets for that timeslot.

When the next guest arrives on the Select Timeslot screen, the quantity of available tickets for the

15:30 – 15:30 timeslot will be 90.

All tickets which have been cancelled or refunded will be released back into the pool of available

tickets.

All tickets will consume exactly 1 unit of availability. For example: There are 10 available tickets for

a timeslot. A guest purchases 1 Adult, 1 Child and 1 Senior for that timeslot. The available tickets

for that timeslot will now be 7.

Packages will not consume ticket availability, unless configured to do so through the Ironwood

Intranet under the Mange Guest Package tab.

Ticket availability will be shared between the different channels. In other words, if a guest

purchases 5 tickets for a particular timeslot, the quantity of available tickets for that timeslot will be

reduced by 5, whether the guest is viewing ticket availability from the Self Service or website

(phase 2) channel.

Page 117 of 122

Goliath


APPENDIX 5 - TEST SCENARIOS

The table below (Table 55) details test scenarios which will be used by the development team to

validate the requirements, and to ensure that the final product delivered is of a high quality and caters

for all scenarios. For the purpose of this assignment I have only covered a subset of the test scenarios.

Scn # Test Scenario Expected Outcome

1 Unplug a printer from one of the self-service

terminals, and then attempt to initiate the ticket

sales process by touching the Welcome screen.

The Out Of Order screen is displayed.

The system sends the Out Of Order email to

[TerminalTestFailedAddress], which indicates

that the terminal used in the test could not

connect to the printer.

The application remains on the Out Of Order

screen until indefinitely.

Only one email notification is sent.

2 Attempt to purchase tickets or perform any other

guest related actions while the Out Of Order screen

is displayed.

Unable to initiate the ticket sales process or

perform any guest actions.

3 Plug the printer back in to the terminal. After 30 seconds the application performs a

check and detects the printer and therefore

removes it from an out of order state back to

the Welcome screen.

The guest is able to initiate the ticket sales

process.

4 Change the values of the system variables on the

Ironwood Intranet and then run the Self Service

application. Update the same system variables with

different values and restart the Self Service

application.

The Self Service application caches the

correct values, both initially and when

restarted; updated values are reflected.

5 Reduce the amount of available tickets from the

Ironwood Intranet to 0 for the day.

The Sold Out screen is displayed when the

guest touches the Welcome screen.

Unable to initiate the ticket sales process or

perform any guest actions.

6 Cycle through different languages on the Select

Language screen.

The text on the screen is translated and

updated in real-time to the language

selected.

7 Attempt to a quantity of tickets which is greater than

the value of the [MaximumTicketsPerSale].

The guest is unable to select a quantity

which is greater than the value of the

[MaximumTicketsPerSale]; all increase

buttons are grayed out and disabled.

8 Select tickets and advance a few steps in the ticket

sales process, and then navigate back to the Ticket

Selection screen.

The guest is able to change the quantity of

tickets and type of tickets they would like to

include in the sale.

9 Select 5 tickets on the Select Ticket screen and then

attempt to upgrade 6 or more to the Iron Class Pass.

The guest is unable to select more than 6

Iron Class Pass upgrades on the Upgrade

Tickets screen.

10 Select to abort the ticket sales process by selecting

the cancel button on each screen.

The ticket sales process is cancelled and the

guest is taken back to the Welcome screen.

Any tickets which were reserved by the guest

Page 118 of 122

Goliath


are released back into the available pool.

11 Select 2 of each ticket types and upgrade them all to

Iron Class Pass.

Do a manual calculation and ensure the Sub

Total, Sales Tax and Total matches the total

the Self Service application displayed.

Ensure the amounts recorded in the

database match the frontend.

12 Update the ticket prices on the Ironwood Intranet

and restart the Self Service application.

Ensure the updated ticket prices are cached

and displayed throughout the ticket sales

process.

13 Attempt to restart the Self Service terminals from

the Ironwood Intranet under on Administration

screen.

The Self Service application restarts.

14 Opt to not upgrade any tickets to an Iron Class Pass

and continue the sales process.

The guest is able to complete the sale

without upgrading any tickets.

The correct warning message is displayed.

15 Attempt to pay with a credit card which is not

supported by the application.

The guest is unable to complete the sale.

The correct error message is displayed.

16 Insert the credit card the incorrect way (magnetic

strip on the opposite side).

The application is unable to read the card.



17 Pay for a sale using each one of the accepted credit

card types: American Express, Discovery,

MasterCard, Visa

The correct amount is deducted from the

card.

The transaction is reflected in PayPal, and

correctly classified as paid.

The sale is marked as complete in the

backend.

The sale is marked as Is Complete on the

Ironwood Intranet on the Sales screen.

18 Attempt to complete a sale without capturing a digital signature.



19 Complete a sale. The Welcome screen is displayed.

The sale is marked as complete.

The values are correctly recorded in the

database.

20 Edit the amount of available tickets on the Ironwood Intranet on the Timeslots screen.

The update amount is saved.

The updated amount is displayed on the

front-end.

The updated amount is correct in the

backend.

21 Edit the amount of available tickets on the Ironwood Intranet on the Timeslots screen and then select the cancel button.

All updates are cleared and the old values

are restored.

No updates are saved on the front-end or

backend.

22 Make an update to the available tickets on the Ironwood Intranet on the Timeslots screen using the adjustment functionality. Make an updating using both a positive and negative number.

All timeslots which the adjustment applies to

are updated correctly.

23 Attempt to insert a non-integer character into the Amount field under the adjustments section.

The application automatically clears the field.

Page 119 of 122

Goliath


24 Reduce the available tickets to 0 on the Ironwood Intranet on the Timeslots screen by selecting the Clear Timeslots button, and then select the Save button.

The amount of available tickets for all

timeslots is reduced to 0.

The correct amount of 0 is saved against

each timeslot in the back-end.

25 Attempt to update the name of the ticket types available through the Self Service application.

The ticket names are not updatable from the

front-end.

26 Attempt to update the Active flag of the ticket types available through the Self Service application.

The ticket Active statuses are not updatable

from the front-end.

27 Scan a valid ticket using the mobile PDA and Admission site.

The Admission site identifies the ticket as

valid.

The ticket status is updated to Is Used.

28 Scan an invalid ticket using the mobile PDA and Admission site.

The Admission site identifies the ticket as

invalid.

29 Complete a few ticket sales and keep track of their details, specifically their monetary amounts, and then run the MRI Import.

The ticket sales are correctly uploaded to

MRI. Ensure all the sales are there and their

amounts match the ones you initially

recorded.

30 Remove Manager access from a user in GACS and then run the GACS Import.

The user can no longer access the Ironwood

Intranet using their credentials.

Table 55: Testing Scenarios

Page 120 of 122

Goliath


APPENDIX 6 - CHANGE MANAGEMENT

Change management involves establishing policies and procedures to detect, analyze, evaluate and

implement modifications to the scope baseline of the project. Any changes to the baseline may severely

impact project success.

There are three classifications for changes:

Major - A major change dramatically alters the schedule, the scope baseline, the budget and/or

anything else deemed to be critical to the project. A major change typically involves 10% or more of the

project effort. A major change implies a rework of the project definition or requirements document.

Minor - A minor change does not imply insignificance. It is categorized as minor because it fails to fit in

the major change category. A minor change does not alter the outcome of the project. It does,

however, potentially affect the chances for a successful outcome. A minor change typically involves less

than 10% of the total project effort. An example of minor change is the provision of additional training.

Corrective - A change that fixes something that was overlooked sometime during the project and

generally does not require more than a day of effort to resolve.

Change requests shall be brought before the project manager and relevant stakeholders for discussion

and for a decision on whether it should be included as part of the implementation. In all cases the

change request will be logged in the change control log. Any changes that require additional resources

or time for the project will require approval by the relevant stakeholders to work commencing on the

change.

ISSUE RESOLUTION PROCESS

Project issues will be logged in the issues log of the weekly status report. Issues should be discussed

and resolved at project status meetings. Project issues generally relate to product functionality, product

configuration, product performance or employee performance. Depending on the nature of the issue,

consideration should be given to resolving the issue directly with the relevant stakeholders and project

manager.

SCOPE AND BUDGET CHANGE AUTHORIZER

Samantha Kerr is the nominated stakeholder who will have the authorization to sign-off on scope and/or

budget changes to the project, if necessary.

Page 121 of 122

Goliath


APPENDIX 7 - REFERENCES

The following references have been used to build up the information in business problems section.

Alvarez & Marsal., 2013, Commercial Real Estate Competitiveness Study, JRT Reality Group

INC, viewed 5 September 2015, from

http://www.alvarezandmarsal.com/sites/default/files/sidebar-

callouts/commercial_real_estate_competitiveness_study.pdf

Chung, J., 2014, One World Trade Center Observatory Sets Admission At $32, gothamist,

viewed 12 September 2015, from

http://gothamist.com/2014/10/28/one_world_trade_center_sets_admissi.php#photo-1

Forbes., 2015, The World’s Top 10 Visited Cities, viewed 5 September 2015, from

http://www.forbes.com/pictures/ehlk45iehm/5-new-york/

NYCGO., 2014, NYC Statistics, viewed 8 September 2015, from

http://www.nycgo.com/articles/nyc-statistics-page

Nyctrip,. 2015, Visiting the Empire State Building, NYCTRIP, viewed 8 September 2015, from

http://www.nyctrip.com/pages/Index.aspx?PageID=1176

Rapoza, K., 2012, Global Growth Forecast 2020, viewed 2 September 2015, from

http://www.forbes.com/sites/kenrapoza/2012/03/26/global-growth-forecast-2020/

Robertson, D., 2012, No threat from large gorillas, The Times, viewed 10 September 2015,

from http://www.thetimes.co.uk/tto/business/industries/construction-

property/article3391920.ece

Saul, M., 2013, New York City Sees Record High Tourism in 2013, wsj, viewed 9 September

2015, from http://www.wsj.com/articles/SB10001424052702304744304579250521791383050

Susman, A., 2013, Manhattan Q3 2013 Office Space Market Statistics, TheSquareFoot Blog,

viewed 6 September 2015, from http://www.thesquarefoot.com/blog/posts/manhattan-q3-

2013-office-space-market-statistics

The World Bank., 2014, GDP growth (annual %), viewed 1 September 2015, from

http://data.worldbank.org/indicator/NY.GDP.MKTP.KD.ZG/countries?display=graph

http://www.alvarezandmarsal.com/sites/default/files/sidebar-callouts/commercial_real_estate_competitiveness_study.pdf

http://www.alvarezandmarsal.com/sites/default/files/sidebar-callouts/commercial_real_estate_competitiveness_study.pdf

http://gothamist.com/2014/10/28/one_world_trade_center_sets_admissi.php#photo-1

http://www.forbes.com/pictures/ehlk45iehm/5-new-york/

http://www.nycgo.com/articles/nyc-statistics-page

http://www.nyctrip.com/pages/Index.aspx?PageID=1176

http://www.forbes.com/sites/kenrapoza/2012/03/26/global-growth-forecast-2020/

http://www.thetimes.co.uk/tto/business/industries/construction-property/article3391920.ece

http://www.thetimes.co.uk/tto/business/industries/construction-property/article3391920.ece

http://www.wsj.com/articles/SB10001424052702304744304579250521791383050

http://www.thesquarefoot.com/blog/posts/manhattan-q3-2013-office-space-market-statistics

http://www.thesquarefoot.com/blog/posts/manhattan-q3-2013-office-space-market-statistics

http://data.worldbank.org/indicator/NY.GDP.MKTP.KD.ZG/countries?display=graph

Page 122 of 122

Goliath


APPENDIX 8 – ENTITY MATRIX (CRUD)

A partial Entity Matrix, also known as the CRUD Matrix, is provided below (Figure 39). The entities are provided in alphabetical order and

the requirements in numerical order, for ease of reference. Please note that for the purpose of this assignment, the ERD below only

contains a subset of the entities required for this system.

Figure 39: Entity Matrix (CRUD)

Date post:	12-Apr-2017
Category:	Documents
Upload:	brendan-butt
View:	74 times
Download:	2 times

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

Documents