NAME: AHMED MUKTAR MUHUMED

REG NO: SCT221-C004-0153/2019.

Chapter 3:
3.0 System Analysis
3.1 Introduction
What is system analysis? System analysis can be defined as “"the process of studying a procedure or
business in order to identify its goals and purposes and create systems and procedures that will achieve
them in an efficient way". Another view sees system analysis as a problem-solving technique that breaks
down a system into its component pieces for the purpose of the studying how well those component
parts work and interact to accomplish their purpose. (Lonnie D. Bentley p.160 7th edition.)

This also describes the plan that the investigator will undertake to develop the ways of solving problems
and provide guidance in various steps of undertaking the research. This study uses descriptive research
design because it is interested in describing the satiation as it exists during the time of study without
making manipulations. It provides the researcher with an opportunity to gain deeper insights into the
subject matter under study.

Robson (2002) points out that descriptive study portrays an accurate profile of persons, events or
situation. Chandran (2004) also states descriptive study describes the existing conditions and attitudes
through observation and interpretation techniques. In the present study, this design is the most
preferable because it helps to deepen understanding of the current situation as it exists. It enables
obtaining of both quantitative and qualitative data for the study because of utilization of questionnaires
and the interview guides.

This part involves assessing the current Courier Management and Delivery System in place. It
includes a detailed analysis of the system's strengths, weaknesses, limitations, and
inefficiencies. Feedback from users and stakeholders is collected to understand their
experiences and pain points with the existing system. Various data collection methods like
interviews, observations, and questionnaires are used to gather relevant information.
 1. Interviews: Interviews are structured or semi-structured conversations between the
analyst and stakeholders, such as end-users, managers, or subject matter experts. The
primary goal of interviews is to gather in-depth and qualitative information about the
system, its functionalities, user experiences, pain points, and expectations. During
interviews, the analyst can ask open-ended questions to encourage detailed responses
and gain valuable insights. Interviews provide an opportunity for stakeholders to share
their thoughts, opinions, and suggestions related to the current system and the
proposed changes. These interviews can be conducted in person, over the phone, or
through video conferencing, depending on the availability and preferences of the
participants.
2. Observations: Observations involve the analyst directly observing the users and system
interactions in their natural working environment. This method allows the analyst to see
how users navigate through the system, perform tasks, and handle different scenarios.
By observing users, the analyst can identify any usability issues, inefficiencies, or
bottlenecks in the current system. Observations can be particularly helpful in
understanding real-world challenges that users face, which may not be apparent from
interviews or questionnaires alone. It's important for the analyst to be non-intrusive
during observations, so as not to disrupt the users' normal workflow.
3. Questionnaires: Questionnaires are structured surveys containing a set of questions that
are distributed to a larger group of stakeholders, such as end-users, customers, or
employees. Questionnaires are a quantitative data collection method and can provide
valuable statistical insights. They are useful for gathering feedback from a diverse range
of users and can help identify trends and patterns in user preferences or experiences.
Closed-ended questions with predefined response options are commonly used in
questionnaires, making data analysis more straightforward. However, open-ended
questions can also be included to allow participants to provide additional comments and
insights. Questionnaires can be distributed electronically (e.g., via email or online
surveys) or in printed form, depending on the target audience's accessibility to
technology.

3.2 FEASIBILITY STUDY

A feasibility study is a detailed report that discusses the project’s frames of analysis in depth. It also
considers the strategy, operations, people and control as well as risk and constraints. The goal is to
get a solution towards the completeness and revamp of a project.

There six type of feasibility which is shall discuss in the context of my project they include; economic
schedule, technical, political, contractual and organizational feasibility. (Will Kenton, 2018)
s
3.2.1 Schedule feasibility
Typically this means estimating how long the system will take to develop, and if it can be completed
in a given time period using some methods like payback period. Therefore, the time allocated for
undertaking the project is three month, which is ample time to finish the project and ensure that it is
working.

