Requirements Gathering for Database Design

Every successful database begins long before the first table is created or the first query is written. It starts with a conversation—a structured, purposeful dialogue with the people who will use, maintain, and depend on the system being built.

User interviews are the cornerstone of requirements gathering in database design. They bridge the gap between what stakeholders need and what the database will ultimately deliver. A database designer who skips or rushes through user interviews is like an architect who designs a building without understanding who will live in it, how they will use it, or what problems they need solved.

In the realm of database design, technical excellence is necessary but insufficient. A perfectly normalized schema that fails to capture critical business requirements is worthless. A high-performance database that stores the wrong data serves no one. User interviews ensure that technical solutions align with real-world needs.

User interviews serve as the primary mechanism for understanding the information needs of an organization. Unlike automated analysis or document review, interviews provide direct access to the tacit knowledge, unwritten rules, and contextual understanding that stakeholders possess.

Why are user interviews irreplaceable?

Database design is fundamentally about modeling reality. But 'reality' in an organizational context is not merely data on paper—it's also procedures, exceptions, relationships, and constraints that exist only in the minds of the people who work within the system daily.

Consider a hospital patient management system. Documents might show that patients have appointments with doctors. But only through interviews will you discover:

• Emergency patients bypass normal scheduling
• Some doctors share patients for specialized cases
• Historical appointments must be preserved even after patient transfer
• Certain patient data requires higher access restrictions due to regulatory requirements

These nuances—invisible in existing documentation—are precisely what interviews reveal.

Effective requirements gathering begins with identifying the right people to interview. Stakeholders are individuals or groups who have an interest in, or will be affected by, the database system. Not all stakeholders are users—some are decision-makers, others are subject matter experts, and some are impacted parties who never directly interact with the system.

Stakeholder Categories:

A comprehensive stakeholder analysis ensures no critical perspective is missed. Missing a key stakeholder is one of the most common sources of requirements gaps.

The Stakeholder Identification Process:

1. Start with organizational charts — Identify departments and roles that interact with the data domain
2. Follow the data flow — Trace who creates, uses, modifies, and archives the relevant data
3. Identify decision-makers — Who approves data, authorizes changes, or sets policies?
4. Consider external parties — Customers, partners, auditors, and regulators often have requirements
5. Ask stakeholders for referrals — "Who else should I speak with?" often reveals overlooked parties
6. Review existing systems — Who uses current systems or workarounds?

Prioritizing Stakeholders:

Not all stakeholders carry equal weight. A common technique is to classify stakeholders by:

• Power — Their authority to influence the project
• Interest — Their level of concern about the database
• Expertise — Their depth of domain knowledge

The quality of an interview is largely determined before a single question is asked. Thorough preparation distinguishes professional requirements gathering from informal conversations.

Pre-Interview Research:

Before meeting any stakeholder, gather as much background information as possible:

• Review existing documentation, forms, reports, and system interfaces
• Understand the organizational structure and the interviewee's role
• Learn the basic vocabulary and terminology of the domain
• Identify known problems, ongoing initiatives, or recent changes
• Review any previous requirements documents or design artifacts

This preparation serves two purposes: it makes the interview more efficient by avoiding basic clarifications, and it demonstrates respect for the interviewee's time, building rapport and credibility.

Designing Interview Questions:

Question design is an art that balances structure with flexibility. Questions should be:

• Open-ended initially — "Tell me about your daily workflow" yields richer information than "Do you enter customer data?"
• Progressively specific — Start broad, then drill into details as understanding develops
• Non-leading — Avoid questions that suggest expected answers
• Domain-appropriate — Use terminology the interviewee understands
• Sequenced logically — Group related questions; flow from general to specific

The interview itself is where preparation meets interpersonal skill. Even with perfect preparation, a poorly conducted interview yields incomplete or misleading information. The interviewer must simultaneously:

• Build and maintain rapport
• Guide the conversation toward objectives
• Listen actively and probe for details
• Document findings accurately
• Manage time effectively

Opening the Interview:

The first five minutes set the tone for the entire session. A strong opening:

1. Thanks the interviewee for their time
2. Explains the purpose of the interview and the project
3. Clarifies how the information will be used
4. Addresses confidentiality concerns
5. Requests permission for note-taking or recording
6. Establishes the expected duration
7. Invites the interviewee to ask questions first

Managing Difficult Interview Situations:

Not all interviews proceed smoothly. Common challenges include:

