Business Process and Structured Modeling

Introduction

Organizations create value through processes: connected activities that transform inputs into outputs for customers, employees, regulators, or other stakeholders. In systems analysis and design, process modeling makes this work visible. It identifies who performs activities, what information is exchanged, where decisions occur, and how a proposed information system should support or improve the work.

This chapter concentrates on structured and process-oriented modeling. Context diagrams define the system boundary. Data-flow diagrams (DFDs) describe how data enters, is transformed, stored, and leaves a system. Process specifications explain the internal logic of elementary processes. Decision tables and decision trees represent conditional business rules. Business Process Model and Notation (BPMN) adds a widely used visual language for events, activities, messages, and organizational responsibility. These techniques are complementary rather than competing: a context diagram provides scope, a DFD provides information-flow structure, and BPMN emphasizes operational sequence and responsibility.

A model is not merely a drawing. It is an explicit, reviewable representation of organizational assumptions. A useful model is understandable to users, precise enough for designers, consistent across levels of detail, and traceable to business objectives and requirements.

Learning Objectives

After completing this chapter, a student should be able to:

1. Explain the purpose and limits of business process and structured modeling.
2. Construct and validate context diagrams and leveled DFDs.
3. Write process specifications using structured English, decision tables, and decision trees.
4. Interpret and create basic BPMN process models.
5. Compare current-state and proposed-state processes.
6. Apply business process improvement principles ethically and critically.
7. Analyze a process case and recommend an improved design.

1. Business Processes and Systems Analysis

A business process is a coordinated set of activities that produces a defined outcome. “Register student,” “approve loan,” and “dispatch order” are processes. A process normally has:

• a trigger or initiating event;
• inputs, such as data, materials, or requests;
• activities and decisions;
• roles or organizational participants;
• outputs and recipients; and
• controls, policies, and performance measures.

A process is different from a function. A function is a broad area of responsibility, such as finance or admissions. A process usually crosses functions and follows a beginning-to-end outcome. For example, order fulfillment may involve sales, inventory, finance, and logistics.

Systems analysts model processes to understand the current system (often called the as-is process) and design a better future system (the to-be process). The analyst must distinguish:

• Business requirement: what the organization needs to achieve.
• Business rule: a policy or condition governing decisions.
• Process activity: work performed by a person or system.
• Data flow: movement of data between a process, store, or external entity.
• Control: a constraint or check that reduces error, fraud, or non-compliance.

Modeling should begin with evidence: interviews, observation, documents, transaction records, system logs, and workshops. Analysts should record assumptions and unresolved questions rather than silently embedding guesses in diagrams.

2. Context Diagrams

A context diagram is the highest-level view of a system. It represents the entire system as one process and shows its interactions with external entities through data flows. It establishes scope, not internal design.

A context diagram contains:

1. one process representing the system;
2. external entities such as customers, suppliers, agencies, or other systems; and
3. named data flows entering or leaving the system.

It normally does not show internal data stores, internal subprocesses, or detailed control logic. External entities are outside the system boundary even when they are organizational departments, provided the modeled system does not control their internal processing.

Figure: A context diagram defines system scope and external interactions.

Context-diagram quality criteria

Every external interaction should have a meaningful name, such as “validated application,” not merely “information.” Arrows should show direction. The analyst should verify that each external entity genuinely lies outside the system boundary. A context diagram should be balanced with the next-level DFD: every context-level input and output must appear at the lower level, although it may be decomposed into several flows.

3. Data-Flow Diagrams

A DFD models the logical movement and transformation of data. Its four basic elements are:

A DFD is logical when it describes what must happen without prematurely specifying programming language, database technology, or screen layout. A physical process model may later identify a particular application, employee, device, or database.

Levels of DFDs

The context diagram is often called the context level. It is decomposed into a Level 0 DFD containing the system’s major processes and data stores. A Level 1 diagram decomposes one Level 0 process; further levels are used only when they improve understanding.

A good decomposition follows these principles:

• Balancing: inputs and outputs at a parent level must be represented at the child level.
• Meaningful process names: use verb–noun phrases such as “Validate payment.”
• Meaningful data names: use noun phrases such as “Payment authorization.”
• Completeness: every required input should lead to an appropriate output or stored result.
• No black holes: a process should not receive data without producing a relevant output.
• No miracles: a process should not produce data that cannot be derived from its inputs or existing stores.
• No direct external-to-store flow: data normally passes through a process that applies validation or business logic.
• No direct store-to-store flow: a process should mediate movement between stores.

These rules are analytic safeguards, not absolute laws. Some modeling conventions permit certain exceptions, but unexplained exceptions usually indicate an incomplete model.

