Car Pool Reservation System - Case Study Example

Car Pool Reservation System Student Name Institution Affiliation Car Pool Reservation System 1.0 Introduction Car Pool Reservations is an online solution that allows that allows car owners to connect with other people within the same locality. In that way, a group of people from the same area can use one vehicle to travel to and from work. Therefore, this solution helps to bring car owners and those without together. However, those without cars pay a small fee where the system takes a small commission and the rest given to the drivers. Once an individual is registered into the system, they may request for transport or provide one. The work of the admin is to connect members requesting for transport and those providing. Non-members can visit the site to see the available service to consider whether they would like to benefit from this arrangement. The benefit of the solution is that it saves on the cost of fuel since various members can use one vehicle to get to work and back home. Also, it provides car owners with the access to insurance policies and RFID chips to track their vehicle. The system works together will toll officials to help drivers navigate through traffic and therefore reach their destinations fast. 2.0 Glossary of Terms 3.0 Project Scope This project offers an arrangement where members with car and those without are connected. As such, the members without vehicles are offered transport to work and back to their homes. However, for the arrangement to work, members must come from the same area as required for instance Brisbane, Perth and Melbourne. Interested members are required to log in the system and request for the type of service they need. For example, those without vehicles should ask for transportation services and the others the chance to offer their cars to carry people. The system requires that a member should only register their vehicle once and it should have insurance cover and RFID trackers. On one hand, interested individuals should register by submitting their details such as name and address. On the other hand, those with vehicles are require to submit their car details and then pay the membership fee. 3.1 Functional Requirements Functional requirements defines what a system can do and includes calculations, manipulation of data, technical details and particular details. The objective is to show what a system such as CPR can accomplish. In that case, they include the following; Allow new members to register by submitting their details to the system and then give their membership fee to complete this process Enable the admin to manage the contact details of the registered members though editing and deleting when necessary The admin should be able to verify membership information then sell and install RFID chips for new members’ vehicle for purposes of tracking them Allow both the admin and members to check for available services for instance find if there are ready vehicles The system should connect insurance clerks to vehicle owners to offer them insurance policies upon requests. Once a user has registered successfully, they should be in a position to select a service say find a driver in a given locality with ease. The system should also provide details of available drivers and when they can provide transportation services. Match the addresses of vehicle owners and the members in need of transport in the same locality The system should coordinate with toll officials to help drivers to maneuver traffic situations and reach their destinations fast This system should effectively record the details of sharing arrangements between the members with car and those without Non-members should be in a position to view insurance quotes and the services offered by the system The authenticated staff should generate the franchise performance records upon request Authenticated staff should provide the details of the potential car sharers. The system should be able to get a fraction of the car owners earnings and provide the net result as income to such members The system should effectively ensure that vehicle owners get their right money after carrying people to and from work 3.2 Non-Functional Requirements The non-functional requirements are the aspects used to describe a system’s characteristics and what would possibly limit its operability. On that note, the following list describes the non-functional requirements; It is expected that the system should be available throughout irrespective of outages or technical problems As the system grows, it should support the increasing number of users to show that it is scalable and its database is capable of maintaining the large data. The system’s capacity should not be limited by increased transactions. Rather, it should maintain efficiency so that car owners and those without can be matched to complete service provision. The system’s usability is expected to be easy to the members so that they can access what they want in either the website or tablet option at any time. Most importantly, the system should show high recoverability in the event of outages and failure to ensure that the much-needed service is available to the members The system should be dependable so that members of the company can be sure that they can access the services they want at any time without experiencing technical hitches. In the event of a breakdown, the system should be serviceable such that within a short time, it should be live so that it serves its purpose. Another critical factor is the security of the system. It should provide secure payments of services and protect the information of members from online attackers as well as unauthorized people. While the system proposes a new concept in the market, it should be manageable considering that the business idea has the potential to grow owing to the benefits it offered to its registered members. Also, the system should show interoperability. The fact that it will be accessed through a website and as a mobile app, there should be no conflict. Members should find it as easy to access the system in either of the platforms. A critical issue concerning the system is data integrity. In that case, the database should be protected to ensure that the information saved is not changed or corrupted by unauthorized individuals. It should remain consistent as the system scales. The system admin should be in control of the system such that they can control transactions and ensure that everything runs in accordance with the system objectives. The Car Pool Reservation System should show resilience in times of outages and network issues such that it should not hang. Rather, the current transactions should terminate and new ones initiated when the system resumes. Finally, the system should be safe from online attackers to prevent intrusion and the spread of malicious malware meant to cripple the services of the company. In that way, users will be assured that the information they share via this website will remain confidential and protected from outside access. 3.3 Out of Scope Items This section covers all the things that the Car Pool Reservation System is not meant to offer the registered members. Such comprise the following; Allowing members to manipulate the contact and registration members of others. The system will not allow a member to register more than one vehicle This system will be designed such that it will not allow a car owner to operate without having installed RFID trackers and having an insurance policy. Member registration will not be completed if one does not provide all the required details and provide their membership fee. The truthfulness of the information provided via this site cannot be fully verified. Therefore, it is upon the users to feel obliged and provide information as required without hiding critical details. Most importantly, the system will not cover the relationships of drivers and members requesting for transport services. The security concerns of car owners will not be addressed, the system will only track the vehicles in the bid to provide the drivers with navigation information. 4.0 Assumptions This part will cover the issues expected to affect the model of the Car Pool Reservation System. They include the following; It is expected that the user should find it easy to register, and request for services from either the system’s website or mobile platforms. The system should be available and ensure optimum performance throughout irrespective of downtime and failures. The database should maintain data integrity as it grows such that information will remain consistent and unchanged. Also, the security of the system’s services should be guaranteed such that issues such as denial of service and malicious software will be prevented from interfering with the access to the much-needed services, System capacity should not be hindered by issues such as internet connectivity and technical difficulties. The system should be manageable to ensure the control of process by the admin. All the users should interact with the system comfortably and produce the right actions irrespective of whether one is a first time user or not. The system will work as designed and therefore all transactions should reach completion unless if interrupted by outages and network challenges at the head office. If a user encounters a problem, then they should reach out to the support for assistance or reach the manual provided at the how it works section of the website and tablet app. 5.0 Use Case Diagram Elaboration of CPR Use Case Use case: Actor(s): < Admin>, and Purpose: Overview: < This use case begins with the registration of members upon which they are required to provide their details such a name and address. The process is completed with the submission of the registration fee. After successful registration, a member can have the access to services where they can provide transport or request for it. However, before a member with a vehicle is allowed to provide transport services, they are required to have a tracker and insurance for their car. With that, an insurance clerk is available to provide a car owner with recommendations on insurance policies based on current information. The use case ends with the car owner being provided with a policy recommendation.> Preconditions: < It can be assumed that a new members knows what the system is supposed to do and the requirements they should fulfil. More so, their interest in the system is because of the need for the service and associated benefits. Therefore, they are willing to comply with the set rules to avoid violation of regulations. On the other hand, it is assumed that the system will perform as required. Furthermore, it will be manageable, serviceable, interoperable and available despite technical challenges.> Postconditions: Typical Course of Events Actor Action System Response 1. 2. Register A new member is required to provide relevant details upon which the system successfully receives the request. Provide transport A registered member is allowed by the system to offer transport services to others from the same location. Request transport A member can ask for transport services and pay a fee from a driver in their area. Review membership details The system should allow the admin to verify the details of members before allowing them to access a service. Recommend policy After a vehicle owner request for a policy, the system should provide a recommendation through an insurance clerk. Alternate Courses Related Use Cases Inclusions Extensions 5.2 ELABORATION OF USE CASE Use case: < CPR Income > Actor(s): & Purpose: Overview: Preconditions: Postconditions: Typical Course of Events Actor Action System Response 1. 2. Pay membership fee A fresh member is required to give their membership fee to have full access to the system. Get insurance commission The system gets a commission from the sale of insurance policies to vehicle owners. Charge driver commission The systems get a portion of the total amount earned by a member giving transport services. Provide earnings details The admin provides the driver with a report of their earnings Earn money After deductions, the driver gets their net income. Alternative Courses Related Use Cases 5.3 ELABORATION OF USE CASE Use case: < Insurance Policy> Actor(s): & Purpose: Overview: Preconditions: Postconditions: Typical Course of Events Actor Action System Response 1. 2. Request insurance policy A user makes a request for recommendations on the best insurance policies. Verify user’s age The insurance clerk verifies the user’s age to determine whether they qualify for the service. Recommend policy After gathering enough information, the insurance clerk provides a recommendation on the best options. Inquire vehicle’s garage information The insurance clerk is required to evaluate the user’s garage information to determine the insurance policy that suits them. Get policy Finally, the user’s request is completed with the provision of the right insurance policy option for them. Alternative Courses Search policies: . Related Use Cases Inclusions 5.4 ELABORATION OF USE CASE Use case: Actor(s): & Purpose: Overview: Preconditions: Postconditions: Typical Course of Events Actor Action System Response 1. 2. Request insurance policy The user makes a request for information on the best insurance policies Request membership fee The system admin ensures that the new member submits their membership fee. Review details The system evaluates the new user to ensure that they have submitted the required details. Related Use Cases Inclusions Extensions 8.0 BUSINESS RULES DIAGRAMS 8.1 BRD OF 8.2 EVENT SPECIFICATION TABLE OF Event Source Action Object Destination Enter registration details CPR Confirm details Request service CPR Provide service CPR Determine service type Get a driver CPR Service type CPR Enter registration details Start CPR 8.3 BRD OF 8.4 EVENT SPECIFICATION TABLE OF Event Source Action Object Destination Get membership fee CPR Income Determine payment Decision item CPR Income Confirm membership payment CPR Income Take a decision Decision item CPR Income 8.5 BRD OF 8.6 EVENT SPECIFICATION TABLE OF Event Source Action Object Destination Login Member determination Enter details Decision process Insurance policy Request insurance policy Member Next evaluation criterion Process object Insurance policy 8.7 BRD OF 8.8 EVENT SPECIFICATION TABLE OF Event Source Action Object Destination Service request Extends Evaluate request Decision object Extends Request evaluation Service request Get membership fee Process object Service request Read More