Functional and Non-functional Requirements for Collin's Parking Car Park System

This article discusses the functional and non-functional requirements for Collin's Parking Car Park System. It includes use case analysis, domain model class diagram, and SDLC phases. The article also mentions the subject, course code, and college/university.

COVER PAGE

Contents
1 Functional and non-functional requirements...........................................................................................3
1.1 Functional requirements.............................................................................................................3
1.2 Nonfunctional requirements for the system;..............................................................................4
2 Use case analysis.................................................................................................................................5
2.1 Use case diagram.........................................................................................................................5
2.1 Use case descriptions........................................................................................................................5
2.2 Detailed use case description......................................................................................................6
3. Domain Model class diagram...................................................................................................................8
4 SDLC..........................................................................................................................................................8
4.1 Planning phase.............................................................................................................................9
4.2 Analysis phase.............................................................................................................................9
4.3 Design phase......................................................................................................................................9
4.4 Implementation phase.................................................................................................................9
4.5 Maintenance................................................................................................................................9
5 References...........................................................................................................................................9

1 Functional and non-functional requirements
1.1 Functional requirements
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.2 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 Use case analysis
2.1 Use case diagram
Figure 1: Use case diagram
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
Figure 2: 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.
4 SDLC
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.