GROUP F

Understanding Structuring
Systems Requirements
Process Modeling
 MEMBERS

Tequillo, Julia
Angela Calma, Arturo

Alarcon, Mary Viojan, Louisse

Grace
 Overview
1. Show how data-flow diagrams can logically 6. Illustrate how data-flow diagrams can be
model processes. used as tools to support systems analysis.
2. Use data-flow diagram symbols and the 7. Show how Structured English can be used
mechanical rules necessary for them to create to model process logic.
accurate and well-structured process models. 8. Demonstrate how decision tables can be
3. Decompose data-flow diagrams into lower- used to represent the logic of choice in
level diagrams. conditional statements.
4. Illustrate the concept of balanced DFDs. 9. Explain that process modeling for Internet-
5. Explain and demonstrate the differences based electronic commerce applications is no
among the four types of DFDs: current physical, different than the process used for other
current logical, new physical, and new logical. applications.
Structuring System Requirements

It involves organizing and defining the specific

needs and expectations of a system in a clear,
concise, and consistent manner. It involves
gathering requirements from stakeholders,
analyzing them, and documenting them in a
structured format.
 Process Modeling
It is a technique processed used to represent
the flow of data and activities within a system.
It involves creating diagrams, such as Data-
Flow Diagrams (DFDs), to represent the
system’s processes, or data flows, that capture,
manipulate, store, and distribute data between
the system and its environment and between
components within a system.
 Data-Flow Diagram
It graphically illustrate movement of data between
external entities and the processes and data stores
within a system. They provide a high-level view of
how data enters a system, is processed and then
exist. DFDs are particularly useful for modeling
information systems because they focus on logical
flow of data. And DFDs can often visual “say” things
that would be hard to explain in words.
 Four Symbols of DFDs
External entity: Represent a Process: Represent a
source or destination of data transformation of data. Any
outside the system. That send or process that changes the data,
receives data, communicating with producing an output. It might
the system being diagrams. They perform computations, or sort data
are the sources and destinations of based on logic, or direct the data
information entering or leaving the flow based on business rules. It is
systems. They might be an outside depicted as a round rectangle.
organization or person, a computer
system or a business system. It is
depicted as a square.
 Four Symbols of DFDs
Data store: Represent a repository Data flow: Represents the
that holds information for later use, movement of data between
such as a database table or a process or between processes,
membership form. Each data store external entities and data store. It
receives a simple label, such as portrays the interface between
“orders”. It is depicted as a the other components and is
rectangle shown with arrows, typically
labeled with a short data name,
like “billing details”
4 common system of symbols are named after their creator

Yourdon and Coad

Yourdon and DeMarco
Gane and Sarson
SSADM (Structured system
Analysis and Design)
4 common system of symbols are named after their creator
 Mechanical Rules of DFDs
1. All process should have unique 3. Any single DFD should not have
names. If two data-flow lines(or more than about seven processes.
data stores) have the same label,
they should both refer to the 4. No process can have only
exact same data flow(or data outputs. (this would imply that the
store). process is making information
from nothing) If can object has
2. The inputs to a process should only outputs, then it must be a
different from the outputs of a source.
process.
 Mechanical Rules of DFDs
6. A process has verb phrase
5. No process can have only label.
inputs. (this is referred to as a
“black hole”) If an object has only 7. Data cannot move directly
inputs, then it must be a sink . from one data store to another
data store. Data must be moved
by a process.
 Mechanical Rules of DFDs
8. Data cannot move directly from an 9. Data cannot move directly to an
outside source to a data store. Data outside sink/external entity from data
must be moved by a process that store. Data must be moved by a
receives data from the source and process.
places the data in the data store.
 Mechanical Rules of DFDs
11. Data cannot move directly from a source
to a sink. It must be moved by a process if
10. A data store has a noun phrase label. the data are of any concern to the system.
If data flows directly from a source to a
sink (and does involved processing) then it
is outside the scope of the system and is
not shown on the system data flow
diagram DFD.
 Mechanical Rules of DFDs
13. A data flow has only one direction
12. A source/sink/external entity between symbols. It may flow in
has a noun phrase label. both direction between a process
and a data store to show a read
before an update. To effectively
show a read before an update, draw
two separate arrows because the 2
steps (reading and updating) occur
at separate times.
DFD levels and layers
 DFD levels and layers
A data flow diagram can dive into progressively more
detail by using levels and layers, zeroing in on a
particular piece. 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.
 DFD levels and layers
Level 0
DFD Level 0 is also called a Context Diagram. It’s a basic overview of the
whole system or process being analyzed or modeled. 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.
 DFD levels and layers
