Innovative Car Parking System For Melbourne CBD – Collins Parking

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.

Requirement ID Save Time On Research and Writing Hire a Pro to Write You a 100% Plagiarism-Free Paper. Get My Paper	Description	User	input	Expected result
1	An ordinary customer enters the car park. When the customer arrives at the paying station, the sensors should detect the car of the customer and then generate a message prompting the customer to press a button. When the customer presses the button, the system checks and verifies that the car park is not full and then produces a ticket to the user	Ordinary customer	Sensor data, Button press action by the user	Ticket is dispatched, Entry barrier is raised
2	An ordinary customer pays for a ticket before leaving the car park at the paying station. The customer inserts the ticket into the paying station and the system reads the barcode of the ticket to determine the price from the time the customer entered the parking up to the current time. The system is then supposed to insert the money and the system verifies that the amount inserted is equal or greater to the amount that is expected and if the amount is greater than the expected amount the system is supposed to give the balance to the user together with the ticket	Ordinary customer	Ticket, Money	Ticket is dispatched,  Balance (optional)
3	Ordinary customer leaves the car park by inserting the ticket at the exist station. The system verifies that the ticket has been paid for and records the current time.	Ordinary customer	ticket	Barrier is raised
4	A fixed customer pays for a subscription using the system. When paying for a subscription the system displays the choices of different subscriptions that the user can choose. The user chooses a subscription and enters the payment details. The system processes the payment and generates a ticket for the user.	Fixed customer	Choice of subscription, Payment details	Fixed customer ticket is dispatched
5	Fixed customer enters the car park. The customer approaches the entry station and the sensor senses the car. The customer inserts the ticket in the entry station. The system verifies that the ticket is valid and then records the entry time and dispatches the ticket to the user and raises the barrier.	Fixed customer	Fixed customer ticket	Fixed customer ticket is dispatched, Barrier is raised
6	A fixed customer leaves the car park. The customer proceeds to the exit station and inserts the ticket. The system records the exit time and raises the barrier then dispatches the ticket back to the customer	Fixed customer	Fixed customer ticket	Fixed customer ticket is dispatched, Barrier is raised
7	A security person uses their ticket to enter the car park. The security person inserts the ticket and the entry time is recorded, barrier is raised and the ticket is dispatched back to the user	Security person	ticket	Ticket is dispatched back to the security person, Barrier is raised
8	Security person leaves the car park by inserting their ticket in the paying station and the system records the exit time and the barrier.	Security person	ticket	Ticket is dispatched back to the security person, Barrier is raised

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.

1. 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.
2. 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.
3. 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.
4. 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

Use case:	Enter car park
Use case ID	3
Actor:	Security person
Description:	A security person enters the car park
Preconditions:	The security person must have a ticket
Priority:	High
Frequency of Use:	Frequent
Normal Course of Events:	1.       User inserts the ticket at the entry booth 2.       System verifies that the ticket is valid 3.       System records the entry date and time of the security person 4.       System dispatches the ticket back to the security personnel 5.       System raises the barrier
Alternative Courses:	2. system verifies that the ticket is valid 2.1 System prompts the user to check the ticket
Exceptions:	A security personnel can enter the car park without a car when there is congestion at the entry station
Includes:	Read barcode, record entry date and time
Assumptions:	The security person is given a ticket by the company

 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?.