"Thalia Tix" - Ticketing Software for Theatres
2. Acceptance Criteria
The basic implementation of the project assumes the application runs on a server and that various clients access it through a REST interface.
The RESTful API will be available here as soon as we clarify the project detail. This process will require you to ask lots of questions, in class, via email, etc.
I will not change the high-level requirements as a result of the requirements clarification process. However, I will document the decisions made in the Q&A document.
Here is the scenario that will be used to test your application.
3. Questions and Answers
Check here for answers before asking your TA or the teacher.
4. Extra Credit
The main purpose of this project is to practice object-oriented analysis, design and programming, not to teach you web development frameworks or relational databases. As such, the use of a database is expressly prohibited for the core project implementation.
There is a finer point to be made about the databases ban, namely that most students would start with the design of a database schema, the way they learned in a Databases class, instead of thinking about use cases, entity objects, etc.
In fact, the database should be a plug-in to your application, the same way the delivery mechanism should be, whether command line, web, etc.
We can talk about extra credit iff (if and only if) your core project implementation works impeccably. This point will not be debated.
If you complete your core project implementation on time and feel adventurous, then you can get extra credit for implementing a web client for the customer.
5. Project Description
I'm a small theatre owner and we've been selling tickets at the box office for as long as I can remember. Virgil has convinced me that his programming class can produce software that would help us manage our seat inventory and sell tickets for shows on the Internet. He asked me to describe what I expect the software to do for us, so here it is, in the next few paragraphs.
Theaters have seats arranged in rows. Multiple seats in the same area are sometimes grouped in sections, such as "main", "mezzanine", "balcony". All seats in a section cost the same amount. Some sections may not be available for certain shows.
Prices vary depending on the show and sometimes between different runs for the same show, for instance the matinee is often times cheaper than the same show in the evening.
Of course we'd like to offer our patrons the ability to purchase tickets online for any of the shows that have been loaded in the system. Patrons should be able to see what shows are available and their dates and times, in addition to specific information about each show, such as director, author, cast, etc.
Patrons should be able to request one or more tickets for a show, in a specific section, and the system will return a block of contiguous seats in that section such that the patron can review them before placing the order. If the user is happy with the selection, then they can submit payment information (payment by CC only) and the system will reserve the tickets for that user; the system will also return a confirmation number for the order that can be later used to retrieve the order detail by the user and by our customer service employees in case they need to.
Sometimes the patrons are not happy with the seat selection recommended by the system and may request another set of seats in the same section, in which case the system will attempt to return for their review another block of contiguous seats. If contiguous seating is not available in the section, then the system will return seats that are not contiguous in the same section and notify the patron that they aren't contiguous. Lastly, if not enough seats are available in the section, then the system will return no seats for review and just inform that patron.
Other times the patrons will request one or more specific seats they want to reserve for a certain show. The system will return for each seat the price and an indicator as to whether the seat is available for purchase or not. The patron has the option to submit a request to purchase tickets for all seats in the recommendation that are available or only some of them.
Tickets cannot be refunded, all orders are final. However, patrons may decide to donate one or more of their tickets, in which case such tickets will be assigned to people who sign-up for donated tickets in a first come first served basis. These users should be able to check from time to time to find out if they got lucky.
I'm hoping that we'll be able to scan tickets at the entrance such that we know which tickets have been used and which ones haven't. Each ticket can only be used once.
My theatre manager wants to know the occupancy for each show and how much revenue has been generated by ticket sales for each show. She also wants to know how much revenue has been generated by ticket sales between any two dates. In addition to all this revenue reporting, the manager will want to know how many tickets have been donated between any two dates, how many of the donated tickets have been used and the total dollar value of donated tickets and donated and used tickets.
The customer services employees should be able to search for any customer by their name, or by the information used to pay for the tickets, or by their email address or phone number.
Here are some ideas for the future:
$Id: project.html,v 1.3 2017/09/12 21:35:06 virgil Exp $