Example for Level 0 DFD: Online Food Ordering System
1. System Name: "Online Food Ordering System"
2. External Entities:
Customer: The person ordering food.
Restaurant: The place preparing the food.
Payment Gateway: The platform used to process payments.
3. Process:
The Online Food Ordering System is the main process.
4. Data Flows:
Customer → Online Food Ordering System: Sends Order Details.
Online Food Ordering System → Restaurant: Sends Order Information.
Restaurant → Online Food Ordering System: Sends Order Status (confirmation, preparation time).
Online Food Ordering System → Customer: Sends Order Confirmation and Status.
Customer → Payment Gateway: Sends Payment Details.
Payment Gateway → Online Food Ordering System: Sends Payment Confirmation.
 DFD levels and layers
LEVEL 1
DFD Level 1 provides a more detailed breakout of pieces of the
Context Level Diagram. You will highlight the main functions
carried out by the system, as you break down the high-level
process of the Context Diagram into its subprocesses.
 DFD levels and layers
Example for Level 1 DFD: Student Registration System
1. System Name: Student Registration System
2. Main Sub-Processes:
1.1 Register Student: Registers new students and collects their details.
1.2 Course Enrollment: Manages course selection and enrollment for students.
1.3 Generate Schedule: Provides students with their course schedules after enrollment.
3. External Entities:
Student: The person who registers and enrolls in courses.
Admin: A person who manages student data and course availability.
Course Database: Stores available courses and student enrollment information.
4. Data Flows:
Student → 1.1 Register Student: Provides personal information to register.
1.1 Register Student → Course Database: Saves student information in the database.
Admin → 1.2 Course Enrollment: Adds or updates course availability in the system.
Student → 1.2 Course Enrollment: Selects courses for enrollment.
1.2 Course Enrollment → Course Database: Updates student enrollment in the selected courses.
Course Database → 1.2 Course Enrollment: Confirms course enrollment availability.
1.2 Course Enrollment → 1.3 Generate Schedule: Sends enrolled courses for schedule creation.
1.3 Generate Schedule → Student: Provides the course schedule to the student.
 DFD levels and layers
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.
 DFD levels and layers
Level 2 DFD Example: Order Pizza in Pizza Ordering System
1. Main Process: Order Pizza (Process 1.2 in a hypothetical Level 1 DFD of the Pizza Ordering System)
2. Sub-Processes of Order Pizza:
1.2.1 Choose Pizza: Allows customers to select the type of pizza they want.
1.2.2 Add Toppings: Lets customers choose additional toppings for their pizza.
1.2.3 Enter Delivery Information: Collects information about where to deliver the pizza.
1.2.4 Confirm Order: Finalizes the order and provides confirmation to the customer.
3. External Entities:
Customer: The person placing the pizza order.
Pizza Menu: Contains the types of pizzas and available toppings.
4. Data Flows:
Customer → 1.2.1 Choose Pizza: Selects the pizza type.
1.2.1 Choose Pizza → Pizza Menu: Requests available pizza options.
Pizza Menu → 1.2.1 Choose Pizza: Returns the list of pizza types.
1.2.1 Choose Pizza → 1.2.2 Add Toppings: Sends selected pizza type to the next step.
Customer → 1.2.2 Add Toppings: Chooses toppings for the pizza.
1.2.2 Add Toppings → 1.2.3 Enter Delivery Information: Sends selected toppings for confirmation.
Customer → 1.2.3 Enter Delivery Information: Provides delivery address.
1.2.3 Enter Delivery Information → 1.2.4 Confirm Order: Sends order details for confirmation.
1.2.4 Confirm Order → Customer: Sends order confirmation back to the customer.
DFD levels and layers
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.
 Four Types of DFDs
1. Current Physical DFD
This diagram represents the actual physical processes and flows of
data in the current system. It captures how data is handled, the
technology used, and the specific entities involved.
Example: Online Food Ordering System (CPDFD):
1. Customer places order (paper form)
2. Order is given to Cashier (physical)
3. Cashier writes order on receipt (physical)
4. Receipt is filed in binder (physical)
 Four Types of DFDs
2. Current Logical DFD
This focuses on the logical aspects of the current system without
delving into the physical implementation. It describes what the
system does and how data moves through it, abstracting away the
specific technologies and processes used.
Example:Current Logical Data Flow Diagram (CLDFD):
1. Customer places order
2. Order is processed
3. Order is stored
 Four Types of DFDs