3.2.2 TECHINICAL FEASIBILITY

Basically, this assessment is based on an outline design of system requirements, to determine
whether the company has the technical expertise to handle completion of the project. Therefore this
study will be aimed at examining whether the organization has Technical feasibility refers to the
assessment of whether the proposed courier management and delivery system can be developed and
implemented with the available technology and resources. It involves evaluating the technical aspects
of the project to determine if it is achievable within the existing IT infrastructure and capabilities.

3.2.3 ECONOMIC FEASIBILITY

This concerns itself with the financial assessment of benefits of the project that may be tangible or
intangible and the capital one is going to use to establish the project. All resources I am going to use
during development are open and free source; therefore not a great amount of money has been
incurred. evaluates whether the proposed system is financially viable and cost-effective. A cost-
benefit analysis is conducted to weigh the potential benefits and savings against the project's costs.
Factors like return on investment (ROI) and revenue generation are considered.

3.2.4 SOCIAL FEASTIBILITY

Social feasibility, also known as operational feasibility, assesses the impact of the proposed courier
management and delivery system on the current social environment within the organization and its
stakeholders. It evaluates whether the system will be accepted, adopted, and effectively utilized by the
people who will be affected by its implementation.

3.2.4 Feasibility Study Report:

3.2.4.1 Introduction:
The Feasibility Study Report is a crucial document that outlines the findings of the
feasibility study conducted to determine whether the courier management and
delivery system project is viable and worth pursuing. It provides an overview of
the project and presents the analysis of technical, social, and economic aspects.
In the context of this project, the introduction section of the Feasibility Study
Report would briefly introduce the courier management and delivery system and
the purpose of conducting the feasibility study. It should also mention the key
objectives of the study, such as assessing the technical feasibility, social impact,
and economic viability of the proposed system.
3.2.4.2 Recommendation:
The recommendation section of the Feasibility Study Report presents the
conclusions drawn from the analysis of the project's feasibility. Based on the
findings of the study, this section provides a clear recommendation on whether to
proceed with the development and implementation of the courier management
and delivery system or not.
In this project's Feasibility Study Report, the recommendation would summarize
the positive and negative aspects of the system's feasibility. It should discuss the
advantages of implementing the system, such as improved efficiency, better
customer service, and cost savings. On the other hand, it should also address any
potential challenges or risks associated with the system's implementation.
The recommendation should ultimately state whether the project is considered
feasible and worthwhile. If the project is deemed feasible, it would propose
moving forward to the next phases of the development process, such as system
design and implementation. If the feasibility study indicates significant issues or
risks that cannot be adequately addressed, it may recommend not proceeding
with the project or suggesting modifications to improve feasibility.

3.3 Software Requirement Specification:

3.3.1 Introduction:
The Software Requirement Specification (SRS) is a detailed document that
precisely defines the requirements and specifications of the courier management
and delivery system. It serves as a blueprint for the development team, providing
a comprehensive understanding of what the system should accomplish and how it
should function.it also explains the purpose of the SRS and its intended audience,
which includes developers, stakeholders, and other relevant parties involved in
the project.
3.3.1.1 Purpose:
The purpose of the SRS is to establish a clear and unambiguous understanding of
the features, functions, and constraints of the courier management and delivery
system. It outlines the specific goals and objectives of the system and serves as a
reference for all parties involved throughout the development process.
In this project's SRS, the purpose would be to document the precise requirements
of the courier management and delivery system, ensuring that developers
understand what is expected from the final product. Additionally, the SRS can
help stakeholders evaluate the system's functionality and ensure that it aligns
with their expectations and needs.
3.3.1.2 Scope:
The scope of the SRS defines the boundaries and limitations of the courier
management and delivery system. It describes what the system will do and what
it will not do. It is essential to set clear boundaries to avoid scope creep during the
development process.
In your project's SRS, the scope would specify the core functionalities of the
courier management and delivery system. This may include
 order management
 real-time tracking
 customer notifications
 delivery scheduling
 reporting capabilities.
