6.1 Specify and Model Requirements (Task 7.1)

6.1 Specify and Model Requirements (Task 7.1)

Quick Summary: BABOK® Guide v3 Task 7.1 (Specify and Model Requirements) is the analytical engine of business analysis. It takes raw, unrefined elicitation results and transforms them into structured, rigorous representations of requirements and design options using textual, matrix, and diagrammatic formats across four foundational model categories.

---

Purpose and Strategic Role of Task 7.1

The purpose of Specify and Model Requirements is to analyze elicitation results and create a detailed, unambiguous description of the capabilities, characteristics, rules, and conditions that a proposed solution must possess. During elicitation (Chapter 3), the business analyst captures stakeholder statements, raw documents, and operational observations. In Task 7.1, the BA synthesizes these disparate inputs into formal representations that stakeholders can understand, validate, prioritize, and implement.

A central distinction in BABOK v3 is the relationship between Requirements and Designs:

• Requirement: Focuses on the need and the business outcome to be achieved (e.g., "The claims processing system must verify policyholder coverage status before adjudication").
• Design: Focuses on a solution approach or specific implementation mechanism to satisfy that need (e.g., "An automated SOAP/REST API gateway that queries the enterprise policy database via a microservice cache").

+-----------------------------------------------------------------------------------+
|                             BABOK Task 7.1 Structure                              |
+-----------------------------------------------------------------------------------+
|  INPUTS:                                                                          |
|  * Elicitation Results (Any State: unconfirmed or confirmed)                      |
|                                                                                   |
|  ELEMENTS:                                                                        |
|  1. Model Requirements (Format and category selection)                            |
|  2. Analyze Requirements (Decomposition, pattern discovery, gap detection)        |
|  3. Represent Requirements and Attributes (Metadata, tracing tags, ownership)     |
|  4. Implement the Appropriate Levels of Abstraction                               |
|                                                                                   |
|  OUTPUTS:                                                                         |
|  * Requirements (Specified and Modeled)                                           |
|  * Designs (Specified and Modeled)                                                |
+-----------------------------------------------------------------------------------+

---

The Three Core Representation Formats

BABOK v3 establishes that requirements and designs are specified using three primary formats. Effective business analysts select the format that maximizes clarity for the target stakeholder audience while minimizing ambiguity.

---

The Four BABOK Model Categories

BABOK v3 classifies all business analysis models into four distinct categories, each addressing a specific dimension of the enterprise problem space:

+-----------------------------------------------------------------------------------+
|                         The 4 BABOK v3 Model Categories                           |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|   1. PEOPLE & ROLES            2. RATIONALE              3. ACTIVITY & FLOW       |
|   * Org Charts                 * Decision Models (DMN)   * Business Process Maps  |
|   * Roles & Permissions Matrix * Business Model Canvas   * Use Cases & Scenarios  |
|   * User Personas              * Root Cause (Fishbone)   * User Stories           |
|   * Stakeholder Maps           * Scope Models            * State Diagrams         |
|                                                          * Sequence Diagrams      |
|   -----------------------------------------------------------------------------   |
|   4. DATA & INFORMATION                                                           |
|   * Data Dictionaries & Glossaries     * Entity Relationship Diagrams (ERDs)      |
|   * Data Flow Diagrams (DFDs)          * Class Models & Concept Models            |
+-----------------------------------------------------------------------------------+

1. People and Roles Models

These models define the human and organizational aspects of the domain, specifying who interacts with the system, their responsibilities, access privileges, and behavioral archetypes:

• Organizational Charts: Depict formal reporting structures, organizational hierarchies, and operational boundaries.
• Roles and Permissions Matrix: A tabular matrix mapping user roles (e.g., Underwriter, Compliance Officer, Branch Teller) against system privileges (Create, Read, Update, Delete, Approve, Export).
• User Personas: Semi-fictional archetypes representing distinct user groups, detailing their goals, motivations, pain points, technical proficiency, and typical usage contexts.

2. Rationale Models

Rationale models explain the "why" behind organizational decisions, strategy, scope boundaries, and corrective actions:

• Decision Models (DMN): Formalize complex business logic, regulatory rules, and conditional branching into structured decision tables and decision requirement diagrams.
• Business Model Canvas (BMC): A 9-building-block strategic blueprint describing how an organization creates, delivers, and captures value.
• Root Cause Analysis (Fishbone / Ishikawa Diagrams, 5 Whys): Diagnoses systemic breakdowns and traces observable symptoms back to foundational process, technology, or human causes.
• Scope Models (Context Diagrams, Functional Decomposition): Establish explicit project boundaries by visualizing external entities sending and receiving data to/from the system.

3. Activity and Flow Models

These models depict the temporal sequence of actions, event handling, procedural pathways, and state transitions:

• Business Process Models (BPMN / Swimlane Flowcharts): Visualizes end-to-end workflows across organizational boundaries, highlighting handoffs, gateways, exceptions, and loops.
• Use Cases and Scenarios: Textual and diagrammatic specifications describing interactions between an external actor and a solution to achieve a specific goal, including main success paths and alternate/exception flows.
• User Stories (INVEST Criteria): Lightweight agile descriptions of functionality from an end-user perspective: "As a [role], I want to [action], so that [business benefit]."
• Sequence Diagrams (UML): Illustrate how objects, system components, or microservices interact across time by exchanging sequential messages.
• State Machine / State Transition Diagrams: Model the lifecycle of an entity (e.g., an insurance claim moving from Draft -> Submitted -> In Review -> Approved -> Paid -> Closed) by defining valid states, triggering events, guard conditions, and transition actions.