3. New Physical DFD
This diagram outlines the proposed changes to the system,
illustrating how the physical processes will operate once changes
are implemented. It shows new hardware, software, or workflows.
example:
New Physical Data Flow Diagram (NPDFD):
1. Customer places order (online form)
2. Order is processed by Website (digital)
3. Order is stored in Database (digital)
 Four Types of DFDs
4. New Logical DFD
This diagram depicts how the new system will function logically,
focusing on what it will do without specifying the physical
implementations. It outlines the new processes and data flows that
enhance or change the system.
example:
New Logical Data Flow Diagram (NLD FD):
1. Customer places order
2. Order is processed
3. Order is stored
HOW DFDs CAN BE
USED AS A TOOL TO
SUPPORT SYSTEM
ANALYSIS
 System Analysis

Systems analysis involves studying a

system or its components to identify its
objectives, understand its functionality,
and discover inefficiencies or potential
improvements
 Role of DFDs

Data-flow diagrams (DFDs) are

one of the most popular tools
used in systems analysis to
visually represent how data
moves through a system.
 Why DFDs Are Useful
Simplification: They break down complex systems into smaller, more manageable
processes, helping analysts and stakeholders understand system functionality.
Visualization: By showing data flow between processes, external entities, and data
stores, DFDs provide a clear overview of the interactions within a system.
Identification of Inefficiencies: Analysts can use DFDs to identify bottlenecks,
redundancies, or unnecessary steps in data processing, helping them improve system
performance.
Consistency Checking: DFDs help verify that data is used and stored correctly, ensuring
that no data is lost or generated without a defined purpose.
 Key Components in DFDs
and Their Role in Analysis
Processes: These show how data is transformed or manipulated in the system.
Identifying processes in DFDs allows analysts to ensure that each action is aligned with
user needs.
Data Flows: Arrows representing the movement of data between processes, external
entities, and data stores. Analysts track these to ensure data is correctly passed and
received.
Data Stores: Indicate where data is held. Analysts check these to see if the system is
efficiently managing data storage and retrieval.
External Entities: Represent users or other systems that interact with the system. These
are crucial for understanding system boundaries and interactions with external
environments.
 Benefits of Using DFDs in
Systems Analysis
Improved Communication: DFDs make it easier for non-technical stakeholders to
understand the system’s operation, enabling better communication between analysts and
stakeholders.
Early Detection of Issues: Because DFDs model data movement and processes early in
the development cycle, potential inefficiencies or missing functionalities can be detected
early on.
Modularity: DFDs allow analysts to decompose a system into smaller processes, making
it easier to pinpoint specific areas for improvement or redesign.
How Structured English Can
Be Used to Model Process
Logic
 Structured English

Structured English is a technique used to

describe the logic of processes in clear,
simple, and understandable English, using
a restricted vocabulary and structured
syntax. It often resembles a mix of
natural language and programming logic.
Key Features of Structured
English
Restricted Vocabulary: Only certain words, especially related
to control structures like "IF," "THEN," "ELSE," "WHILE," "DO," and
"END," are used.
Simple Logic: Structured English is meant to reduce ambiguity
and make the process logic clear.
Pseudocode-like Style: It often looks like pseudocode,
providing a bridge between plain English and actual code,
making it easier to translate into programming later.
Structure and Syntax of
Structured English
Conditional Statements: "IF-THEN-ELSE" structures to show
choices or conditions.
Looping Structures: "WHILE-DO" loops to repeat certain
actions until a condition is met.

Action Statements: Instructions for what the process should

do, written in clear action-oriented sentences.
Benefits of Structured English
in Process Modeling
Simplicity: It translates complex system logic into plain, easy-
to-understand terms.
Precision: Structured English allows analysts to define the
exact steps in a process without relying on technical language,
avoiding ambiguity.
Consistency: It ensures consistency in how logic is applied
throughout different processes, especially in large systems
with many rules.
Loan Application System
 Decision Tables in E-commerce and
Process Modeling

Decision tables are a powerful tool for representing complex decision

logic in a clear and concise manner. They are particularly useful in e-
commerce and process modeling, where there are often numerous
conditional statements that need to be evaluated
 E-commerce Example: Discount
Calculation

Consider an e-commerce website with a complex

discount system. The discount applied to an order
depends on several factors:
 E-commerce Example: Discount
Calculation

By using a decision table, we can easily visualize and

understand the complex discount logic. This table can
be directly translated into code or a rule engine to
automate the discount calculation process
 Process Modeling Example: Loan
Approval

In a loan approval process, there are multiple factors to

consider, such as the applicant's credit score, income,
and debt-to-income ratio. A decision table can be used
to represent the approval criteria:
 This decision table can be used to model the loan