The scope should also mention any features that are out of scope for the current
version of the system but may be considered for future enhancements.
3.3.2 Product functional and non-functional requirements
3.3.2.1 Functional Requirements:
Functional requirements define the specific functionalities and capabilities that
the courier management and delivery system must possess. These requirements
describe what the system should do to meet the needs of its users and achieve its
intended goals. Here are some examples of functional requirements for your
courier management and delivery system:
1. Inventory Management:
The system shall maintain a database of available delivery vehicles, their
capacities, and maintenance schedules. Administrators shall have access to
inventory data to manage vehicle allocation and maintenance.
2. Reporting and Analytics:
The system shall generate reports and analytics on delivery performance,
agent efficiency, customer feedback, and overall system performance.
Administrators shall have access to these reports for decision-making and
performance evaluation.
3. Real-time Tracking:
The system should provide real-time tracking of packages and shipments.

4. Notifications:
The system should send automated notifications to customers, updating
them about the status of their delivery, including package pickup, transit,
and successful delivery.

5. Reporting and Analytics:

The system should generate comprehensive reports and analytics for
tracking delivery performance, delivery success rates, and customer
satisfaction.
3.3.2.2 Non-Functional Requirements:
Non-functional requirements specify the criteria that the courier management
and delivery system must meet regarding its overall performance, quality, and
user experience. Unlike functional requirements, non-functional requirements are
not directly related to specific functionalities but focus on aspects such as system
performance, security, reliability, and usability.
Examples of Non-Functional Requirements for the Courier Management and
Delivery System:
1. Performance: The system should be able to handle a high volume of
concurrent users and maintain responsiveness even during peak times. The
response time for actions like order placement, tracking, and notification
delivery should be minimal.
2. Security: The system should implement robust security measures to protect
user data, including encryption of sensitive information, secure
authentication, and access control to prevent unauthorized access.
3. Reliability: The system should be highly reliable and available, ensuring
minimal downtime or disruptions. It should have mechanisms for data
backup and recovery in case of system failures.
4. Usability: The system's user interface should be intuitive, user-friendly, and
accessible to both customers and delivery personnel. It should require
minimal training for users to navigate and perform tasks effectively.
5. Scalability: The system should be scalable to accommodate future growth
and increasing demands. It should be capable of handling an expanding
user base and additional features without significant performance
degradation.

3.3.2.3 User Characteristics.

The intended users (customer,admin, staff) should posses the following qualities. 
  They should be computer literate.
 Have an understanding of navigations

3.3.3 Specific Requirements.

In the context of the courier management and delivery system, the "Specific Requirements"
section of the Software Requirements Specification (SRS) contains detailed descriptions of the
functionalities and features that the system must possess to cater to the needs of different
entities participating in the web portal operation. Below is a breakdown of specific
requirements for each entity:
 Customers:
 Package Booking: Customers should be able to book delivery services by providing
necessary details such as sender's information, recipient's information, package weight,
and delivery address.
 Package Tracking: Customers should have the ability to track the status and location of
their packages in real-time using unique tracking numbers or order references
 Employees (Delivery Personnel):
 Login and Task Assignment: Employees should be able to log in to the system to view
their assigned delivery tasks and track their progress.
 Package Pickup and Delivery: Delivery personnel should update the system with package
pickup and delivery status in real-time to provide accurate tracking information to
customers.
 Navigation Support: The system may include navigation support to help delivery
personnel find the most efficient routes for delivery.

 Admin (Administrative Staff):

 User Management: The admin should have the ability to manage user accounts,
including customers and delivery personnel.
 Order Management: The admin should be able to view and manage all orders, including
order processing, assignment, and status updates.
 Delivery Personnel Assignment: The admin should be able to assign delivery tasks to
