Architecture And Design Of The Collin’s Car Park System

Functional Requirements for Ordinary Customers

Functional requirements are the requirements that the end users expect the system to meet so that they can use the system to achieve different goals (Stephens, 2015). Functional requirements describe what the users expect from the system. For the Collin’s Parking Car Park System the functional requirements can be classified based on the type of users. These users are;

• Customers
• Security managers

Collin’s Car park system has two types of customers;

• Ordinary customers- One of customers who pay for the parking on demand basis.
• Fixed customers- These customers pay a subscription based payment for example for weeks, months or a year on a specific car park. After the paying then they can park their cars anytime as long as the deadline of the card has not reached.

Functional requirements for ordinary customers are;

• An ordinary customer should be able to use the system to generate a ticket at the entrance of the car park. The ticket generated will grant the customer access to the car park by raising the barrier. The process of generating a ticket will involve verifying that the car park is not full at that moment. This will be done automatically after the system detects a vehicle approaching the barrier using sensors installed at the entrance of the car park system. After the sensor senses the vehicle it displays a message on the control pillar. The process of generating a ticket is triggered by pressing of the button.
• Ordinary customers expect to pay for their tickets using the system. Paying for a ticket is done before the customer leaves the car park. The customer should use their ticket at the pay station and the system should show the customer, the amount he or she is supposed to pay. The customers should then insert the money and the ticket should be validated so that the customer can use it at the exit station.
• Ordinary customers should use the tickets they have paid for to exit the car park. Exiting the car park will involve inserting the ticket on the exit control station and the system should record the time of departure then the barrier is raised.

Functional requirements for the fixed customers are;

• Fixed customers should be able to pay for a subscription through the system. The system should show the customer different options and the amount of money it will cost for each. The customer should then select a service and then pay for it. After the payment is processed the customer should be issued with a card. For new customers the system should start with registration to record details of the new customer.
• Fixed customers should be able to use their cards to enter the car park. During entry, the customer approaches the barrier at the entrance and it’s detected by sensors. The customers should insert his or her card and then the system should make sure that the card of the customer has not expired and then raise the barrier after ejecting the card. The system should also record the time of entry for the customer.
• To leave the car park, the customer should be able to use their card at the exit control station. The system should record time of departure and open the barrier after ejecting the ticket.

The other type of user for the system is the security manager delegated with enforcing security at the car park. The following are the functional requirements of the security manager;

• The security manager should be able to use their card to gain entry to the car park using the system. Upon approaching the entrance station, the security manager should insert the card and the system should record the time of arrival.
• The security manager should be able to use the system to exit the car park. When exiting, the security manager should insert their card and the system should record the time of departure and then raise the barrier after ejecting the card.

1.1 Nonfunctional requirements for the system

Nonfunctional requirements are requirements of the system that the end user does not interact with but they are needed to facilitate the functional requirements for the user to achieve various goals using the system (Harker, Ziegler and Galer, 2016). For the Collin’s Car Park System, the nonfunctional requirements of the system are;

• Performance- The system should perform and execute all tasks using the least amount of time to make sure the end user is able to achieve their goals using the system. For example when an ordinary customer approaches the entrance station and presses the button to trigger the ticket generation process, the system should perform all tasks and processes involved with ticket generation within 5 seconds.
• Availability- The system should be available at all times. Availability is a crucial nonfunctional requirement because the car park is used at all times as customers and security managers are entering and leaving at any time. Thus, the system should be available to make sure all the functional requirements are achievable at any time.
• Robustness- The system should be robust meaning that it should be able to operate in the presence of errors. The system should not crash because of an error, for example if an error is experienced at the entrance station, then the whole system should not become dysfunctional.
• Accuracy- The system should be accurate to make sure all functional requirements are achievable. For example the sensors at the entrance station should be accurate and the system should be able to interpret the data accurately so as to respond accordingly.
• Reliability- The system should be reliable to make sure all functional requirements can be achieved. The system should be relied to perform all user functions in the expected way to achieve the expected result.
• Security- The system should be secure to make sure all data is processed securely without any user interruption intended to change the way it’s supposed to operate. The data generated by the system should also be stored successfully to make the data is not easily accessible by malicious users.

2.1 Use case descriptions

The following are the use case descriptions for all the use cases.

