SMH + A GitHub Wiki

The listing below includes the necessary documents and procedures for our current project.

Business Vision

Purpose: Creating a mobile application that will be used as a ticketing system for all the College of Charleston events. This system will allow users to purchase and post College of Charleston events.

Overview: Implement software (to be determined) for College of Charleston events that interact with a database.

Technical requirements:

• Must be built using the Java (or equivalent) object oriented language.
• Must include unit tests for each applicable methods.

Must Have’s (MVP):

• Secure login

  • Unique username
  • Password must be 15 characters and include lower case letter, upper case letter, number, and special character

• Functions of the system

  • Allow users to search for events
  • Allow users to purchase tickets for events, if they are available
  • Mock process payment
  • Display message of payment success
  • Update ticket inventory

Stretch goals:

• Add purchased tickets event date/time and info to the user's Google Calendar
• Allow users to choose their seats (if seated event)
• Update seat map

Summary

1. Register user: cofc email: username, password | cofc student involved
2. Log-in use case: username, password | backend, user involved
3. Find an event: User searches for an event: location, duration of the event, number of tickets available
4. Paying for event: payment available: cougar card, debits, credit card | enter card information and submit payment
5. Event cancelation: cancel, submit
6. Updating ticket availability
7. Contact us: issues including payment not going through, event canceled/refund, change of time and location
8. Manage profile: picture, contact info

Fully Dressed Use Cases

Case 1

Use Case Name:	Checking Availability
Scope:	The system is under design
Level:	“User - Goal” or subfunction
Stakeholders and Interest:	People trying to find how many tickets are left
Primary Actor:	Any person trying to get tickets for a CofC event
Preconditions:	There must be tickets available for people to buy for the event
Success Guarantee:	If they have bought a ticket, then the counter of how many available tickets must go down
Main Success Guarantee:	Searching for a CofC event, visually showing the amount of tickets left, if available allow them to buy the ticket
Extensions:	A failure would involve when people are buying the ticket, the availability counter is not updating
Special Requirements:	Adding a timer for sales, showing how many tickets are left without clicking on the event, and pictures for the background of the event so that it has more appeal to the users.
Technology and Data Variations List:	Use PayPal to buy the tickets, Using Apple Pay instead of manually typing the numbers on the user’s card
Frequency of Occurrence:	Could be nearly continuous
Miscellaneous:	Open Issues (None at the moment, will update per project)

Case 2

Use Case Name:	Purchase ticket
Scope:	The system is under design
Level:	“User - Goal” or subfunction
Stakeholders and Interest:	People trying to purchase tickets for a CofC event
Primary Actor:	Any person trying to purchase tickets for a CofC event
Preconditions:	The person must have a cougar card, debit card, credit card, PayPal account, or Apple Pay to purchase tickets.
Success Guarantee:	If they have bought the ticket then the screen will display a receipt
Main Success Guarantee:	The user will have the receipt of the purchased ticket saved on their in-app account
Extensions:	A failure would involve the transaction not going through due to insufficient funds or a program error
Special Requirements:	Adding a timer for sales, having the user select the number of tickets they are purchasing, and having the user enter their email and phone number while purchasing
Technology and Data Variations List:	Use PayPal to buy the tickets, Using Apple Pay instead of manually typing the numbers on the user’s card, and using CofC ID to get access to free tickets
Frequency of Occurrence:	Could be nearly continuous
Miscellaneous:	Open Issues (None at the moment, will update per project)

Domain Model

System Sequence Diagrams

Supplementary Specification

Revision History:

Version:	Date:	Description:	Author:
Inception Draft	September 14, 2023	First Draft, To Be Refined	SMH + A

Introduction: Document for all requirements not captured in the use cases

Functionality: (Functionality common across many use cases)

Logging and Error Handling: Log all errors to persistent storage

Security: All usage requires you to be logged in using a username and a special password

Usability Human Factors: Customers trying to buy tickets for events at the College of Charleston should feel an easy way to access the tickets and know the price of them. Therefore:

• Text should be visible enough from 1 meter.
• Use colors that work with the different kinds of color blindness.
• App should follow standard design conventions; such as, well known button icons. Allowing the UI to be very easy to follow will make it flow relatively well and the user will be able to check the availability of the tickets as well as buying the tickets.

Reliability Recoverability: In the event that there are issues with outside sources; such as payment authorization, the team will use their own local solution to complete the sale of the ticket. (Figure out the specifics of this later)