4. Data and Information Models

Data models describe the structure, semantics, rules, transformations, and relationships governing enterprise information:

• Data Dictionaries & Glossaries: Centralized repositories defining data element names, descriptions, data types, lengths, valid value ranges, and allowable formats.
• Data Flow Diagrams (DFDs): Illustrate how data moves through a system via processes (transformations), data stores (repositories), external entities (sources/sinks), and data flows. DFDs use Level 0 (Context Diagram) for high-level boundary modeling and Level 1+ for functional decomposition.
• Entity Relationship Diagrams (ERDs): Conceptual and logical models representing domain entities, their attributes, and relational cardinalities (1:1, 1:N, M:N).
• Class Models (UML Class Diagrams): Object-oriented models defining classes, attributes, methods/operations, and object relationships (inheritance, aggregation, composition).
• Concept Models: Semantic vocabularies defining core business concepts and the precise grammatical relationships connecting them, independent of software implementations.

---

Choosing the Appropriate Level of Abstraction

Requirements and designs exist along a spectrum of abstraction. Business analysts must tailor the granularity of models based on the project lifecycle phase, stakeholder audience, and risk profile:

   ┌─────────────────────────────────────────────────────────────────────────────┐
   │ HIGH ABSTRACTION (Conceptual / Strategic)                                   │
   │ Target Audience: Executives, Sponsors, Business Owners                      │
   │ Artifacts: Context Diagrams, Business Model Canvas, High-Level Process Maps  │
   ├─────────────────────────────────────────────────────────────────────────────┤
   │ MEDIUM ABSTRACTION (Logical / Business Domain)                              │
   │ Target Audience: Product Managers, Operations Leads, Business SMEs          │
   │ Artifacts: BPMN Detailed Workflows, Use Cases, Logical ERDs, Decision Tables│
   ├─────────────────────────────────────────────────────────────────────────────┤
   │ LOW ABSTRACTION (Physical / Technical Implementation)                       │
   │ Target Audience: Software Architects, Database Engineers, QA Automators     │
   │ Artifacts: Physical Database Schemas, API Specs (Swagger), Sequence Diagrams│
   └─────────────────────────────────────────────────────────────────────────────┘

Progressive Elaboration

In predictive environments, abstraction decreases systematically as the project advances from charter to functional specification. In adaptive (agile) environments, progressive elaboration occurs just-in-time: epics (high abstraction) are decomposed into user stories and acceptance criteria (low abstraction) during sprint backlog refinement.

---

Enterprise Scenario: Commercial Loan Origination Modernization

A global commercial bank initiates a digital transformation of its corporate credit lending platform. The lead business analyst applies multi-model synthesis to specify and model the solution:

1. People and Roles: The BA creates User Personas for Credit Analysts, Senior Risk Underwriters, and Commercial Relationship Managers, coupled with a Roles and Permissions Matrix defining credit approval caps ($500K, $2M, $10M+).
2. Rationale: A Decision Model (DMN) is constructed to formalize the credit scoring algorithm, debt-service coverage ratio (DSCR) thresholds, and automated covenant checks.
3. Activity and Flow: The end-to-end workflow is modeled using BPMN swimlane diagrams to show handoffs between front-office origination, compliance vetting, risk committees, and loan servicing. A State Transition Diagram models the loan lifecycle (Draft, Underwriting, Conditional Approval, Funded, Defaulted).
4. Data and Information: A Data Flow Diagram (Level 1) maps incoming financial statements, credit bureau feeds, and core banking ledgers. A logical Entity Relationship Diagram (ERD) establishes relationships between Borrower, Credit Facility, Collateral Asset, and Guarantor.

---

Key BABOK v3 Techniques for Task 7.1

• Business Rules Analysis: Discovers, documents, and organizes business rules governing enterprise operations into catalogs or decision tables.
• Data Modeling: Defines entity structures, attributes, and relationships using ERDs, class diagrams, or data dictionaries.
• Functional Decomposition: Breaks down complex business domains, processes, or systems into smaller, manageable sub-components.
• Process Modeling: Graphically represents the sequential flow of enterprise activities, inputs, outputs, decisions, and roles.
• Sequence Diagrams & State Modeling: Models real-time dynamic behavior, message exchange timelines, and entity lifecycle state transitions.
• Use Cases and Scenarios & User Stories: Specifies functional behavior from the actor's perspective to guide development and testing.

[!TIP] CCBA Exam Tip: Scenario questions frequently present a specific modeling challenge and ask you to select the most appropriate technique. If the scenario involves complex branching business rules with multiple if/then conditions, choose a Decision Table / Decision Model. If it involves an entity changing status over time based on triggers, choose a State Model / State Machine Diagram.

[!WARNING] CCBA Exam Trap: Be vigilant about confusing Data Flow Diagrams (DFDs) with Process Models (Flowcharts/BPMN). Process models show temporal sequence, chronological order, and control decisions (using diamonds/gateways). DFDs show how data moves and is transformed across processes, data stores, and external entities; DFDs have no chronological sequence, no timing, and no decision branching.