Software Engineering and Systems Analysis

The assignment discusses the various stages of software engineering, including system development, testing, and maintenance. It explains the different models used in software engineering, such as black box testing, unit testing, and use case modeling. The document also provides a brief overview of the unified conceptual model, systems analysis and design, requirements engineering, and generating Petri net-based behavioral models from textual use cases.

Running head: ASSESSMENT ITEM 2
Assessment Item 2: Case Study of Collin’s Parking Car
Park System
Name of the System
Name of the University

ASSESSMENT ITEM 21
Table of Contents
1. Functional and Non-Functional Requirements:...........................................................................2
1.1 Functional Requirements:......................................................................................................2
1.2 Non-Functional Requirements:..............................................................................................3
2. Use Case Modeling:.....................................................................................................................5
3. UML Domain Model Class Diagram:.........................................................................................8
4. Activities of SDLC:.....................................................................................................................9
Bibliography:.................................................................................................................................12

ASSESSMENT ITEM 22
1. Functional and Non-Functional Requirements:
1.1 Functional Requirements:
The functional requirements of the system will be defining the system operations. The
functional requirements of the Collin’s Parking Car Park System are as following.
i. Authorization: The authorization is the process of validating the user request. The
system will have various authorization levels which will separate the fixed
customer requests from the ordinary customer requests. All this authorizations
will be done within the core of the system. The customer identification will be
done using the ticket.
ii. Authentication: The authentication is process of verifying a user. The system will
read the ticket and retrieve the details from the database. If the ticket is valid then
only the customer will be authenticated to enter the parking area.
iii. Database: The database of the system is a significant functional requirement. It
will record all the data into a hardware device called magnetic tapes. The system
will retrieve all the stored data from the database as per need. The database serves
as the memory of the system.
iv. Report Generating: The system will be generating reports based on the stored
data and information. These reports can be accessed by the organization’s
executive management only. The system will create report weekly, monthly and
yearly basis. This reports will be stored in the system for a long time so that it can
be available to the management for a long period.

ASSESSMENT ITEM 23
v. Backup and Recovery: The backup and recovery technique will be allied to the
system to back up the data into a secure server. In case the data is lost, customers
may not be able to exit the parking area as there will be no data on the system
based on which the processes can be excited. In such situations the system will
automatically retrieve the lost data from the backup server.
vi. Interfaces: The system will be having displays or interfaces. These interfaces will
be serving as the interaction medium between the customer and the system. The
interface will show messages like ‘press button’, ‘Take ticket’ and ‘Full’.
vii. Access to Pillars: The system will be controlling the pillars. These pillars will be
opened if the customer authorization is successful.
viii. Payment handle: The system will handle the payment process. In case of fixed
customers, the system will be taking all the charges for the ticket at the time of
generating. The card is provided to the ticket reader device and the payment will
be deducted. In case of ordinary customers, the system will calculate the charge
and the payment needs to be done through card or cash.
1.2 Non-Functional Requirements:
The non-functional requirements of the system will be defining the how the system
operations will be functioned. The non-functional requirements of the Collin’s Parking Car Park
System are as following.
i. Performance: The system will be highly efficient and effective in terms of
performance. The system will be taking no more than five seconds to process user
request. The system will be accepting only one ticket at a time. The total time

ASSESSMENT ITEM 24
from car appear in front of pillar to accepting the parking must not take more than
7 seconds in average.
ii. Scalability: Scalability refers to the capability of the system coping with the
business requirements. The system will be using resources based on the frequency
of the car appearing. In order to boost the profit, the system will be generating
forecasting reports that will allow the management to identify when more
resources are required. Through proper scalability, the system will be ready for
providing services to the customer.
iii. Availability: The system will be available for providing service 24*7. The
customers can come to park their cars at any hour of the day. In order to maintain
the system availability, the organization will be appointing an expert to maintain
the system functionality.
iv. Security: In modern world, securing an ICT system is a major factor. The system
will not be accepting any peripheral devices. This will any type direct injection of
viruses or Trojans. The system will be secured using three layered approach so
that no one can access the database unauthorized way.
v. Recoverability: The system will be equipped with a disaster recovery technique.
In case all the data and the magnetic tapes are destroyed, the organization will be
able to collect all the data from the disaster recovery approach.
vi. Usability: The usability of the system will be of high quality. The customer will
be performing tasks as per the instructions appearing on the display.
vii. Data Integrity: The data stored in the system will be accurate and consistent. The
system will have various checks and validation methods to check the integrity of

ASSESSMENT ITEM 25
the data. If the validations are successful then only the system will store the data
into the database.
2. Use Case Modeling:
Figure 1: The Use Case Diagram of Collin’s Parking Car Park System
(Source: Created by Author)

ASSESSMENT ITEM 26
Brief Use Case Descriptions: The brief use case descriptions are as following.
i. Make Payment: The customer will be making payment for the time period the car
was parked. The ordinary customer can make payment through two ways such as
cash or card. The fixed personnel will be paying the charges through the ticket.
ii. Activate Entry Sensor: The car will be activating the sensor at the entry gate.
This way the system will be notified that a car has approached for parking.
iii. Activate Exit Sensor: The car will be activating the exit sensor so that the system
can understand a cat is being emptied from the parking area.
iv. Maintain Administration: The system administrator employed as the system
maintenance staff will be maintaining the functionality of the system.
v. Generate Ticket: The printer will be creating tickets for the customer. There are
two types of tickets that the system will be generating. Based on the ticket that the
customer has the type of the customer is decided.
Use Case Name Get ticket
Scenario The customer will request for a ticket to the system. The
system will create a ticket for the customer. The customer will
then receive the ticket and enter the parking area.
Triggering event The customer request for ticket
Brief description The customer actor approaches the system display and press
on the button. The system generate a ticket for the customer.
The ticket will have a unique id which will distinguish it from

