INSY 55:

Systems Analysis and Design

Week 5: Analysis Process

After the completion of the chapter, students should be able to:

1. observe and differentiate the different analysis process
2. interpret the process a specifications and structured decisions and
3. identify what is problem analysis tools and the fundamentals in preparing the system
proposal.

Analysis Process

The analysis process refers to a systematic approach used to understand, evaluate, and interpret
information or data in order to identify problems, requirements, or opportunities for improvement.
It is a critical phase in various fields, including systems analysis, business analysis, research, and
project management. Here are key components of the analysis process:

Definition of Analysis Process

• Identification of Objectives: The first step involves defining the goals and objectives of the
analysis. This includes understanding what needs to be achieved and the questions that
need to be answered.
• Data Collection: Gathering relevant data and information from various sources, such as
stakeholders, existing documentation, interviews, surveys, and observations. This step is
crucial for ensuring that the analysis is based on accurate and comprehensive information.
• Data Organization: Structuring and categorizing the collected data to facilitate analysis.
This may involve creating models, charts, or frameworks that help visualize the information.
• Evaluation and Interpretation: Analyzing the organized data to identify patterns, trends,
and insights. This step often involves applying analytical techniques and tools to draw
meaningful conclusions from the data.
• Identification of Issues and Opportunities: Based on the analysis, identifying any
problems, gaps, or opportunities for improvement. This may include recognizing user
needs, system deficiencies, or market trends.
• Documentation of Findings: Recording the results of the analysis in a clear and structured
manner. This documentation serves as a reference for stakeholders and guides decision-
making.
• Recommendations: Formulating actionable recommendations based on the analysis
findings. This may involve suggesting solutions to identified problems or strategies to
capitalize on opportunities.
• Review and Validation: Engaging stakeholders to review the findings and
recommendations, ensuring that they align with business goals and user needs. This step
may involve revisiting the analysis process if necessary.
6.1 Using Data Flow Diagrams

The analysis process using Data Flow Diagrams (DFDs) is a structured approach to visually
represent the flow of data within a system. DFDs help analysts understand how data moves through
processes, the interactions between different components, and the overall functionality of the
system. Here’s a breakdown of the analysis process using DFDs:

Steps in the Analysis Process Using Data Flow Diagrams

1. Identify the System Boundaries

o Define the scope of the system being analyzed. Determine what is included in
the analysis and what is outside the system boundaries. This helps in focusing
the DFD on relevant processes and data flows.

2. Gather Requirements

o Collect information from stakeholders through interviews, surveys, and

document reviews. Understand the functional requirements, user needs, and
business processes that the system must support.

3. Identify Major Processes

o Identify the key processes that will be represented in the DFD. Each process
should represent a specific function or activity that transforms input data into
output data.

4. Define Data Flows

o Determine the data that flows between processes, data stores, and external
entities. Each data flow should be clearly named and described, indicating what
information is being transferred.

5. Identify Data Stores

o Identify the data stores that will hold information used and created by the
processes. Data stores represent repositories of data, such as databases or
files.

6. Create Context Diagram

o Start with a high-level context diagram that shows the entire system as a single
process. This diagram includes external entities that interact with the system
and the data flows between them and the system.

7. Develop Level 0 DFD

o Create a Level 0 DFD (also known as a high-level DFD) that breaks down the
single process from the context diagram into major subprocesses. This diagram
provides a more detailed view of how data flows between these subprocesses.

8. Create Level 1 DFDs

 o For each major subprocess identified in the Level 0 DFD, create Level 1 DFDs
that further decompose these processes into more detailed subprocesses. This
step continues until the processes are broken down to a level that is
manageable and understandable.

9. Validate DFDs with Stakeholders

o Review the DFDs with stakeholders to ensure accuracy and completeness.

Validate that the diagrams accurately represent the processes, data flows, and
data stores as understood by users and stakeholders.

10. Refine and Iterate

o Based on feedback, refine the DFDs as necessary. The analysis process is often
iterative, and adjustments may be needed as new information is gathered or as
understanding of the system evolves.

