Structuring System

Requirements:
Process Modeling

GROUP 5
TEAM

MUGABO Vedaste

MUGWANEZA MANZI Audace

MUKAMFIZI Gisele

MUNEZERO Michel
Learning Objectives

● Understand the logical modeling of processes through studying examples of

data-flow diagrams.
● Draw data-flow diagrams following specific rules and guidelines that lead to
accurate and well-structured process models.
● Decompose data-flow diagrams into lower level diagrams.
● Balance higher-level and lower-level data-flow diagrams.
● Use data-flow diagrams as a tool to support the analysis of information
systems.
● Use decision tables to represent process logic.
 Key terms
Process modeling involves graphically representing the processes, or
actions, that capture, manipulate, store, and distribute data between a
system and its environment and among components within a system. It
helps analysts understand and communicate how a system operates and
how data moves through it. We need process modeling to improve
communication and aid in system design. Techniques we use are data
flow diagram, Flowcharts and Case Diagrams.
Modeling a system, The analysis team begins the process of structuring
requirements with an abundance of information gathered during
requirements determination. You must organize the information into a
meaningful representation of the information system that exists and of the
requirements desired in a replacement system. It is a critical step in system analysis
and design, helping stakeholders visualize how a system works and how its components interact.

Deliverables and Outcomes, First, a context data-flow diagram shows the system,
indicating which elements are inside and outside the system. Second, data-flow
diagrams of the current system specify which people and technologies are used in
which processes to move and transform data, accepting inputs and producing outputs.
Data flow diagrams
 Data flow diagrams

Data-flow diagrams are versatile diagramming tools. With only four symbols,
data-flow diagrams can represent both physical and logical information systems. The
four symbols used are datastores, processes, sources/sinks (or external entities).It’s a
graphical representation that visually maps out how data moves through a system or process.

Data store Data at rest, which may take the form of

many different physical representations.

Process The work or actions performed on data

Process so that they are transformed, stored, or
distributed.

Sink/ Source/sink The origin and/or destination of data;

Source sometimes referred to as external entities
DFD Example MACOCO Restaurant
 Recap

