DublinTheatreFinder-SystemsAnalysis

1
DT265 Systems Analysis and Testing
Phase I Submission
Semester 2 2015/2016
Kate Godinho
Dublin Theatre Finder

2
Table of Contents
Table of Contents.......................................................................................................................2
1 General Project Information ..............................................................................................1
1.1 Group Details ..............................................................................................................1
1.2 Project Description......................................................................................................1
1.2.1 System Scope.......................................................................................................1
1.2.2 Assumptions/Constraints .....................................................................................1
1.2.3 Restrictions on the scope .....................................................................................2
2 Research Conducted...........................................................................................................2
2.1 Competitor analysis.....................................................................................................2
2.1.1 Common features.................................................................................................2
2.1.2 Ticketmaster (http://www.ticketmaster.ie/) .........................................................3
2.1.3 Gate Theatre (http://www.gatetheatre.ie/) ...........................................................5
2.1.4 Abbey Theatre (http://www.abbeytheatre.ie/) .....................................................6
2.1.5 Official London Theatre (http://www.officiallondontheatre.co.uk/) ...................7
2.2 Major Functions ..........................................................................................................8
2.2.1 Theatre-side functionality....................................................................................8
2.2.2 Customer-side functionality.................................................................................9
3 Model Developed.............................................................................................................10
3.1 Use Case Diagram.....................................................................................................10
3.1.1 Customer interaction use case diagram..............................................................10
3.1.2 Theatre interaction use case diagram...................................................................1
3.2 Use Case Narratives ....................................................................................................1
3.2.1 Book tickets use case narrative............................................................................1

3
3.2.2 Purchase tickets use case narrative ......................................................................2
3.3 Activity Diagrams .......................................................................................................1
3.3.1 Book tickets activity diagram ..............................................................................1
3.3.2 Purchase tickets activity diagram.........................................................................1
4 Entity Classes.....................................................................................................................1
4.1 Class diagram..............................................................................................................1
4.2 Derivation of classes ...................................................................................................1
5 Guidelines for developing required artefacts.....................................................................2
5.1 Use Case Diagram – guidelines ..................................................................................2
5.2 Use Case Narrative – guidelines .................................................................................3
5.3 Activity diagrams – guidelines....................................................................................4
5.4 Entity classes – guidelines...........................................................................................5

1
1 General Project Information
1.1 Group Details
Teamwork: We decided on the system to work on as a team (4 people) and some of the
competitors we could use. After the initial discussion, we worked individually for the rest of
the project and each decided our own assumptions and constraints for the system.
1.2 Project Description
Project name: Dublin Theatre Finder.
The project is based around designing a theatre website which allows customers to browse
theatre listings for the Dublin area, select shows they are interested in attending, and book
tickets.
1.2.1 System Scope
The system is an online theatre booking website. It provides a single website for theatres in
the Dublin area to allow customers to view information about upcoming shows and book
tickets directly through the website.
Theatres can register with the website and provide information for customers, such as theatre
information, accessibility, directions and theatre plans. Theatres can provide details of
upcoming shows (dates, ticket prices, etc.) and the website provides an online interface for
customers to browse and book tickets.
Customers can browse the website and view information on theatres and upcoming shows.
For each theatre show, the website provides detailed information about the show, including a
synopsis, cast information, running dates and ticket prices. Customers can book tickets for
shows directly through the website.
Customers can register as a member of the website in order to access additional functionality.
Once they register, they will be able to edit their personal details, view their bookings, leave
reviews of theatre shows, share information on social media, and access the ticket resale
service.
1.2.2 Assumptions/Constraints
1. Direct sales: Theatres allow tickets to be sold directly through the website rather than
linking back to their own booking engine or a third party website.
2. Ticket sales by other providers: The theatre will maintain a record of any tickets sold
directly by the theatre or through other websites. This record will be linked to the
ticket booking system in order to update the ticket availability.
3. Third party payment systems: At payment stage, payment information will be sent to
third party providers (i.e. PayPal, credit/debit card providers) for verification. Any
additional security steps will be handled by these providers. The booking system will
receive an accept response if the payment details are verified and a reject response if
the payment details are invalid.

2
4. Theatre box office manages printing/postage: The theatre box office will handle
printing and postage of tickets if a customer chooses to collect tickets at the box office
or receive them in the post.
5. All theatres will provide seating plans: I have assumed that all theatres will provide
seating plans which can be used when booking tickets.
1.2.3 Restrictions on the scope
1. Dublin area only: We constrained our system to dealing with theatres in the Dublin
area. This will limit the number of theatres that can register with the website.
2. Group/corporate bookings: The system does not allow group bookings or corporate
bookings. Only individual bookings are allowed.
3. Ticket cancellation: Once tickets have been booked they cannot be cancelled.
However, customers who have registered through the website will be able to resell
tickets at face value through the site.
4. Theatre-side interaction: As I mainly wished to model customer behaviour, I limited
research to customer-side interactions. While I have included a rough use case
diagram of theatre-side interactions, this is based on assumptions on a fee model
based on registration and ticket booking commission.
2 Research Conducted
To investigate the functionality for customers browsing listings and booking tickets, I
researched websites for individual Irish theatres and also looked at ticket booking sites that
included theatre tickets. While each theatre has its own website, and there are ticketing
websites such as Ticketmaster which list theatre shows, there does not appear to be a direct
competitor which gives listings for multiple theatres in Dublin (or Ireland) and allows
customers to book tickets directly. In order to research a site dedicated to providing tickets
and listings for multiple theatres, I analysed a website for London theatres
(http://www.officiallondontheatre.co.uk/).
2.1 Competitor analysis
I analysed several websites for their main functionality. I was particularly interested in their
functionality for browsing theatre listings and for booking tickets. Details of specific
functionalities are given below.
2.1.1 Common features
Certain features were shared by most of the websites I analysed. These functionalities should
be included in the design of any new theatre ticket booking system.
Browsing functionality
1. Sort by date: In all websites, the default browsing was by date. This appears the most
sensible way to order a list of shows as customers will generally have a date range in
mind when browsing.

3
2. Customer reviews: Most sites allowed customers to leave reviews of performances
and read reviews left by others. This makes the website more interactive and allows
customers to read and share opinions on a show.
3. Search: Customers can type in a show or theatre to quickly navigate to listings they
are interested in.
Booking functionality
1. Book by theatre plan or best available: Once a customer selects a show date and time,
they can book tickets based on a seating chart or can enter the number of tickets, price
and/or section and the website will select the best available tickets. However, not all
theatres have a seating plan available – this is something to note when designing a
theatre booking website.
2. Timeout: Once tickets have been selected, a customer must buy them within a certain
period of time, otherwise they are released for booking by other customers. This is a
useful feature, as it means that tickets cannot be held indefinitely, for example, if the
webpage is left open by the customer. However, the time limit for booking should be
set in such a way that a customer does not feel that they are rushed through an order.
3. Multiple delivery options: All sites offered a range of delivery options, e.g. collect at
box office, postal options, and print at home. This offers customers greater flexibility
in how they wish to receive their tickets.
Other functionality
1. Social media links: Social media links are provided to share information about a
show. For example, customers can “like” a particular show or share the show
information (title, synopsis, dates, etc.). Once tickets have been booked, customers
also have the option to share on social media that they are attending a particular show.
This is a useful feature as shares may generate more interest in the show and act as
free advertising.
2. Registration: All websites allowed customers to register so that their personal details
can be saved to the system for their next booking.
2.1.2 Ticketmaster (http://www.ticketmaster.ie/)
Ticketmaster is the main website used by Irish theatres to provide theatre tickets. Many Irish
theatres, such as The Gaiety, The Olympia and Bord Gáis Energy theatre use Ticketmaster
for their ticket sales.
Browsing functionality: In terms of functionality, the main issues that Ticketmaster has are
around the browsing functionality. As it is primarily designed for booking tickets rather than
browsing, and is not exclusively dedicated to theatre, it has limited functionality for browsing
theatre shows.
1. Limited theatre browsing categories: A customer wishing to browse theatre tickets
needs to first select the category “Arts, Theatre and Comedy” and then choose from
the subcategories within this: Ballet&Dance, Classical, Comedy, Drama, Museums,
Musicals, Opera and More Arts, Comedy and Theatre. It is not possible to select
multiple subcategories to view. As the listings in the “Arts, Theatre and Comedy”

4
category include non-theatre shows, this makes it difficult for a customer to browse
only theatre shows.
2. Difficult to browse by theatre: While Ticketmaster does provide information on
venues, it does not provide a list of venues on the website and the only way to view a
list of shows by venue is to search for the venue name or click on the venue name for
a particular show.
3. Limited venue information: The venue information on the Ticketmaster website is
limited and is not very accessible as it requires the customer to scroll down to the
bottom right hand of the screen when viewing listings (Figure 1). This makes it
difficult for a customer to view venue information such as location, accessibility and
contact details.
Figure 1 Ticketmaster booking site with venue details on bottom right.
4. Limited ‘Order by’ options: When browsing for tickets within a particular category,
the only option is to view in date order for a particular date range. There are no
options to view alphabetically or by venue.
Booking tickets: The ticket booking functionality within the Ticketmaster website is well
designed, as would be expected given that this is the main function of the website. There are
a number of functions that could be useful to a new theatre booking site.
1. Leaving single seats: The system will not allow a customer to book seats in such a
way that a single seat is left unbooked in the middle or at the end of a row. If a
customer leaves a single seat, a warning is displayed and customers must reselect
seats until there are no single ones left. This is a useful feature for theatres as single
seats are more difficult to sell than grouped seats.
2. Save tickets for later: Before making any payment, the customer has an option to save
their tickets for later. If a customer chooses this option, tickets are added to their cart
and they can go back and purchase them later if the tickets are still available. The
system will not hold the tickets as other customers may wish to purchase them in the
meantime. However, it is still a useful feature to have as it saves a customer time if
they wish to return to book tickets.
3. Registration required: In order to buy tickets through Ticketmaster, a customer must
register. While this may have benefits for the customer for tracking orders and saving
personal details/preferences, some customers may not wish to complete a registration
process due to privacy issues.

5
4. Cancellation only at end: Customers are only given an option to cancel out of an order
before submitting their payment details. At other points in the booking process, the
only options given are to continue or save tickets for later. While a customer can
always leave the webpage if they do not wish to continue, I feel that an option to
cancel the order should be available earlier in the booking process to allow the
customer to exit more easily.
5. Ticket upgrades: Some theatres offer upgrade packages such as champagne on arrival
or interval drinks.
2.1.3 Gate Theatre (http://www.gatetheatre.ie/)
The Gate Theatre site is not particularly well structured. While it has some features that I
would include in a theatre booking site, the overall structure looks quite old-fashioned and it
is relatively difficult to navigate.
At the time I browsed, there were only two plays listed for booking, which limited my ability
to assess the browsing features of the website.
1. Unnecessary options on booking screen: The booking screen included options to buy
a gift certificate and a show programme. I feel that these should not be included in a
list of booking options and could be included as optional extras instead.
1. Too many options per page: The booking process includes too many selections to be
made per page and these are not carried out in a logical order. For example, the initial
booking screen is given in Figure 2.
Figure 2 Initial booking page for Gate Theatre website
It first asks customers to enter the number of tickets, then if they want to split seats,
and only then asks for a preferred date/time. The options to Choose seats or Best
available are at the bottom of the screen. In addition, the seat selection and delivery

6
options are both on the same page. I feel that this layout is quite poor as it asks the
customer for too much information at once. It would be better to split the process into
more steps, e.g. select date/time, select tickets, select delivery option, enter payment
details.
2. Limited delivery options: The only delivery options available appeared to be box
office collection or print at home. Some of the shows only offered box office
collection and had no email option. I feel that email would be a preferred option for
many customers and should always be included.
3. Stage view from seat: There is an option to show a photograph of the stage from the
selected seat. This is a useful feature as it lets the customer see the angle to the stage
and to view any possible obstructions.
4. No registration required: The website does not require you to register before buying
tickets. While it is possible to create an account, the system does not prompt for login
before buying tickets. Although I do not think a theatre booking system should require
registration to book tickets, it may be better to be prompted to login so that tickets are
linked to a registered customer’s profile.
2.1.4 Abbey Theatre (http://www.abbeytheatre.ie/)
The Abbey Theatre website is not particularly well laid out for browsing listings. The
dropdown menus are difficult to navigate and the overall layout of listings is not well
designed. However, there are still some positive features which I have highlighted below.
1. Difficult to navigate show listings: I found that it was difficult to navigate to the list of
shows that are on in the theatre. The “What’s On” page gives images showing the
different plays that are on in date order (see Figure 3), however, it is not possible to
order these alphabetically or by genre. The “Full Events Listings” page gives a list of
events in date order, however, there is no “Sort by” option. It would be better to have
several viewing options, for example, alphabetically, by genre, or by audience.
Figure 3 What's On page for Abbey Theatre
2. Detailed show information page: The show information is quite detailed and provides
all the information a customer might want about a show in one place. It provides a

7
synopsis, age guidance, cast information, ticket prices, show dates, reviews and
dates/times for audio-described and sign language performances. It also provides a
link to buy a programme. I feel that this type of detailed show information page is a
necessary feature for any theatre website.
1. View from seat: When choosing a seat from the theatre map, a pop-up window shows
the view of the stage from the seat as well as the prices (see Figure 4). I think this is a
good way of allowing a customer to view all of the options for a particular seat in one
place.
Figure 4 Abbey theatre seat selection
2. Optional extras: Before paying for tickets, optional extras are offered, including
theatre donations, merchandise, gift vouchers and theatre membership. As this is a
way of generating income for the theatre, I feel that optional extras such as these
could be included in our ticketing website.
3. Registration required: Similar to Ticketmaster, it is not possible to buy tickets without
registering with the website. I feel that it would be better to give a customer the option
to proceed without registration.
2.1.5 Official London Theatre (http://www.officiallondontheatre.co.uk/)
The Official London Theatre website gives listings for numerous theatres in London and
allows customers to buy tickets through the website. While it is not a direct competitor to our
proposed website, I used it to research the functionality that may be necessary in a ticket
booking website that handles multiple theatres.
Browsing functionality:
1. Multiple filtering options: Shows can be filtered by genre (musical, play, opera,
entertainment, dance), audience (family, adult, children), and assisted performances

8
(captioned, audio, signed). This allows customers to quickly find the types of shows
they are interested in.
2. Multiple sorting options: In addition to filtering by category, it is possible to sort
shows A-Z, Z-A, by opening night, by closing night and by venue A-Z. This gives the
customer greater control over how they view theatre listings.
3. Detailed show/theatre information: The show information page is quite detailed and
gives information about the synopsis, cast, show calendar, theatre accessibility,
theatre information and assisted performances. It is well organised, making it easy to
navigate to information of interest.
Booking functionality:
1. No choose seats from map option: It is only possible to buy tickets by price and
seating area. It is not possible to view a map and select seats. Once tickets have been
selected, a static map is displayed, along with the seat numbers so that the customer
can locate the seats. However, it would be better to allow customers to choose
available seats from an interactive theatre plan.
2. Optional extras: Once tickets have been selected, additional options are given to book
nearby restaurants. Including this option in our system could bring additional income
to the website from restaurant advertisements. However, care should be taken that this
does not introduce too many additional steps into the booking process as otherwise a
customer may choose to exit or cancel.
3. No cancellation option: Once the customer proceeds to payment, no cancellation
option is given. This means that a customer must navigate away from the site in order
to exit the booking process. A cancellation button would make it easier for the
customer to cancel the order, while still remaining within the website, possibly to
book other tickets.
2.2 Major Functions
Based on my research, the proposed functionality for the theatre booking website is given
below. I have split it into the theatre-side functionality and the customer-side functionality.
2.2.1 Theatre-side functionality
1. Theatre registration: Theatres must register an account with the website in order to list
shows on the website.
2. Fee payment: Theatres can pay website fees, such as registration and commission fees
directly through the website.
3. Provide and update theatre information: Theatres can add information about the
theatre to the website such as location, accessibility, floor plans, and photos showing
the stage view from each seat. Once provided, they can update this information at any
stage, for example if the floor plan changes after refurbishment.
4. Add show: Theatres can add shows to the website and provide information such as
show times/dates, ticket prices, special offers, and upgrade offers.
5. Manage show: Theatres can update show information on the website. They can add
additional show dates/times, update cast information or delete a show if it is
cancelled.

9
2.2.2 Customer-side functionality
Customers can be divided into two groups – those who have already registered with the
website (registered customers) and those who have not registered. Certain functionality will
only be available to registered customers. I have outlined below the functionality that will be
available to all customers and the additional functionality available to registered customers.
All customers
1. Browse: Customers can browse the website for theatre shows and view the shows in a
variety of different orders. The default is to view by date, however, they can also
choose to view alphabetically, by theatre, by genre or by recommended audience
(family, children, adult).
2. Customer registration: Customers can register with the website to access extra
functionality.
3. Book tickets: Customers can select tickets for a show they are interested in and book
tickets directly through the website. Within the booking office, the following
functionality will be included:
a. Select seats from seating plan: Customers can select the required number of
seats from a theatre plan. Within this functionality, they can also get a photo of
the stage from their seat if this has been provided by the theatre.
b. Select seats by price/section: Customers can choose seats by selecting a
desired section and price range.
c. Multiple delivery options: The website offers several delivery options – postal
options, print at home, and collect at box office.
d. Optional upgrades: Customers can add optional extras to their booking such as
champagne, a restaurant meal or a theatre programme.
4. Social media sharing: Customers can share information about a show on social media,
such as the synopsis, reviews, or a message that they are attending a show.
Registered customers
1. Review shows: Registered customers can review shows they have attended. Only
registered customers will have this option as this will make it easier to moderate
reviews.
2. Save tickets: During the booking process, registered customers can save ticket
information to their basket for later purchase. While the system cannot guarantee that
the tickets will not be sold, it provides the registered customer with a shortcut to
return to the booking process.
3. View previous bookings: Registered customers can view bookings that they have
previously made and reprint tickets if they have chosen the print at home delivery
option.
4. Ticket resale: If a registered customer wishes to resell tickets, the site provides a
resale service where they can post the tickets for resale at face value.
5. Manage profile: Customers can edit the personal details that are saved to the website
and manage their communication preferences (e.g. emails about theatre shows).

10
3 Model Developed
3.1 Use Case Diagram
3.1.1 Customer interaction use case diagram
Explanations for particular relationships
Dispatch tickets: Tickets will always be dispatched upon purchase and they have therefore
been linked to “Purchase tickets” using <include>. A customer can choose to receive tickets
by different methods, which have been included as specialisations of “Dispatch tickets”. They
can receive tickets by email (Email tickets), by post (Post tickets) or by collection at the box
office (Send tickets to box office). I have marked “Post tickets” to interact with the box office
staff as I have assumed in my model that the box office will manage printing and postage of
tickets.
Select seats: I have inserted select seats as a separate use case which is included in “Book
tickets” as there are two methods for selecting seats – “Select from seating plan” and “Select
by price/section”. These two methods of selecting seats have been included as specialisations
of “Select seats”.

11
View stage from seat: I have marked “View stage from seat” as an extension of “Select from
seating plan” as not all theatres will have uploaded seat view images to the system.
Share on social media: I have indicated “Share on social media” as an extension of “Purchase
tickets” so that customers can inform their network if they are attending a particular show. I
have also linked this to the customer as a customer will be able to share other information
from the site such as a show synopsis or a review.
Resell tickets: I have added “Resell tickets” as an extension of “View bookings”. This allows
registered customers to resell tickets through the website if they wish to do so.

1
3.1.2 Theatre interaction use case diagram

2
Provide stage view from seat images: I have inserted this as an extension of “Provide theatre information” as not all theatres will have images of
the stage from each seat.
Add ticket upgrade offers/Add special offers: Not every show will have special offers or optional upgrades and I have therefore included these
with “extends”.

1
3.2 Use Case Narratives
3.2.1 Book tickets use case narrative
Use Case Name: Book tickets
Intent: Allows customers to book tickets for a theatre show
Actors: Customer, Registered Customer
Precondition: Customer has selected a theatre show to book (see “Browse theatre listings” use case).
Use Case Initiation: Customer selects Book tickets
Dialog (Description):
1. System presents a calendar of available show dates.
2. Customer selects show date they are interested in.
3. System presents a dialog asking the customer whether they would like to choose seats from the theatre plan or
choose seats by section/price.
4. Customer selects to choose seats from theatre plan.
5. System presents a map of the theatre indicating the sections.
6. Customer chooses a seat section to view.
7. System presents a map of the section showing available seats.
8. Customer selects a seat.
9. System presents customer with price options for the seat (adult, child, student, etc.).
10. Customer selects price.
11. System marks seat as selected in map view.
12. Steps 7 to 11 are repeated until customer has selected the required number of seats.
13. Customer selects proceed to payment.
Alternate Flows:
4A.1 If customer selects to choose seats by section/price, system prompts customer to enter the required number of tickets
and to select the desired section(s) and ticket price(s).
4A.2 System displays a list of tickets in selected sections and price range.
4A.3 Customer selects tickets from list.
4A.4 System displays seat numbers for tickets along with a theatre seat plan.
4A.5 If customer selects reject tickets, return to step 4A.2, otherwise return to step 13 in main flow.
8A If customer wishes to view a different theatre section, customer selects back to theatre overview. Return to step 5 in
main flow.
9A If theatre has provided images of stage view from seat, system displays an image of the stage view from the selected
seat along with price options for seat.
10A If customer chooses to reject seat selection, return to step 7 of main flow.
13A If customer selects to save tickets for later, release tickets and proceed via “Save tickets” use case.
13B.1 If customer selects cancel booking, system displays message asking if they wish to save the tickets for later.
13B.2 If the customer chooses to save the tickets for later, release tickets and proceed via “Save tickets” use case.
Otherwise, if the customer chooses to exit without saving, system releases tickets for sale. System displays home screen
and use case terminates.

2
13C If customer has left one seat in a row, system displays a warning that single seats cannot be left in a row. Return to
step 7 in main flow.
Timeout:
- Once customer has entered ticket selection process (step 4 and 4A), a timer is started.
- If timer reaches limit between steps 4 and 13, system presents a warning that ticket booking session has timed
out.
- System releases tickets for sale to other customers.
- System asks user if they would still like to book tickets.
- If customer selects that they would like to book tickets, return to step 1 in main flow. Otherwise, use case
terminates.
Use Case Termination:
Normal termination: Customer has selected tickets and has proceeded to payment (see “Purchase tickets” use case).
Save tickets: If customer chooses to save tickets, tickets are released for sale and “Save tickets” use case is initiated.
Cancellation:
1. If customer exits system at any stage, any selected tickets are released for sale.
2. If customer selects to cancel booking, tickets are released back for sale. System returns to home screen.
Timeout: If customer does not complete ticket selection within a predefined time limit, tickets are released back for sale.
Post condition:
Normal termination: Tickets are saved to customer basket. Customer proceeds to “Purchase tickets” use case.
Save tickets: Any tickets selected by the customer are available for sale. Customer proceeds to “Save Tickets” use case.
Cancellation: Any tickets selected by the customer are available for sale.
Timeout: Any tickets selected by the customer are available for sale.
3.2.2 Purchase tickets use case narrative
Use Case Name: Purchase tickets
Intent: Allows customer to buy tickets for a theatre show. Should be viewed alongside “Book tickets” use case.
Actors: Customer, Registered Customer
Precondition: Customer has chosen tickets they wish to buy (see “Book tickets” use case).
Use Case Initiation: Customer selects “Proceed to payment”.
Dialog (Description):
1. System displays a login screen with options to register or continue without registering.
2. Customer chooses to proceed without registration.
3. System presents a form asking the customer to provide personal details
4. Customer enters personal details (name, address, email address, phone number).
5. Customer selects Confirm order.
6. System presents a delivery options screen asking if customer would like to receive tickets by post, by email or to
collect tickets at box office.
7. Customer selects a delivery option (see “Dispatch tickets” use case).
8. Customer selects Proceed to checkout.
9. System presents a payment options screen.
10. Customer selects pay by credit/debit card.

3
11. System presents a form asking the customer to provide credit/debit card information (name, card number, billing
address, etc.)
12. Customer enters payment information.
13. Customer selects Confirm payment.
14. System sends payment information for verification externally.
15. System displays a payment confirmation message and an order number.
16. System emails order number to customer.
17. System updates ticket availability information.
Alternate Flows:
1A If customer is already logged in, proceed to step 2A.2.
1B.1 If theatre show has offered upgrades, system displays a list of upgrade offers.
1B.2 If customer wishes to upgrade, customer selects one or more upgrade offers, otherwise proceed to step 1B.3.
1B.3 Customer selects “Proceed to payment”. Return to step 1 in main flow.
2A.1 Registered customer logs into system using username and password (see “Login” use case).
2A.2 System presents a web form populated with the personal details provided by the registered customer.
2A.3 If any personal details are incorrect, customer edits web form. Return to main flow step 5.
2B If customer chooses to register, proceed via “Register” use case. Once registration is complete, proceed via step 2A.2.
5A.1 If customer selects Cancel order, system displays message asking if they wish to save the tickets for later.
5A.2 If the customer chooses to save the tickets for later, release tickets and proceed via “Save tickets” use case.
Otherwise, if the customer chooses to exit without saving, system releases tickets for sale. System displays home screen
and use case terminates.
6A.1 If any required details are missing from the form or invalid, system displays an error message.
6A.2 System displays personal details form with errors marked.
6A.3 Customer edits personal details. Return to step 5 of main flow.
8A If customer selects Cancel order, proceed as for alternate flow 5A
10A.1 If customer selects pay by PayPal, system displays PayPal login screen.
10A.2 Customer enters PayPal information.
10A.3 Return to step 13 of main flow.
10B If customer selects Cancel order, proceed as for alternate flow 5A
13A If customer selects Cancel order, proceed as for alternate flow 5A
15B.1 If payment information is rejected, system displays payment rejected message.
15B.2 System prompts customer to check their payment details.
15B.3 System displays completed payment form.
15B.4 Customer edits payment details.
15B.5 Return to step 12 in main flow.
Timeout:
- Once customer starts payment process (step 1) a timer is started.
- If timer reaches limit between steps 1 and 15, system presents a warning that payment has timed out.
- System releases tickets for sale to other customers.
- System asks user if they would still like to book tickets.
- If customer selects that they would like to book tickets, proceed via “Book tickets” use case. Otherwise, system
displays cancellation message and use case terminates.
Use Case Termination:
Normal termination: Customer receives order number. Tickets are assigned to customer. Ticket availability is updated.

4
Cancellation:
1. Customer cancels order. Tickets are released back for sale. Customer returns to home screen.
2. Customer exits before completing booking process. Tickets are released back for sale.
Save tickets: Customer selects Save tickets for later. Tickets are released for sale. “Save tickets” use case is initiated.
Timeout: Customer does not complete booking process within predefined time limit. Tickets are released for sale.
Post conditions:
Normal termination: Ticket availability is updated. Tickets are assigned and ready to dispatch to customer (see “Dispatch
tickets” use case).
Cancellation: Any tickets selected by the customer are available for sale.
Save tickets: Any tickets selected by the customer are available for sale. Customer proceeds to “Save tickets” use case.
Timeout: Any tickets selected by the customer are available for sale.

1
3.3 Activity Diagrams
The activity diagrams for the Book tickets and Purchase tickets use cases are shown below.
Note that the system timeout is omitted from the diagrams as it is too complex to include. See
the use case narratives for the flow for system timeout.

1
3.3.1 Book tickets activity diagram

1
3.3.2 Purchase tickets activity diagram

1
4 Entity Classes
4.1 Class diagram
4.2 Derivation of classes
Actors
Each actor in the system has its own class – customer, registered customer, box office staff,
theatre sales staff, and website sales staff.

2
- Customer: A customer can access the website without registering to view listings and
book tickets. The attributes required relate to contact details (name, address, phone,
etc.) and payment details (credit card, paypal, etc.). They have a register() method to
allow them to register details with the website and can also search() the website for
information and share information on social media.
- Registered customer: A registered customer has a username and password to access
the website. They are a specialised case of a customer.
- Box office staff: Box office staff are required when a customer chooses to pick up
tickets at the box office or post tickets. They require a username and password and
information about their name and email address will also be stored.
- Theatre sales staff: Theatre sales staff interact with the system to register theatres and
manage shows. They will require a username and password, and their name and email
address.
- Website sales staff: Website sales staff process new theatre registrations and are
involved in processing fees. They require a username and password to access the
system and information about their name and email address should also be stored.
Other entities
- Theatre: Theatres have been included as an entity to include overall information about
the theatre such as the capacity, sections, theatre plan and contact details.
- TheatreShow: The theatre show entity is used to hold information related to a
particular show, such as dates/times, cast, synopsis, reviews and special offers.
- Ticket: The ticket entity is used for tickets for a particular show. It holds information
such as the seat number, ticket price, and ticket availability.
- TheatreListings: A theatre listings entity has been included to hold a list of theatre
shows that the customer can browse. It contains the names of the theatre shows and
the dates that they are running. It takes information from the theatre show entity.
- CustomerProfile: Registered customers have a customer profile which contains saved
personal details, including their name, address, email address and payment details.
- Bookings: Previous bookings are saved for registered customers. The entity holds
information about the ticket details. Registered customers can view bookings and
print out tickets.
- SavedTickets: If the customer saves tickets for later purchase, they are stored in the
entity SavedTickets. This provides ticket details and availability so the customer can
go back and buy tickets if they are still available.
- WebsiteFee: This entity is used to store information about any fees paid by the theatre
to the website. It includes information about the fee amount and type of fee
(registration, commission, etc.).
5 Guidelines for developing required artefacts
5.1 Use Case Diagram – guidelines
1. Break down the system into smaller subsystems in order to simplify the use case
diagrams
Within the system, first identify the actors. Then identify the main interactions
between the actors as a general overview in order to work out which groups of actors
interact with each other through the system. In a complex system, this can allow you

3
to break down the use cases into several separate diagrams rather than having one
complex diagram. For example, in this assignment, I broke down the theatre booking
system into customer-side interactions and theatre-side interactions.
2. Start by making by making a skeleton overview of the main use cases
Identify the major use cases you want to document e.g. book tickets, browse listings.
Start with a skeleton overview just documenting these main use cases and their
interactions. These should give an overview of the normal path through the system.
3. Identify any alternative paths through the system
Having created a skeleton, think about any alternative paths through the system that
may need to be included, e.g. saving tickets for later, reselling tickets. Add these to
the diagram using “extends” arrows.
4. Keep it general – avoid breaking down use cases too much
The use case diagram should be a general overview and does not need to include
every step of the process. Keep the use cases as broad as possible to start with. They
can always be broken down later using “includes” or “extends”.
5. Identify any generalisations/specialisations
Check if any use cases are generalisations or specialisations of other use cases. For
example, I was able to use “Dispatch tickets” as a generalisation of “Send tickets to
box office”, “Email tickets” and “Post tickets”.
6. Continually review and update your diagram while creating the narrative and
activity diagrams
The first draft diagram may not include all possible use cases. When creating
narratives and activity diagrams, if you think of something that has not been
documented in the use case diagram, go back to the diagram and add it in where
appropriate. It can be easier to identify alternative paths when going through the step-
by-step approach of the narrative and activity diagrams. If the narrative for a
particular use case becomes overly complex, it may be better to split it into several
use cases using “includes” or “extends” arrows.
5.2 Use Case Narrative – guidelines
1. Keep consistent with use case diagram
Use the same use case names and actor names as in the use case diagrams. Do not
change from “customer” to “client” or from “buy ticket” to “purchase ticket”.
2. Identify actors
Identify the actors involved in the use case. Use the actor name throughout the
narrative to indicate who does what (e.g. Customer selects seat, registered customer
logs in).
3. Include system actions
Make sure that system actions are included as well as user interactions. For example,
system displays error message, customer clicks ok, system displays home screen.
4. Refer to other use cases where necessary
For any particular narrative, other use cases may be involved at various stages from
initiation, through main flow to termination. Reference these use cases by name to
make it easier for the reader to find the corresponding narrative (e.g. see “Register”
use case).
5. Determine preconditions using previous post-conditions
If the use case follows from a previous one, for example if it is an ‘extends’ or
‘includes’ case, check the previous use case’s post-conditions to determine the current

4
use case’s preconditions. Note this in the description if necessary (e.g. Customer has
purchased tickets (see Purchase tickets use case)).
6. Check previous use case to determine initiation
Initiation of one use case can often be determined from the final step or termination of
a previous use case. Ensure that no steps are omitted when moving from one use case
to a sequential one.
7. Start by writing the normal flow through the system
Start the narrative by writing the steps for the normal flow through the system. When
there is a choice of steps (e.g. login or register), choose the one that you think will be
most used, and make a note of the second action for an alternate flow. Concentrate on
writing a complete normal flow before looking at alternate flows.
8. Labelling alternate flows
a. Reference the main flow step
When labelling alternate flows, include the number of the main flow step (e.g.
alt-step 2, 2A). As there can be multiple flows for any one step it is easiest to
label the alternate flows using A, B, C, etc. (e.g. 3A, 3B, 3C…).
b. Each alternate flow can have multiple steps
Complex alternate flows may have a number of steps. To make the narrative
easier to read, document each step separately, e.g. 2B.1, 2B.2, 2B.3, etc.
9. Add alternate flows from branches in the system
Start by including alternate flows from any obvious branches in the main flow that
you have noted from point 6 above. Document any alternative choices of methods for
a particular step, e.g. email tickets or post tickets.
10. Go through the normal flow step by step to find alternate flows
Look at each step in the normal flow in turn and think of any options you may wish to
provide to the user (e.g. save process and exit), or unexpected directions that the user
may take (e.g. invalid username). Add these as alternate flows to the narrative.
11. Include exits/cancellations as terminations rather than alternate flow
It is not necessary to include every exit/cancellation as an alternate flow. For example,
in a website, it can be assumed that the user can exit at any point by closing the
browser or going to another webpage. This can be included in the narrative as a
termination without being explicitly included as an alternate flow.
12. Categorise terminations and post-conditions
Include categories such as “Normal termination”, “Cancellation” and “Timeout” when
documenting termination and post-conditions. This makes it easier to identify the
distinct exit points in the system.
13. Review and update as you build further diagrams
As for use case diagrams, the narrative may need to be updated after consideration of
the activity diagrams. It should be continually reviewed throughout the documentation
process to ensure consistency between all diagrams.
5.3 Activity diagrams – guidelines
1. Use the narrative to build the activity diagram
The narrative outlines all the steps required for the activity diagram. Translate these
steps into actions in the activity diagram.
2. Identify actors to decide on swimlane approach

5
If there are multiple actors in the system, it may be best to use a swimlane approach to
document who does what. However, if the system is complex, it may be easier to
draw a diagram without swimlanes.
3. Start with the main flow
Start by building an activity diagram of the main flow from start to finish without any
branches. This will give you a skeleton to start your diagram.
4. Go through the alternate flows to add branches
Each time there is an alternate flow, add a diamond to the activity diagram indicating
a branch. Make sure to label the branches to make the directions obvious. Complete
each alternate flow before moving to the next.
5. Make sure each alternate flow returns to main flow or exits
When adding alternate flows, make sure to either bring them back to the main flow or
to a termination node.
6. Add merge nodes only when needed for clarity
To avoid having too many diamonds in the diagram, only add merge nodes when they
help with clarity. For example, if multiple flows merge and immediately branch again,
a merge node and a decision node may be placed next to each other to avoid having
too many arrows for one diamond.
7. Some flows may occur in parallel
If certain actions occur simultaneously, forks and joins should be used to specify
them. Make sure that each fork is balanced with a join.
5.4 Entity classes – guidelines
1. Include an entity class for each actor
Each actor in the system can be treated as an entity. Think about any attributes that
they have and include them in the class diagram. Include any
specialisations/generalisations when adding actors.
2. Look at nouns in use case diagram for obvious entities
Identify the nouns in the use case diagram and use these to add other entities, e.g.
ticket, theatre, and show.
3. Look at verbs in use case diagram for methods
Use the verbs in the use case diagram to identify any methods that will be associated
with entities. Where a verb and noun occur together, add the verb as a method to the
entity class of the noun.
4. Look at narratives to identify other entities/attributes
Go through the use case narratives to identify any other entities. Think about any data
that will need to be stored for each entity to work out the attributes.

DublinTheatreFinder-SystemsAnalysis

Recommended

Recommended

More Related Content

Similar to DublinTheatreFinder-SystemsAnalysis

Similar to DublinTheatreFinder-SystemsAnalysis (20)

DublinTheatreFinder-SystemsAnalysis