With the recent rise in the popularity of public transportation, many people may experience issues in planning and comparing travel routes or tracking the status of different transportation options. Sometimes services arrive full or late without notice or may not even show up at all. These factors can deteriorate the overall experience of taking public transportation which is an otherwise great service.
In an attempt to address these issues, Fast Travel was created. It enables you to plan, manage, and compare a wide range of public transportation options in a more intuitive and detailed manner. Supporting monitoring of transportation options keeps you informed about the state of different services, allowing you to make the best decisions on what routes to take. These routes can be generated on differing requirements and be saved for later use. With this service, the biggest issues with the current public transportation system are resolved to provide a better overall experience.
Name: Caleb Clarke
Student number: 47428364
The system enables users to create, manage and compare travel routes using public transportation to find an option that works best for their needs. This gives users the necessary information they need such that they have control over their own commuting experience.
The features necessary for the software system are as follows:
To achieve the Minimum Viable Product for the system, the following features should be implemented:
Availability is the capability for users to access the software in as many different capacities as possible. In this case, availability means that the software should work at any time and be supported by a multitude of devices, and still have limited functionality without internet service. This allows for different users to make use of the software in many situations.
Since many different types of users will be using the software at all hours of the day, it must be as easy to access and use as possible. This means that it should be available across multiple devices and still maintain limited functionality even when offline. By reducing the collective number of API calls and moving the logic internally, these users should be able to view saved routes and estimated schedules with poor connection quality.
Availability is the capability for users to access the software in as many different capacities as possible. In this case, availability means that the software should work at any time and be supported by a multitude of devices, and still have limited functionality without internet service. This allows for different users to make use of the software in many situations.
Since many different types of users will be using the software at all hours of the day, it must be as easy to access and use as possible. This means that it should be available across multiple devices and still maintain limited functionality even when offline. By reducing the collective number of API calls and moving the logic internally, these users should be able to view saved routes and estimated schedules with poor connection quality.
Scalability is the software tolerance for large varying user loads that may come and go at different times. For the software, scalability is an important component because it is expected to experience very high loads during its peaks, with significantly less usage during less active hours. This ensures that even with high user counts the software will still work for all the users while not wasting money when there are fewer active users.
The number of users throughout the day will fluctuate greatly with peaks in the morning and evening. On the contrary, there are likely to be significantly fewer users at later hours of the night. Because of this, the system will need to be able to handle these peak hours while minimising the infrastructure costs while there is less traffic. Therefore, most of the logic should be processed by the user’s device in separate modules allowing the system to scale dynamically based on demand.
To evaluate the availability of the system, some key requirements have to be met alongside some more subjective goals. The system must work on different devices without issues (iOS, Android, and Web platforms) as well as be functional without internet service. The degree of offline functionality is a bit more subjective, but there should be a way to use access save routes and schedule data with limited connection.
To judge the maintainability of the system, component failures should be simulated and subsequently fixed. The impact of the failure on the system components and the difficulty of solving it should be measured. A separate test should be conducted where the time taken for the service to be taken down and restarted for updates should be measured.
To understand the scalability of the system, a test should be done with varying simulated user loads and measure the limits as well as connection times for these loads. When the system is not in high demand, the performance of the service should be reduced to optimise the infrastructure costs.