Logical and physical models

A logical DFD might contain “Maintain customer record.” A physical model could show “Customer service clerk enters data into CRM application,” “CRM validation service,” and “Customer database.” Logical models are useful during requirements analysis because they avoid locking the project into a premature implementation.

4. Process Specifications

A process specification (mini-spec) defines the logic of an elementary process—the lowest level that need not be decomposed further. It may use structured English, pseudocode, a decision table, or a decision tree.

Structured English uses restricted natural language:

READ order
IF customer account is active AND stock is available THEN
    CALCULATE order total
    RESERVE stock
    SEND payment request
ELSE IF customer account is inactive THEN
    SEND account correction notice
ELSE
    SEND out-of-stock notice
END IF

The specification should identify inputs, outputs, preconditions, business rules, exception handling, and relevant data stores. It should not mix unrelated user-interface details with business logic.

5. Decision Tables and Decision Trees

A decision table is useful when several conditions combine to produce different actions. It consists of condition rows, action rows, and rule columns. Each rule column represents a meaningful combination of condition values.

Worked example: order approval

Suppose an organization approves an order only when the account is active and the order total is no more than the customer’s credit limit. If either condition fails, the order is referred or rejected according to policy.

The table makes coverage visible. “Y,” “N,” and “–” may be used where a condition is irrelevant. For example, if an inactive account always requires correction, the credit-limit condition may be “–” in that rule.

A decision tree represents the same logic as a sequence of branches. It is often easier for users to follow when decisions occur in a natural order, but it can become unwieldy when many conditions exist. Decision tables are generally better for checking completeness and identifying combinations; trees are often better for explaining execution order.

A sound decision model should test for mutually exclusive outcomes, complete coverage, unreachable rules, contradictory actions, and missing combinations. Business rules should be traceable to policy, law, contract, or an authorized business owner.

6. BPMN for Process Modeling

BPMN is a standardized notation for modeling business processes. Basic BPMN elements include:

• Events: something that happens, such as a message received, timer reached, or process completed. Events are circles.
• Activities: work performed, such as “Assess application.” Activities are rounded rectangles.
• Gateways: points that control divergence or convergence, such as an exclusive decision. Gateways are diamonds.
• Sequence flows: order of activities within a process or pool.
• Message flows: communication between separate participants or pools; they should not be used as internal sequence arrows.
• Pools and lanes: pools represent participants or organizations; lanes partition responsibility within a participant.

An exclusive gateway means one route is selected based on a condition. A parallel gateway means multiple routes proceed concurrently. An inclusive gateway allows one or more routes, depending on conditions. Analysts should label gateway conditions clearly and show how paths eventually converge where appropriate.

BPMN is especially useful for cross-functional workflows and event-driven processes. DFDs answer “what data is transformed and where does it go?” BPMN answers “what happens, in what order, by whom, and under which event or decision?” A project may use both.

Common BPMN errors

Analysts often confuse sequence flow with message flow, omit start or end events, place activities in the wrong lane, or use gateways without explicit conditions. A diagram should not imply that two activities are parallel merely because they are drawn side by side. Parallelism requires a parallel gateway or an explicitly documented concurrent behavior.

7. Modeling Current and Proposed Processes

The as-is model documents actual practice, including workarounds and exceptions. It should not simply reproduce official procedure manuals if staff routinely bypass them. Observation and transaction evidence are important because interviews may describe intended rather than actual behavior.

The to-be model represents a proposed process after requirements, constraints, and improvement opportunities have been considered. A disciplined transition includes:

1. define the problem and performance objectives;
2. document the as-is process;
3. identify delays, rework, duplication, errors, controls, and customer pain points;
4. generate alternative designs;
5. assess feasibility, risk, cost, compliance, and user impact;
6. model and validate the preferred to-be process;
7. define requirements, implementation steps, and measures.

Process improvement should not mean automating every existing activity. Automation can accelerate waste. Analysts should first ask whether an activity is necessary, whether steps can be simplified, and whether information can be captured once and reused.

Useful improvement principles include:

• eliminate unnecessary handoffs;
• reduce duplicate data entry;
• move validation nearer to the point of capture;
• standardize routine cases while providing controlled exception paths;
• use straight-through processing for low-risk transactions;
• retain human review for ambiguity, high impact, or legally sensitive decisions;
• design controls proportionately rather than adding indiscriminate approvals;
• measure outcomes, not only activity volume.

A process map can reveal bottlenecks, but a diagram alone does not prove that a change will improve performance. Baseline evidence and post-implementation measurement are required.

8. Applied Case: University Course-Registration Service

The following is an illustrative case, not a report of a particular university.