Performance: People purchasing tickets and checking the availability of tickets want to have the system work very quickly so that they can get the ticket and be done. We need the system to have the authorization be under a minute

Supportability Adaptability: Each user in the application has a different business rule depending on the need during the process of the sale and how the events are output into the system.

Configurability: Unsure of configurations currently. Will be discussed soon.

Implementation Constraints: Undecided on what technology the team will be using.

Purchased Components: None at the moment, will be changed in the future.

Free Open Source Components: Once the team has decided on the technology, the open source components of that software will be used to optimize the development process.

Interfaces Noteworthy Hardware and Interface: Hardware:

• Touchscreeen device (cell phone tablet, laptop, etc.)
• Non-touchscreen device (desktop, laptop, etc.)

Software Interfaces: Software Interface will be a web application that is run on a browser.

Application-Specific Domain (Business) Rules:

ID	Rule	Changeability	Source
RULE1	Purchaser discount rule. Examples: CofC Employee 20% off, CofC Alumna 10% off, CofC Student free	High: Depending on the event and who it is made for the rules may vary.	CofC Event policy
RULE2	Sale (transaction-level) discount rules: Applies to pre-tax total. Examples: Buy a ticket, get 1 free for a friend; Free ticket after a certain amount of games attended	High: Each CofC event uses different rules depending on the kind of event, day, and hour.	CofC Event policy

Legal Issues The team will be using open source components to prevent licensing and legal restrictions to allow for the sale of College of Charleston events and tickets to events. All state tax rules will be applied, by law, but can change often.

Information in Domains of Interest Pricing: Pricing must be disclosed on the website prior to being purchased.

Credit and Payment Handling: When the payment is process and approved, this payment is to then go to the seller and not the buyer.

Sales Tax: Sales tax will be static and be added to every purchase.

Glossary

analysis: An investigation of a domain that results in describing its static and dynamic characteristics. It emphasizes questions of “what,” rather than “how.”

availability: The quality or state of being available. In terms of the ticketing system, if there are tickets available for the desired event.

ticket: A certificate or token showing that a fare or admission fee has been paid.

Prototype

System Sequence Diagrams

Operation Contracts

Check Ticket Availability

Operation	SearchEvent(eventName: String)
Cross Reference	Check ticket availability
Pre Condition	The user must be logged in and on the homepage of the application. The user must have either selected or typed in the specific event they are looking for.
Post Condition	If they have fulfilled the necessary requirements for searching for the event, then the user will be able to select the event on the application.

Operation	LookTicket(ticketID: String)
Cross Reference	Check ticket availability
Pre Condition	There is a user, user is logged in, user searched for an event, and has selected the event of their choosing
Post Condition	Ticket info is updated and returned if there are tickets available

Operation	ReturnTicketInfo()
Cross Reference	Check ticket availability
Pre Condition	The ticket info
Post Condition	The ticket info and availability is sent and displayed to the user

Login Accessibility

Operation	createUser()
Cross Reference	Creating a login for a user (login accessibility)
Pre Condition	The person must have a unique username and a password that must be 15 characters and include lower case letter, upper case letter, number, and special character
Post Condition	If they have fulfilled the necessary requirements for a unique username and a password with all of the following conditions, then they will be accepted into the system

Operation	userConfirm()
Cross Reference	The system has accepted the user into the system (login accessibility)
Pre Condition	The person must have a unique username and a password that must be 15 characters and include lower case letter, upper case letter, number, and special character
Post Condition	If they have fulfilled the necessary requirements for a unique username and a password with all of the following conditions, then they will be accepted into the system

Purchase Tickets

Operation	purchaseTickets(ticketID: int)
Cross Reference	Purchase Tickets
Pre Condition	The user has logged in, added tickets to their cart, and then selected “Purchase Tickets”
Post Condition	The ticket inventories are updated.

Operation	updateInventory(ticketID: int)
Cross Reference	Purchase Tickets
Pre Condition	The user has logged in, added tickets to their cart, and then selected “Purchase Tickets,” and the ticket inventories need to be updated
Post Condition	The ticket inventories are updated and are confirmed

Operation	confirmation(conNum: int, tickets: string)
Cross Reference	Purchase Tickets
Pre Condition	The user has logged in, added tickets to their cart, then selected “Purchase Tickets,” and the ticket inventories are updated
Post Condition	A confirmation number is created and printed on the confirmation screen with the purchased tickets