System Analysis and Design
Caasey@98
Final-Report-for-Toyota-Stadium.docxONINE Ticketing SYstem
ONLINE TICKETING SYSTEM
Table of contents:
Part 1:
Planning…………………………………………………………………………………...3
1.1 Introduction about the problem domain……………………………………………….3
1.2 System Request………………………………………………………………………...4
1.3 Feasibility Analysis…………………………………………………………………….5
1.4 Requirements Definition……………………………………………………………….6
Part 2:
Analysis...............................................................................................................................8
2.1 Activity Diagram………………………………………………………………………8
2.2 Use Case Diagram……………………………………………………………………...9
2.3 Use Case Description…………………………………………………………………...10
2.4 Initial Class Diagram…………………………………………………………………….20
2.5 Sequence Diagram………………………………………………………………………...21
Part 3:
Design………………………………………………………………………………………...28
3.1 Final Class Diagram……………………………………………………………………...28
3.2 Package Diagram………………………………………………………………………...29
3.3 Database Design………………………………………………………………………….30
3.4 Data Access and Manipulation Design………………………………………………….31
Part 1: Planning
1.1 Introduction to the problem domain
Sports has always played a pivotal role in our society. If we dig into the history of sports, there has been a huge revolution because of internet. People consider sports now as a business as well as great means of entertainment. Sports like soccer, basketball and football are the best investment for Business world. Introduction of internet in the sports area has contributed a lot on sports E-commerce market. Watching our favorite sports sitting in home or watching Live on stadium is easy and convenient because of Internet and its new online ticketing system.
The goal of this project is to design an online Sports Ticketing system named Online ticketing system for Toyota Stadium that sells ticket of different price ranges for people based on their seating preferences.
The number of purchased tickets is stored and Tracked with SAP software where customers are open to buy and cancel ticket within limited time frame through F.C Dallas website and also order tickets from the Toyota Stadium website as well. Customer can obtain various information regarding the prices of tickets based on the preferred seating, number of seats available, any changes in price of tickets based on various games and events happening in the Toyota Stadium. The tickets will be available for purchasing within in a month before the game and can be ordered through both debit and credit cards. Moreover, Customers will be provided an option to purchase parking tickets as the same time when they are ordering the tickets online.
1.2 System Request
System Request: Online Ticketing System
Project Sponsor: F.C Dallas, Frisco, Texas
Business Need: This system is developed to help customers buy online ticket via our Website or
mobile app.
Business Requirements:
Door sale of tickets can be a lot of hassle and time consuming. However, through the internet via cellphone or laptop now buying tickets is much more convenient and hassle free. Now we easily reserve the seats for the game and pay online in a matter of seconds. If the ticket is unavailable customers should be able to browse the game ticket through our website and mobile app. They should be able to book their game tickets, reserve seats, pay online and cancel 24 hours before game started. Customers can sign up to get a notification when the future game tickets are sold. After the payment is received, the customer will receive email notification of an invoice as well as e-ticket. If the customer wants a hard copy of the ticket, they can fill up the shipping information and will be shipped in 24 business hours.
Business Value:
Buying tickets at door used to be both time consuming and hassle for the customers. With the
use of our newly designed website people can buy tickets from anywhere in the world where
there is access of Internet. Customers can also enroll in membership program which allows
them to access lots of benefits. Our payment system is secure and safe. Buying tickets online
should benefit the business from improved customer satisfaction and increased brand recognition due to its internet presence.
Special issues or constraints:
This project would be beneficial as introduction to online ticketing system which will add value
to our current business model. In the future, we can update our website and mobile app to
make it more user friendly.
1.3 Feasibility analysis
In order to do a feasibility study, we need to identify the technical, economical and organizational factors for an effective system development.
Technical Feasibility:
The online ticketing system is feasible technically, however there is some risk.
· Technical and competent staff is required to take the responsibility of new server system and database for this Online Ticketing system.
· Since, this is a new online system there are three people with some programming expertise and, we need to add necessary hardware and software to run this system effectively.
· This system is easy to set up for both administration and customers.
· The software that is used for this system is very efficient than its counterparts.
Economic Feasibility:
To decide an economic feasibility of any project we should consider:
· Cost benefit analysis
· Long term benefits
· Maintenance cost
The proposed Online Ticketing System is internet based. Therefore, it does not incur extra economic overheads that makes the system economically feasible. The project seems profitable for business in long term because it increases the sales of online sports ticket through the internet during the sports events in a better price than other competitors.
However, it requires good access to internet.
Intangible cost and benefits:
Increased customer satisfaction.
Increased online market share.
Quick and reliable service.
Organizational Feasibility:
From organizational point of view, this project has low risk as compared to the rewards.
· This system is designed in a simple way for every customer to use it.
· Some online training will be provided to the staff on order to provide convenient service to the customer. Therefore, chance of failure of this project is very low.
1.4 Requirements Definitions
Nonfunctional Requirements
1. Operational Requirement
a. Seat availability information will be archived from the Toyota Stadium database.
b. In SAP nothing can be erased or abrogated, everything is put away and can be followed, this can be imperative as we will know what was not done right and be able to settle the issue for the future reference.
2. Performance Requirement
a. It is accessible and available 24-7.
3. Security Requirement
a. Only authorized personnel can access the system, cancel or modify the ticket.
b. Malware detection and antivirus will be installed.
4. Cultural and Political Requirements
a. No specific cultural and political requirements.
Functional Requirements
1. Maintain Ticket Information
a. The online framework ought to be able to preserve the database of the fundamental data of the accessible ticket. For instance, game time, date, venue, etc. To be concise it would reflect the complete detail such as Monday July 20, 7:00 PM, FC Dallas Vs San Jose Earthquakes at Toyota Stadium, tickets starting from $35.
b. The online system will sync with the stadium database and will update, delete or modify any new information.
2. Maintaining Ticket Marketing Information
a. We can use ads on Google, Facebook and Instagram to promote our website.
b. Customers who already have purchased from us would be able to leave a comment and a rating for the service.
c. Customers purchasing ticket can sign up for email/text notification for any future games and events or promotions.
3. Placing Order
a. Customer can enter our site and search around for particular game or events. Our system will suggest customer with different seats, prices and the availability.
b. Once the customer is in our website, a display screen would pop up with individual rows, containing their prices and ticket availability with the diagram of the stadium highlighting the different rows, seat numbers and the entrance which would let customer decide their preferable view.
c. After the customer has selected their preferred seat and are ready for the check out; they are guided towards creating an account and once their account is created, they would be able to put in their payment information and complete the purchase.
d. Customer can use the same account for any further changes if available. For instance, cancellation, upgrading, etc.
4. Shipping Order
a. Once the payment is received, customer will receive a e-ticket on their email address used during the sign-up process.
b. Customer can make the printout of the e-ticket or use the e-ticket on their electronic devices for the admissions to the stadium.
Part 2: Analysis
2.1 Activity Diagram
Whenever user visits our site, user can search the game, he wants to find available seats and purchase a ticket. Diagram below clearly shows the flow from one activity to another.
2.2 Use Case Diagram
We have designed 7 use cases for the system that contain the functions of our system. They are as follows:
· Login
· Maintain Ticket marketing information
· Maintain Ticket Information
· Book a Ticket
· Place order
· Checkout
· Confirmation
2.3 Use Case Description
|
Use Case Name: Login |
I D: 1 |
Importance Level: High |
|
Primary Actor: User |
Use Case Type: Detail, essential |
|
|
Stakeholders and Interests: Customer – wants to visit website to search for games and buy the ticket. Administrator – wants to access the create and update account information.
|
||
|
Brief Description: This use case describes how the users log into the system and access to different module. |
||
|
Trigger: The user clicks on the login button in order to find information about the games . Type: External |
||
|
Relationships: Association: Administrator, Customer Include: place order Extend: Generalization: |
||
|
Normal Flow of Events: 1. The user clicks on the “login” button in home page. 2. The user enters their login username and password. 3. The username and password are available, and the user is verified as customer. If it is verified as customer, the S-1: login as customer sub flow is performed. 4. Then, the user places the order. 5. The user clicks the logout button. 6. The user returns to the home page.
|
||
|
Sub flows: S-1: login as customer The user sees a page showing “search games” button. In search games options, customer find the list of games going on in the stadium and they can select their preferred games accordingly.
|
||
|
Alternate/Exceptional Flows: 3a1: The username or password is not valid. 3a2: The system shows an error page. 3a3: The user is returned to home page. |
|
Use Case Name: Maintain Ticket Marketing Information |
I D: 2 |
Importance Level: High |
|
Primary Actor: Maintain Ticket Marketing Information |
Use Case Type: Detail, essential |
|
|
Stakeholders and Interests: Vendors: wants to sell ticket and market it. Administrator: want to ensure that customer needs are met.
|
||
|
Brief Description: This use case describes how Vendors market their ticket to our Customers . |
||
|
Trigger: Vendors will provide all the equipment and marketing materials to promote their games in order to increase the selling of ticket . Type: External |
||
|
Relationships: Association: Vendors Include: Extend: Generalization: |
||
|
Normal Flow of Events: 1.Vendor will provide all the equipment, materials and marketing plan, so that they can promote and market their ticket availability online. 2. Toyota Stadium still reserves the right to go with their ideas. If all stakeholders agree that the idea is effective and efficient, the marketing plan will be preceded to further steps. 3. If any stakeholders do not agree on marketing plan provided by the Vendor, then A-1: Disapprove marketing plan is performed. 4. Once, the marketing plan is approved all the materials and promotion are applied for online ticket selling.
|
||
|
Sub flows: A-1: Disapprove Marketing Plan 1. If any stakeholder thinks that the Marketing Plan is not good or efficient. 2. Voting shall be done, Majority wins. 3. If the Marketing Plan fails to meet the requirement, it is not applied, and Stakeholders can follow their own ideas and plans. 4. Or, Vendors might propose another Marketing Plan that is discussed with the stakeholders and if approved it is preceded to further steps.
|
||
|
Alternate/Exceptional Flows: None |
|
Use Case Name: Maintain Ticket Information |
I D: 3 |
Importance Level: High |
|
Primary Actor: IT Department |
Use Case Type: Detail, essential |
|
|
Stakeholders and Interests: IT Department: Make sure that the ticket information is always updated, and online ticket selling is running effectively.
|
||
|
Brief Description: This use case describes how online sports ticketing information is updated by IT department. |
||
|
Trigger: IT Department update the information about current sports and online ticket availability for those sports. Type: Internal |
||
|
Relationships: Association: IT Department Include: Extend: Create Generalization: |
||
|
Normal Flow of Events: The IT professionals should be able to maintain the database of basic information of the available tickets and ongoing sports on the stadium. For example: kind of sports, price of ticket, seat availability and discounts for veterans and elderly people. 2. Once the order is placed by customer, the IT Department updates the available ticket in the inventory. 3. If there is something wrong with the system, they are responsible to get it fixed.
|
||
|
Sub flows: None
|
||
|
Alternate/Exceptional Flows: None |
|
Use Case Name: Book Ticket |
I D: 4 |
Importance Level: High |
|
Primary Actor: Customer |
Use Case Type: Essential, Detail |
|
|
Stakeholders and Interests: Customer: wants to book the ticket for available games in available date and time. Ticket Officer: make sure that customer needs are fulfilled and finalizes the booking by providing the payment information.
|
||
|
Brief Description: This use case describes how customer chooses the selected ticket and the system books the seats and issues the ticket. |
||
|
Trigger: Customer clicks on “Book Ticket” button Type: External |
||
|
Relationships: Association: Customer Include: Check out Extend: Generalization: |
||
|
Normal Flow of Events: 1. The user checks the ticket availability for selected sports. If Seat is not available in ticket category, S-1: the system informs the agent that no seats are available in the user’s selected price category. If Seat is not available i.e. fully booked. S-2: the system informs the agent that no seats are available at all. If Seat is available, user book the ticket. 2. The user then checks out from the website to confirm their order. 3. The user returns to the home page
|
||
|
Sub flows: S-1: If Seat is not available in ticket category, The user specifies another price preference. S-2: If Seat is not available i.e. fully booked, The user specifies another time preference for chosen sports.
|
||
|
Alternate/Exceptional Flows: No |
|
Use Case Name: Place Order |
I D: 5 |
Importance Level: High |
|
Primary Actor: Customer |
Use Case Type: Detail, Essential |
|
|
Stakeholders and Interests: Customer- wants to search web site to purchase ticket. Sales Representative- wants to maximize customer satisfaction. |
||
|
Brief Description: This use case describes hoe customers can search web site and place orders. |
||
|
Trigger: Customer Visit web site and place order Type: External |
||
|
Relationships: Association: Customer Include: Checkout, Book a Ticket Extend: Generalization: |
||
|
Normal Flow of Events: 1. Customer submits a search request to the system. 2. The System provides the Customer a list of ongoing sports in the Stadium. 3. The customer chooses one of the games to find the additional information. 4. The system provides the Customer with basic information. 5. The customer book a ticket. 6. The customer executes the checkout use case. 7. The customer logs out and return to home page.
|
||
|
Sub flows:
|
||
|
Alternate/Exceptional Flows: 3a-1. The customer submits a new search request to the system. 3a-2. The customer iterates oversteps 2 to 3 until satisfied with search results or gives up. 7a. the customer aborts the use case. |
|
Use Case Name: Checkout
|
I D: 6 |
Importance Level: High |
|
Primary Actor: Customer |
Use Case Type: Detail, Essential |
|
|
Stakeholders and Interests: Customer: wants to purchase, cancel of modify order. Sales Representative wants to ensure that customer needs are met.
|
||
|
Brief Description: This use case describes how orders are processed through check out.
|
||
|
Trigger: Customer can check out after they are done adding ticket to their cart. Type: External |
||
|
Relationships: Association: Customer Include: Confirmation Extend: Generalization: |
||
|
Normal Flow of Events: 1. The customer clicks the “Check out” button on the Web Page. 2. The system displays the tickets in the order table of customer on the web page. 3. The customer checks the order list for any inconsistency If nothing found customer clicks on the proceed button. 4. The system displays the invoice page. 5. The customer enters the credit card information and clicks the OK button. 6. The system checks that the credit card is valid. 7. The system will display the Confirmation use case. 8. The customer checks that all information is correct.
|
||
|
Sub flows:
|
||
|
Alternate/Exceptional Flows: Confirmation |
|
Use Case Name: Confirmation |
I D: 7 |
Importance Level: High |
|
Primary Actor: Customer Sales Representative
|
Use Case Type: Detail, Essential |
|
|
Stakeholders and Interests: Customer: wants to review the order and confirms the information provided in the system. Sales representative wants to confirm the booking information.
|
||
|
Brief Description: This use case describes how the system checks the completeness and correctness of customer’s data entry. |
||
|
Trigger: The customer clicks on “Booking Confirmation” button. Type: External |
||
|
Relationships: Association: Customer Include: Extend: Generalization: |
||
|
Normal Flow of Events: 1. The System checks the completeness and correctness of customer’s personal information and payment information. 2. The system sends e-mail confirmation.
|
||
|
Sub flows: 1a. The customer’s personal information is not completed. 1. The booking is not successful. 2. The system will send an e-mail to customer. 1b. The customer’s personal information is not corrected. 1.The booking is not successful. 2.The system will send an e-mail to customer.
|
||
|
Alternate/Exceptional Flows: The customer changes or cancels the booking |
2.4 Initial Class Diagram:
This is our initial class diagram. We have produced six classes for our project: User Class, Admin Class, Customer Class, Ticket class, Ticket Order Class, Shopping Cart Class. The administrator can manage the accounts of customers. And the customer class can manage the ticket order information and their shopping carts.
2.5 Sequence Diagram
The sequence diagrams describe the objects that participate in the use cases and the messages that pass between them over time. One sequence is corresponded to one use case.
Part 3: Design
3.1 Final Class Diagram
The final class diagram is slightly different with the initial diagram. Firstly, the Employee with the Sales rep and IT professional’s class has been deleted in the diagram because we found that there is no need to put Employee class in the class diagram. Secondly, one new Ticket class is added into the diagram. The Shipping class is used to contain the creates SL () method and some of the shipping order information.
3.2 Package Diagram
The package diagram is shown below:
Person class with Employee Class, Sales Representatives class and IT Professional class is packaged together to be the Person package. While the Customer class and Shopping cart is packaged together in Customer Package. The order class Book ticket class and Bill class is packaged together to be the order package since they all contain some information of the package. And the payment class is packaged in payment package.
3.3 Database Design
The database design is shown below. As shown in the diagram, the Customer Table contains
customer detail and administrator and couriers’ account information. The order table contains the order information for every package. The book table contains identification code of the book, its price and also description.
3.4 Data Access and Manipulation Design
The Data access and manipulating design shows the relationship between classes and databases. The line pointed from database to class shows the corresponding relationship between classes and databases.
