Innovative Car Parking System For Melbourne CBD - Collins Parking

Requirements specification

Collin’s Parking operates twenty car parks in Melbourne CBD. The city administration has a requirement for a new and innovative system to control its car parks. The new system should therefore be capable to handle the day-to-day operation of each car park, which include: generate tickets (i.e. daily, weekly, monthly, and annual), accept tickets, handle payments, control boom gates, record problems in a log book, and manage security. Detailed information on some aspects of the Collin’s Parking car parking system is listed below. Types of customers There are two types of customers: ordinary customers, who pay every time whenever they use the car park; and fixed customers, who pay a fixed amount in advance to park their vehicles for week(s), month(s) and year in a specific car park.

It is compulsory that a fixed customer can only park their vehicles in the designated spaces which are not available to ordinary customers. Tickets Generation Depending on the type of user, the following types of tickets can be generated: (1) a fixed ticket is issued to a named individual or company, and the contact details (i.e. name, mobile number, residential address and emergency details) is recorded. These tickets could be issued for week(s), month(s) and year with a certain expiry date. However, an ordinary ticket is issued for a short term (i.e. daily for few hours or a complete day) stay at the car park. Parking fees Parking fees need to be calculated by using the following mechanism.

Fixed customer 1 week 50 AUD 2 weeks 95 AUD 1 month 150 AUD 3 months 350 AUD 6 months 575 AUD 12 months 800 AUD Ordinary customer Early bird (during weekday’s midnight to 10 AM) 2.5 AUD per hour Normal rate (during weekdays 10 AM to midnight) 5 AUD per hour Early bird (during weekend’s midnight to 10 AM) 5 AUD per hour Normal rate (during weekend’s 10 AM to midnight) 10 AUD per hour Mode of payment Payment at car park can only be made through Card (Master / VISA / DEBT) or Cash (50c, 1$, 2$, 5$, 10$, 20$, 50$) Access to the Car Park When a car approaches an entry barrier, its presence is detected by a sensor under the road surface, and a ‘Press Button’ display is flashed on the control pillar. The ordinary customer must press a button on the control pillar, and a ticket is printed and issued. The ticket must be printed within five seconds.

A ‘Take Ticket’ display is flashed on the control pillar. When the customer pulls the ticket from the control pillar, the barrier is raised. If the car park is full, no ticket is issued, and a ‘Full’ display is flashed on the control pillar. The fixed ticket holder does not press the button, but insert their fixed ticket into a slot on the control pillar. A check is made that the ticket is valid for this car park and has not expired. If all these checks are passed, then the barrier is raised. The checks must take no longer than five seconds. A record is made of the time of entry. Exit the Car Park Fixed ticket holders do not have to go to the pay station, when they are ready to leave the car park, they go to the exit and insert their ticket into a slot on the exit barrier control pillar. The barrier is raised and a record is made of the time at which the ticket holder left.

Ordinary ticket holders should go to the payment station to pay for their trip. To do so, the ticket is inserted into a slot, the bar code is checked and the fees will be calculated. Upon successful payment, the customer can go to the exit and insert their ticket into a slot on the exit barrier control pillar. The barrier is raised and a record is made of the time at which the ticket holder left. Security Management The City administration has a contract with security companies to visit the car parks at regular intervals. The contract specifies the number of visits per day to each car park and the minimum duration of each visit.

When a security guard arrives in a car park, he or she puts a card into the card reader and the date and time of arrival is recorded. When the security guard leaves, he or she puts the card in again, and the departure time is recorded. (This card also allows security guards to enter and leave the car park in the same way as fixed ticket holders. However, this is not used to record the arrival and departure of security guards, as they may not be able to enter with a vehicle if there is a queue of cars at the barrier.) Note In case of missing information, kindly make suitable assumptions and mention them in your assignment.

1 Requirements specification

This section discusses the functional and non-functional requirements of the proposed Collin’s car park system.

a.Functional requirements

Functional requirements are requirements specified by the user of the system to help them perform various tasks using the system (Ambler, 2018). They specify how the user interacts with the system to perform various tasks defined within the scope of the system. Collin’s car park system has different type of users that interact with the system. These users include the customers i.e. fixed and ordinary customers and the security persons who perform schedules security checks in the car parks. The proposed system manages the usage of the car park by the users. The following are the functional requirements for the proposed car park system.

b.Non-functional requirements

Non-functional requirements are requirements that are used to specify the criteria on which the operation of a system is judged. Functional requirements specify the behavior of a system and what is expected of the system while non-functional requirements are specify how the system should perform the functional requirements (Labunisky, 2017). The following are the functional requirements for the proposed Collin’s Car park System.

1. Security- Considering the nature of the proposed system, this is perhaps one of the most crucial non-functional requirement. The proposed system should be able to ensure security at very many levels. These levels are;

