Study guide
9.2 Process, Data & Non-Functional Requirements Modeling
CCBA Certification of Capability in Business Analysis Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & CCBA Exam Foundation
1.1 CCBA Exam Structure, Eligibility & IIBA Framework 1.2 The Business Analysis Core Concept Model (BACCM™) 1.3 Requirements Classification Schema & Architecture 1.4 CCBA Competency & Proficiency Levels (Level 2 — Skilled)
2 Chapter 2: Business Analysis Planning and Monitoring
2.1 Plan Business Analysis Approach (Task 3.1) 2.2 Plan Stakeholder Engagement (Task 3.2) 2.3 Plan Business Analysis Governance (Task 3.3) 2.4 Plan Business Analysis Information Management (Task 3.4) 2.5 Identify BA Performance Improvements (Task 3.5)
3 Chapter 3: Elicitation and Collaboration
3.1 Prepare for Elicitation (Task 4.1) 3.2 Conduct Elicitation (Task 4.2) 3.3 Confirm Elicitation Results (Task 4.3) 3.4 Communicate Business Analysis Information (Task 4.4) 3.5 Manage Stakeholder Collaboration (Task 4.5)
4 Chapter 4: Requirements Life Cycle Management
4.1 Trace Requirements (Task 5.1) 4.2 Maintain Requirements (Task 5.2) 4.3 Prioritize Requirements (Task 5.3) 4.4 Assess Requirements Changes (Task 5.4) 4.5 Approve Requirements (Task 5.5)
5 Chapter 5: Strategy Analysis
5.1 Analyze Current State (Task 6.1) 5.2 Define Future State (Task 6.2) 5.3 Assess Risks (Task 6.3) 5.4 Define Change Strategy (Task 6.4)
6 Chapter 6: Requirements Analysis and Design Definition — Modeling & Architecture
6.1 Specify and Model Requirements (Task 7.1) 6.2 Verify Requirements (Task 7.2) 6.3 Validate Requirements (Task 7.3) 6.4 Define Requirements Architecture (Task 7.4)
7 Chapter 7: Requirements Analysis and Design Definition — Design & Value
7.1 Define Design Options (Task 7.5) 7.2 Analyze Potential Value and Recommend Solution (Task 7.6) 7.3 Estimation Techniques & Solution Trade-Offs 7.4 Acceptance and Evaluation Criteria Definition
8 Chapter 8: Solution Evaluation
8.1 Measure Solution Performance (Task 8.1) 8.2 Analyze Performance Measures (Task 8.2) 8.3 Assess Solution Limitations (Task 8.3) 8.4 Assess Enterprise Limitations (Task 8.4) 8.5 Recommend Actions to Increase Solution Value (Task 8.5)
9 Chapter 9: Essential BABOK Techniques
9.1 Core Elicitation & Analysis Techniques 9.2 Process, Data & Non-Functional Requirements Modeling 9.3 Financial Analysis & Business Case Techniques 9.4 Prioritization & Scope Techniques 9.5 Root Cause & Decision Analysis Techniques
10 Chapter 10: Underlying Competencies & Perspectives
10.1 Analytical Thinking, Problem Solving & Systems Thinking 10.2 Behavioral Characteristics, Communication & Interaction Skills 10.3 Business Acumen, Solution Knowledge & BA Tooling 10.4 The Five BABOK Perspectives in Practice
11 Chapter 11: CCBA Exam Mastery & Scenario Strategy
11.1 Deconstructing CCBA Scenario Questions & BABOK Logic 11.2 Common Traps, Distractors & Subtle BABOK Distinctions 11.3 Comprehensive 8-Week Study Plan & Exam Day Strategy
9.2 Process, Data & Non-Functional Requirements Modeling
Key Takeaways Explain This Topic AI
Process Modeling using BPMN 2.0 provides standardized visual representations of end-to-end workflows using Events, Activities, Gateways, Pools, and Swimlanes.
Data Flow Diagrams (DFDs) track data movement and transformations across External Entities, Processes, Data Stores, and Data Flows across hierarchical levels (Level 0 Context to Level 1+ Decompositions).
Entity Relationship Diagrams (ERDs) model the logical and conceptual data architecture with entities, primary/foreign keys, and Crow's Foot cardinalities, while Data Dictionaries formalize the elements themselves — primitive fields, composite structures, data types, and business validation constraints.
Class Models in UML specify object-oriented systems by encapsulating attributes, operations, and structural relationships (Generalization, Aggregation, and Composition).
Non-Functional Requirements Analysis is a distinct BABOK v3 technique covering availability, performance efficiency, security, usability, compliance, scalability and related quality categories; an NFR written as an adjective such as "fast" or "secure" fails the verifiability test and must be restated as a measure, target value, condition, and load context.
Last updated: August 2026
9.2 Process, Data & Non-Functional Requirements Modeling
Quick Summary: Modeling transforms complex business domains into rigorous, visual, and structured specifications. BABOK® Guide v3 highlights Process Modeling (BPMN) , Data Flow Diagrams (DFDs) , Entity Relationship Diagrams (ERDs) , Class Models , and Data Dictionaries as the core visual languages for defining system behavior, data structures, and enterprise boundaries.
1. Process Modeling (BPMN 2.0)
Process Modeling visually depicts the sequential flow of activities, decisions, and handoffs across an enterprise to achieve an organizational goal. The industry standard notation is Business Process Model and Notation (BPMN 2.0) . +-----------------------------------------------------------------------------------+
- | BPMN 2.0 Core Visual Notation |
- +-----------------------------------------------------------------------------------+
- | EVENTS (Circles): |
- | * Start Event (Thin circle) : Triggers process inception |
- | * Intermediate Event (Double circle) : Occurs during execution (e.g., Timer) |
- | * End Event (Thick circle) : Marks process completion / terminal state|
- | |
- | ACTIVITIES (Rounded Rectangles): |
- | * Task : Atomic unit of work (e.g., "Validate Loan Application") |
- | * Sub-Process : Compound activity containing an underlying decomposed workflow |
- | |
- | GATEWAYS (Diamonds - Decision & Divergence Logic): |
- | * Exclusive (XOR - 'X' marker) : Exactly ONE outgoing path is selected |
- | * Inclusive (OR - 'O' marker) : ONE or MORE paths based on valid conditions |
- | * Parallel (AND - '+' marker) : ALL outgoing branches execute concurrently |
- | * Event-Based (Pentagon marker) : Branch taken depends on which event fires first|
- | |
- | SWIMLANES: |
- | * Pool : Represents an independent participant, organization, or external entity |
- | * Lane : Sub-partition within a pool representing internal roles or departments |
- +-----------------------------------------------------------------------------------+
- Critical BPMN Sequencing Rules
Sequence Flows (Solid Arrows): Connect activities, events, and gateways within the same pool . Sequence flows can NEVER cross pool boundaries.
Message Flows (Dashed Arrows with Open Circles): Depict message communications between two separate pools . Message flows can NEVER connect elements within the same pool.
2. Data Flow Diagrams (DFDs)
A Data Flow Diagram (DFD) illustrates how data enters a system, transforms through processing steps, stores in persistent repositories, and outputs to external destinations. Unlike process models, DFDs contain no chronological timing, no control sequences, and no decision branching .
The 4 Core DFD Components (Gane-Sarson / Yourdon-DeMarco)
Element Visual Symbol BABOK v3 Definition & Constraints
External Entity (Source / Sink) Square / Double Square An external actor, department, or external software system outside the boundary of the modeled domain that sends or receives data.
Process Rounded Rectangle or Circle An operational or automated transformation that takes input data, modifies it, and produces output data. Must be named with a strong Verb-Noun phrase.
Data Store Open-ended Rectangle / Parallel Lines A persistent data repository (database, physical filing cabinet, cache) holding information for future retrieval.
Data Flow Labeled Arrow (Noun) Represents a packet or pipeline of structured information in motion between entities, processes, and data stores. ┌─────────────────────────────────────────────────────────────────────────────┐
- │ DFD Connection Validity Rules │
- ├─────────────────────────────────────────────────────────────────────────────┤
- │ VALID: [External Entity] ──(Data Flow)──> [Process] │
- │ VALID: [Process] ──(Data Flow)──> [Data Store] │
- │ VALID: [Process] ──(Data Flow)──> [Process] │
- │ │
- │ INVALID: [External Entity] ──(Data Flow)──> [External Entity] (No Proc) │
- │ INVALID: [External Entity] ──(Data Flow)──> [Data Store] (No Proc) │
- │ INVALID: [Data Store] ──(Data Flow)──> [Data Store] (No Proc) │
- │ │
- │ *RULE: Every Data Flow MUST connect to at least one Process!* │
- └─────────────────────────────────────────────────────────────────────────────┘
- DFD Hierarchy: Leveling & Decomposition
Level 0 (Context Diagram): High-level view of the entire system represented as a single, central process bubble (Process 0), surrounded by external entities and external data flows. Establishes project scope boundaries. Data stores are NOT shown at Level 0.
Level 1 Diagram: Decomposes Process 0 into the major functional sub-processes (1.0, 2.0, 3.0), introducing internal data stores and detailed internal data flows.
Level 2+ Diagrams: Further decomposes complex sub-processes (e.g., Process 1.0 into 1.1, 1.2, 1.3) while maintaining balancing (all input and output flows at parent level must match child level exactly).
3. Entity Relationship Diagrams (ERDs)
An Entity Relationship Diagram (ERD) is a data modeling technique that graphically models the data entities of a domain, their constituent attributes, and the logical relationships between them.
ERD Core Elements
Entity: A person, place, event, or concept about which the enterprise stores information (e.g., Customer , Order , Invoice ). Modeled as a rectangle.
Attribute: A discrete piece of information describing an entity (e.g., DateOfBirth , UnitPrice ). Contains Primary Keys (PK) for unique record identification and Foreign Keys (FK) for establishing relational links.
Relationship: The business association connecting two entities (e.g., Customer places Order ).
- Crow's Foot Cardinality and Modality Notation Symbol Cardinality Meaning
- ──||──────────── Mandatory Exactly One (1..1)
- ──O|──────────── Optional Zero or One (0..1)
- ──|<──────────── Mandatory One or Many (1..N)
──O<──────────── Optional Zero or Many (0..N) +-----------------------------------------------------------------------------------+
- | Enterprise ERD Normalization |
- +-----------------------------------------------------------------------------------+
- | Many-to-Many (M:N) Relationship: |
- | [Student] >─────── (Enrolls In) ───────< [Course] |
- | |
- | Resolved into Relational Architecture via Associative Entity: |
- | [Student] ──||──────────O< [Enrollment Record] >O──────────||── [Course] |
- | (PK: Student_ID) (PK/FK: Student_ID) (PK: Course_ID) |
- | (PK/FK: Course_ID) |
- | (Attr: Grade, Date) |
- +-----------------------------------------------------------------------------------+
- 4. Class Models (UML Class Diagrams)
A Class Model describes the static object structure of a software system by defining classes, their encapsulated attributes, callable operations (methods), and the structural relationships between objects.
Class Structure Anatomy (Three Compartments)
Top Compartment: Class Name (e.g., BankAccount ).
Middle Compartment: Attributes with visibility indicators: + (Public), - (Private), # (Protected), ~ (Package) (e.g., - accountBalance: Decimal ).
Bottom Compartment: Operations / Methods (e.g., + deposit(amount: Decimal): Boolean ).
Class Relationships
Generalization (Inheritance): An is-a relationship where a child subclass inherits all attributes and methods of a parent superclass (depicted by a solid line with a hollow triangle pointing to the superclass; e.g., SavingsAccount is a BankAccount ).
Association: A structural semantic link between two classes (solid line with optional multiplicity numbers).
Aggregation: A weak has-a whole-part relationship where parts can exist independently of the whole (depicted by a hollow diamond on the whole; e.g., Department has Employees ).
Composition: A strong whole-part ownership relationship where parts cannot exist if the whole is destroyed (depicted by a solid/filled diamond on the whole; e.g., Order contains OrderLineItems ).
5. Data Dictionary
A Data Dictionary is a centralized repository that defines the precise business meaning, technical metadata, structural relationships, and integrity constraints for all data elements used across enterprise models.
Data Element Classifications
Primitive Data Elements: Atomic, indivisible data points that cannot be broken down further (e.g., SocialSecurityNumber , ZipCode , InterestRate ).
Composite Data Elements: Aggregations of primitive elements combined into a cohesive business structure (e.g., CustomerAddress = StreetLine1 + City + StateProvince + PostalCode + CountryCode ).
Standard Data Dictionary Metadata Fields
- Attribute Name Metadata Description Enterprise Example
- Data Element Name Standardized unique business identifier Policy_Effective_Date
- Alias / Synonyms Alternate names used by different business units Coverage_Start_Date , Inception_Date
Description Unambiguous business definition The date and time when insurance liability coverage commences.
- Data Type Technical storage format ISO 8601 Timestamp ( YYYY-MM-DDThh:mm:ssZ )
- Length / Precision Character length or numerical scale 20 characters
Allowable Values Enumerated valid list or calculation rule Cannot be more than 90 days in the past or 60 days in future.
- Optionality Mandatory (NOT NULL) vs Optional (NULL) Mandatory (Required for policy bind)
- 6. Non-Functional Requirements Analysis
Process and data models capture what the solution must do . BABOK® Guide v3 names Non-Functional Requirements Analysis as the separate technique for capturing how well it must do it — the quality attributes and constraints that a functional model cannot express. It is one of the most reliably tested techniques on the CCBA because candidates habitually treat non-functional requirements as an afterthought, and the exam punishes exactly that.
What Counts as a Non-Functional Requirement
A functional requirement describes a behaviour ("the system shall calculate the settlement amount"). A non-functional requirement constrains the quality of service around that behaviour ("the settlement amount shall be calculated within 400 milliseconds for the 95th percentile of requests"). BABOK® Guide v3 lists the categories a business analyst should sweep:
Category Question It Answers Example NFR
Availability When must it be usable? 99.95% uptime during the 06:00–22:00 trading window.
Compatibility What must it coexist with? Operates against Oracle 19c and PostgreSQL 15 without schema changes.
Functionality How complete and correct? Settlement calculations match the clearing house figure to two decimal places.
Maintainability How easily changed? A new fee type can be added through configuration, without a code release.
Performance Efficiency How fast, at what load? 400 ms p95 response at 2,000 concurrent sessions.
Portability Where can it run? Deployable to any Kubernetes 1.28+ cluster.
Reliability How rarely does it fail? Mean time between failures of 720 hours.
Scalability How far can it grow? Scales to 5× current transaction volume without re-architecture.
Security How is it protected? Customer PII encrypted at rest with AES-256 and in transit with TLS 1.3.
Usability How easily learned and used? A trained clerk completes onboarding in under four minutes.
Certification What standards must it meet? Meets PCI DSS 4.0 for cardholder data handling.
Compliance What law applies? Retains audit records for seven years per statutory requirement.
Localization Which locales? Supports en-CA, fr-CA date, currency, and address formats.
Service Level Agreements What is contractually owed? Severity-1 incidents acknowledged within 15 minutes.
Extensibility What future capability? Exposes a public API for third-party reconciliation tools.
Making Non-Functional Requirements Testable
The recurring defect is an NFR written as an adjective. "The system must be fast," "the system must be secure," and "the system must be user-friendly" are all unverifiable, and BABOK® Guide v3 treats verifiability as a quality characteristic every requirement must have. Convert each one using four elements: MEASURE + TARGET VALUE + CONDITIONS + TIME/LOAD CONTEXT
- ────────────────────────────────────────────────────────────────
- "Fast" ──► Response time | <= 400 ms at p95
- | for authenticated search requests
- | at 2,000 concurrent sessions during month-end close
Worked conversion. A warehouse client says "the new picking app has to work offline." Elicit the measure and the boundary: the app shall queue up to 500 pick confirmations locally and synchronize within 60 seconds of network restoration, with no data loss across a 4-hour disconnection. Now it can be tested, estimated, and traced.
Important
Exam traps on this technique. (1) NFRs are elicited and analyzed like any other requirement — they are not design decisions, so an answer that jumps straight to "specify a Redis cache" is choosing a design option, not analyzing a requirement. (2) NFRs commonly conflict with each other and with functional requirements; the CCBA-level response is trade-off analysis , not unilaterally dropping one. (3) A constraint imposed from outside the solution (a regulation, an existing platform) is a constraint , whereas a quality target the solution must achieve is a non-functional requirement — the exam distinguishes them.
Non-functional requirements are usually attached to the functional models built earlier in this section: a performance target hangs off a BPMN activity, a retention rule hangs off an ERD entity, and an availability target hangs off a whole subsystem. Modeling them in isolation from the process and data models is what produces late, expensive architectural rework.
Comparative Matrix: Process vs. Data Modeling Techniques
Modeling Technique Primary Modeling Focus Key Visual Elements Distinguishing Characteristic
Process Model (BPMN) Temporal sequence, procedural workflows, decision routing. Events, Tasks, Gateways, Pools, Swimlanes. Features chronological order and control decisions (gateways). Sequence flows cannot cross pools.
Data Flow Diagram (DFD) Movement and transformation of information. Processes, Data Stores, Data Flows, External Entities. No timing, no control logic, no loops. Every data flow must touch at least one process.
Entity Relationship (ERD) Persistent data entities, attributes, and structural cardinality. Entities, Attributes (PK/FK), Crow's Foot links. Focuses on relational database structure; models 1:1, 1:N, and M:N relationships.
Class Diagram (UML) Static object architecture, encapsulation, object operations. 3-compartment classes, Inheritance, Composition. Encapsulates both data (attributes) and behavior (methods); models object-oriented systems.
Enterprise Scenario: Global Logistics Tracking Platform
A multinational logistics carrier develops an automated freight tracking platform:
BPMN Process Model: Maps the package delivery journey from Pickup Scheduled -> Warehouse Barcode Scan -> Exclusive Gateway (Is International?) -> Customs Clearance Subprocess -> Final Mile Delivery .
Level 0 DFD: Identifies external entities ( Shipper , Consignee , Customs Border Agency ) exchanging data flows ( Shipment Manifest , Delivery Confirmation , Tax Clearance Certificate ) with the central Logistics Core System 0 .
Level 1 DFD: Decomposes the core system into 1.0 Manifest Ingestion , 2.0 Tariff Calculation , and 3.0 Route Dispatch , connecting to internal data stores D1: Active Shipments and D2: Carrier Tariffs .
ERD & Data Dictionary: Defines the relational structure where Consignment has a mandatory 1:N relationship with Package , referencing a standardized Data Dictionary defining Tracking_Number as an alphanumeric 18-character regex string.
Tip
CCBA Exam Tip: On the exam, when asked to distinguish between Composition and Aggregation in UML class modeling, remember lifecycle dependency: In Composition (filled diamond), if the parent container is deleted, child parts are automatically deleted. In Aggregation (hollow diamond), child parts survive parent deletion.
Warning
CCBA Exam Trap: Never select a Data Flow Diagram (DFD) if the scenario requires modeling conditional branching logic , time sequencing , or departmental swimlane handoffs . DFDs strictly track data transformations and cannot represent execution order or if/then decision pathways.