Background and problem

A university receives course-registration requests through email. An administrator checks prerequisites manually, consults a spreadsheet for seat availability, seeks finance confirmation, and then sends a reply. Students experience delays, records are inconsistent, and staff repeatedly enter the same information.

Analysis

Observation identifies four major problems: duplicated entry, unclear ownership of exceptions, delayed prerequisite checking, and weak auditability. The context diagram would show the student, finance service, academic department, and registration system as interacting participants. A Level 0 DFD could include “Capture registration request,” “Validate eligibility,” “Confirm payment status,” and “Record enrollment.” Data stores would include student records, course catalog, and enrollment records.

A decision table for eligibility might use conditions such as valid student status, prerequisite satisfied, available seat, and financial clearance. Actions could be enroll, place on waitlist, or refer to academic advising. The table should specify priority where conditions conflict; for example, a serious academic restriction may override seat availability.

Proposed approach

The to-be BPMN process begins when a student submits a request through a portal. The system validates required fields and checks the catalog and enrollment stores. A gateway distinguishes eligible requests from exceptions. Eligible requests proceed to enrollment and confirmation. Requests with a missing prerequisite are routed to an academic adviser. Requests with no seat are offered a waitlist. A payment exception is routed to finance. Every decision and notification is logged.

Outcome and measures

Expected benefits include fewer duplicate entries, faster routine processing, clearer exception ownership, and improved audit records. The university should establish baseline and target measures, such as median processing time, percentage of requests completed without manual intervention, error rate, number of unresolved exceptions, and student satisfaction. The design should be piloted before full deployment.

Learning points

The case demonstrates that a context diagram clarifies participants, a DFD clarifies data movement, decision logic clarifies policy, and BPMN clarifies sequence and responsibility. It also shows why improvement requires governance: a system must not silently reject a student or make an opaque eligibility decision merely because automation is convenient.

9. Quality, Governance, and Ethical Considerations

Process models influence system requirements, staffing, control design, and sometimes eligibility decisions. They therefore have ethical and governance consequences.

Privacy and security: model only necessary personal data, identify access responsibilities, and distinguish data flows from authorization to use data. Sensitive information should not be copied into uncontrolled spreadsheets merely to simplify a process.

Accountability: assign process ownership and record who approves rules. Automated decisions should have explainable criteria, an appeal or review route where appropriate, and an audit trail.

Fairness: examine whether a rule disadvantages a group indirectly. Automation can reproduce historical bias if past decisions were biased or if proxy variables are used.

Compliance and retention: identify statutory, contractual, financial, accessibility, and records-management obligations. Retention and deletion requirements should appear in requirements and data governance, even if not shown on a simple DFD.

Model governance: use version control, naming standards, review dates, model owners, and traceability from process elements to requirements and test cases. A model that is never updated becomes misleading documentation.

Artificial intelligence may assist analysts by clustering event logs, suggesting process variants, or identifying bottlenecks. Such outputs are hypotheses requiring human validation. AI-generated models can omit exceptions, expose confidential data, or infer inappropriate rules. Organizations should control data access, document model provenance, and require accountable review before implementation.

10. Limitations and Best Practices

No single notation captures every aspect of organizational work. DFDs may underrepresent timing, motivation, organizational politics, and informal collaboration. BPMN may become visually complex and may encourage analysts to model procedural detail before understanding business purpose. Decision tables can grow large, while structured English can be interpreted inconsistently if terms are undefined.

Best practices are therefore integrative:

1. establish scope and stakeholders before drawing details;
2. use a glossary so identical terms have identical meanings;
3. validate models in facilitated walkthroughs with subject-matter experts;
4. maintain balance and traceability between levels;
5. model normal, alternative, and exception paths;
6. separate business rules from implementation choices;
7. annotate assumptions and unresolved issues;
8. keep diagrams readable and decompose complexity;
9. connect process models to data definitions, requirements, controls, and tests;
10. measure whether the implemented process achieved its intended outcome.

Chapter Summary

Business process modeling represents how organizational work is triggered, performed, controlled, and completed. Context diagrams define system boundaries and external interactions. DFDs show logical data movement through processes and stores, while balancing and integrity rules help detect incomplete models. Process specifications describe elementary logic using structured English, decision tables, or decision trees. Decision tables are effective for systematic combinations of conditions; trees are effective for communicating branching order. BPMN models events, activities, gateways, sequence, messages, and responsibility, making it valuable for cross-functional workflows.

As-is and to-be models support evidence-based improvement. Effective improvement removes unnecessary work, reduces duplication and handoffs, strengthens controls, and preserves appropriate human judgment. Ethical modeling requires attention to privacy, fairness, security, accessibility, accountability, compliance, and auditability. Models should be validated, governed, versioned, and connected to requirements and performance measures.

