Object and Data Modelling Report: Swifty Unified Management System

This report provides a comprehensive analysis of the Swifty Unified Management System (SUMS), a vehicle rental business. It begins by outlining the functional and non-functional requirements of the system, including online booking, vehicle registration, vehicle removal, service recording, business reporting, and live vehicle tracking. The report then details the system's capabilities and benefits, addressing access security, accessibility, availability, efficiency, integrity, reliability, and usability. Use case diagrams are presented to illustrate major use cases and actors, with a fully developed use case description for the 'Track live location' scenario. Finally, the report concludes with domain model class diagrams that visually represent the system's data structure and relationships. The report leverages UML models to provide a clear and detailed overview of the system's design, offering a valuable resource for understanding and implementing the SUMS.

Running head: OBJECT AND DATA MODELLING
OBJECT AND DATA MODELLING
Name of student
Name of university
Author’s note:

1
OBJECT AND DATA MODELLING
Table of Contents
Introduction....................................................................................................................2
Discussion......................................................................................................................2
Requirements..............................................................................................................2
Functional requirements.........................................................................................2
Non-functional requirements.................................................................................3
Use case diagram........................................................................................................6
Use case description...................................................................................................8
Domain model class diagram...................................................................................11
Conclusion....................................................................................................................13
References....................................................................................................................14

2
OBJECT AND DATA MODELLING
Introduction
Swifty is the vehicle rental business that is presently gaining popularity and the
increase of customers is becoming troublesome for the company to track the vehicle and
provide services to the customers. The manual system of the business is becoming
significantly inefficient in handling the requirements and the needs of the customers and the
business is facing huge loss in the revenue gained. For eliminating the issues in the present
business scenario, the Swifty Unified Management System is being implemented in the
business that would help the company to save their costs and eliminate the major losses. This
report intends to provide the overview of the new system and the requirements of the
company from the new system.
Discussion
Requirements
Functional requirements
 System should provide the customers with the facility of making the online
booking of vehicle easily and then make the payment for the vehicle booked.
 System should provide the manager and the system with the functionality of
registering any new vehicle in the system by entering all the details of the car such
as the make, the model, the year, the seating capacity, the mechanical
specification and the in-car specifications.
 System should provide the system admin with the functionality of easily removing
any vehicle that has been sent for repair or any kind of servicing.
 System should provide the system admin and the manager to record the details of
the car that have been sent to service along with the details of the kind of servicing
that is required in the vehicle.

3
OBJECT AND DATA MODELLING
 System should provide the manager of the company with the functionality of
generating the business reports weekly so that the manager would have the proper
idea of the present condition of the business and the functions of the business.
 System should provide the admin and the manager with the functionality of
tracking the live location of each of the vehicles.
Non-functional requirements
Access security: The range to which this system has been protected from any kind of
deliberate and the intrusive faults from the external and the internal sources. The employees
of Swifty should be enforced with the protocol of changing their respective passwords the
next time when they have logged in into the system (Kurtanović & Maalej, 2017). The users
of Swifty system should modify the initially allocated login information for the authentication
immediately afterwards the initial successful login. The payroll system of Swifty should
guarantee that the salary data of the employees could only be accessed by the managerial
staff and no other users (Eckhardt, Vogelsang & Fernández, 2016). The employees of Swifty
should not be permitted with the update of their respective salary information.
Accessibility: The degree to which this particular software system could be utilised by
the people with the vast range of the capabilities of achieving any particular goal in the
particular area context (Khan et al., 2016). The Swifty system must be made accessible to any
people with the disabilities in accordance to the various laws and the regulations. The Swifty
system must be solely made available by the people with the particular vision requirements.
The system should be made manageable by the people who might be color blind, to the
degree that they should have the ability of discerning all the text as well as any other
information that has been displayed by this system (Lu & Liang, 2017).