• The system should ensure that no unauthorized entry into the car park should happen. The system should be developed to make sure that all types of entries i.e. entry for an ordinary customer, fixed customer or security personnel should happen as expected for all types of users.
• The system should make sure the customer is secure from malicious users who might use it for their malicious gains. This can be done by encrypting the data before storing it.

2. Performance- The system should perform all actions using the least amount of time to make sure that the users are able to perform their actions effectively. The response time should be fast for example when a customer approaches the entry station, the sensors should send the data and the system should display the message within 3 seconds. When the user inserts the ticket at the time of exit, the system should not take more than 5 seconds before raising the barrier. This will help reduce congestion both at the entry station and the exit station.
3. Availability- Availability of the system is crucial as the system is expected to be operational at all times to make sure users are able to perform all user actions using the system. A user should be able to enter and leave the car park at any time and this is possible only if the system is available and operational at all times.
4. Fault tolerance- fault tolerance of a system is the ability of a system to remain operational after encountering an error. An error in one part of the system should not cause a complete failure of the system. The system should be designed in such a way that if a fault occurs at the entry sub system of the system, the exit subsystem and the payment subsystems should continue operations to ensure that not all actions of the car park are sabotaged. This non-functional requirement should be looked at carefully during the testing of the system as it has potential to cause problems to the company if the system is not designed correctly.
5. Recoverability- Recoverability of a system is the ability of a system to restore to normal functioning by retaining the data in the event of a complete failure. The proposed car park system should be able to recover and continue with operation in case a complete failure occurs. These failures can be caused by natural disasters like fires or floods. To ensure recoverability, the development team should ensure measures to perform frequent data backups are put in place so that data can be recovered in case of a disaster. Setting parallel systems to operate in place of the real system.

 2Use case modelling

Use case diagrams are used to show interactions of different actors of the system with the system within a specific system boundary (Badgaretti, 2009).

a.Use case descriptions

Based on the use case diagram in figure 1, Collin’s car park system has the following use cases.

• Enter car park use case (ordinary customers) - For ordinary customers entering the car park the system accomplishes this operation through this use case. The system reads the sensors to prompt the user to prompt the button, then checks if the car park is full prints a tickets and dispatches it to the user. The entry barriers is then raised.
• Pay ticket (ordinary customer) - An ordinary customer pays for a ticket using the system through this use case. To pay for a ticket, after inserting it in the pay station the system reads the barcode and calculate the fees. The system then processes the payment and dispatches the ticket back to the user.
• Pay subscription (fixed customer) - a fixed customer pays for a subscription using the system by using this method. The user pays for a subscription using this use case. To pays for a subscription the user selects the subscription type for example weekly or monthly and then enters the payment details. The system processes the payment and prints the ticket for the user.
• Enter car park (fixed customer) - A fixed customer enters the car park using the system through this use case. The user enters the ticket and the ticket is verified and entry time recorded and the barrier is raised as the ticket Is dispatched back to the user
• Enter car park (Security person) - A security person enters the car park through this use case. The user enters the receipt in the entry station and the system records the entry time of the security person.
• Leave car park (ordinary customer, fixed customer and security person) – To leave the car park, the user uses this use case. Leaving the car park involves inserting the ticket in the exit station and the system verifies the ticket for ordinary customers. For ordinary customers and security persons the ticket is dispatched back to the user and the barrier is raised.

b.Detailed use case description

 2 Class diagrama.Assumptions

To come up with the class diagram an assumption about the payment for a subscription for a fixed customer was made. A fixed customer is supposed to pay for a subscription from their desired car park. The system verifies that the slots for the fixed customers are not full and processes the subscription. The customer has to provide payment details which may be bank details so that the billing is processed by the system. 

2.Software development life cycle

The software development life cycle (SDLC) has six stages;

• Planning phase- At this phase all the project planning is done. Planning involves coming up with the project schedule and the project plan to determine the project cost and resources required to implement the project. This phase will also involve determining the methods to be used to gather requirements and the implementation method.
• Analysis phase- In the analysis phase an analysis of the project plan is done. All the requirements are also analyzed to come up with software specifications document. This document will then be used in the design phase.
• Design phase- The design phase of the project involves coming up with a design from the software specifications document achieved in the analysis phase.
• Implementation phase- the implementation phase of the project is where the design is implemented to achieve all the functional requirements. Testing is also done at this stage to make sure all the non-functional requirements have been followed.
• Deployment phase- After the implementation is finished the next step is the deployment of the complete system for use at the car parks.
• Maintenance phase- Maintenance phase involves maintaining the system in case of bugs and updates to improve the system. 

3.References

Ambler, S. (2018). Strategies for Capturing Non-Functional Requirements. 

Badgareti. (2009). Software Engineering – Use Case Diagrams / Descriptions. 

Bell, D. (2004). The class diagram.  

Labunisky, E. (2017). What comes first: Functional or non-Functional Requirements?.