approval process in a business process modeling tool
like BPMN. The table can be represented as a decision
node, with the conditions and outcomes clearly defined.
 Benefits of Using Decision Tables

Clarity and Conciseness: Decision tables present complex logic in a

clear and easy-to-understand format.
Completeness: They ensure that all possible combinations of
conditions and their corresponding actions are considered.
Consistency: Decision tables help maintain consistency in decision-
making throughout the system.
 Benefits of Using Decision Tables

Maintainability: Changes to the decision logic can be easily

implemented by modifying the table.
Testability: Decision tables can be used to generate test cases to
ensure the correct implementation of the logic.
 Process Modeling for
Internet-Based E-commerce
Applications: A Unified
Approach
Process Modeling for Internet-Based E-
commerce Applications: A Unified
Approach

The core principles of process modeling remain largely

consistent across different application domains, including
Internet-based e-commerce. While the specific details and
nuances may vary, the underlying methodology and
objectives are fundamentally the same.
 Understanding the Process Modeling
Approach

Process modeling is a technique used to visualize and

understand the workflow and interactions within a system.
It involves breaking down complex processes into smaller,
more manageable steps and analyzing their relationships.
This helps in identifying inefficiencies, bottlenecks, and
potential areas for improvement.
 Key Similarities in Process Modeling for
E-commerce and Other Applications:

1.)System Requirements Gathering: The process begins

with a thorough understanding of the system's
requirements. This involves identifying the goals, objectives,
and functionalities of the e-commerce application. While
the specific requirements (e.g., product catalog, shopping
cart, payment gateway) might differ from other
applications, the process of gathering and documenting
them remains similar.
 Key Similarities in Process Modeling for
E-commerce and Other Applications:

2.)Process Identification and Decomposition: Once the

requirements are understood, the process of identifying
and decomposing the system's key processes begins. This
involves breaking down the overall system into smaller,
more manageable subprocesses. In e-commerce, these
might include customer registration, product search, order
placement, and shipping.
 Key Similarities in Process Modeling for
E-commerce and Other Applications:

3.)Process Flow Analysis: The identified processes are

then analyzed to understand their sequence and
dependencies. This involves creating process flow
diagrams or using other visual techniques to represent the
flow of information and activities within the system.
 Key Similarities in Process Modeling for
E-commerce and Other Applications:

4.)Data Flow Analysis: In addition to process flow, data

flow analysis is also essential. This involves identifying the
data elements that flow between processes and
understanding how they are used and transformed.
 Key Similarities in Process Modeling for
E-commerce and Other Applications:

5.)Decision Modeling: Many processes involve decision

points where different paths can be taken based on certain
conditions. Decision modeling helps visualize and analyze
these decision points and their potential outcomes.
 Unique Considerations for E-commerce
Applications:

While the core principles of process modeling are

shared across different applications, there are some
unique considerations specific to e-commerce
 Unique Considerations for E-commerce
Applications:

•User Experience (UX): E-commerce applications

heavily rely on a positive user experience. Process
modeling can help ensure that the user interface and
workflows are intuitive and efficient.
 Unique Considerations for E-commerce
Applications:

•Security: E-commerce applications handle sensitive

customer data, so security is a top priority. Process
modeling can help identify potential security
vulnerabilities and ensure that appropriate measures
are in place.
 Unique Considerations for E-commerce
Applications:

•Integration with External Systems: E-commerce

applications often need to integrate with external
systems like payment gateways, shipping carriers,
and inventory management systems. Process
modeling can help visualize these integrations and
ensure smooth data flow.
Thank
You
QUIZ
 MULTIPLE CHOICES
1. It represent a source or destination of data
outside the system
A.Data store
B.Process
C.External entity
2. It graphically illustrate movement of data
between external entities, processes and data
stores within a system.
A.Current physical DFD
B.Data-flow Diagram
C.Structuring System
 MULTIPLE CHOICES
3. Involves studying a system or its components to
identify its objectives, understand its functionality and
discover inefficiencies or potential improvements
A.Level 0
B.Process
C.System Analysis
4. OhA Level that provides a more detailed breakout or
called Context level diagram.
A.Level 01
B.Level 0
C.New Physical DFD
 MULTIPLE CHOICES

5. It involves organizing and defining the specific needs

and expectation of a system in a clear,concise, and
consistent manner.
A.Process modeling
B.Structuring System Requirements
C.New logical DFD
 ENUMERATION

6. Its a type of diagram that provide high level

view of a data enters a system.
7. It is also called a Context diagram.
8. This diagram outlines the proposed changes to
the system.
9-10. Give 2 common system of symbols that are
named after their creator.