4
OBJECT AND DATA MODELLING
Availability: The extent to which the users could depend on this system for being
functioning during the times of normal operations (Khan et al., 2017). The payment system of
Swifty that has been integrated in the system should be made available for the utilisation
among the hours of 7:00 a.m. till midnight. No transactions would be accepted after the
midnight and the payment module would not be functional during this time. If the system has
been made non-operational, this Swifty system should present the users with the proper
notification with the information regarding the reason due to which the system has been made
non-operational (Castro et al., 2019).
Efficiency: The degree to which this software system has the ability of handling the
increasing capacity, the output and the response time. Over 20 percent of all the processor
capability as well as the storage space made accessible to the system should be kept
unexploited at the ultimate load and the seasonal periods (Ameller et al., 2019). The restart
cycle of Swifty system should execute totally within almost 1 minute. The system should
have the ability of processing the notifications in less than 1 second and it should have the
ability of processing over 200 notifications in 20 seconds. The interface among the users and
this automated system must have the maximum time for response of two seconds (Vierhauser
et al., 2019).
Integrity: The extent to which the data has been maintained by this software system
and are significantly accurate, authentic and maintained without any kind of corruption
(Afreen, Khatoon & Sadiq, 2016). All the monetary amounts should be accurate to over two
decimal points. Whenever any change have been made to the information that has been stored
in the form of the Word document, the fact of the changes should be immediately recorded in
the database or any equivalent technology that is being constantly backed up in the remote
servers away from the main servers (Pan et al., 2020).

5
OBJECT AND DATA MODELLING
Reliability: The degree to which this software system has the ability of consistently
performing the particular functions without any kind of system failure. The payment module
of the Swifty system should have the functionality of rolling back the entire process if the
transactions made by the customers is not successful (Zhang & Wang, 2019). The live
tracking of the vehicles of the company should have the ability of providing the real time data
corrected upto 1 minute. The procedure of the data transmission should effectively confirm
the terminal of receiving which is maintained in the ready stage before the initiation of any
kind of the transmission.
Usability: This is the extent to which any of the users of the new system should have
the ability of learning, then operate, organize the inputs, and then interpret the output through
each of the interactions with the system. This new Swifty system in the company should be
significantly easy to use by any of the adult employers and the customers (Behutiye et al.,
2017). The Swifty system should be made significantly usable by the program developers
afterwards having over five weeks of the training. The system should provide the accurate
data of the reports that are generated by the manager regarding the performance of the
company in the last month.

6
OBJECT AND DATA MODELLING
Use case diagram
Figure 1: Overall use case of SUMS subsystem

7
OBJECT AND DATA MODELLING
Figure 2: Live tracking subsystem
Figure 3: Payment subsystem

8
OBJECT AND DATA MODELLING
Figure 4: Customer relationship subsystem
Use case description
Use case name Track live location
Scenario The manager logs in into the system for tracking the live location
of any registered vehicle.
Triggering event Manager login into the system and clicks on track vehicle.

9
OBJECT AND DATA MODELLING
Brief description The manager logs in into the system for tracking the live location
of any particular vehicle. The manager inputs the login credentials
in the system and then the system provides the access to the
manager in the system. The manager is then provided with the
access to the manager where the manager is provided with the
feature of tracking the live location of any particular registered
vehicle. The manager would provide the registration number of
vehicle in the form and the last known location where the vehicle
was spotted. The system would then provide the location of the
vehicle and the theft of the vehicles could be stopped.
Actors Manager
Related use cases Login, register
Stakeholders Manager, system admin, vehicle driver
Preconditions Manager has to be logged in into the system
Postconditions The manager is provided with the live location of the vehicle in
the map on the screen on the system.
Flow of activities Actor System
1. Manager opens the website
of the system.
2. Manager enters the login
credentials in the system.
3. Managers clicks on the
option of track live location
of vehicle.
4. Manager then enters the
1.1 System provides the
homepage of the system to
the manager
2.1 System verifies the login
credentials entered in the
system
3.1 System provides the vehicle
number entering form to the

