What is Structured Analysis?

Structured analysis is a software engineering methodology that utilizes

graphical representation to convert real-world cases into data
specifications that can be used to create computer programs and
hardware configurations.

1
 QUIZ

IN NOT MORE THAN 5 LINES EACH, EXPLAIN:

1. SPIRAL MODEL
2. RAPID APPLICATION MODEL
3. PROTOTYPE MODEL
2
This methodology of structured analysis was developed to
document system requirements and designs.

3
 Why Structured Analysis?
• Because of a large demand for complex information systems. and there
were no standard techniques for documenting requirements,
configurations, and processes involved in a software system.

• The main characteristic of structured analysis is the usage of diagrams to

display various functions and the flow of data.

4
 What is the main aim of structured analysis?

• The main aim of structured analysis is to break down

complex information into smaller simpler parts so as to
aid in the efficient development of a software system.

5
 Structured analysis techniques are of three types:

• Functional — This technique utilizes data flow diagrams to

depict functions and flow of data.
• Data — This technique utilizes entity relationship diagrams to
depict the dependencies of the software system with the
external environment.
• Dynamic — This technique utilizes state transition diagrams to
depict the conditions and working of the system.
6
 Data flow diagram

• A data flow diagram (DFD) maps out the flow of information for any process or system.
• It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show
data inputs, outputs, storage points and the routes between each destination.
• They can be used to analyse an existing system or model a new one.
• a DFD can often visually “say” things that would be hard to explain in words, and they
work for both technical and nontechnical audiences, from developer to CEO.
• Data-flow diagrams provide a graphical representation of the system that aims to be
accessible to computer specialist and non-specialist users alike.
• The models enable software engineers, customers and users to work together effectively
during the analysis and specification of requirements.
7
Symbols and Notations Used in DFDs

8
 Two common systems of symbols are named
after their creators:
• Yourdon and Coad /Yourdon and DeMarco
• Gane and Sarson.
• One main difference in their symbols is that Yourdon-Coad and Yourdon-DeMarco use
circles for processes, while Gane and Sarson use rectangles with rounded corners.
• There are other symbol variations in use as well, so the important thing to keep in mind is
to be clear and consistent in the shapes and notations you use to communicate and
collaborate with others.

9
 Symbols for data flow diagrams
• External entity: an outside system that sends or receives data, communicating with the system being
diagrammed. They are the sources and destinations of information entering or leaving the system. They
might be an outside organization or person, a computer system or a business system. They are also
known as terminators, sources and sinks or actors.
• Process: any process that changes the data, producing an output. It might perform computations, or sort
data based on logic, or direct the data flow based on business rules.
• Data store: files or repositories that hold information for later use, such as a database table or a
membership form. Each data store receives a simple label.
• Data flow: the route that data takes between the external entities, processes and data stores. It portrays
the interface between the other components and is shown with arrows.

10
11
 DFD levels
• DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3 or beyond.
• The necessary level of detail depends on the scope of what you are trying to accomplish.
• Progression to Levels 3, 4 and beyond is possible, but going beyond Level 3 is uncommon. Doing
so can create complexity that makes it difficult to communicate, compare or model effectively.

12
 DFD Level 0
• DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole system or process
being analysed or modelled. It’s designed to be an at-a-glance view, showing the system as a single
high-level process, with its relationship to external entities. It should be easily understood by a
wide audience, including stakeholders, business analysts, data analysts and developers.

13
 DFD Level 1

• DFD Level 1 provides a more detailed

breakout of pieces of the Context
Level Diagram.
• highlight the main functions carried
out by the system and break down the
high-level process of the Context
Diagram into its subprocesses.

14
 DFD Level 2
• DFD Level 2 then
goes one step deeper
into parts of Level
1. It may require
more text to reach
the necessary level
of detail about the
system’s
functioning.

15
 Categories of a data flow diagram

• These are the two categories of a data flow diagram.

• A Logical DFD visualizes the data flow that is essential for a business to operate.
It focuses on the business and the information needed, not on how the system
works or is proposed to work.
• However, a Physical DFD shows how the system is actually implemented now,
or how it will be. For example, in a Logical DFD, the processes would be
business activities, while in a Physical DFD, the processes would be programs
and manual procedures.

16
 Logical DFD

• Purpose: A logical DFD focuses on what the system does, representing the business functions, processes,
and information flow without going into technical details about how they are implemented.
• Components: It emphasizes the flow of data, the inputs and outputs of processes, and the overall system's
functions.
• Details: Logical DFDs are often used during the initial stages of system design to understand the
requirements and outline the functional aspects of the system. They help stakeholders and analysts get a
clear picture of the system's purpose, requirements, and essential operations.
• Example: In a library system, a logical DFD would show processes like "Check Out Book" or "Return
Book" and how they interact with data entities such as "Member Records" or "Book Inventory" without
detailing the specific hardware or software involved.

17
 Physical DFD

• Purpose: A physical DFD describes how the system will be implemented, specifying the actual hardware,
software, files, databases, and people involved in the system’s operations.
• Components: It includes specific details about data storage locations, actual file formats, hardware
requirements, and software applications used.
• Details: Physical DFDs are typically used in later stages of system development when focusing on
implementation details. They help developers and system architects understand the exact setup and
components needed to operate the system.
• Example: In a library system, a physical DFD would detail the specific database (e.g., SQL database)
where "Member Records" are stored, the exact server or hardware used, and software tools like scanners
or kiosks for "Check Out Book" processes.

18
 Key Differences

• Abstraction Level: Logical DFDs are more abstract and focus on business processes, while
Physical DFDs are detailed and focus on technical aspects.
• Audience: Logical DFDs are useful for analysts and stakeholders to understand the system
conceptually, whereas Physical DFDs are geared toward developers and IT professionals for
implementation.
• Timing in Development: Logical DFDs are used in the early stages of system design, while
Physical DFDs are used when moving towards implementation.

19
 Process description
• Process description tools help document, represent, and analyze the flow of information, logic, and
decision-making within a system or process.
• These tools enable system analysts, developers, and stakeholders to understand complex processes
and make informed decisions

20
 Here are some commonly used process description tools:

• Decision Tables
• Decision Trees
• Structured English
• Pseudocode
• Flowcharts

21