Chapter 5

Systems Modeling Concepts: Logical vs. Physical Models

Systems analysis relies on graphical modeling techniques to analyze, design, and document information systems.
Logical Model:
- Defines what an information system must do, independent of any hardware, software, programming language, or physical implementation details.
- Focuses entirely on business requirements, processing operations, data inputs, and outputs.
Physical Model:
- Describes how the system will be constructed and implemented physically.
- Outlines implementation details, including specific technology stacks, platform choices, hardware architectures, data structures, and manual procedures.

Overview of Data Flow Diagrams (DFDs)

A Data Flow Diagram (DFD) is a graphical technique used in structured analysis to show how data moves through an information system and how input data is transformed into useful information.
DFDs focus exclusively on data motion, processes, data storage, and system interfaces.
DFDs do not depict program logic, procedural steps, execution order, or conditional loops.
A set of DFDs provides a comprehensive logical model of the system, illustrating functional requirements clearly to users, management, and technical teams.

Data Flow Diagram Symbols and Symbol Sets

DFDs use four foundational symbols to represent system components: processes, data flows, data stores, and external entities.
Two prominent symbol sets are widely recognized in systems analysis: Gane and Sarson and Yourdon.

Data flow diagram symbols, symbol names, and examples of the Gane and Sarson and Yourdon symbol sets

Process Symbol:
- Represents a functional component or business logic that receives input data and transforms it into output data.
- Gane and Sarson Symbol: A rectangle with rounded corners, partitioned with a top section for the reference number.
- Yourdon Symbol: A circle.
- Naming Convention: Must be named using an active verb-noun phrase that clearly states its function (e.g., APPLY PAYMENT, CALCULATE GROSS PAY, GRADE STUDENT WORK, CREATE INVOICE).
- Black Box Concept: A process symbol can be viewed as a "black box" where internal processing details are hidden from view at higher abstraction levels.
- Must contain at least one input data flow and at least one output data flow.
Data Flow Symbol:
- Represents one or more specific data items or structured records moving through the system.
- Gane and Sarson & Yourdon Symbol: A line with a single or double arrowhead indicating the direction of data movement.
- Naming Convention: Named with a descriptive noun (e.g., BANK DEPOSIT, SERVICES PERFORMED, HOURS WORKED, PAY RATE).
Data Store Symbol:
- Represents data that the system preserves for later retrieval or processing.
- Gane and Sarson Symbol: A flat open-ended rectangle (or double-sided line with a left-hand partition for data store identification like $D1$ ).
- Yourdon Symbol: Two parallel horizontal lines.
- Naming Convention: Named with a plural noun (e.g., STUDENTS, ACCOUNTS RECEIVABLE, DAILY PAYMENTS).
- Internal Structure: A DFD does not show the granular internal fields or data structure of a data store; detailed definitions are recorded in the data dictionary.
External Entity Symbol:
- Shows how the system interfaces with the outside environment.
- Represents individuals, departments, external systems, or organizations that supply data to the system or receive output from the system.
- Also called terminators because they represent the origin sources or ultimate destinations of data flows.
- Gane and Sarson Symbol: A shaded, three-dimensional rectangle.
- Yourdon Symbol: A flat rectangle.
- Naming Convention: Named with a singular or plural noun describing the entity (e.g., CUSTOMER, EMPLOYEE, BANK, WAREHOUSE, INSTRUCTOR).

Data Flow Diagram Rules and Process Errors

Correct process and data flow configurations ensure valid data transformation across the system.

Examples of correct combinations of data flow and process symbols

Examples of valid process combinations:
- A process receiving a single input SERVICES PERFORMED and producing a single output INVOICE (Process: CREATE INVOICE).
- A process receiving SUBMITTED WORK and outputting GRADED WORK and STUDENT GRADE (Process: GRADE STUDENT WORK).
- A process receiving multiple inputs HOURS WORKED and PAY RATE to produce output GROSS PAY (Process: CALCULATE GROSS PAY).
- Chained processes where output of VERIFY ORDER (ACCEPTED ORDER) serves as input to ASSEMBLE ORDER to yield INVENTORY CHANGE.
Critical Process Errors to Avoid:

Examples of incorrect combinations of data flow and process symbols

*   **Spontaneous Generation**:
    *   Occurs when a process produces output data flows without receiving any input data flows.
    *   Example: A process labeled `APPLY INSURANCE PREMIUM` that emits `POLICY NUMBER` and `PAYMENT AMOUNT` without any incoming data flow.
*   **Black Hole**:
    *   Occurs when a process receives input data flows but produces no output data flows.
    *   Example: A process labeled `CALCULATE GROSS PAY` that accepts `HOURS WORKED` and `PAY RATE` as inputs but has zero outgoing flows.
*   **Gray Hole**:
    *   Occurs when a process has input data flows and output data flows, but the provided input is logically impossible or completely inadequate to produce the designated output.
    *   Example: A process labeled `CALCULATE GRADE` that receives `DATE OF BIRTH` as its sole input and attempts to generate `FINAL GRADE`.

Rules for Data Stores, External Entities, and Data Flows

Rules governing connections between DFD symbols must be strictly observed to maintain logical consistency.

Examples of correct uses of data store symbols

Examples of incorrect uses of data store symbols

Data Store Rules:
- A data store must be connected to a process via a data flow.
- Data cannot flow directly between two data stores without an intervening process (e.g., connecting COURSES directly to STUDENTS via CLASS LIST is incorrect).
- Data cannot flow directly from a process to a data store without a defined output, nor can a process draw from a store without proper flow logic.
- Each data store should generally have at least one incoming data flow (to update/write data) and at least one outgoing data flow (to read/retrieve data).
External Entity Rules:

Examples of correct uses of external entities

Examples of incorrect uses of external entities

*   An external entity must connect directly to a process via a data flow.
*   Data cannot move directly from one external entity to another external entity (e.g., `PAYROLL DEPARTMENT` sending a `PAYCHECK` directly to `EMPLOYEE` without passing through a system process is invalid on a DFD).
*   An external entity cannot directly write to or read from a data store (e.g., `CUSTOMER` sending `PAYMENT` directly into `ACCOUNTS RECEIVABLE`, or `BANK` reading `BANK DEPOSIT` directly from `DAILY PAYMENTS`).

Summary Matrix of Valid and Invalid Data Flows:

Correct and Incorrect Examples of Data Flows

*   `Process to Process`: **Valid**
*   `Process to External Entity`: **Valid**
*   `Process to Data Store`: **Valid**
*   `External Entity to External Entity`: **Invalid**
*   `External Entity to Data Store`: **Invalid**
*   `Data Store to Data Store`: **Invalid**
*   All data flow lines must be uniquely and descriptively labeled.
*   A double-headed arrow may be used on a data flow line only if the exact same data structure/items move in both directions between symbols.

Guidelines and Step-by-Step Construction of DFDs