11. Document Findings

o Document the DFDs along with any accompanying descriptions and

explanations. This documentation serves as a reference for future phases of the
project, such as design and implementation.

6.2 Using Data Dictionaries

The analysis process using data dictionaries involves creating a structured repository that
defines and describes the data elements used within a system. A data dictionary serves as
a critical tool for systems analysts, providing clarity and consistency in understanding data
requirements, relationships, and usage. Here’s a breakdown of the analysis process using
data dictionaries:

Steps in the Analysis Process Using Data Dictionaries

1. Define the Purpose of the Data Dictionary

o Establish the goals for creating the data dictionary. This may include
standardizing data definitions, improving communication among
stakeholders, and providing a reference for data management.

2. Identify Data Elements

o Gather information about all the data elements that will be used in the
system. This includes identifying attributes, fields, and variables that are
relevant to the processes being analyzed.

3. Collect Data Definitions

o For each data element, provide a clear and concise definition. This should
include:
 o Name: The name of the data element.

o Type: The data type (e.g., integer, string, date).

o Description: A detailed explanation of what the data element represents.

o Format: The expected format of the data (e.g., YYYY-MM-DD for dates).

o Constraints: Any rules or limitations on the data (e.g., maximum length,

required fields).

4. Establish Relationships

o Define how data elements relate to one another. This may include identifying
primary keys, foreign keys, and relationships between different data entities.
Understanding these relationships is crucial for data integrity and
normalization.

5. Document Data Sources

o Identify where each data element originates from and how it is collected.
This may include specifying whether the data is input by users, generated by
processes, or retrieved from external systems.

6. Create Data Dictionary Entries

o Organize the collected information into a structured format, typically in a

table or spreadsheet. Each entry should include all relevant details for each
data element, making it easy to reference and understand.

7. Review with Stakeholders

o Share the data dictionary with stakeholders, including users, developers,

and project managers. Gather feedback to ensure that the definitions and
relationships accurately reflect the needs and understanding of the system.

8. Refine and Update

o Based on stakeholder feedback, refine the data dictionary as necessary. The

data dictionary should be a living document that is updated as the system
evolves and new data requirements emerge.

9. Integrate with Other Analysis Tools

o Use the data dictionary in conjunction with other analysis tools, such as
Data Flow Diagrams (DFDs) and use cases. The data dictionary provides the
detailed data definitions that support the processes and flows represented
in these tools.

10. Document Findings and Decisions

 o Maintain comprehensive documentation of the data dictionary and any
decisions made during the analysis process. This documentation serves as
a reference for future phases of the project, such as design, development,
and maintenance.

6.3 The Analysis Process Using Process Specifications And Structured Decision-Making
Techniques, Such As Structured English, Decision Tables, And Decision Trees

• This is essential for clearly defining the logic and rules that govern business
processes. These techniques help analysts articulate complex processes and
decision-making criteria in a way that is understandable and actionable. Here’s a
breakdown of the analysis process using these methods:

Steps in the Analysis Process Using Process Specifications and Structured Decisions

1. Identify Processes and Decisions

o Begin by identifying the key processes within the system that require detailed
specifications. Determine where decisions are made within these processes
and what criteria influence those decisions.

2. Gather Requirements

o Collect information from stakeholders about the processes and decisions. This
may involve interviews, workshops, and document analysis to understand the
business rules and logic that need to be captured.

3. Develop Process Specifications

o For each identified process, create a process specification that outlines:

o Process Name: A clear and descriptive name for the process.

o Purpose: A brief explanation of what the process accomplishes.

o Inputs: The data or information required to execute the process.

o Outputs: The results produced by the process.

o Steps: A detailed description of the steps involved in the process, which can be
articulated using Structured English.

4. Use Structured English for Process Logic

o Employ Structured English to describe the logic of the process in simple, clear
sentences. This technique uses a limited vocabulary and straightforward syntax
to convey the steps and decisions involved in the process. For example:

