Cinema Booking Ticket
E-Cinema Booking Project
The project is a web-based application that allows the cinema owner and viewers to handle all online cinema activities quickly and securely. Using the interactive graphical user interface, anyone can learn to use the complete system quickly. As, the owner does not have to sit down and completely manage the activities on paper. Meanwhile, this system gives them the power and flexibility to manage the entire system from a single online portal. Online movie ticket reservation provides movie ticketing, seat management, ticket cancellation, and payment services. The system will be very simple and attractive which makes fans / viewers comfortable to use and choose favorite movie with desired seat number and seat position.
The viewer can also quickly search for the required movie and the number of seats from the different options available, and this will be all easy to use so that the audience will have no problem booking a movie ticket. Also, the system allows the owner to check ticketing progress from interactive charts, and the system allows the owner to track available seats for a specific movie and even preserve various details about audiences. Viewers can also watch movies that are shown in the cinema or those that will be released for a short period along with their showtimes and also book tickets online through the use of various payment gateways such as ATM / credit / debit cards.
A- SYSTEM ANALYSIS
I. Product Features: List and explain major product features to be developed in the section
II. Functional Requirements: All functional requirements (in relation with the production features identified
in the section above) are expressed as use-cases as well as analysis models and
deign models are included in this chapter. Fill out the following template for
each use-case. Don’t really say “Use-Case 1.” State the use-case name in just a
few words e.g. “Withdraw Cash from ATM”. A use-case may have multiple
alternate courses of action. 3 use case table in minimum
Use-Case 1
Identifier UC-1
Purpose …
Priority <Choose one from {High, Medium, Low}>
Pre-conditions …
Post-conditions …
Typical Course of Action
S# Actor Action System Response
1
2
3
…
Alternate Course of Action
S# Actor Action System Response
1 Step 1 System Response 1
2 New response 1 Trigger 2
3
…
Use-Case 2 (and so on)
III. Nonfunctional Requirements
Performance Requirements
If there are performance requirements for the product under various
circumstances, state them here and explain their rationale, to help the
developers understand the intent and make suitable design choices. Specify the
timing relationships for real time systems. Make such requirements as specific
as possible. You may need to state performance requirements for individual
functional requirements or features.
Safety Requirements
Specify those requirements that are concerned with possible loss, damage, or
harm that could result from the use of the product. Define any safeguards or
actions that must be taken, as well as actions that must be prevented. Refer to
any external policies or regulations that state safety issues that affect the
product’s design or use. Define any safety certifications that must be satisfied.
Security Requirements
Specify any requirements regarding security or privacy issues surrounding use
of the product or protection of the data used or created by the product. Define
any user identity authentication requirements. Refer to any external policies or
regulations containing security issues that affect the product. Define any
security or privacy certifications that must be satisfied.
Software Quality Attributes
Specify any additional quality characteristics for the product that will be
important to either the customers or the developers. Some to consider are
adaptability, availability, correctness, flexibility, interoperability,
maintainability, portability, reliability, reusability, robustness, testability, and
usability. Write these to be specific, quantitative, and verifiable when possible.
At the least, clarify the relative preferences for various attributes, such as ease
of use over ease of learning.
Other Requirements
Define any other requirements not covered elsewhere in the SRS. These might
include database requirements, external (hardware, software, or
communication) interface requirements, internationalization requirements,
legal requirements, and reuse objectives for the project.
IV. Analysis Models
Include the following analysis models: use-case diagram
Note: Every model should be described under separate level 03 heading and with brief description (important)
B- SYSTEM DESIGN
Include the following design model with:
- Component diagram
- Deployment diagram
- Design level sequence diagram
- Complete class diagram
- Entity-relationship diagram
- Data flow diagram
Note: Every model should be described under separate level 03 heading and with brief description (important)