Skip to content

Phase 1: Discovery

AI lifecycle checkpoint

Treat Lab 7's support-prioritization scenario as a teaching extension, not an interview fact. Record intended and prohibited uses, affected stakeholders, necessary data, one uncertain assumption and a follow-up question about consent or authority. Carry these requirements into later phases without presuming permission for reuse.

Requirements Extraction from Business Context

Overview

In this phase, you are acting as a Junior Data Architecture team.

You are not drawing ER diagrams yet.

You are not designing tables.

You are performing Discovery.

Your objective is to extract structured technical requirements from an intentionally messy business conversation.

This phase trains you to:

  • Interpret ambiguity
  • Identify architectural signals
  • Separate business language from technical structure
  • Document uncertainty professionally

Before architecture comes clarity.

Discovery is clarity.

The Living Portfolio Principle

Professional architecture work is iterative.

Discovery artifacts are not disposable.

They are promoted into formal models.

All Phase 1 work must be documented in the portfolio template.

This portfolio serves as:

  • Your architectural record
  • Your governance reasoning log
  • Your promotion foundation for Phase 2 (Logical Data Model)

Work completed here will directly inform structural design decisions later.

Discovery is not brainstorming.

It is traceable architectural preparation.

Case Study Context

Organization Type: Retail provider (online and in-store operations)
Architectural Objective: Design a system that balances:

  • Operational speed
  • Analytical accuracy
  • Governance enforcement
  • Regulatory compliance
  • Executive visibility

You will analyze a stakeholder interview transcript containing:

  • Business terminology
  • Operational constraints
  • Compliance references
  • Implicit system requirements

Your responsibility is to convert narrative language into structured architectural components.

Your Task

Working in small architecture teams:

Complete the Phase_1_Requirements sheet in the portfolio.

You must:

1. Identify Entities (Nouns)

What “things” must the organization track?

Examples:

  • Customer
  • Product
  • Order
  • Store
  • Inventory

Entities represent persistent system components.

If it must be stored, queried, or governed — it is likely an entity.

2. Identify Relationships (Verbs)

How do entities interact?

Examples:

  • Customer places Order
  • Store fulfills Order
  • Product belongs to Category

Relationships define structural dependencies.

Without relationships, architecture is fragmented.

3. Identify Attributes

What details describe each entity?

Examples:

  • Customer → Email, Date of Birth, Loyalty Tier
  • Product → MSRP, SKU, Category
  • Order → Timestamp, Payment Method

Attributes must be mapped to the correct entity.

Check misplaced attributes against entity meaning and relationship structure.

4. Assign Confidence Levels

Each identified component must be marked:

  • High Confidence
  • Medium Confidence
  • Low Confidence

This reflects professional humility.

If marked as Low, you must document:

  • What is unclear
  • What additional question you would ask
  • What risk ambiguity introduces

Strong architects document uncertainty explicitly.

Deliverable

Submit the completed Phase_1_Requirements portfolio.

Requirements:

  • All group members listed
  • Entities clearly defined
  • Relationships structured
  • Attributes mapped precisely
  • Confidence levels assigned
  • Notes provided where required

Discovery quality directly impacts Phase 2.

Weak discovery produces weak architecture.

Evaluation Criteria

Your work will be assessed based on:

Completion

Are all major entities and relationships represented?

Precision

Are attributes mapped correctly to their entities?

Professional Reasoning

Do Low Confidence items include thoughtful stakeholder follow-up questions?

Structural Readiness

Is the discovery work usable as input for a Logical Data Model?

Discovery is not about guessing correctly.

It is about documenting thinking clearly.

Why This Phase Matters

Organizations fail at architecture not because engineers cannot model.

They fail because requirements were misunderstood.

Discovery prevents:

  • Structural rework
  • Compliance gaps
  • Data ownership confusion
  • Governance blind spots

This phase builds your ability to:

  • Translate business language into structured systems
  • Detect hidden requirements
  • Recognize regulatory implications early
  • Document ambiguity professionally

You are learning to think like a systems architect.

Final Perspective

Architecture does not begin with diagrams.

It begins with disciplined listening.

Strong discovery leads to strong structure.

This phase is the intellectual foundation of the entire capstone.

Author: Isaac K. Nti. Citation and reuse terms.