o "If the order total is greater than $100, apply a discount. Otherwise, do not apply
a discount."
 5. Create Decision Tables

o For processes that involve multiple conditions and outcomes, develop Decision
Tables to represent the decision logic. A Decision Table consists of:

o Conditions: The various criteria that affect the decision.

o Actions: The corresponding actions or outcomes based on the conditions.

o Each combination of conditions is represented in the table, making it easy to

see how different scenarios are handled.

6. Develop Decision Trees

o Use Decision Trees to visually represent the decision-making process. A

Decision Tree consists of nodes (decisions) and branches (outcomes) that
illustrate the flow of decisions based on specific criteria. This method is
particularly useful for complex decision-making scenarios where multiple paths
may be taken based on different conditions.

7. Validate with Stakeholders

o Review the process specifications, Structured English descriptions, Decision

Tables, and Decision Trees with stakeholders to ensure accuracy and
completeness. Gather feedback to confirm that the representations align with
their understanding and expectations.

8. Refine and Iterate

o Based on stakeholder feedback, refine the specifications and decision-making

tools as necessary. The analysis process is often iterative, and adjustments may
be needed as new information is gathered or as understanding of the processes
evolves.

9. Document Findings

o Maintain comprehensive documentation of the process specifications,

Structured English descriptions, Decision Tables, and Decision Trees. This
documentation serves as a reference for future phases of the project, such as
design and implementation.

10. Integrate with Other Analysis Tools

o Use the developed specifications and decision-making tools in conjunction with

other analysis methods, such as Data Flow Diagrams (DFDs) and data
dictionaries. This integration ensures a holistic understanding of the system and
its processes.

6.4 HIPO Charts

 The HIPO (Hierarchy plus Input-Process-Output) chart is a structured analysis tool used to
represent the functional requirements of a system in a clear and organized manner. It helps
analysts visualize the relationships between different processes and their inputs and outputs.
Here’s a breakdown of the analysis process using HIPO charts:

Steps in the Analysis Process Using HIPO Charts

1. Define the System Scope

o Begin by clearly defining the scope of the system being analyzed. Identify the main
objectives and the boundaries of the system to ensure that the HIPO charts focus
on relevant processes.

2. Identify Major Functions

o Determine the major functions or processes that the system will perform. These
functions should align with the overall goals of the system and represent the high-
level activities that need to be captured in the HIPO charts.

3. Create the Hierarchical Structure

o Develop a hierarchical structure for the HIPO chart. The top level represents the
overall system or main function, while subsequent levels break down the main
function into sub-functions or processes. This hierarchical representation helps to
organize the information logically.

4. Detail Inputs, Processes, and Outputs

o For each function in the hierarchy, specify the following:

o Inputs: Identify the data or information required to perform the function. This
includes any external data sources or user inputs.

o Processes: Describe the steps or activities that take place to transform the inputs
into outputs. This may involve calculations, data manipulations, or decision-
making.

o Outputs: Define the results produced by the function, including any reports, data
files, or user notifications.

5. Use HIPO Chart Symbols

1. Utilize standard HIPO chart symbols to represent different elements:

2. Rectangles: Represent processes or functions.

3. Arrows: Indicate the flow of data between inputs, processes, and outputs.

4. Input/Output Symbols: Distinguish between inputs and outputs, often

using different shapes or labels.

o Review and Validate with Stakeholders

 1. Share the HIPO charts with stakeholders, including users and project team
members, to validate the accuracy and completeness of the information.
Gather feedback to ensure that the charts accurately reflect the system’s
requirements.

o Refine and Iterate

1. Based on stakeholder feedback, refine the HIPO charts as necessary. The

analysis process is often iterative, and adjustments may be needed as new
information is gathered or as understanding of the system evolves.

o Document Findings

1. Maintain comprehensive documentation of the HIPO charts and any

decisions made during the analysis process. This documentation serves as
a reference for future phases of the project, such as design and
implementation.

o Integrate with Other Analysis Tools

