MAULANA ABUL KALAM AZAD UNIVERSITY OF TECHNOLOGY
SOFTWARE ENGINEERING
PCA 1
NAME : SOURAV YADAV
ROLL NO : 10071023021
REG. NO : 231000510715
PAPER CODE : MCAC393
DEPARTMENT : MCA
SEMESTER : 3RD
INDEX
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 Assumptions and Dependencies
3. Specific Requirements
3.1 Functional Requirements
3.2 Non-Functional Requirements
3.3 Interface Requirements
4. Other Non-Functional Requirements
4.1 Performance Requirements
4.2 Security Requirements
4.3 Reliability Requirements
4.4 Maintainability
5. Appendices
5.1 Future Scope
5.2 Glossary
1. INTRODUCTION
1.1 Purpose
The MedVan Ambulance Booking App aims to provide a seamless platform for users to book
ambulances in emergencies. The app includes two interfaces: one for customers to request
ambulances and another for drivers to accept and fulfill the requests. The system ensures automated
ride allocation to the nearest available ambulance driver.
1.2 Scope
The MedVan application will serve individuals in need of emergency medical transportation. It
ensures:
• Real-time ambulance booking.
• Automated allocation of the nearest ambulance.
• Easy communication between users and drivers.
• Secure authentication using Firebase.
The app will include features such as ride history, driver tracking, and notifications. It is expected to
be compatible with Android and iOS platforms.
1.3 Definitions, Acronyms, and Abbreviations
• SRS: Software Requirement Specification.
• UI: User Interface.
• Firebase: Backend-as-a-Service platform used for authentication and database integration.
1.4 References
• GeeksforGeeks
• Firebase Documentation
1.5 Overview
The document details the functional and non-functional requirements, constraints, and
dependencies for the MedVan Ambulance Booking App.
2. OVERALL DESCRIPTION
2.1 Product Perspective
The app is a real-time booking system with two distinct user types:
1. Customers: Request ambulances through a simple interface.
2. Drivers: Accept or be automatically assigned rides.
2.2 Product Features
• User authentication and registration (via Firebase).
• Real-time location tracking.
• Automatic allocation of the nearest ambulance.
• Push notifications for booking status.
• Ride history for customers and drivers.
2.3 User Classes and Characteristics
• Customers: Individuals needing emergency medical transport.
• Drivers: Certified ambulance operators.
2.4 Operating Environment
The application will run on:
• Android (version 8.0 and above).
• iOS (version 12.0 and above).
2.5 Design and Implementation Constraints
• Integration with Firebase for authentication and database management.
• Dependence on GPS services for real-time tracking.
• Compliance with privacy and security regulations.
2.6 Assumptions and Dependencies
• Users and drivers must have a stable internet connection.
• Drivers are expected to keep their location services turned on.
3. SPECIFIC REQUIREMENTS
3.1 Functional Requirements
• Authentication: Secure login and registration via Firebase.
• Customer Module:
o Book an ambulance with real-time location input.
o View ride history.
o Receive notifications on ride status.
• Driver Module:
o Accept or automatically be assigned rides.
o View upcoming and past rides.
• Admin Module (future scope):
o Manage users and drivers.
o Monitor bookings.
3.2 Non-Functional Requirements
• Performance: The app must process bookings within 2 seconds.
• Scalability: The system should support up to 10,000 concurrent users.
• Security: Use encrypted communications for sensitive data.
• Availability: Ensure 99.9% uptime.
3.3 Interface Requirements
• User Interface:
o Intuitive design for ease of use.
o Responsive layout for mobile devices.
• Hardware Interface:
o GPS and internet connectivity required.
• Software Interface:
o Firebase for backend integration.
4. OTHER NON-FUNCTIONAL REQUIREMENTS
4.1 Performance Requirements
• The system should locate and assign the nearest driver within 5 seconds.
4.2 Security Requirements
• Multi-factor authentication for users and drivers.
• Data encryption in transit and at rest.
4.3 Reliability Requirements
• System should handle failures gracefully, ensuring data integrity.
4.4 Maintainability
• Modular architecture for easy updates and bug fixes.
5. APPENDICES
5.1 Future Scope
• Expansion to include SOS calls.
• Integration with hospitals for faster dispatch.
• Support for multiple languages.
5.2 Glossary
• SOS: Emergency distress signal.
• Admin: Administrator responsible for managing system operations.