10
OBJECT AND DATA MODELLING
vehicle number in the form
provided by the system
5. Manager selects the options
of viewing the live location
and the movement of the
vehicle in the map.
manager where the vehicle
number would be entered
4.1 System verifies the
authenticity of the vehicle
number entered by the
manager
5.1 System provides the
location of the vehicle in
the real time to the manager
and provides the map where
vehicle in presently situated
to the manager
Exceptional
conditions
Vehicle number is not authentic
Company is presently facing some technical issues because of
which the live location of the vehicle could not be provided to the
manager

11
OBJECT AND DATA MODELLING
Domain model class diagram
Figure 5: Domain model class diagram

12
OBJECT AND DATA MODELLING
Figure 6: Live tracking subsystem
Figure 7: Payment subsystem

13
OBJECT AND DATA MODELLING
Figure 8: Customer relationship subsystem
Conclusion
Therefore, it could be concluded that the new system in this organisation would help
in increasing the sales of the company and also help in reducing the losses that are presently
residing in the company. The system would be made easily usable for all the users and the
users would be provided with the access to the functions of the system depending on the level
of the authorisation provided to the users.

14
OBJECT AND DATA MODELLING
References
Khan, F., Jan, S. R., Tahir, M., Khan, S., & Ullah, F. (2016). Survey: dealing non-functional
requirements at architecture level. VFAST Transactions on Software
Engineering, 9(2), 7-13.
Khan, S., Babar, M., Khan, F., Arif, F., & Tahir, M. (2016). Collaboration Methodology for
Integrating Non-Functional Requirements in Architecture. the Journal of Applied
Environmental and Biological Sciences (JAEBS), 6 (4S), 63-67.
Castro, C. F., Fantinato, M., Aksu, U., Reijers, H. A., & Thom, L. H. (2019). Towards a
conceptual framework for decomposing non-functional requirements of business
process into quality of service attributes. In 21st Int. Conf. on Enter. Inf. Syst.
Ameller, D., Franch, X., Gómez, C., Martínez-Fernández, S., Araújo, J., Biffl, S., ... &
Muccini, H. (2019). Dealing with non-functional requirements in model-driven
development: A survey. IEEE Transactions on Software Engineering.
Vierhauser, M., Cleland-Huang, J., Burge, J., & Grünbacher, P. (2019, May). The interplay of
design and runtime traceability for non-functional requirements. In 2019 IEEE/ACM
10th International Symposium on Software and Systems Traceability (SST) (pp. 3-10).
IEEE.
Afreen, N., Khatoon, A., & Sadiq, M. (2016). A taxonomy of software’s non-functional
requirements. In Proceedings of the second international conference on computer and
communication technologies (pp. 47-53). Springer, New Delhi.
Zhang, X., & Wang, X. (2019). Tradeoff Analysis for Conflicting Software Non-Functional
Requirements. IEEE Access, 7, 156463-156475.

15
OBJECT AND DATA MODELLING
Behutiye, W., Karhapää, P., Costal, D., Oivo, M., & Franch, X. (2017, November). Non-
functional requirements documentation in agile software development: challenges and
solution proposal. In International conference on product-focused software process
improvement (pp. 515-522). Springer, Cham.
Eckhardt, J., Vogelsang, A., & Fernández, D. M. (2016, May). Are" non-functional"
requirements really non-functional? an investigation of non-functional requirements
in practice. In Proceedings of the 38th International Conference on Software
Engineering (pp. 832-842).
Lu, M., & Liang, P. (2017, June). Automatic classification of non-functional requirements
from augmented app user reviews. In Proceedings of the 21st International
Conference on Evaluation and Assessment in Software Engineering (pp. 344-353).
Kurtanović, Z., & Maalej, W. (2017, September). Automatically classifying functional and
non-functional requirements using supervised machine learning. In 2017 IEEE 25th
International Requirements Engineering Conference (RE) (pp. 490-495). IEEE.
Pan, Z., Zhuang, X., Ren, J., & Zhang, X. (2020, January). Pattern-Based Knowledge Graph
Embedding for Non-functional Requirements. In 2019 6th International Conference
on Dependable Systems and Their Applications (DSA) (pp. 407-412). IEEE.