Chapter 4- Structured Analysis-October 2024.ppt

Chapter 4- Structured Analysis
4.1. What is Structured
4.1. What is Structured analysis
analysis
4.2. Data Flow Diagram
4.3. Data Dictionary
4.3. Data Dictionary
4.4. Decision Tree
4.4. Decision Tree
4.5. Decision Tables
4.5. Decision Tables
4.6. Structured English
4.6. Structured English
4.7. Entity Relationship Diagram
4.7. Entity Relationship Diagram
AASTU-SWEG3109-System Analysis and Modeling.2024/2025 A/Y: 1st Semester
1

Structured analysis
Structured analysis:
 techniques & graphical tools used to develop new system
techniques & graphical tools used to develop new system
specifications
specifications that are easily understandable
easily understandable to the user.
 Considers new goals
new goals & structured tools
structured tools for analysis.
 The new goals specify the following:
 Use graphics wherever possible to help communicate better
with user.
 Differentiate between
Differentiate between logical &
& physical systems
systems.
 Build a
Build a logical system model to familiarize the user with system
characteristics and interrelationships before implementation.
 The structured tools focus on:
 data flow diagram, data dictionary,
data flow diagram, data dictionary,
 structured English, decision trees, decision tables
structured English, decision trees, decision tables
 Entity-R/ship Diagrams-ERDs(data requirement modeling)
Entity-R/ship Diagrams-ERDs(data requirement modeling).
AASTU-SWEG3109-System Analysis and Modeling.2024/2025 A/Y: 1st Semester 2

The SDLC with structured analysis
The SDLC with structured analysis
The primary steps are:
1.
1. Study affected user areas
Study affected user areas, resulting in a physical DFD (as-is system)
physical DFD (as-is system)
2.
2. Remove the physical checkpoints and replace them with a logical
Remove the physical checkpoints and replace them with a logical
equivalent
equivalent, resulting in the logical DFD. => The logical equivalent of
the present system results in a logical DFD.
3. Model new logical system.
4.
4. Describe policies
Describe policies to realize primitive processes
primitive processes on DFDs using :
– Structured English
– Decision Trees
– Decision Tables
5. Describe data requirements (from DFD data stores) using ERDs
 Models + the requirement list
Models + the requirement list forms
forms the system
system Proposal
Proposal

In summary, structured analysis has the ff. attributes:
1. It is graphic. Example: The DFD presents a picture of
what is being specified and is a conceptually easy-to –
understand presentation of the application.
2. The process is partitioned so that we have a clear picture
of the progression from general to specific in the system
flow.
3. It is logical rather than physical. The elements of
system
system do not depend on vendor or hardware
do not depend on vendor or hardware. They
concisely specify the working of the system & how it
hangs together.
4. It calls for a rigorous study of the user area

4.2. Data Flow Diagram (DFD):
4.2. Data Flow Diagram (DFD):
 1st
developed by Larry Constantine
developed by Larry Constantine as a way of expressing system
requirements in a graphical from
requirements in a graphical from; this led to a modular design.
 Diagram business processes
Diagram business processes & the data that pass among them.
 also known as “bubble chart
also known as “bubble chart,” has purpose of clarifying system requirements
& identifying major processes that will later become programs
identifying major processes that will later become programs.
 consists of a series of bubbles joined by lines
series of bubbles joined by lines: bubbles
bubbles represent = data
transformations (processes
processes); lines
lines represent = data flows
data flows in the system.
 Although the name DFD implies a focus on data, this is not the case. The
focus is mainly on processes/activities.
 Data modeling, discussed later ( Data Requirements- as ERDs), presents how
the data created and used by processes are organized.
 Logical process models: models that describe processes, without suggesting
without suggesting
how
how they are conducted.
they are conducted.
 Physical process models
Physical process models: drawn in the design phase
drawn in the design phase by refining logical
models- provide information needed to ultimately build the system.