1. Learning objectives
2. Defining key terms ( Process modeling, Modeling a system
process, Data Flow Diagram, Tools figma, Deliverables and
outcomes. )
3. DFD mechanics ( data store, Process, Source/Sink
4. Developing DFD Example MACOCO Restaurant

How do you decide whether a system component

should be represented as a source/sink or as a
process?
 DFD Rules using a diagram

1. Process: No process can have only outputs or Input , A process has a

verb-phrase label.
2. Data Store: Data can only move in or from Data Store moved by Process
3. Sink/ source: Data cannot move directly from a source to a sink. They
must be moved by a process if the data are of any concern to our system.
Otherwise, the data flow is not shown on the DFD.
4. Data Flow: A data flow has only one direction of flow between symbols.A
data flow to a data store means update (delete or change).A data flow from
a data store means retrieve or use. Process
Decomposition in DFDs

● Functional decomposition is the process of breaking

down a system into smaller, more manageable parts. This
helps in understanding and designing complex systems.
● The decomposition starts from a context diagram (a
high-level overview) and moves into more detailed levels.
● The level-0 DFD provides the main processes of the
system, showing how data flows between them.
● Each of these main processes can be further
decomposed into subprocesses, creating level-1 DFDs.
● The decomposition can continue, generating level-2,
level-3, etc., diagrams, until reaching the lowest level of
detail, known as the primitive DFD.
Example: Hoosier Burger’s Food-Ordering System

1. The context diagram represents the overall system and its interaction
with external entities (customers, kitchen, inventory system).
2. The level-0 DFD breaks the system into four main processes.
3. The level-1 DFD further decomposes one of these processes (e.g.,
"Receive and Transform Customer Food Order") into five
subprocesses.
4. If necessary, each of these sub processes can be further decomposed,
resulting in level-2 DFDs, and so on.
Balancing Data Flow Diagrams and Primitive DFD
What is Balancing?

Balancing in DFDs ensures that when a process is decomposed into a lower-level diagram,
the number and type of inputs and outputs must remain the same. This principle
maintains consistency across different levels of a system’s data representation.

Key Concepts of Balancing

1. Conservation of Inputs and Outputs

○ When breaking down a process from a level-0 DFD into a level-1 DFD, all
inputs and outputs must be maintained.
○ No new inputs or outputs should appear unless they are accounted for in the
previous level.
2. Example: Hoosier Burger Food-Ordering System
○ Context Diagram:
■ One input: Customer Order
■ Three outputs: Customer Receipt, Kitchen Order, Management
Reports.
 ○ Level-0 DFD:
■ The same input and outputs appear, ensuring balancing.
○ Level-1 DFD (Process 1.0 Decomposition):
■ The single input and multiple outputs remain the same.
1. Unbalanced DFD Example
○ Suppose the context diagram has one input (A) and one output (B).
○ If the level-0 DFD introduces a new input (C) that wasn’t in the context diagram, the
diagrams are unbalanced.
○ Solution: The analyst must update the context diagram to include C and its source.

A Primitive DFD is the lowest level of a Data Flow Diagram (DFD), where no further
breakdown is necessary. To determine when to stop decomposing, follow these guidelines:

1. Processes are reduced to a single decision or database operation (e.g., retrieve,

update, delete).
2. Each data store represents only one entity (e.g., customer, product).
3. Users and analysts don’t need more detail for system development.
4. All data flows are fully detailed, with no need for further splitting.
5. Each business transaction, form, or report is mapped to a single data flow.
6. All menu options have corresponding processes.
Recap

1. DFD Rules using a diagram

2. Decomposition will be explained using
example in 4.
3. Balancing DFDs and Primitive DFDs
 Guidelines for Drawing DFDs

Completeness – Ensure all essential components (processes, data flows, data stores, and
external entities) are included and properly connected. CASE tools help detect missing
elements.

Consistency – Higher and lower-level DFDs should align. No data flows should appear in one
level but not another. CASE tools help identify inconsistencies.

Timing – DFDs do not represent time-based operations (e.g., real-time updates vs. batch
processing). They should be drawn as if the system is always running.

Iterative Development – DFDs require multiple revisions to accurately model the system. On
average, about three revisions per DFD are needed. CASE tools simplify this process.

Primitive DFDs ensure that the system is detailed enough for development while avoiding
unnecessary complexity. They help maintain completeness, consistency, and accuracy in
system modeling and serve as a foundation for system design and implementation.
DFD Design rules, Document to download

2-system-analysis-and-design-vallacish-5th-edition1-189.pdf - Google Driv

e
 Using DFDs as Analysis Tools
Data-Flow Diagrams (DFDs) are versatile tools for process modeling and gap analysis, used to visualize
and improve both physical and logical systems. They help analysts identify discrepancies and
inefficiencies, such as redundant data flows, unused data, and excessive processing steps.

Key Analysis Techniques:

● Gap Analysis: Detects mismatches between DFDs or within a single DFD.

● Redundancy Check: Identifies duplicated data flows or data stores.
● Validation of Rules: Ensures processes have sufficient inputs and necessary outputs without
violating DFD rules, like avoiding process loops.
DFD Analysis Softwares

1. Microsoft Visio
2. Lucidchart
3. Enterprise Architect

https://www.lucidchart.com/pages
 Logic Modeling

Logic modeling is a method used to represent the internal processing logic of a system.

Purpose: To represent the internal logic of processes that Data-Flow Diagrams (DFDs) cannot show.

Use Case: Helps to define how input data is processed into output information within a system's
processes.
Decision Tables
 Decision Tables

A decision table is a matrix that represents the logic of a decision, showing possible conditions and the corresponding
actions.

Components of a Decision Table:

1. Condition Stubs: List all relevant conditions.

2. Action Stubs: Specify the actions resulting from the conditions.
3. Rules: Link specific conditions to specific actions.

Example: Payroll System Decision Table (Figure 6-14):

● Conditions: Employee type (Salaried or Hourly) and Hours worked (<40, 40, >40).
● Actions: Pay base salary, Calculate hourly wage, Calculate overtime, Produce Absence Report.
● Rules: Define which actions are triggered by each condition combination.
Component of the Decision Tables

1. Condition stubs are part of a decision table that lists all the relevant conditions (or decision criteria) that
need to be evaluated before taking an action. They define the specific scenarios under which actions are
triggered.
2. Action stubs are components of a decision table that list all possible actions that might be taken based on
evaluated conditions. They describe what the system or process should do when specific conditions
(outlined in condition stubs) are met.
3. Rules in a decision table represent specific combinations of conditions and the corresponding actions that
should be executed. Each rule is essentially a column in the decision table that maps a unique scenario (set
of conditions) to specific actions.
Web Store
 Example on Web store

A web store needs to decide the appropriate action when a customer attempts to place an
order. The decision depends on three conditions:

● Is Payment Completed?
● Is Stock Available?
● Is the Customer a VIP Member?

Completeness: All possible scenarios are covered.

Priority Handling: VIP members receive special offers when stock is limited.

Consistency: No contradictory actions under the same rule.

Clarity: Clear guidelines for developers or business teams to implement.

This decision table ensures that the web store's checkout process is logical, fair, and
provides a good user experience, especially for VIP customers.
Recap

1. Guidelines for drawing rules

2. Using DFDs analysis tools, figma, draw.io, Adobe
3. Logic modeling ( Decision table, Condition stubs, Action
stubs, Rules
4. Example on Web store.

Explain what the term DFD completeness

means and provide an example.
What you learned from this presentation?
Thank
you!