Interview End Users (Final ERD Review)

Who to invite (and why)

• Process owners / SMEs: Source-of-truth for rules and exceptions.
• Power users / analysts: Own complex queries and reports.
• Application developers: Validate integration, IDs, and API impacts.
• Data governance / security: Classify sensitive attributes and access rules.
• Product/ops lead: Prioritize tradeoffs; approve changes.

Preparation checklist

• Current ERD (conceptual) and a change log.
• Glossary of entities/attributes (plain language).
• Top-10 real queries/use cases; sample rows for key entities.
• CRUD matrix (which roles Create/Read/Update/Delete each entity).
• Open issues and assumptions list.

How to run the review

1. Warm-up: Align on goals and scope (conceptual model only).
2. Walk the domain: For each entity, confirm definition, keys, mandatory attributes, and value domains.
3. Validate relationships: Read each relationship both directions; state cardinality and participation out loud (e.g., “ORDER must have exactly one CUSTOMER; a CUSTOMER can have zero or many ORDERS”).
4. Prove it with queries: Take the top real questions and show how the ERD answers them; note gaps.
5. Decide and record: Log each change with rationale, owner, due date, and impact.
6. Close with acceptance criteria: Define what “ready for normalization” means and who signs off.

Elicitation techniques that work

• Scenario walkthroughs: Start-to-finish journeys (create, amend, cancel, archive).
• Counterexamples: “When does this rule not hold?” surfaces edge cases.
• Attribute audit: Distinguish identifiers, natural keys, and optional attributes.
• Lifecycle mapping: Draft states (e.g., Draft → Active → Closed) and state-dependent constraints.

Templates

Use the following quick templates during the session.

Interview agenda

Title: Final ERD Review (Conceptual)
Duration: 60–90 minutes
Participants: SME(s), Power Users, Dev, Product, Data Gov

1) Context and objectives (5)
2) Entities and attributes review (20)
3) Relationships: cardinality and participation (20)
4) Top queries / reports validation (20)
5) Decisions and change log (10)
6) Sign-off criteria and next steps (5)

Decision / change-log entry

ID: CHG-007
Area: CUSTOMER–ORDER relationship
Change: Set CUSTOMER→ORDER min to 0 (allow guest carts)
Rationale: Guest checkout requirement
Impact: New nullable FK; auth/reporting update
Owner: Product/Dev
Due: 2025-10-01
Status: Approved

Question bank (ask users)

• Which reports do you run weekly? What fields/filters do they require?
• What records can exist without parents? For how long?
• Which attributes are required at creation vs. later in the lifecycle?
• What constitutes “duplicate”? How do you merge?
• Which data is sensitive or access-restricted?

Normalization readiness (exit criteria)

• Every entity has a clear purpose, key(s), and minimal attribute set.
• All relationships have explicit cardinality and participation on both ends.
• Ambiguities and exceptions documented; none block core flows.
• Top queries trace to the model with no unknown joins.
• Open items have owners and due dates; risks noted.

Common pitfalls

• Conflating implementation choices (surrogate vs natural keys) with conceptual modeling.
• Missing optionality rules (assuming “one” when “zero or one” is allowed).
• Encoding process steps as attributes instead of modeling state and events.
• Over-fitting to a single team’s vocabulary; use shared business terms.

After the interview

1. Update ERD and glossary; circulate the change log.
2. Resolve conflicts offline; return decisions to stakeholders within 2–3 business days.
3. Capture sign-off; proceed to normalization with the accepted conceptual model.

Accommodating Client - Exercise