CHAPTER THREE
SYSTEM ANALYSIS AND DESIGN
3.0 INTRODUCTION
This chapter contains the research methodology. In this chapter, it will discuss about the
methodology that will used to develop the system. Hence the SDLC or system development
life cycle that going to be used is Iterative Waterfall model. Waterfall model is chosen to
develop this Traffic Offence Management System (TOMS) because it is based on the flow
itself where there are few steps which are essential to keep repeating during the development
process. In this chapter it will explain more detail about every phase that involve in this project
development, also stated here is the system requirement.
3.1 SOFTWARE DEVELOPMENT MODEL
The waterfall model is sequential software development model in which the development
process is seen as flowing steadily downward (waterfall) through several phases. A project
begins with feasibility analysis. As the successful demonstration of the feasibility analysis is
done, the requirement analysis and project planning begin and so on. Once a phase is completed
there no moving back because output of one phase work will become as an input of the next
phase, so any alteration and modification in the previous phase cannot be done and might cause
the lead to failure. The waterfall model maintains that one should move to a next phase only
when the current proceeding phase is completed and no error. Phases of development waterfall
model are thus discrete, and there is no turning back and forth or overlap between phases. The
use of waterfall model as a purely sequential process is still popular and has eve since come to
an approach of software development. the steps in it involves the following:
Planning
Analysis
Design
Implementation
Testing
Deployment and
Maintenance
Figure. 3.1 Waterfall Model
This section will cover the details explanation of methodology that was used to make this
project complete and working well. Findings from this research can and should be used to
improve upon this project in upcoming studies. In order to evaluate this project, the
methodology is based on waterfall software Development.
Planning: In this planning phase, a remotely conversation was held with supervisor to discuss
about the title of the Final Year Project (FYP). A decision is achieved to develop a system about
Traffic Offence management System. The title of the system is registered to the Head of the
Department which my supervisor himself. In order to get an idea about the system flow, a
couple of discussion has been conducted with the related person to discuss about the
requirements of the system. In this phase, we plan and evaluate the system throughout. The
proposal and presentation slides must be prepared.
Analysis: In this phase, the requirements of the system are discussed and the focus is more on
what does the system should do and how it will work. we were going through together the
offence form and all of the flow regarding offence submission making so that it will be easier to
understand. After a few analyses has been done and a comparison between the current manual
system and the system that is to be develop, all of the drawbacks and the weaknesses are figured
out and a solution has been found to improve the system. The TOMS traffic offence
management system that is to develop must cover all the drawbacks and upgrade the
functionality of the previous system. Hence, to make sure that the system is more efficient and
achieve an optimal level of satisfaction, it must be user friendly in which it is easy to be used by
all type of users of the system. The information collected from the meeting has been match with
the requirement that were already discussed with supervisor. If the requirement needs an
alteration, the process of system will undergo an alteration too.
Design: In this phase, the design of the Graphical User Interface (GUI) is started. This phase
requires the student to design the entire module in the system and find the suitable coding that is
related to the requirement process. The coding of the design has been searched and been
discussed with the supervisor. The GUI that has been design will be needed to show and to
discuss with my supervisor so that if the design does not fulfill the requirements, adjustment
will be made until it meets the requirement. If the GUI meets the requirements, then it should
move to the next phase which is the development of the GUI and the coding of the system was
on the go in this phase. The previously discussed coding will be used to develop the system.
Programming language that has been chosen to develop this project is PHP and database is
Xampp server. The database is also designed in this phase. Please refer to Chapter 4 of
modeling and design where the database has been created and the interface has been developed
too.
Implementation: After the GUI of the system has been designed, the implementation phase will
do some checking to all of the system’s modules. If the coding has an error, discussion about the
coding with the supervisor, Unit testing and integrated testing for the module is purposely to
find an error of the system and find ways to overcome it. Next, the entire modules will be
combined and implemented. Test cases are used purposely to test the system and checking the
system for an error.
Deployment and Maintenance: In this phase, the button, the validation process of the system
must be checked so that if an error occurs, it can be repaired and the system will be updated
from the previous one. The maintenance process is important because if there is any found error,
it can be corrected, and thus, making sure that all of the processes of the system is functioning
well.
3.2 Requirement Engineering.
The requirements of both hardware and software are the most important part of some project
as it will lead to the project success. Without both of software and hardware requirements, the
project cannot be accomplished completely. In order to complete the project, tools from both
hardware and software should be used. The consumption of these tools depends on what
already been provided or what they have been used before. Below are the details of the
requirements of the CMS.
The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document. Requirement Engineering Process It is a four-
step process, which includes:
• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation
3.2.1 Feasibility study
Feasibility study is an important phase in the software development process. It enables the
developer to have an assessment of the product being developed. It refers to the feasibility study
of the product in terms of outcomes of the product, operational use and technical support
required for implementing it. Feasibility study should be performed on the basis of various
criteria and parameters. The various feasibility studies are: • Economic Feasibility • Operational
Feasibility • Technical Feasibility
3.2.1.1 Economic Feasibility
It refers to the benefits or outcomes we are deriving from the product as compared to the total
cost we are spending for developing the product. If the benefits are more or less the same as the
older system, then it is not feasible to develop the product.
3.2.1.2 Operational Feasibility
It refers to the feasibility of the product to be operational. Some products may work very well at
design and implementation but may fail in the real environment. It includes the study of
additional human resource required and their technical expertise.
3.2.1.3 Technical Feasibility
It refers to whether the software that is available in the market fully supports the present
application. It studies the pros and cons of using particular software for the development and its
feasibility. It also studies the additional training needed to be given to the people to make the
application work.
3.2.2 Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the client and
end-users to know their ideas on what the software should provide and which features they want
the software to include.
3.2.3 Software Requirement Specification
SRS is a document created by system analyst after the requirements are collected from various
users.
SRS defines how the intended software will interact with hardware, external interfaces, speed of
operation, response time of system, portability of software across various platforms,
maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of
system analyst to document the requirements in technical language so that they can be
comprehended and useful by the software development team.
SRS should come up with following features:
• User Requirements are expressed in natural language.
• Technical requirements are expressed in structured language, which is used inside the
organization.
• Design description should be written in PHP code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.
3.2.4 Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this document
are validated. User might ask for illegal, impractical solution or experts may interpret the
requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
Requirements can be checked against following conditions - • If they can be practically
implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated
3.2.4.1 Software Requirements Characteristics
Gathering software requirements is the foundation of the entire software development project.
Hence, they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source
3.2.4.2 Software Requirements
We should try to understand what sort of requirements may arise in the requirement elicitation
phase and what kinds of requirements are expected from the software system.
Broadly software requirements should be categorized in two categories:
3.2.4.3 Functional Requirements
Requirements, which are related to functional aspect of software fall into this category.
They define functions and functionality within and from the software system.
• officer should be able to record offense.
• officer can be able to login into the system.
• Should comply Federal Road Safety rules and administrative functions.
• Software is developed keeping downward compatibility intact.
3.2.4.4 Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this category.
They are implicit or expected characteristics of software, which users make assumption of.
Non-functional requirements include -
• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility
Requirements are categorized logically as
• Must Have: Software cannot be said operational without them.
• Should have: Enhancing the functionality of software.
• Could have: Software can still properly function with these requirements.
• Wish list: These requirements do not map to any objectives of software.
User Interface requirements
UI is an important part of any software or hardware or hybrid system. A software is widely
accepted if it is -
• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface
User acceptance majorly depends upon how user can use the software. UI is the only way for
users to perceive the system. A well performing software system must also be equipped with
attractive, clear, consistent and responsive user interface. Otherwise, the functionalities of
software system can not be used in convenient way. A system is said be good if it provides
means to use it efficiently. User interface requirements are briefly mentioned below -
• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of colour and texture.
• Provide help information
• User centric approach
• Group based view settings.
3.3 System Design
The system design phase decides how the system will operate, in terms of the hardware,
software and network infrastructure such as the user interface, forms and reports that will be
used; and the specific programs, databases, and files that will be needed. The basic architecture
design for the system will be touched in this phase where it describes the hardware, software
and network infrastructure that will be used. The interface design specifies how the users will
move through the system such as menus, submenus and on-screen buttons. It also covers the
forms and reports that the system will use and the database and file specification that define
exactly what data will be stored. Then the system specification such as architecture design,
interface design, database and file specifications will be handed to the programming team for
implementation.
In conclusion, the design phase includes the description of a structure of the system and the
detailed design of intervals of system components. In systems design functions and operations
are described in detail, including screen layouts, process diagrams and other documentations.
3.3.1 Use case Diagram
Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions
(use cases) that some system or systems (subject) should or can perform in collaboration with
one or more external users of the system (actors).
Figure. 3.2 Use case Diagram
3.3.2 System Flowchart
The flowchart shows the complete view of the whole proposed system design. Figure. 3.3 is the
physical design of proposed system show how the execution of the proposed system carried out.
Figure. 3.3
START
System
Flowchart
Register
Login
Databa
Verify User
Processing Data
Databa
Display Info
3.2.3 Database Schema
A database is a collection of interrelated data stored with minimum redundancy to serve many
users quickly and efficiently. The general objective is to make database access easy, quick,
inexpensive and flexible for the user. Relationships are established between the data items and
unnecessary data items are removed. Normalization is done to get an internal consistency of
data and to have minimum redundancy and maximum stability. This ensures minimizing data
storage required, minimizing chances of data inconsistencies and optimizing for updates. The
MS Access database has been chosen for developing the relevant databases. A complete set of
table design for a database is called database schema. It is the blue print of the database. Here,
the basic structure of the tables composing the database is shown along with the information
about the primary & foreign keys.
3.2.3.1 Admin Login
This table stores the details about the administrator’s login information. The admin login
contains the fields, username, password etc. Table 3.1 shows a detailed view of the table
Table 3.1 Table format for admin details in TOMS database
Field Name Data Type (Limit) Description
ID Auto Number Primary key, specifies the
number of records in the
particular table
Username TEXT (255) A unique name used to
identify an administrator
Password TEXT (255) A unique, secret and hidden
word an administrator uses to
access
Surname TEXT (255) Surname of the administrator
Other Names TEXT (255) Other names of the
administrator excluding
his/her surname
Officers Details
This table stores the general information about officer in the database. The design of this
module will involve designing a database for entering data of a new student. Table 3.3 shows a
detailed view of the table.
Table 3.2 Table Format for Officers Details in Toms Database
Field Name Data Type Description Field Size
Officer Number Numeric This stores a set of 10
numbers that act as a
unique identifier for
each officers. It is also
the primary key of this
table.
First name Text Stores officer’s 255
the
first name
Last name Text Stores officer’s 255
the
surname
Other names Text Stores officer’s 255
the
other names
Officer ID Numeric Unique identifier for 10
officers in
the database.
Used as a record
counter.
Phone Number Numeric Stores the 255
officer’s phone
number
Gender Text Stores the 255
officer’s gender
Picture Image Stores an image of the
officers
Email address Text Stores the e-mail 255
address of the officers
Address (Residential) Text Stores the officer’s 255
residential address
3.3 Chapter Summary
This chapter contains the research methodology. It has provided a detailed description of the
phases and approach in the development of the study by providing an analysis of the system
and a design of the proposed system. It also examined the components of the system.
