6.1 Specify and Model Requirements

6.1 Specify and Model Requirements

Purpose of Task 20

The primary objective of Task 20: Specify and Model Requirements is to analyze, synthesize, and transform information elicited from stakeholders into formal requirements and design options. Elicited information often starts as unstructured conversation transcripts, workshop whiteboard notes, or legacy documentation. The business analyst must structure this raw input into standardized models that convey intent, logic, capabilities, and constraints without ambiguity.

In the BABOK® Guide v3 framework, requirements and designs exist on a continuum of specificity. Requirements describe what value must be created or what capability is needed, whereas designs represent how that requirement can be fulfilled or operationalized. Specifying and modeling applies equally to high-level strategic business requirements and granular technical design options.

---

Inputs, Outputs, and BACCM Relationships

Executing Task 20 relies on specific BABOK inputs and produces standardized outputs for downstream governance and solution evaluation.

Mapping to the Business Analysis Core Concept Model (BACCM)

Modeling requirements requires evaluating how requirements interact across the six core concepts:

• Context: Modeling depicts how the surrounding enterprise infrastructure, regulatory landscape, and vendor software impact requirements.
• Need: Models illustrate the underlying business problems, strategic opportunities, and operational gaps driving the initiative.
• Solution: Requirements models specify structural and behavioral characteristics of candidate design options.
• Stakeholder: Diverse model formats (such as process flows vs. ERDs) target specific stakeholder viewpoints to ensure comprehension.
• Value: Models highlight how features, capabilities, and processes directly contribute to expected monetary and operational value.
• Change: Models define the scope boundary between current-state practices and future-state target architectures.

---

Requirements Formats: Matrix, Diagrammatic, and Textual

A senior BA must select the appropriate requirements format based on the nature of the information and the target audience. BABOK v3 categorizes requirements formats into three primary structures:

                             REQUIREMENTS FORMAT TAXONOMY
 ┌─────────────────────────┬─────────────────────────┬─────────────────────────┐
 │     TEXTUAL FORMAT      │      MATRIX FORMAT      │   DIAGRAMMATIC FORMAT   │
 ├─────────────────────────┼─────────────────────────┼─────────────────────────┤
 │ • Business Rules        │ • Traceability Matrix   │ • Process Models (BPMN) │
 │ • User Stories          │ • CRUD Matrix           │ • Use Case Diagrams     │
 │ • Text Specifications   │ • RACI Matrix           │ • ER Diagrams (ERD)     │
 │ • Acceptance Criteria   │ • Decision Tables       │ • Data Flow Diagrams    │
 └─────────────────────────┴─────────────────────────┴─────────────────────────┘

1. Textual Format

Textual requirements express business rules, policy constraints, quality attributes, and acceptance criteria in structured natural language. They are essential for capturing detailed business logic that diagrams cannot easily convey (e.g., complex calculation formulas, validation parameters, and legal compliance rules).

Example: "The credit underwriting system must automatically flag any loan application where the applicant's Debt-to-Income (DTI) ratio exceeds 43.5% and dispatch an alert to a Senior Risk Officer within 2 seconds of submission."

2. Matrix Format

Matrices organize complex, multi-dimensional relationships into rows and columns. They are optimal when managing cross-referencing capabilities, data ownership, permission structures, or traceability linkages across hundreds of items.

• CRUD Matrix: Maps user roles or system modules against data entities to show who can Create, Read, Update, or Delete data.
• Decision Table: Maps complex combinations of conditional logic (inputs) to specific operational outcomes (outputs).
• Traceability Matrix: Maps business requirements to functional requirements, test cases, and design components.

3. Diagrammatic Format

Diagrams provide visual representations of complex relationships, temporal sequences, structural hierarchies, and behavioral workflows. Visual models allow business analysts to convey complex enterprise relationships rapidly, bridging communication gaps between business users and technical architects.

---

BABOK v3 Modeling Categories

BABOK Guide v3 organizes modeling techniques into five distinct categories based on the perspective of the business analysis information being captured:

---

Practical Example: Selecting Modeling Techniques for a Digital Claims Portal

Consider a global insurance provider replacing a legacy claims system with an automated digital portal. A senior BA executes Task 20 by selecting targeted models across multiple categories:

1. Rationale Category: Constructs a Decision Model specifying the automated payout thresholds vs. manual investigation triggers.
2. Activity Flow Category: Constructs a BPMN 2.0 Process Diagram showing claim submission, validation, adjuster assignment, and payment dispatch.
3. Data Category: Constructs a Logical Entity Relationship Diagram (ERD) modeling entities such as Policyholder, Insurance Policy, Claim Submission, and Adjuster Report.
4. People & Roles Category: Constructs a Roles and Permissions Matrix defining CRUD rights for Customer, Claims Adjuster, Fraud Examiner, and Finance Director.

---

CBAP Exam Strategy & Distractor Analysis

• Watch for Form vs. Content Distractors: Exam questions may present a scenario where a BA uses a process model to capture complex financial calculations. Remember that textual or decision table formats are far superior for complex business rules.
• Differentiate Requirements vs. Designs: Remember that a textual specification describing a capability constraint ("Process 5,000 transactions per second") is a requirement, whereas an architectural topology diagram demonstrating how three load-balanced servers handle that volume is a design option.
• Identify Key Elicitation Inputs: You cannot model requirements without confirmed elicitation results. If an exam scenario states that elicitation results are unconfirmed, modeling cannot proceed to verification.