ASSESSMENT ITEM 27
other tickets. The user accept the ticket and parks the car.
Actors Customer
Related Use Case Generate tickets
Stakeholders Customer, Collin’s car park and System Admin
Preconditions The parking are must have one space free
The customer must not be a fixed customer as these customers
already have a ticket
The system be functioning properly
Postconditions The must be customer is allocated a space
The ticket must be generated
Flow of activities Actor System
1. Customer approaches the
system of Collin’s Parking
Car Park facility
2. Customer press button
8. The customer receive the
ticket
3. System searches if any
space is available
4. A ticket is generated
5. The ticket is associated
with the space
6. The system stores the
current time as car park entry
time

ASSESSMENT ITEM 28
7. System prints the ticket
Exception Condition The ticket data is incomplete
The system is able to access local time
The system is properly connected to database

ASSESSMENT ITEM 29
3. UML Domain Model Class Diagram:
Figure 2: The Domain Model Class Diagram of Collin’s Parking Car Park System
(Source: Created by Author)
The domain model class diagram has represented the UML class model of Collin’s
Parking Car Park System. The class diagram has seven classes. Through generalization the types

ASSESSMENT ITEM 210
of tickets and types of payment has been represented. The customer data will be saved for the
fixed ticket only.
4. Activities of SDLC:
The generic software development life cycle model consists of five stages including
design. These stages are analysis, design, implementation, testing and maintenance. The object
oriented system development methodology has these stages and some additional stages also. The
phases of the object oriented system development methodology are as following.
i. System/Information Engineering and Modeling: Dennis, Wixom and Tegarden
(2015) stated that the proposed software is a large system (p. 17). That is why
finding the requirements of the system is the first step in the project. The business
analyst will identify the environment in which the system will be developed. After
the all the requirements are identified subset of these requirements are allocated to
the system. The system view obtained from completing the previous process is
crucial as the core software will be interfaced with the hardware, resource and
people.
ii. Software Requirement Analysis: This phase is also known as the feasibility
study. The development team visit the customer and study the environment. The
system analyst also investigate what technology and design approaches are
required to automate the system functions (Chitchyan et al., 2015, p. 44). In this
phase, the system and business requirements found in the first phase. The analyst
documents the information and data found in this phase. The information domain
of the software is a crucial factor in the system development. The analyst should
be able to understand the software domain properly.

ASSESSMENT ITEM 211
iii. System Analysis and Design: The designers of the system defines the structure of
the system. This structure is the basic layout of the system. Based on this structure
the designing application components are developed. The UML diagrams of the
system are developed in the design phase. The UML use case diagram assist in
documenting the interaction among the user and the system. Dick, Hull and
Jackson (2017) pointed out the activity diagrams are for the processes that will be
done by the system and user (p. 211). The class diagram shows the OO based
approach of the system. The sequence diagram is for showing the flow of data and
connection between the classes. This processes makes the system design process a
crucial part of the system development methodology. In the design phase the
logical, conceptual and physical design of the database is done.
iv. Code Generation: In order to convert the design into the machine readable
format, the system is creating step by step. The complexity of this phase is
indirectly but significantly depended on the quality of the designs. The system
will be developed using Java programming. As software method the prototyping
model has been chosen among Prototyping Model, Rapid Application
Development (RAD) model and Component Assembly Model (Azhar, Khalfan, &
Maqsood, 2015, p. 22). The prototypes of the system is developed and provided to
the end users for reviewing. Based on the user review, changes are done in the
system.
v. Testing: The testing phase initiates as soon as the code generation phase is
completed. The project manager can test the application through black box

ASSESSMENT ITEM 212
testing, unit testing and many more. The connection between the different devices
and the system will be tested.
vi. Maintenance: After the delivery, the system may need changes in the
functionalities.

ASSESSMENT ITEM 213
Bibliography:
Ahmad, M., Belloir, N., & Bruel, J. M. (2015). Modeling and verification of functional and non-
functional requirements of ambient self-adaptive systems. Journal of Systems and
Software, 107, 50-70.
Azhar, S., Khalfan, M., & Maqsood, T. (2015). Building information modelling (BIM): now and
beyond. Construction Economics and Building, 12(4), 15-28.
Chitchyan, R., Rashid, A., Sawyer, P., Garcia, A., Alarcon, M. P., Bakker, J., ... & Jackson, A.
(2015). Survey of aspect-oriented analysis and design approaches.
Da Silva, A. R. (2015). Model-driven engineering: A survey supported by the unified conceptual
model. Computer Languages, Systems & Structures, 43, 139-155.
Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object-
oriented approach with UML. John wiley & sons.
Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object-
oriented approach with UML. John wiley & sons.
Dick, J., Hull, E., & Jackson, K. (2017). Requirements engineering. Springer.
Ding, Z., Jiang, M., & Zhou, M. (2016). Generating Petri net-based behavioral models from
textual use cases and application in railway networks. IEEE Transactions on Intelligent
Transportation Systems, 17(12), 3330-3343.
Eckhardt, J., Vogelsang, A., & Fernández, D. M. (2016, May). Are" Non-functional"
Requirements really Non-functional? An Investigation of Non-functional Requirements