4.2. Data Flow Diagram (DFD): …
4.2. Data Flow Diagram (DFD): … DFD Elements (Symbols)- 4 symbols.
 Process (rounded rectangle, ellipse/circle
Process (rounded rectangle, ellipse/circle: transforms input to output
 Arrow
Arrow: data in motion
=> Shows data flow
data flow
 Data store
Data store: data at rest.
data at rest.
 External Entity
External Entity: source
or sink of data/info.
 Direction of flow:
Direction of flow: top to
top to
bottom & from left to right
bottom & from left to right.
 Each process performs
Each process performs
only one activity
only one activity & has
at-least 1 incoming &
at-least 1 incoming &
1 outgoing data flow
1 outgoing data flow.

 A data store needs
data store needs to have at least 1 incoming& 1 outgoing data flow
at least 1 incoming& 1 outgoing data flow.
 External Entity
External Entity: a person
person, organization
organization, organization unit
organization unit, or system
system that is
external to the system, but interacts with it
interacts with it (e.g., customer
customer, government
organization, accounting system, etc
accounting system, etc).
 provide data to system or receive information from the system, &
provide data to system or receive information from the system, &
serve to establish system boundaries.
serve to establish system boundaries.
 external to the system, but may/may not be part of the organization.
external to the system, but may/may not be part of the organization.
 Most business processes are too complex to be explained in one DFD
Most business processes are too complex to be explained in one DFD
and are therefore composed of a set of DFDs.
 The 1
1st
st
DFD (context diagram
DFD (context diagram) provides a summary of the overall system
summary of the overall system,
with additional DFDs providing more detail about each part of the overall
business process. Thus, leading to the decomposition of the business
process into a hierarchy of DFDs
hierarchy of DFDs, with each level down the hierarchy
each level down the hierarchy
consisting of diagrams with less scope
consisting of diagrams with less scope but more detail.

1. Context Diagram
Context Diagram: top level DFD in every business process model, whether
‐
a manual system or a computerized system. As the name suggests, it
shows the entire system in context with its environment
shows the entire system in context with its environment.
 All process models have
All process models have one context
one context diagram
diagram. It shows the overall business
process as a single
single process (i.e., the system itself
process (i.e., the system itself) & shows data flows to &
from external entities.
 Data stores are not included
Data stores are not included on the context diagram. If the system uses
data from or supplies data to another independent information system,
that system should be shown as an external entity, not a data store.
2. Level-0 Diagram:
Level-0 Diagram: shows all major processes at 1
all major processes at 1st
st
level of numbering
level of numbering, the
data stores, external entities
data stores, external entities, and data flows among them
data flows among them. The purpose
purpose is
to show all major high level processes
‐ & how they relate to each other
and to stored data. All process models have one & only one level 0 DFD
All process models have one & only one level 0 DFD.
 Key principle
Key principle in creating sets of DFDs is balancing
balancing. Balancing
Balancing means
ensuring that all information presented in a DFD at one level is accurately
all information presented in a DFD at one level is accurately
represented in the next level DFD.
‐
represented in the next level DFD.
‐

3. Level 1 Diagrams:
Level 1 Diagrams: Each process on the level 0 DFD must be decomposed
Each process on the level 0 DFD must be decomposed
into a more explicit DFD
into a more explicit DFD, called a level 1 DFD.
 all process models have as many level 1 diagrams as there are processes on
have as many level 1 diagrams as there are processes on
the level 0 diagram
the level 0 diagram; every process in the level 0 DFD would be decomposed
into its own level 1 DFD.
 The processes in the level 1 diagram are the children of the parent process
in the level 0 diagram. When a parent process is decomposed into children
processes, its children must completely perform all of its functions
children must completely perform all of its functions.
4. Level 2 Diagrams and Below
Level 2 Diagrams and Below: If any of the processes in the level 1 diagram
processes in the level 1 diagram
appear to be “busy” with multiple inflows and outflows
appear to be “busy” with multiple inflows and outflows, it may be
appropriate to decompose that process into a lower level child diagram.
The next level under level 1 would be labeled as level 2, and so forth.
 The ultimate goal
ultimate goal is to decompose a process so that each child process
performs one essential task, not multiple tasks; thus creating a primitive or
a primitive or
elementary process
elementary process.
.

Alternative Data Flows
Alternative Data Flows
 Suppose that a process produces two different data flows under different
a process produces two different data flows under different
circumstances
circumstances.
.
 Example: a quality control process could produce a quality approved
‐ ‐
widget or a defective widget; or a customer may or may not approve the
a customer may or may not approve the
order modification.
order modification.
 We show both data flows and use the process description to explain
show both data flows and use the process description to explain
that they are alternatives.
that they are alternatives.
 Nothing on the DFD itself shows that the data flows are mutually
Nothing on the DFD itself shows that the data flows are mutually
exclusive, i.e., we do not know whether these are produced
exclusive, i.e., we do not know whether these are produced
simultaneously or whether they are mutually exclusive
simultaneously or whether they are mutually exclusive.

(Dennis, Wixon& Roth,2019,P.159)
Context diagram
decomposed into
Level 0 Diagram

(DFD): …
(DFD): …
Processes 1,2, & 3 Level 1
Level 1
Diagrams
Diagrams
(Dennis, Wixon& Roth,2019,P.161)

4.2. Data Flow Diagrams
4.2. Data Flow Diagrams: -Examples: Context Diagram
Partial Product Customization Shop
Product Customization Shop Management System Context Diagram

4.2. Data Flow Diagrams: Examples-Level 0 DFD

4.2. Data Flow Diagrams: Examples-Level 1 DFD

4.2. Data Flow Diagrams: Validating Data Flow Diagrams

4.3. Data Dictionary (DD):
 Structured repository of Data;
rigorous definitions of all DFD data
elements(process, flows, stores) &
data structure
 Is a valuable reference
 improves analyst/ user
communication by establishing
consistent definitions of various
elements, terms & procedures.
 During implementation, it
serves as a common base against
which programmers compare
their data descriptions.
e.g., Process description entry in a data dictionary
e.g., Process description entry in a data dictionary

 Control information maintained for each data element
Control information maintained for each data element is cross- referenced
in the data dictionary. E.g, programs that use a given data element are
cross- referenced in a data dictionary, which makes it easy to identify them
and make any necessary changes.
 Finally, DD is an important step in building a database
DD is an important step in building a database. Most DBMSs have a
DD as standard feature.
 Data element
Data element: smallest unit of data with no further decomposition (e.g.,
day, month & year are lumped together in a date)
 Data Structure
Data Structure: group of data elements handled as a unit. E.g., Book detail:
author name, Title, ISBN, publisher’s name…
 Data element description
Data element description include name, description & an alias (synonym)
as well as usage characteristics -range of values or frequency of use or
range of values or frequency of use or
both
both (e.g., age: value b/n 18 & 65), control info (source, date of origin,
users, or access authorizations), Physical location in terms of a
record, file or data base.

4.3. Data Dictionary: …
4.3. Data Dictionary: …
In constructing a data dictionary, the analyst should consider the ff. points:
1.
1. Each unique data flow/data store/ primitive or elementary process
Each unique data flow/data store/ primitive or elementary process in
the DFD must have one data dictionary entry
must have one data dictionary entry.
2.
2. Definitions must be readily accessible by name
Definitions must be readily accessible by name.
3.
3. No redundancy or unnecessary definitions
No redundancy or unnecessary definitions in the data definition. It must
also be simple to make updates
simple to make updates.
4. The procedure for writing definitions should be straightforward but
specific. There should be only one way of defining words.
In Summary:
 a data dictionary is an integral component of the structured
data dictionary is an integral component of the structured
specification
specification.
 Without a data dictionary, the DFD lacks rigor, and without the DFD, the
Without a data dictionary, the DFD lacks rigor, and without the DFD, the
data dictionary is of no use.
data dictionary is of no use.
 Therefore, the correlation between the two is important
correlation between the two is important.

Process
Process [Logic] description:
: explain what the process does & provide info not available
explain what the process does & provide info not available
on DFD.
on DFD.
 As we move through the SDLC, we gradually move from generic to precise requirement
descriptions that are eventually translated into programming.
 When a process is straightforward the requirements definition, a DFD with simple text
description provide sufficient detail to support activities in design phase.
 Sometimes, however, the process is sufficiently complex that it can benefit from a more
detailed process description that explains the logic which occurs inside the process
detailed process description that explains the logic which occurs inside the process.
 Three techniques
Three techniques are commonly used to describe more complex processing logic:
structured English
structured English, decision trees
decision trees, and decision tables
decision tables.
 Very complex processes may use a combination of structured English and either
Very complex processes may use a combination of structured English and either
decision trees or decision tables
decision trees or decision tables.
 Structured English:
Structured English: uses short sentences to describe work that a process performs.
 Decision trees:
Decision trees: display decision logic (IF stat’s) as questions & answers
logic (IF stat’s) as questions & answers.
 Decision tables: represent complex policy decisions as rules linking conditions with
Decision tables: represent complex policy decisions as rules linking conditions with
actions.
actions.
Note: flowcharts (intimidate most end-users) and natural English (lead to
flowcharts (intimidate most end-users) and natural English (lead to
misinterpretation) are not good candidates for describing process logic
misinterpretation) are not good candidates for describing process logic.

4.4. Structured English (SE):
4.4. Structured English (SE): a language syntax for specifying logic of a process.
 Brings advantages of natural English & rigor of programming logic tools
Brings advantages of natural English & rigor of programming logic tools.
 Is not a pseudo-code: no initialization, declaration, linking, …
 However, it borrows the logical constructs of structured programming to overcome
borrows the logical constructs of structured programming to overcome
the lack of structure and precision in the English Language
the lack of structure and precision in the English Language.
 Use strong action verbs: CREATE, READ, FIND
Use strong action verbs: CREATE, READ, FIND, ; Only names in dictionary shall be used
 Can include formula as part of a sentence: CALCULATE GROSS PAY = HOURS WORKED X
HOURLY WAGE.
Example: SE for “CHECK CUSTOMR CREDIT” (Primitive process on a DFD).

4.5. Decision Trees (DT):
4.5. Decision Trees (DT): one of the methods for describing decisions,
while avoiding difficulties in communication.
 display decision logic (IF statements) as a set of nodes (questions) and
logic (IF statements) as a set of nodes (questions) and
branches (answers
branches (answers).
 Decision – Tree Characteristics
 DT presents conditions and actions sequentially and thus shows which
presents conditions and actions sequentially and thus shows which
conditions to consider first,
conditions to consider first, which second
which second, and so on
AASTU-SWEG3109-System Analysis and Modeling.2024/2025 A/Y: 1st Semester
22

4.5. Decision Trees (DT):…
 root of tree, on left of the diagram, is starting point of decision sequence
root of tree, on left of the diagram, is starting point of decision sequence.
 The right side of the tree lists the actions to be taken depending on the sequence
right side of the tree lists the actions to be taken depending on the sequence
of conditions
of conditions that is followed. Example:- discount, based on amount with in a
certain period
 The need to describe conditions and actions forces analysts to formally identify
the actual decision that must be made.
 DTs are effective when describing business problems of more than one
effective when describing business problems of more than one
dimension or condition
dimension or condition

4.5. Decision Trees (DT):… Avoiding problems with DTs
Avoiding problems with DTs
 A DT for a complex system with many sequences of steps and
combinations of conditions will be unwieldy.
 A large number of branches with many paths confuses rather
large number of branches with many paths confuses rather
than aid analysis
than aid analysis. Analyst may not be able to determine which
business policies or practices guide the formulation of specific
decisions. Decision tables model complex policies.
4.7. Decision Table:
4.7. Decision Table: logic modeling tool for complex conditions
logic modeling tool for complex conditions
 A major drawback of a decision tree is the lack of information in
drawback of a decision tree is the lack of information in
its format to tell us what other combinations of conditions to
its format to tell us what other combinations of conditions to
test
test. This is where the decision table is useful.
 A decision table is a table of contingencies for defining a
a table of contingencies for defining a
problem and the actions to be taken
problem and the actions to be taken. It is single representation
of the relationships between conditions and actions.

4.7. Decision Table…
4.7. Decision Table…
 Complex combinations of conditions, which are encountered
Complex combinations of conditions, which are encountered
in business policies can easily be expressed in neither of a
in business policies can easily be expressed in neither of a
structured English nor decision tables.
structured English nor decision tables.
 Policy
Policy: a set of rules that governs how a process is to be
set of rules that governs how a process is to be
completed
completed
 Decision Table
Decision Table: a table that specifies set of conditions and
corresponding actions. It is a way to formalize the
specification of policies & other complex combinations of
conditions.
 Has 4 quadrants
Has 4 quadrants: condition stub(top left quadrant), action
condition stub(top left quadrant), action
stub(lower, left quadrant), rule stub(top, right quadrant) and
stub(lower, left quadrant), rule stub(top, right quadrant) and
action entry stub (lower, right quadrant).
action entry stub (lower, right quadrant).

4.7. Decision Table… Example
4.7. Decision Table… Example
Whitten & Bentley, 2007, p.375

4.8. Pros & Cons of analysis modeling tools
4.8. Pros & Cons of analysis modeling tools
 Which tool is the best depends on a number of factors
Which tool is the best depends on a number of factors: the nature &
complexity of the problem, the number of actions resulting from the
decision, and the ease of use. Look at the ff summary
 strength of the DFD
DFD is its ability to represent data flows. It provides good
system documentation. However, the tool only weakly shows input and
output detail. The user often finds it confusing initially
output detail. The user often finds it confusing initially.
.
 The data dictionary helps the analyst simplify the structure for meeting the
data requirements of the system. It does not provide functional details, and
it is not acceptable to many nontechnical users.
 Structured English
Structured English is best used when the problem requires sequences of
actions with decisions
 Decision trees
Decision trees are used to verify logic & problems that involve a few
verify logic & problems that involve a few
complex decisions resulting in limited number of actions.
complex decisions resulting in limited number of actions.
 Decision tables
Decision tables are best suited for dealing with complex branching routines
such as calculating discounts or sales commissions or inventory control
procedures.

4.8. Pros & Cons of analysis modeling tools…
4.8. Pros & Cons of analysis modeling tools…
 Use structured English
Use structured English if there are many loops and actions are
complex.
 Use decision tables
Use decision tables when there are a large number of conditions
to check and logic is complex.
 Use decision trees
Use decision trees when sequencing of conditions is important
sequencing of conditions is important
and if there are few conditions to be tested
and if there are few conditions to be tested.
 Both decision tables and decision trees evaluate properties or
Both decision tables and decision trees evaluate properties or
conditions to return results when a comparison evaluates to
conditions to return results when a comparison evaluates to
true
true.
 While decision tables evaluate against the same set of
properties or conditions;
 decision trees evaluate against different properties or
conditions.
AASTU-SWEG3109-System Analysis and
Modeling.2024/2025 A/Y: 1st Semester
28

4.9. Entity Relationship Diagram(ERD)
4.9. Entity Relationship Diagram(ERD)
 data model (DM): a formal way of representing the data that are used and
created by a business system; it illustrates people, places, or things about
illustrates people, places, or things about
which information is captured and how they are related to each other.
which information is captured and how they are related to each other.
 logical DM: shows the logical organization of data without indicating how
logical organization of data without indicating how
data are stored, created, or manipulated (analysis phase).
data are stored, created, or manipulated (analysis phase).
 Physical DM: reflect how data will physically be stored in DBs & files (design
phase)
 ERD: picture which shows info that is created, stored, & used by a business
picture which shows info that is created, stored, & used by a business
system.
system.
 Elements of ERDs: has 3 elements- entities, attributes & relationships
entities, attributes & relationships.
 Entity: is a person, place, event, or thing about which data is collected—
is a person, place, event, or thing about which data is collected—
e.g., an employee, an order, or a product.
e.g., an employee, an order, or a product.
 Attribute: info that is captured about an entity- e.g., last name an
employee.

4.9. Entity Relationship Diagram(ERD)…
 Relationship: associations b/n entities. Every r/ship has a parent entity & a
child entity. Generally, the parent entity is on the “one” side of the
relationship line, and the child entity is on the “many” side.
 R/ships have 2 properties that convey meaning about the nature of the
entity relationship.
1.
1. Cardinality
Cardinality: ratio of parent instances to child instances (1:1, 1:N, or
M:N)
2. Modality
Modality: characterizes the nature of the r/ship b/n two entities.
R/ships have a modality of either “required”(not null) or
“optional”(null) i.e., whether an instance of an entity can exist without
a related instance in the related entity.
E.g., Customer instances could exist in the Customer entity without having
placed any Custom Orders; the relationship is optional. Modality is
Modality is
depicted by placing a zero on the r/ship line next to the parent entity if
depicted by placing a zero on the r/ship line next to the parent entity if
nulls are allowed
nulls are allowed. A bar is placed on the relationship line next to the
A bar is placed on the relationship line next to the
parent entity if nulls are not allowed
parent entity if nulls are not allowed.

4.9. Entity Relationship Diagram(ERD)… symbol set
symbol set

 data dictionary: where the
analyst goes to define or look
up information about the
entities, attributes, & r/ship
on the ERD.
E.g. Data
dictionary entry for entity.

E.g., Data dictionary entry for data element. E.g., Data Dictionary entry for a Relationship

4.9. Entity Relationship Diagram(ERD)… meta data example
meta data example
 Meta data
Meta data: data about data.
Info you see in the data
dictionary.
 describes an entity, attribute
, or r/ship, such as entity
names, attribute descriptions,
& relationship cardinality, and
it is captured to help designers
better understand the system
that they are building
& to help users better
Understand the system that
they will use.

Building Entity Relationship Diagrams
Building Entity Relationship Diagrams: is a 3 steps process- 1st
identify entities; 2nd
identify attributes, and 3rd
identify relationships.
 Intersection Entity: also called associative entities are added to a data model to
store info about two entities sharing M:N relationship.
 The process of adding an intersection entity is called “resolving an M:N
relationship” because it eliminates the M:N relationship and its associated
problems from the data model.

 An independent entity: an entity that can exist without the help of another entity,
such as Customer, Custom Drone Order, Drone Base Model, and Drone Component.
These entities all have identifiers that were created from their own attributes.
Attributes from other entities were not needed to uniquely identify instances of these
entities. Independent entities are drawn as rectangles with a single border line.
 When a relationship includes an independent child entity, it is called a non-
identifying relationship. This name is derived from the fact that parent entity
attributes are not needed as part of the child entity’s identifier. E.g., the relationship
between Customer and Custom Drone Order is an example of a non-identifying
relationship.
 Dependent Entity: situations when a child entity does require attributes from the
parent entity to uniquely identify an instance. Thus, the child entity is called a
dependent entity, & its identifier consists of at least one attribute from parent entity.
 When r/ships have a dependent child entity, they are called identifying relationships.
This name is derived from the fact that parent entity attributes are needed as part of
the child entity’s identifier. E.g., Ordered Drone Component

Validating ERDS:
Validating ERDS: Normalization, Balancing ERDs with Process models
 Normalization: a process whereby a series of rules are applied to a logical data model or a
file to determine how well formed it is. These rules help analysts identify entities that are
not represented correctly in a logical data model, or entities that can be broken out from a
file. The result of the normalization process is that the data attributes are arranged to form
stable, yet flexible, relations for the data model.
 Balancing ERDs with DFDs
Balancing ERDs with DFDs: DFD data flows & data stores need to balance with the ERD.
I.e., DFD data components need to correspond with ERD’s data stores (i.e., entities) & data
elements that comprise data flows (i.e., attributes) depicted on the data model.
 Check your data model & see whether there are any entities you have created that do
not appear as data stores on your process models. If there are, add them to process
models to reflect the decision to store info about that entity in system. Verify that all
data items included in the data stores & data flows in the process model have been
included somewhere as an entity attribute in the data model.
 On the other hand, if some data elements have been omitted from the process model,
then we need to investigate whether those data items are truly needed in the
processing of the system.
•

 If they are needed, they must be added to the process model data stores and
data flows; otherwise, they should be deleted from the data model as
extraneous data items.
 A useful tool to clearly depict
the interrelationship between
process & data models is the create,
read, update, delete (CRUD) matrix.
It is a table that depicts how the
system’s processes use the data
within the system.

Chapter 4- Structured Analysis-October 2024.ppt

More Related Content

Similar to Chapter 4- Structured Analysis-October 2024.ppt

Recently uploaded

Chapter 4- Structured Analysis-October 2024.ppt