The Overly Technical Expert: Some interviewees dive into implementation details or use domain-specific jargon. Gently redirect: "That's very helpful—could you explain this as if I were a new employee learning the system?"

The Reluctant Participant: Some stakeholders view interviews as interruptions. Emphasize the impact of their input: "Your insights will directly shape how the new system works. Without your expertise, we might miss critical requirements."

The Scope Expander: Some interviewees use the interview to lobby for features outside the project scope. Acknowledge their ideas and document them, but refocus: "That's noted for future consideration. For now, let's focus on the core order processing workflow."

The Conflict Revealers: Sometimes interviews reveal conflicting requirements between stakeholders. Don't resolve conflicts during the interview—document both perspectives and address them in follow-up sessions with relevant parties.

The value of an interview is only realized through proper documentation. Raw interview notes must be processed, organized, and validated to become usable requirements.

Immediate Post-Interview Processing:

Within 24 hours of each interview—while memory is fresh—complete these steps:

1. Expand abbreviations and shorthand — Convert quick notes into complete sentences
2. Organize by topic — Group related information together
3. Identify gaps — Note areas that remain unclear or were not covered
4. Highlight key findings — Mark critical requirements, constraints, and insights
5. Note contradictions — Flag statements that conflict with previous interviews
6. Draft follow-up questions — Prepare queries for clarification
7. Extract data elements — Begin identifying entities, attributes, and relationships

Interview Summary Distribution:

A professional practice is to send a summary of the interview to the interviewee for validation. This:

• Confirms your understanding is correct
• Gives the interviewee opportunity to clarify or add information
• Creates a record of agreement on requirements
• Demonstrates professionalism and respect

The summary should be concise—typically 1-2 pages—highlighting key requirements without reproducing raw notes verbatim.

Synthesizing Multiple Interviews:

After several interviews, patterns emerge. Requirements synthesis involves:

• Consolidating common requirements across stakeholders
• Identifying and resolving conflicts between stakeholders
• Prioritizing requirements by frequency, importance, and feasibility
• Building a unified picture of data needs, processes, and constraints
• Creating preliminary conceptual models based on aggregated findings

Different situations call for different interview approaches. A skilled requirements analyst adapts their technique to the context, stakeholder, and information needs.

Individual vs. Group Interviews:

Both formats have distinct advantages and appropriate use cases.

Structured, Semi-Structured, and Unstructured Interviews:

Specialized Techniques:

Contextual Inquiry (Observation + Interview): Rather than interviewing in a meeting room, observe the stakeholder in their actual work environment while asking questions. This hybrid approach reveals the reality of how work is performed, including workarounds, informal processes, and environmental constraints.

Joint Application Development (JAD) Sessions: Facilitated workshops bringing together multiple stakeholders for intensive requirements gathering. JAD sessions typically span 1-5 days and aim to achieve consensus on major requirements.

Day-in-the-Life Studies: Shadow a user for an extended period (hours to days) to understand the complete context of their work, including interruptions, exceptions, and the rhythm of actual operations.

Even experienced database designers can fall into interview traps that compromise requirements quality. Awareness of these pitfalls is the first step to avoiding them.

The 'User Knows Best' Fallacy:

A subtle but dangerous assumption is that users always know what they need. In reality:

• Users describe solutions, not underlying problems
• Users base requests on current limitations
• Users may not envision possibilities outside their experience
• Different users have conflicting needs

The interviewer's job is to understand the underlying needs and constraints, not simply to transcribe user requests verbatim. This requires respectful probing: "You mentioned wanting a weekly report. What decision are you trying to make with that report?"

The 'Everything is Important' Problem:

Stakeholders often claim every requirement is critical. Techniques for prioritization:

• Ask about consequences: "What happens if this data is unavailable for a day?"
• Request ranking: "If you could only have three of these features, which would they be?"
• Probe frequency: "How often does this situation actually occur?"
• Explore workarounds: "How do you handle this today?"

User interviews are the foundational activity of requirements gathering in database design. They provide access to tacit knowledge, business rules, and contextual understanding that no document or automated tool can capture.

What's Next:

User interviews provide rich qualitative input, but they represent only one source of requirements. The next page explores Document Analysis—the systematic examination of existing forms, reports, manuals, and records that complement interview findings with concrete, verifiable artifacts. Together, interviews and document analysis form a comprehensive picture of organizational data needs.