• Generate ticket use case – An ordinary customer generates a ticket to gain entry into the car park. Generate ticket is triggered by the ordinary customer by pressing the button at the control station. This use case includes checking if the car park is full, then printing the ticket, issuing the ticket to the user and finally raising the barrier for the user to enter the car park.
• Resister use case- A fixed customer registers using the system for them to be able to pay for a subscription. Registration involves filling a registration form with all the required details.
• Pay subscription- A fixed customer pays for a subscription. The customer select a subscription and then pays for it and a ticket is generated.
• Insert ticket use case- A fixed customer inserts ticket in order to gain entry in to the car park. This use case includes, checking validity of the ticket, recording the time that the customer has entered the car park and then raising the barrier for the customer to proceed into the car park.
• Pay for ticket use case- An ordinary customer uses this use case to pay for a ticket at the paying station. This use case includes reading the barcode of the image and then calculating the fees. After the calculation the customer is supposed to pay the amount specified and then the system should process the payment and issue the customer with the ticket.
• Enter car park use case – A security manager uses this use case to enter the car park. This use case includes, inserting a card, recording the time of arrival and raising the barrier for the security manager to enter.
• Leave car park use case- leave car park use case is used by all users of the system that is the ordinary customer, fixed customer and the security manager. This use case includes inserting the ticket, recording the time of leaving the car park and raising the barrier.

2.2 Detailed use case description

The following use case description is for pay for a ticket use case.

Use Case ID:	UC1
Use Case Name:	Pay for ticket
Created By:	Author	Last Updated By:	Author
Date Created:	4/24/2018	Date Last Updated:	4/24/2018

Actor:	Ordinary customer
Description:	An ordinary pays for a ticket before they leave the car park.
Preconditions:	The customer must be within the car park system and have entered the car park before paying for a ticekt
Postconditions:	The status of the ticket is changed
Priority:	High
Frequency of Use:	Very
Normal Course of Events:	1. User inserts his or her ticket into the pay station. 2. System reads the barcode of the card 3. System calculates the time the customer took in the car system. 4. The system calculates the amount and displays the amount on the control screen. 5. User pays the money. 6. System validates the money is enough and update the status of the ticket. 7. System issues the ticket to the customer
Alternative Courses:	6 System validates the money is enough and updates the status of the ticket 6.1 The system finds the money is not enough. 6.2 The system displays a message to the customer. 6.3 The system goes back to step 4.
Exceptions:
Includes:	Read barcode, calculate fees
Special Requirements:	The money entered by the customer must be valid.
Assumptions:	The system can take money in form of notes or coins

3. Domain Model class diagram

While modelling the diagram the following assumptions were made;

• It’s assumed a fixed customer has to register so that they can pay for a subscription. This is done to avoid collecting the customer details every time the customer wants to pay for a new subscription. Registration of fixed customers will make it easy for them to renew their expired subscriptions or to change subscription.

Software development lifecycle has 5 phases;

• Planning phase
• Analysis phase
• Design phase
• Implementation phase
• Maintenance phase

4.1 Planning phase

During this phase the project team gathers the requirements of the system. Gathering the requirements will be done using various methods like observation or questionnaires. Observation will have to be done on many car parks for the project team to understand the business process of the organization. Questionnaires will be addressed to relevant stakeholders to get their view of the system and how they expect to work. At this stage the resources and schedule are drafted.

4.2 Analysis phase

Analysis phase involves determining whether the project is viable and if it is possible to complete within the allocated time schedule and resources. Any necessary changes in the project schedule and budget are done at this level. Requirements gathered are analyzed to come up with a requirements document.

4.3 Design phase

At this phase actual design of the system based on the requirements document is done (Endsley, 2016). For the Collin’s Car park System the system requirements will be specified, for example;

• The system will run on a MySQL database as it will be a distributed application.
• The system will comprise of a Linux server which will hold the database and will centralize resources of the system (Foster and Godbole, 2016).
• For the design of the application, Java will be used specifically JavaFX and the implementation will use Java.
• All the stations will run on Windows

4.4 Implementation phase

Implementation phase involves the actual implementation of the design achieved at the design phase. Testing is done iteratively at this age to make sure all components and the system as a whole are working fine. For the Collin’s Car park system; the database will be created, System will be written using java and the physical infrastructure will be laid out including the sensors and the stations. The system is then deployed and tested on the platform.

4.5 Maintenance

Maintenance will involve performing routine maintenance activities like backup and adaptive maintenance to make sure the system is running fine.

5 References

Endsley, M. R. (2016). Designing for situation awareness: An approach to user-centered design. CRC press.

Foster, E. C., & Godbole, S. (2016). Database User Interface Design. In Database Systems (pp. 139-153). Apress.

Harker, S., Ziegler, J., & Galer, M. (Eds.). (2016). Methods and tools in user-centred design for information technology (Vol. 9). Elsevier.

Stephens, R. (2015). Beginning Software Engineering. John Wiley & Sons.