Key Terms

Business process: Coordinated activities that produce a defined organizational outcome.

As-is model: Representation of the current process, including actual practices and exceptions.

To-be model: Representation of a proposed future process.

Context diagram: Highest-level model showing one system and its external interactions.

Data-flow diagram: Model showing processes, data flows, external entities, and data stores.

External entity: Person, organization, or system outside the modeled boundary.

Data flow: Named movement of data between model elements.

Data store: Logical repository in which data is retained.

Process specification: Detailed logic for an elementary process.

Structured English: Restricted natural language used to specify procedural logic.

Decision table: Matrix of conditions, rules, and resulting actions.

Decision tree: Branching representation of sequential conditional logic.

BPMN: Standard notation for business events, activities, gateways, and flows.

Event: Something that starts, interrupts, or ends a process.

Gateway: BPMN element controlling branching or merging of process paths.

Sequence flow: BPMN order relationship within a participant.

Message flow: BPMN communication relationship between participants.

Balancing: Consistency of inputs and outputs between DFD decomposition levels.

Business rule: Policy or condition governing organizational decisions.

Process owner: Person accountable for process performance and governance.

Review Questions

Short Answer Questions

1. What is the purpose of a context diagram?
2. Name the four basic elements of a data-flow diagram.
3. What is meant by balancing in a leveled DFD?
4. Distinguish a sequence flow from a message flow in BPMN.
5. Why should an as-is model include workarounds and exceptions?

Long Answer Questions

1. Explain how context diagrams, DFDs, process specifications, and BPMN complement one another.
2. Describe the rules for constructing a useful and logically consistent DFD.
3. Compare decision tables with decision trees, including their strengths and limitations.
4. Explain a systematic method for moving from an as-is process to a to-be process.
5. Discuss privacy, fairness, accountability, and auditability in automated process design.

Analytical / Application Questions

1. A hospital receives appointment requests by telephone, email, and web form. Design a context diagram description and identify likely external entities and data flows.
2. Construct a decision table for approving a library-book renewal using membership validity, overdue status, and reservation status. Define appropriate actions and check whether the rules are complete.
3. A retailer proposes automating every approval in its returns process. Analyze the proposal using process-improvement, control, exception-handling, and ethical principles.

Multiple Choice Questions with Answers

Question 1

Which element is normally shown in a context diagram?

A. Every internal database table

B. External entities interacting with the system

C. Detailed program modules

D. All elementary process specifications

Correct Answer: B. External entities interacting with the system

Question 2

What does a data-flow diagram primarily represent?

A. Physical network topology

B. Employee hierarchy

C. Movement and transformation of data

D. Source-code execution time

Correct Answer: C. Movement and transformation of data

Question 3

Which rule identifies a process that produces output without an identifiable source?

A. Balancing rule

B. No-miracles rule

C. Lane rule

D. Message-flow rule

Correct Answer: B. No-miracles rule

Question 4

Which technique is most suitable for systematically checking combinations of conditions and actions?

A. Decision table

B. Context diagram

C. Entity list

D. Deployment diagram

Correct Answer: A. Decision table

Question 5

In BPMN, which element represents a point where process paths are controlled?

A. Event

B. Gateway

C. Pool

D. Message

Correct Answer: B. Gateway

Question 6

What is the main distinction between logical and physical process models?

A. Logical models describe purpose without committing to implementation details

B. Logical models can contain no data flows

C. Physical models never identify people

D. Physical models cannot represent technology

Correct Answer: A. Logical models describe purpose without committing to implementation details

Question 7

Which statement about BPMN message flow is correct?

A. It represents internal sequence within one participant

B. It communicates between separate participants

C. It always means parallel execution

D. It replaces all gateways

Correct Answer: B. It communicates between separate participants

Question 8

In the illustrative registration case, what is an appropriate response to a missing prerequisite?

A. Automatically enroll every student

B. Delete the registration request

C. Route the exception to academic advising

D. Ignore the prerequisite

Correct Answer: C. Route the exception to academic advising

Question 9

Which is an example of a process-improvement principle?

A. Duplicate data entry for every department

B. Add approvals without assessing their value

C. Validate data near the point of capture

D. Remove all exception paths

Correct Answer: C. Validate data near the point of capture

Question 10

Why should AI-generated process models be reviewed by people?

A. AI outputs always contain no process information

B. AI may omit exceptions or infer inappropriate rules

C. Human review prevents any need for testing

D. AI cannot process event logs

Correct Answer: B. AI may omit exceptions or infer inappropriate rules