9.2 Process, Data & Non-Functional Requirements Modeling

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

1. Sequence Flows (Solid Arrows): Connect activities, events, and gateways within the same pool. Sequence flows can NEVER cross pool boundaries.
2. 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)

   ┌─────────────────────────────────────────────────────────────────────────────┐
   │                   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)

1. Top Compartment: Class Name (e.g., BankAccount).
2. Middle Compartment: Attributes with visibility indicators: + (Public), - (Private), # (Protected), ~ (Package) (e.g., - accountBalance: Decimal).
3. 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

---

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:

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

---

Enterprise Scenario: Global Logistics Tracking Platform

A multinational logistics carrier develops an automated freight tracking platform:

1. BPMN Process Model: Maps the package delivery journey from Pickup Scheduled -> Warehouse Barcode Scan -> Exclusive Gateway (Is International?) -> Customs Clearance Subprocess -> Final Mile Delivery.
2. 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.
3. 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.
4. 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.