specific delivery personnel based on availability and location.
 Reporting and Analytics: The admin should have access to various reports and analytics
to monitor the overall performance of the courier service, including delivery efficiency,
customer feedback, and financial analysis.
 Chapter 4: System Design
 This section explains design issues involved in the system architecture, interface designs
of stand alone application and Database modeling.

 4.1 Portal Architecture

System Architecture for the proposed web portal is based on the open source perl for
web applications. The servelet engine include the Apche as well as web server.

3.4.2 Recommended Channels

It is a representation of the web pages in the web portal and their sections. The
channels are a visual representation of the pages available on the web portal and what they do
 HOME
Tracking CMS

SERVICE
About us SS

Contact
staff us
CUSTOMERS

Figure 1.9 :customer

 HOME
Tracking CMS

SERVICE
booking SS

com munication

Figure 2.0 : staff: Use case Diagram

 booking
Tracking CMS
Updating

parcels
Reporting

Communcation
Creating branches
emails

Use case diagram

3.4.3 Data Flow Diagrams
It is a representation of the properties of the data within an existing or proposed system. It involves
shifting fact collected during the investigation state process into a data model concept.
a)Context Diagram
Figure 2.2 :Context
Diagram

Fig 2.3 Diagram Zero

Fig 2.5 Diagram 1(b)Authenticate User.
2.4.2 Sequence Diagram for Goods booking

2.4.3 Sequence Diagram for New Branch Request

3.4.7 Database Design
In this section database designing for the proposed system is explained. The methodology for
designing database consists of three phases that is conceptual design, logical design, and
physical design. These three phases are explained as follows:-

Conceptual Database Design – conceptual database design includes the identification of the
entities, relationship between entities and defining the attributes.

Logical Database Design – this level helps in designing the relations and constraints.

Physical Database Design – this level includes the physical implementation of relations into
database management system.

Entity-relationship Diagram helps in describing the entities and relationship. The database
designing was done from beginning and during database designing it is ensured that Database
model is in the normalized form. The database design for the organization is based on the
following ER Diagram showing entities and their relationships.

3.4.7.1 Conceptual Database Design

4.1.1 Entity Relationship Modeling

Entity-Relationship Modeling (ERM) is a popular method used in conceptual database design to

represent the relationships between different entities in a system. For a courier management
and delivery system, we need to identify the main entities involved and their relationships. Let's
begin by identifying some key entities:

1. users:[ CustomerID (Primary Key), Name, Address, Contact Information].

2. Courier:[ CourierID (Primary Key), Name, Contact Information]
3. Package: [PackageID (Primary Key), Weight, Contents, Delivery Status]
4. ADMIN=[Password,UserName]
Figure 3.0 ER Diagram
3.4.7.2 Logical Database Design

The project has been identified to contain twelve data base tables which are practically as follows:
Table Name: Branches
Field Name Data Type Size
INT 5
REQUEST ID INT 5
APPLICANT NAME VARCHAR 100
BRANCH NAME VARCHAR 50
BRANCH LOACATION VARCHAR 100
PHONE NO VARCHAR 50
MANAGER VARCHAR 100

TABLE NAME: EMPLOYEES

Field Name Data Type Size

EMP ID INT 20
EMPLOYEE NAME VARCHAR 50
ROLE VARCHAR 50
DATE OF JOIN DATE
SALARY FLOAT

Table Name: GoodsBooking

 Field Name Data Type Size
BOOKING ID INT 5
LR NO INT 10
CUSTOMER NAME VARCHAR 50
PHONE NO VARCHAR 50
MATERIAL 100
PARTICULARS VARCHAR

NO OF ITEMS INT 50
BRANCH ID INT 5
BOOKED AT BRANCH VARCHAR 100

Portal Admin Table Table 1.4

Attribute name Data type and length Validation

Username char Unique primary key

Password varchar