1. Use the HIPO charts in conjunction with other analysis methods, such as
Data Flow Diagrams (DFDs) and data dictionaries. This integration ensures a
holistic understanding of the system and its processes.

o Transition to Design Phase

1. Once the HIPO charts are finalized and validated, they can serve as a
foundation for the design phase of the project. The detailed inputs,
processes, and outputs outlined in the HIPO charts will guide the
development of system specifications and design documents.

6.5 Problem Analysis Tools

The analysis process using problem analysis tools like Pareto Analysis and Fishbone
Diagrams (also known as Ishikawa diagrams) is essential for identifying, understanding, and
addressing issues within a system or process. Here’s how each tool can be utilized in the analysis
process:

6.5.1 Pareto Analysis

Purpose: Pareto Analysis is based on the Pareto Principle (80/20 rule), which states
that roughly 80% of effects come from 20% of the causes. This tool helps prioritize
problems or causes based on their impact.

Steps in Pareto Analysis:

1. Identify Problems:
 o Gather data on the problems or issues faced in the system or process. This
can be done through surveys, interviews, or historical data analysis.

2. Categorize Problems:

o Group similar problems together to create categories. This helps in

simplifying the analysis and focusing on major issues.

3. Quantify Impact:

o Assign a measurable value to each problem category, such as frequency of

occurrence, cost, or time lost. This quantification allows for a clearer
comparison.

4. Create a Pareto Chart:

o Construct a bar chart where the x-axis represents the problem categories
and the y-axis represents the impact (e.g., number of occurrences or cost).
The bars should be arranged in descending order of impact.

o Optionally, add a cumulative percentage line to show the cumulative impact

of the problems.

5. Analyze Results:

o Identify the "vital few" problems that contribute most significantly to the
overall impact. Focus on addressing these high-impact issues first.

6. Develop Action Plan:

o Create an action plan to address the identified problems. This may involve
process improvements, resource allocation, or training.

6.5.2 Fishbone Diagram

Purpose: The Fishbone Diagram is a visual tool used to identify the root causes of a
problem. It helps teams brainstorm and categorize potential causes in a structured manner.

Steps in Creating a Fishbone Diagram:

1. Define the Problem:

o Clearly state the problem or effect that needs to be analyzed. Write this at
the head of the fishbone diagram.

2. Identify Major Categories:

o Determine the major categories of potential causes. Common categories

include:

o People: Issues related to personnel or human factors.

 o Processes: Problems in workflows or procedures.

o Materials: Issues with raw materials or components.

o Equipment: Problems with machinery or tools.

o Environment: External factors affecting the process.

3. Brainstorm Causes:

o For each major category, brainstorm potential causes of the problem.

Encourage team members to contribute ideas without judgment to foster
creativity.

4. Organize Causes:

o Place the identified causes under their respective categories on the

diagram. This visual organization helps in understanding the relationships
between causes and the main problem.

5. Analyze and Prioritize Causes:

o Review the causes identified in the diagram and prioritize them based on
their likelihood of contributing to the problem. This can be done through
discussion or additional data analysis.

6. Develop Action Plan:

o Create an action plan to address the root causes identified in the Fishbone
Diagram. This may involve process changes, training, or resource
adjustments.

6.6 Entity-Relationship Diagram

The analysis process using an Entity-Relationship Diagram (ERD) is a crucial step in

database design and systems analysis. ERDs help visualize the data requirements and
relationships within a system, making it easier to understand how data entities interact.
Here’s a structured approach to using ERDs in the analysis process:

Steps in the Analysis Process Using Entity-Relationship Diagrams

1. Identify the Purpose of the ERD:

o Determine the scope of the system or application being analyzed.

Understand what data needs to be captured and how it will be used.

2. Gather Requirements:

o Conduct interviews, surveys, and workshops with stakeholders to gather

information about the data requirements. This includes understanding the
business processes, data needs, and how different entities interact.
3. Identify Entities:

