Design Phases

Every database project that has ever failed—from multi-million dollar enterprise initiatives to startup MVPs—shares a common root cause: inadequate requirements analysis. Before a single table is defined, before any ER diagram is sketched, before any SQL is written, there exists a critical phase that determines whether every subsequent hour of development effort will lead to success or catastrophic failure.

Requirements analysis is not merely a preliminary step to 'get through' before the 'real' design work begins. It is, without exaggeration, the most consequential phase of the entire database design lifecycle. Errors introduced here propagate through every subsequent phase, often becoming exponentially more expensive to correct as the project progresses.

Consider this sobering reality: fixing a requirements defect during the analysis phase costs 1x. Fixing it during design costs 5x. During implementation: 10x. During testing: 20x. After deployment: 50-200x. This is not hyperbole—these multipliers are well-documented across decades of software engineering research.

Requirements analysis in the context of database design is the systematic process of discovering, documenting, and validating what the database system must accomplish. This encompasses not only the data that must be stored but also the operations that must be performed, the constraints that must be enforced, the performance characteristics that must be achieved, and the business rules that must be embedded within the data architecture.

Definition (Formal):

Requirements analysis is the process of determining user expectations for a new or modified product. These requirements must be quantifiable, relevant, and detailed. In database systems, requirements specify what data the system must manage and how that data must behave—without yet specifying how the system will be implemented.

The Three Dimensions of Database Requirements:

Why Requirements Analysis Differs for Databases:

Database requirements analysis has unique characteristics that distinguish it from general software requirements analysis:

1. Data Persistence — Unlike application code that can be readily refactored, database schemas create long-lived structures that accumulate data. Changing a schema after data accumulation requires complex migrations.

2. Multiple Stakeholder Views — Different user groups often need different views of the same underlying data, requiring analysis that captures these varied perspectives while identifying the unified conceptual model.

3. Integration Requirements — Databases often serve multiple applications simultaneously. Requirements must account for all current and foreseeable integration points.

4. Regulatory Constraints — Data frequently carries legal obligations (GDPR, HIPAA, SOX) that impose non-negotiable requirements on data retention, access control, and audit trails.

5. Historical and Temporal Dimensions — Unlike transient application state, database systems often must maintain historical records and support temporal queries that were never explicitly requested.

Before requirements can be gathered, you must first identify who holds those requirements. Stakeholder identification is a systematic process that goes far beyond asking "who will use this database?"

Definition:

A stakeholder is any individual, group, or organization that has an interest in or will be affected by the database system. This includes not only direct users but also individuals who provide input data, consume output, define business rules, enforce compliance, or make decisions based on database information.

The Stakeholder Ecosystem:

Stakeholder Analysis Matrix:

Not all stakeholders carry equal weight. A stakeholder analysis matrix helps prioritize whose requirements take precedence when conflicts arise:

Key Players receive the most intensive elicitation effort and have the greatest influence on design decisions. Keep Satisfied stakeholders may have veto power but low engagement. Keep Informed stakeholders care deeply but have limited decision authority. Monitor stakeholders require minimal direct engagement.

Identifying Hidden Stakeholders:

Critical stakeholders are often overlooked in initial analysis:

Requirements elicitation is the art and science of extracting requirements from stakeholders. It is not passive information gathering—it is active investigation that uncovers requirements stakeholders cannot or do not articulate directly.

The Elicitation Challenge:

Stakeholders often cannot articulate their requirements because:

• They take existing processes for granted (tacit knowledge)
• They don't know what's technically possible
• They focus on current problems without considering future needs
• They describe solutions rather than problems
• They assume you understand their domain context

Core Elicitation Techniques:

Raw requirements gathered through elicitation must be organized into a structured taxonomy that enables analysis, prioritization, and traceability. A well-organized requirements repository is essential for managing the complexity of enterprise database projects.

Primary Categorization Schema:

Non-Functional Requirements Taxonomy:

Non-functional requirements (NFRs) often receive insufficient attention during database design, leading to systems that meet functional needs but fail under real-world conditions:

Requirement Prioritization:

Not all requirements carry equal weight. Prioritization frameworks help make difficult trade-off decisions:

MoSCoW Method:

• Must Have: Requirements without which the system has no value
• Should Have: Important requirements that can be temporarily worked around
• Could Have: Desirable requirements if resources permit
• Won't Have (this time): Explicitly deferred to future phases

Kano Model:

• Basic expectations: Unstated but assumed (data won't be lost)
• Performance requirements: Satisfaction proportional to delivery (query speed)
• Excitement requirements: Delight if present, not missed if absent (advanced analytics)

Value vs. Effort Matrix: Plot requirements on a 2x2 grid of value (to the business) vs. effort (to implement). Prioritize high-value, low-effort requirements first. This is particularly useful for database design where some requirements (adding an audit column) are trivial while others (implementing row-level security) are complex.

Requirements documentation serves multiple critical functions: it provides a contract between stakeholders and developers, enables traceability throughout the project lifecycle, supports impact analysis when requirements change, and serves as input for test case development.

Documentation Hierarchy:

Individual Requirement Documentation:

Each requirement should be documented with sufficient detail for implementation and testing:

Data Dictionary Standards:

The data dictionary is particularly critical for database requirements. Each data element entry should include:

Validation ensures that documented requirements accurately capture stakeholder needs and are of sufficient quality to proceed with design. This is the last line of defense before requirements errors become design and implementation errors.

Validation Criteria (CURVES):

Each requirement should be evaluated against the CURVES criteria:

Validation Techniques:

Common Requirements Defects:

Watch for these frequent problems during validation:

Requirements will change. Business conditions evolve, stakeholders refine their understanding, regulations shift, and technical constraints emerge. A robust change management process distinguishes projects that adapt successfully from those that spiral into scope chaos.

Change Management Framework:

Change Control Board (CCB):

For significant database projects, establish a CCB with authority to approve or reject requirement changes. Membership should include:

• Technical lead (impact assessment)
• Business owner (priority decisions)
• Project manager (schedule/resource impact)
• QA representative (testing impact)
• Architecture representative (design consistency)

Change Request Documentation:

Requirements analysis is not a phase to rush through—it is the foundation upon which every subsequent design decision rests. Time invested here pays exponential dividends throughout the project lifecycle.

What's Next:

With requirements thoroughly analyzed and documented, we are ready to enter the conceptual design phase. Here, we transform stakeholder requirements into an abstract, implementation-independent model of the data—the Entity-Relationship model that will guide all subsequent design decisions.

The next page explores conceptual design: how to identify entities from requirements, determine their attributes and relationships, and create ER diagrams that accurately capture the conceptual schema of the database.