Business Analysis 101: Requirements Analysis and Design Definition Data Modeling Basics ERD Class Diagrams Data Dictionary

What This Is

Data modeling is the practice of defining what data the solution must store, how it relates, and the rules that govern it. In the BA lifecycle it lives in the Requirements Analysis & Design Definition knowledge area and feeds the downstream Solution Assessment & Validation work.
Real‑world example: While rolling out a new Customer Relationship Management (CRM) system, the BA creates an Entity‑Relationship Diagram (ERD) to capture customers, contacts, opportunities, and activities, then translates those entities into class diagrams for the development team and a data dictionary that becomes the authoritative source for field definitions, data types, and business rules.

Key Terms & Techniques

• Entity‑Relationship Diagram (ERD) – Visual notation (entities, attributes, relationships) that shows the logical data structure. KA: Requirements Analysis & Design Definition; Deliverable: Logical Data Model.
• Class Diagram – UML diagram that models objects (classes), their attributes, methods, and associations; bridges business concepts to system design. KA: Requirements Analysis & Design Definition; Deliverable: UML Model.
• Data Dictionary – Tabular repository describing each data element (name, definition, type, allowed values, source). KA: Requirements Analysis & Design Definition; Deliverable: Data Dictionary.
• Normalization – Process of organizing data to reduce redundancy (1NF, 2NF, 3NF). KA: Requirements Analysis & Design Definition; Deliverable: Normalized Logical Model.
• Primary Key (PK) / Foreign Key (FK) – PK uniquely identifies a record; FK creates a link to another entity’s PK. KA: Requirements Analysis & Design Definition; Deliverable: ERD with keys.
• Cardinality & Modality – Defines “how many” (one‑to‑one, one‑to‑many, many‑to‑many) and optionality of relationships. KA: Requirements Analysis & Design Definition; Deliverable: Relationship notation on ERD.
• Business Rules – Constraints or calculations that govern data (e.g., “A claim must be filed within 30 days of incident”). KA: Requirements Analysis & Design Definition; Deliverable: Business Rules Matrix, Data Dictionary notes.
• Logical vs. Physical Data Model – Logical model focuses on business concepts; physical model adds DBMS‑specific details (tables, indexes, storage). KA: Requirements Analysis & Design Definition; Deliverable: Logical Model → Physical Model.
• Data Modeling Workshop – Collaborative session with SMEs, architects, and developers to surface entities, relationships, and rules. KA: Requirements Elicitation & Collaboration; Deliverable: Workshop artefacts (sticky notes, draft ERD).
• Attribute Domain – Set of permissible values for an attribute (e.g., “Status” = {Open, Closed, Pending}). KA: Requirements Analysis & Design Definition; Deliverable: Data Dictionary entry.

Step‑by‑Step / Process Flow

1. Identify & Engage Data Stakeholders – Business SMEs, DBAs, architects, and end‑users; capture their data concerns in the Stakeholder Register (KA: Stakeholder Management).
2. Elicit Data Requirements – Run a Data Modeling Workshop (or interview) to surface entities, attributes, and business rules; record raw notes in a Requirements Traceability Matrix (KA: Requirements Elicitation & Collaboration).
3. Draft the Logical Data Model – Build an ERD and Class Diagram using the elicited items; apply normalization and define PK/FK relationships.
4. Validate & Refine – Review the draft with stakeholders; verify cardinality, business rules, and attribute domains; capture changes in the Change Log.
5. Produce the Data Dictionary – Populate a tabular definition for every attribute (name, definition, type, length, allowed values, source).
6. Hand‑off to Architecture/Development – Deliver the Logical Model, Data Dictionary, and any Business Rules to the solution designers for physical modeling and implementation (KA: Solution Assessment & Validation).

Common Mistakes

Certification Exam Tips

1. Know the Input/Output Matrix – For Requirements Analysis & Design Definition, the input is the Elicitation results (e.g., workshop notes) and the output is the Data Model (ERD, Class Diagram) and Data Dictionary. Exam questions often ask “What does the BA produce after analyzing data requirements?” – answer: Logical Data Model.
2. Distinguish Knowledge Areas – Data modeling belongs to Requirements Analysis & Design Definition, not Solution Evaluation. If a question ties data modeling to “validate a solution,” the correct answer is to use the model as a validation artifact, not to create it.
3. Watch for “MoSCoW” traps – The exam may list MoSCoW under Prioritization; remember it is a technique, not a deliverable. The deliverable would be a Prioritized Requirements List.
4. Remember the “Elicitation vs. Documentation” nuance – ⚠️ Elicitation is the activity; the ERD is a documentation artifact that results from analysis, not from elicitation itself.

Quick Check Questions

1. Scenario: After a data‑modeling workshop, the BA discovers that “Customer” can have multiple “Contact” records, but a “Contact” must belong to exactly one “Customer”. Which diagram element captures this rule?
   Answer: Cardinality (one‑to‑many) on the relationship line.
   Justification: Cardinality defines the “many” side for Customer → Contact and the mandatory “one” side for Contact → Customer.

2. Scenario: The development team asks for a definitive list of field lengths, data types, and allowed values for the “PolicyStatus” attribute. What BA artifact should the BA provide?
   Answer: Data Dictionary entry for “PolicyStatus”.
   Justification: The Data Dictionary records attribute domains, data types, and constraints—exactly what the team needs.

3. Scenario: A stakeholder argues that the ERD should include “Employee” entities even though the CRM scope is limited to sales. What should the BA do?
   Answer: Refer to the Scope Statement and document “Employee” as out‑of‑scope, possibly for a future phase.
   Justification: BABOK requires the BA to keep the model within the defined solution scope; out‑of‑scope items are captured separately.

Last‑Minute Cram Sheet (10 one‑liners)

1. KA 1: Business Analysis Planning & Monitoring – sets the “how” for all BA work.
2. KA 2: Elicitation & Collaboration – produces raw stakeholder input (notes, recordings).
3. KA 3: Requirements Analysis & Design Definition – outputs Logical Data Model (ERD/Class Diagram) + Data Dictionary.
4. KA 4: Solution Evaluation – uses the data model as a validation artifact.
5. ERD = Entity‑Relationship Diagram – logical view of data; not a physical DB schema.
6. PK = Primary Key; FK = Foreign Key – define uniqueness and referential integrity.
7. Normalization (1NF‑3NF) reduces redundancy; a common exam trap is to think it’s optional.
8. Cardinality = “how many”; Modality = “optional vs. mandatory”.
9. Data Dictionary = single source of truth for every attribute’s definition, type, and domain.
10. ⚠️ Elicitation ≠ Documentation – the BA elicits information; the ERD/Data Dictionary are outputs of analysis, not of elicitation.

Good luck – you now have the practical roadmap to ace the data‑modeling portion of any IIBA exam and to apply it confidently on the job!