o Identify the main entities that will be represented in the ERD. An entity is a
person, place, thing, or concept that is relevant to the system. Examples
include:

▪ Customer

▪ Order

▪ Product

▪ Employee

4. Define Attributes:

o For each identified entity, determine the attributes (properties or

characteristics) that need to be captured. For example, a Customer entity
might have attributes like CustomerID, Name, Email, and Phone Number.

5. Establish Relationships:

o Identify how the entities are related to one another. Relationships can be
one-to-one, one-to-many, or many-to-many. For example:

▪ A Customer can place multiple Orders (one-to-many).

▪ An Order can include multiple Products (many-to-many).

6. Draw the ERD:

o Create the ERD using standard notation (such as Crow’s Foot or Chen
notation). The diagram should include:

▪ Rectangles for entities.

▪ Ovals for attributes.

▪ Diamonds for relationships.

▪ Lines connecting entities to show relationships, with appropriate

notation to indicate the type of relationship.

7. Review and Validate the ERD:

o Share the ERD with stakeholders to ensure it accurately represents the data
requirements and relationships. Gather feedback and make necessary
adjustments.

8. Normalization:

o Apply normalization techniques to ensure that the data model is efficient

and free of redundancy. This involves organizing the attributes and
relationships to minimize duplication and dependency.
 9. Finalize the ERD:

o Once validated and normalized, finalize the ERD. This diagram will serve as a
blueprint for database design and implementation.

10. Use the ERD for Further Analysis:

o The finalized ERD can be used to derive additional models, such as Data
Flow Diagrams (DFDs) or to inform the development of application logic and
user interfaces.

6.7 Preparing the Systems Proposal

Preparing a comprehensive systems proposal involves detailing the hardware and

software needs, costs and benefits, and the overall system proposal. Below is a structured
approach to creating this proposal, incorporating these essential elements.

6.7.1 Hardware and Software Needs

• Hardware Specification:

o List the required hardware components, such as servers, workstations, network

devices, and peripherals.

o Include specifications for each component, such as processing power, storage

capacity, and any special features.

o Example:

▪ Database Server: 8 TB disk drive, Xeon E5-4600 v4 processor, RAID

configuration.

▪ Client Workstations: Windows 10 Pro, Intel Core i5 processor, 1 TB disk

drive.

• Software Specification:

o Identify the software needed, including operating systems, application software,

and any special-purpose software.

o Consider licensing agreements, maintenance, and training costs.

o Example:

▪ Operating System: Windows Server 2019.

▪ Database Software: Oracle Database.

6.7.2 Costs and Benefits

 1. Cost-Benefit Analysis

o Estimated Costs:

▪ Provide a detailed breakdown of costs associated with hardware,

software, development, implementation, and ongoing maintenance.

▪ Example:

▪ Hardware Costs: $50,000

▪ Software Licenses: $20,000

▪ Development Costs: $30,000

▪ Total Estimated Cost: $100,000

o Expected Benefits:

▪ Quantify the benefits of the proposed system, such as cost savings,

increased efficiency, improved data accuracy, and enhanced customer
satisfaction.

▪ Example:

▪ Expected annual savings from improved efficiency: $40,000.

▪ Increased revenue from enhanced customer service: $30,000.

▪ Total Expected Annual Benefits: $70,000.

6.7.3 System Proposal

Systems Proposal Structure

1. Executive Summary

o A brief overview of the proposal, summarizing the key points, including the
problem, proposed solution, and expected benefits.

2. Introduction

o Contextualize the proposal by providing background information about the

organization and the specific problem or opportunity that the proposed system
addresses.

3. Problem Statement

o Clearly articulate the problem or opportunity that necessitates the new system.
Use data or examples to illustrate the impact of the current situation.

4. Objectives
 o Define the specific objectives of the proposed system, ensuring they are
measurable and aligned with organizational goals.

5. Proposed Solution

o System Overview: Describe the recommended system, including its main

features and functionalities.

o Technology Stack: Outline the technologies, platforms, and tools that will be
used in the development and implementation of the system.