General Modeling Guidelines:
- Fit the top-level context diagram on a single page.
- Name the main process in the context diagram after the entire information system (Process $0$ ).
- Assign unique names to symbols within each symbol set.
- Do not cross data flow lines.
- Provide a unique reference number and descriptive name for every process.
- Ensure the overall model is accurate, readable, and satisfies business requirements.
Three-Step DFD Construction Process:
- Step 1: Draw a Context Diagram
  - Provides a high-level overview of the system showing external boundaries and interfaces.
  - Contains exactly one process symbol labeled Process $0$ , representing the system as a whole.
  - Does not show any data stores.
  - Shows all external entities interacting with the system and all primary input/output data flows connecting entities to Process 0$.\n\n![Context diagram DFD for grading system](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/10.jpg)\n\n * *Grading System Context Diagram Example*:\n * Process 0: `GRADING SYSTEM`\n * Entities: `STUDENT RECORDS SYSTEM`, `STUDENT`, `INSTRUCTOR`\n * Flows: `SUBMITTED WORK` (from Student to system), `GRADED WORK` (from system to Student), `CLASS ROSTER` (from Student Records System to system), `FINAL GRADE` (from system to Student Records System), `GRADING PARAMETERS` (from Instructor to system), `GRADE REPORT` (from system to Instructor).\n\n![Context diagram DFD for an order system](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/11.jpg)\n\n * *Order System Context Diagram Example*:\n * Process 0: `ORDER SYSTEM`\n * Entities: `CUSTOMER`, `WAREHOUSE`, `SALES REP`, `BANK`, `ACCOUNTING`\n * Flows: `ORDER` and `PAYMENT` (from Customer), `ORDER REJECT NOTICE` and `INVOICE` (to Customer), `PICKING LIST` (to Warehouse), `COMPLETED ORDER` (from Warehouse), `COMMISSION` (to Sales Rep), `BANK DEPOSIT` (to Bank), `CASH RECEIPTS ENTRY` (to Accounting).\n * **Step 2: Draw Diagram 0 DFD**\n * Creates an exploded view of Process 0$.
  - Displays the primary sub-processes (typically numbered $1, 2, 3, \dots$ ), key data stores, and internal data flows.

    *   *Order System Diagram 0 Example*:
        *   Sub-processes: `1 FILL ORDER`, `2 CREATE INVOICE`, `3 APPLY PAYMENT`.
        *   Data Store: `D1 ACCOUNTS RECEIVABLE`.
        *   Internal Flows: `INVOICE` recorded into `D1 ACCOUNTS RECEIVABLE`, `INVOICE DETAIL` pulled from  $D1$  into Process  $3$ , `PAYMENT DETAIL` sent from Process  $3$  to D1$.\n    *   **Step 3: Draw Lower-Level Diagrams**\n        *   Decomposes complex sub-processes into detailed sub-diagrams.\n\n![Diagram 1 DFD shows details of the FILL ORDER process in the order system](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/13.jpg)\n\n        *   *Order System Diagram 1 DFD Example* (decomposing Process 1\text{ FILL ORDER}):\n            *   Processes: `1.1 VERIFY ORDER`, `1.2 PREPARE REJECT NOTICE`, `1.3 ASSEMBLE ORDER`.\n            *   Data Stores: `D2 CUSTOMERS`, `D3 PRODUCTS`.\n            *   Internal Flows: `ORDER` enters `1.1`, checks `PRODUCT DETAIL` from D3 $and `CREDIT STATUS` from$ D2 $. If rejected, sends `REJECTED ORDER` to `1.2` which updates `CREDIT HISTORY` in$ D2 $and emits `ORDER REJECT NOTICE`. If accepted, `ACCEPTED ORDER` passes to `1.3`, which reads `PICKING DETAIL` from$ D3 $, updates `INVENTORY CHANGE` in$ D3, and sends `PICKING LIST` to `WAREHOUSE`.\n\n# Leveling and Balancing Data Flow Diagrams\n\n*   **Leveling**:\n    *   The technique of using a series of increasingly detailed DFDs to model an information system from general to specific.\n    *   Also referred to as exploding, partitioning, or decomposing.\n    *   Deconstructs a parent black box process into lower-level child diagrams.\n\n![Parent DFD showing process 0 as a black box](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/17.jpg)\n\n![Process 0 black box revealed into lower level processes inside dashed line](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/16.jpg)\n\n    *   In higher-level parent diagrams, Process 0 $represents a black box. In the child diagram, Process$ 0 $reveals underlying internal components (e.g., Processes$ 1, 2, 3 $, Data Stores$ 1 $and$ 2, and internal flows).\n*   **Balancing**:\n    *   Ensures that input and output data flows of a child DFD match exactly with the incoming and outgoing data flows of the parent process.\n\n![Parent Diagram 0 and exploded Diagram 3 DFD balanced](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/15.jpg)\n\n    *   *Balancing Validation Example*:\n        *   Parent Process 3\text{ APPLY PAYMENT} $in Diagram$ 0 $receives inputs `PAYMENT` (from Customer) and `INVOICE DETAIL` (from$ D1\text{ ACCOUNTS RECEIVABLE} $) and outputs `PAYMENT DETAIL` (to$ D1), `COMMISSION` (to Sales Dept), `BANK DEPOSIT` (to Bank), and `CASH RECEIPTS ENTRY` (to Accounting).\n        *   Exploded Diagram 3\text{ DFD} $(containing processes$ 3.1\text{ POST PAYMENT} $,$ 3.2\text{ DEPOSIT PAYMENT} $,$ 3.3\text{ PREPARE ACCOUNTING ENTRY} $,$ 3.4\text{ PAY COMMISSION} $, and store$ D4\text{ DAILY PAYMENTS}) maintains exact equivalence for all boundary inputs and outputs.\n\n# The Data Dictionary and Repository Management\n\n*   A **Data Dictionary** (or data repository) is a central storehouse of information about all data elements, data structures, data flows, data stores, processes, and entities within an information system.\n*   Used by analysts to collect, document, define, and organize facts about system components.\n*   **Data Element**: The smallest meaningful unit of data in an information system (also called a data item or field).\n*   **Record**: A meaningful group of related data elements combined into a cohesive unit (also called a **data structure**).\n*   **CASE Tools**:\n    *   Computer-Aided Software Engineering (CASE) repositories automate documentation management, preventing discrepancies as systems grow in complexity.\n    *   Standardize data definitions across all development phases of the Systems Development Life Cycle (SDLC).\n\n# Documenting Data Dictionary Objects\n\n*   Comprehensive data dictionary entries require standard documentation attributes for each object type:\n*   **Documenting Data Elements**:\n    *   *Attributes*: Name/label, Alias, Type and length, Default value, Acceptable values (Domain & validity rules), Source, Security level, Responsible user(s).\n\n![Visible Analyst screen describing SOCIAL SECURITY NUMBER](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/18.jpg)\n\n    *   *Visible Analyst Specification Example*:\n        *   Label: `SOCIAL SECURITY NUMBER`\n        *   Entry Type: `Data Element`\n        *   Description: `Social Security Number`\n        *   Alias: `SSN`\n        *   Type and Length: `SN` (Social Security Number format, 9 digits)\n        *   Default Value: `None`\n        *   Acceptable Values: Any nine-digit number\n        *   Source: `Application form`\n        *   Security: `Payroll department`\n        *   Responsible User: `Payroll department`\n        *   System Constraint: Repository object labels can be up to 128 characters long, and the first character must be a letter.\n*   **Documenting Data Flows**:\n    *   *Attributes*: Data flow name/label, Description, Alternate name(s), Origin, Destination, Record/structure, Volume and frequency.\n*   **Documenting Data Stores**:\n    *   *Attributes*: Data store name/label, Description, Alternate name(s), Attributes/data structures contained, Volume and frequency estimates.\n\n![Visible Analyst screen that documents a data store named IN STOCK](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/19.jpg)\n\n    *   *Visible Analyst Specification Example*:\n        *   Label: `IN STOCK`\n        *   Entry Type: `Data Store`\n        *   Description: `Raw materials, assemblies, and finished goods`\n        *   Alias: `AVAILABLE`\n        *   Attributes: `INVENTORY CHANGE`, `PICKING DETAIL`, `PRODUCT DETAIL`\n        *   Volume & Frequency: 5000 $to$ 10000 $product records;$ 300 $to$ 500 changes per month. (Documenting these estimates is essential as they impact database indexing and physical design decisions in subsequent SDLC phases).\n*   **Documenting Processes**:\n    *   *Attributes*: Process name/label, Description, Process number, Process logic description.\n\n![Visible Analyst screen that describes a process named VERIFY ORDER](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/20.jpg)\n\n    *   *Visible Analyst Specification Example*:\n        *   Label: `VERIFY ORDER`\n        *   Entry Type: `Process`\n        *   Description: `Accept or reject customer order based on credit status and product availability`\n        *   Process #: `1.1`\n        *   Input Data Flows: `ORDER`, `CREDIT STATUS`, `PRODUCT DETAIL`\n        *   Output Data Flows: `REJECTED ORDER`, `ACCEPTED ORDER`\n*   **Documenting External Entities**:\n    *   *Attributes*: Entity name, Description, Alternate name(s), Input data flows, Output data flows.\n*   **Documenting Records (Data Structures)**:\n    *   *Attributes*: Record name/label, Definition/description, Alternate name(s), Attribute list.\n\n![Visible Analyst screen that documents a record or data structure named CREDIT STATUS](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/21.jpg)\n\n    *   *Visible Analyst Specification Example*:\n        *   Label: `CREDIT STATUS`\n        *   Entry Type: `Data Structure`\n        *   Description: `Customer credit data`\n        *   Attributes: `CUSTOMER NUMBER` (Type: Char, Null: Yes), `CUSTOMER STATUS CODE` (Type: Char, Null: Yes)\n*   **Data Dictionary Reports**:\n    *   CASE repositories generate key reports:\n        *   Alphabetized list of all data elements by name.\n        *   User/Department responsibility reports detailing entry, updating, or deletion rights.\n        *   Cross-reference reports showing all data flows and stores referencing a specific data element.\n        *   Detailed attribute reports for selected elements, records, flows, stores, or processes.\n\n# Process Description Tools and Modular Design\n\n*   A **Process Description** documents the internal processing steps and business logic of a **functional primitive** (a lowest-level DFD process that cannot be decomposed further).\n*   Structured analysis uses three principal process description tools: Structured English, Decision Tables, and Decision Trees.\n*   **Modular Design Principles**:\n    *   Modular design constructs business logic by combining three basic logical control structures:\n\n![Sequence structure](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/24.jpg)\n\n![Selection structure](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/23.jpg)\n\n![Iteration structure](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/22.jpg)\n\n    *   **Sequence Structure**: Sequential execution of steps in exact order (e.g., `VERIFY PRODUCT CODE` \rightarrow $`VERIFY PRICE`$ \rightarrow `VERIFY STOCK LEVEL`).\n    *   **Selection Structure**: Conditional execution of distinct branches based on evaluation of a logical condition (e.g., Checking if `HOURS > 40?` If `YES`, execute `CALCULATE OVERTIME PAY`; if `NO`, skip).\n    *   **Iteration Structure (Looping)**: Continuous repeating of processing steps while or until a condition is met (e.g., Checking `END OF FILE?` If `NO`, execute `PRINT PAYCHECK` and loop back; if `YES`, terminate loop).\n*   **Structured English**:\n    *   A modified form of English used to express process logic clearly.\n    *   *Rules*:\n        *   Use only sequence, selection, and iteration structures.\n        *   Use indentation to denote logical block structure and alignment.\n        *   Limit vocabulary to data dictionary names and explicit action verbs.\n\n![Structured English description of VERIFY ORDER process](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/25.jpg)\n\n    *   *Structured English Example*:\n        *   `For each ORDER:`\n        *   `IF CUSTOMER STATUS CODE = Y and if PRODUCT DETAIL = OK`\n        *   `Output ACCEPTED ORDER`\n        *   `Else`\n        *   `Output REJECTED ORDER`\n*   **Comparison with Object-Oriented (O-O) Analysis**:\n    *   In O-O development, data and processes are combined into units called **objects**.\n    *   Similar objects are grouped into **classes**.\n    *   Operational procedures within objects are called **methods**.\n\n# Decision Tables and Decision Trees\n\n*   **Decision Tables**:\n    *   Tabular representations showing all possible combinations of conditions, business rules, and resulting actions.\n    *   Ensure every potential condition outcome is evaluated so no scenario is overlooked.\n    *   Ideal for describing complex business logic with multiple nested conditions.\n    *   **Mathematical Rule Count**: For n binary conditions, the total number of possible combinations (rules) is given by:\n        R = 2^n\n    *   Every time a new binary condition is added, the total number of rules doubles.\n\n![Simple decision table for VERIFY ORDER process](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/26.jpg)\n\n    *   *Two-Condition Verify Order Table* (n = 2 $,$ 2^2 = 4 rules):\n        *   Conditions: `Credit status is OK`, `Product is in stock`.\n        *   Rule 1: Y, Y \rightarrow `Accept order` (X).\n        *   Rule 2: Y, N \rightarrow `Reject order` (X).\n        *   Rule 3: N, Y \rightarrow `Reject order` (X).\n        *   Rule 4: N, N \rightarrow `Reject order` (X).\n\n![Decision table with 3 conditions for VERIFY ORDER process](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/27.jpg)\n\n    *   *Three-Condition Verify Order Table with Credit Waiver* (n = 3 $,$ 2^3 = 8 rules):\n        *   Conditions: `Credit status is OK`, `Product is in stock`, `Waiver from credit manager`.\n        *   Rule 1: Y, Y, Y \rightarrow Accept order.\n        *   Rule 2: Y, Y, N \rightarrow Accept order.\n        *   Rule 3: Y, N, Y \rightarrow Reject order.\n        *   Rule 4: Y, N, N \rightarrow Reject order.\n        *   Rule 5: N, Y, Y \rightarrow Accept order.\n        *   Rule 6: N, Y, N \rightarrow Reject order.\n        *   Rule 7: N, N, Y \rightarrow Reject order.\n        *   Rule 8: N, N, N \rightarrow Reject order.\n\n![Decision table simplification and rule reduction](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/28.jpg)\n\n    *   *Decision Table Simplification Procedure*:\n        1. Identify conditions where outcome is identical regardless of a specific variable's state, replacing irrelevant states with dashes (`-`).\n        2. Combine redundant rules.\n        3. *Simplified Final Result* (4 Rules):\n           *   Rule 1 (Combines 1, 2): Credit status OK = Y, Product in stock = Y, Waiver = `-` \rightarrow Accept order.\n           *   Rule 2 (Previous 5): Credit status OK = N, Product in stock = Y, Waiver = Y \rightarrow Accept order.\n           *   Rule 3 (Previous 6): Credit status OK = N, Product in stock = Y, Waiver = N \rightarrow Reject order.\n           *   Rule 4 (Combines 3, 4, 7, 8): Credit status OK = `-`, Product in stock = N, Waiver = `-` \rightarrow Reject order.\n    *   *Sales Promotion Policy Example (Holiday Season 2014)*:\n\n![Sales promotion policy initial decision table](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/30.jpg)\n\n        *   Business Rules:\n            *   Preferred customers ordering \$1000 $or more receive a$ 5\% $discount, and an extra$ 5\% discount if using the company charge card.\n            *   Preferred customers ordering under \$1000 $receive a$ \$25 bonus coupon.\n            *   Non-preferred customers receive a \$5 bonus coupon.\n        *   Initial table contains 2^3 = 8 rules across 3 conditions (`Preferred customer`, `Ordered $1,000 or more`, `Used our charge card`).\n\n![Sales promotion policy final decision table](https://assets.knowt.com/pdf-flow-prod/da6bb263-6710-42c6-95fe-2e61d9a2d5f7-figures/31.jpg)\n\n        *   Final simplified table retains clear non-redundant outcomes:\n            *   Rule 1: Y, Y, Y \rightarrow5\% $discount + Additional$ 5\% discount.\n            *   Rule 2: Y, Y, N \rightarrow5\% discount.\n            *   Rules 3 & 4: Y, N, `-` \rightarrow\$25 bonus coupon.\n            *   Rules 5 to 8: N, `-`, `-` \rightarrow\$5$$ bonus coupon.

Decision Trees:
- A graphical representation of logic showing conditions, actions, and decision paths horizontally in a branching tree format.

Decision tree for sales promotion policy

*   Provides identical analytical conclusions as a decision table, but presents decision paths in a visual flowchart format preferred by many users.

Strategic Sequence of Systems Models

While structured analysis tools construct a logical model for a new system, they are also applied during analysis to understand legacy systems.
Four-Model Approach:
1. Develop a Physical Model of the Current System.
2. Develop a Logical Model of the Current System.
3. Develop a Logical Model of the New System.
4. Develop a Physical Model of the New System.
Advantage: Guarantees thorough understanding of existing operations, preventing critical functionality from being lost.
Disadvantage: Requires additional development time and increases overall project cost.