Purpose of Requirements Analysis in Database Design

The overall purpose of Requirements Analysis is to gather every piece of information needed to design a database that meets the informational needs of an organization. A database that is built without thorough requirements gathering will reflect the designer's assumptions about what the organization needs rather than what the organization actually needs. Those assumptions are almost always incomplete, and the gaps they introduce surface later as missing entities, incorrect relationships, or data integrity problems that are expensive to correct after implementation.

Requirements Analysis accomplishes its purpose by performing a series of related tasks:

1. Examine the existing database(s)
2. Conduct user interviews
3. Create a data flow diagram (if needed)
4. Determine user views
5. Document all findings

Each of these tasks contributes a distinct type of information to the overall requirements picture. Together they produce a formal requirements specification that the database designer can hand off to the conceptual design stage with confidence. The sections below examine each task in detail, applying them to the Stories on CD, Inc. case study introduced in Lesson 1.

Requirements Analysis in the DBLC

As established earlier in this course, Requirements Analysis is the most important and most labor-intensive stage in the Database Life Cycle (DBLC). Every stage that follows — conceptual design, logical design, physical implementation — depends on the accuracy and completeness of the requirements gathered here. Errors introduced at the Requirements Analysis stage propagate forward and compound. A missing entity discovered during physical implementation requires revisiting the logical design, which may require revisiting the conceptual design, which may require additional stakeholder interviews. The cost of correction grows at each stage.

It is critical for the designer to approach Requirements Analysis armed with a plan for each task in the process. That plan does not have to be rigid — as the next section explains, the sequence of tasks is deliberately flexible — but the designer must enter each phase of the work knowing what they are trying to learn and how they intend to learn it. Preparation is especially important for new designers who have not yet developed the instinct for recognizing when a stakeholder's description of their data needs is incomplete or internally inconsistent.

Experience is the great teacher when it comes to assessing informational needs, but there is no substitute for preparation. Most database designers begin Requirements Analysis by examining the existing database or data storage system to establish a framework for the remaining tasks. Analyzing how an organization stores data about its business objects^[1], and scrutinizing its perception of how it uses stored data — for example, gaining familiarity with its business rules^[2] — provides that framework before the first stakeholder interview takes place.

Why the Sequence of Tasks Is Flexible

The sequence in which the tasks associated with Requirements Analysis are performed is not fixed. Nor are the tasks themselves necessarily performed in isolation from one another. In practice, the tasks overlap and inform each other continuously throughout the requirements gathering process.

For example, tasks are documented while they are being performed rather than after a discrete documentation phase. A data flow diagram is often sketched while conducting interviews, because a visual representation of data movement helps stakeholders identify gaps in their verbal descriptions. User views are frequently outlined while examining the existing database, because the structure of the existing system reveals which categories of users are currently being served and which are not. The review and edit cycle continues until the model is certified as correct.

For Stories on CD, Inc., this flexibility plays out practically. When the database designer examines Ted's flat-file system, she immediately identifies that the system conflates in-store and mail-order customers in a single undifferentiated table. This observation shapes the interview questions she will ask Bob and Jane Martin, because she needs to understand whether the business distinguishes between these customer types for operational or marketing purposes. The interview reveals that it does — and that the distinction between actual and potential customers is equally important. That finding drives the definition of a customer type attribute that would never have emerged from the flat-file examination alone. The tasks do not proceed in isolation; each one feeds the next.

Requirements analysis also encompasses those tasks that go into determining the needs or conditions for a new or altered product and accounting for the possibly conflicting requirements of various stakeholders. Requirements must be documented, actionable, measurable, testable, and related to identified business needs or opportunities. They can be architectural, structural, behavioral, functional, or non-functional — and a complete requirements specification addresses all relevant categories for the system being designed.

Task 1: Examine the Existing Database

The first task gives the designer a concrete starting point. Before any stakeholder is interviewed, the designer examines whatever data storage system the organization currently uses — whether that is a relational database, a flat-file system, a spreadsheet, a set of paper forms, or some combination. The goal is not to evaluate the current system's quality but to understand what data the organization is already capturing and how it is being used.

For Stories on CD, Inc., Ted's flat-file system reveals the following. Customer records exist but contain no mechanism for distinguishing actual customers from potential customers. Order records are present but do not capture the order channel — there is no way to tell from the data alone whether an order was placed in-store or by mail. Product records exist but lack the age group classification that the Martins use to organize their catalog and target their marketing brochures. Distributor information is not in the system at all — Jane maintains it on Rolodex cards.

Each of these observations becomes a line item in the requirements specification. The flat-file examination does not answer the question of what the new database should contain, but it answers the question of what the existing system fails to provide — which is a productive starting point for the stakeholder interviews that follow.

Task 2: Conduct User Interviews

The database requirements are determined by interviewing both the producers and users of data and using that information to produce a formal requirements specification. That specification captures the data required for processing, the natural relationships between data elements, and the software platform for the database implementation. Products, customers, salespersons, and orders can be formulated in the mind of the end user during the interview process — the designer's role is to draw those formulations out through structured questioning.

For Stories on CD, Inc., the designer interviews Bob Martin (who handles purchasing and distributor relationships), Jane Martin (who manages marketing and the customer mailing list), the store manager (who oversees in-store sales and inventory), and the fulfillment staff (who process mail-order shipments). Each interview surfaces requirements that the others do not. Bob knows that the company sources CDs from a small set of domestic distributors and that distributor contact details need to be accessible when placing orders. Jane knows that the marketing brochures are sent several times a year and that the featured CDs change with each edition — a requirement that implies a Brochure entity with a many-to-many relationship to the Product entity. The store manager knows that stock levels need to be visible to sales staff at point of sale. The fulfillment staff knows that shipping status must be tracked per order and updated as shipments are processed.

None of these requirements are visible in Ted's flat-file system. They emerge only through direct conversation with the people who do the work.

Practical Interview Guidance

Interviews can be conducted as individual sessions or as group meetings. Both formats have appropriate uses depending on the nature of the information being gathered and the organizational dynamics involved.

Individual interviews work best when the designer needs detailed operational knowledge from a specific role — the fulfillment process, the purchasing workflow, the marketing campaign cycle. Individual sessions allow the interviewee to speak freely without concern for how colleagues will react to their description of current workflows, which often surfaces more accurate information about how the organization actually operates rather than how it is supposed to operate.

Group sessions work best when the designer needs to understand how different roles interact around a shared process — for example, how a mail-order is handed off from the sales function to the fulfillment function. Group sessions also allow stakeholders to correct each other's descriptions in real time, which reduces the number of follow-up interviews needed. Keep group sessions to under five or six people. Larger groups tend to fragment into side conversations or become dominated by senior voices whose descriptions of processes may not reflect operational reality. Where possible, group people by function — a session with all fulfillment staff is more productive than a mixed session that includes both marketing and fulfillment personnel.

Use a whiteboard or shared document to record information gathered from the interviews in real time. Recording visually — sketching a rough entity list or a preliminary data flow — gives interviewees something to react to, which often produces corrections and additions that a purely verbal interview does not. The sketch does not need to be accurate; its purpose is to make the designer's current understanding visible so that the interviewee can identify where it is wrong.

Task 3: Create a Data Flow Diagram

A data flow diagram (DFD) maps how data moves through the organization — where it originates, what processes it passes through, and where it is stored or consumed. For Stories on CD, Inc., a DFD for the mail-order process would show the customer as an external entity submitting an order, the order entry process that records the order in the system, the inventory check process that verifies stock availability, the fulfillment process that packages and ships the order, and the shipping status update that records the outcome. Each step in the diagram identifies data elements that must be stored and relationships between them that the database must support.

The DFD is described as conditional in the task list — it is created if needed — because not every organization has data flows complex enough to warrant formal diagramming. For a very simple system with a single user and a handful of entities, the data flows may be self-evident from the interviews. For Stories on CD, Inc., with two sales channels, multiple stakeholder roles, and a marketing process that runs independently of sales, a DFD is warranted. Lesson 7 of this module covers data flow diagrams in detail.

Task 4: Determine User Views

A user view defines the subset of database data that a particular category of user needs to see and interact with. Different roles within the same organization have different data needs, and the database must support all of them without exposing data that is not relevant or not authorized for a given role.

For Stories on CD, Inc., the sales staff need a view that shows customer information and current inventory levels at point of sale. The fulfillment staff need a view that shows pending mail-order items, their quantities, and their shipping status. Jane Martin needs a marketing view that shows the customer list segmented by customer type — actual versus potential — with contact details for mailing. Bob Martin needs a purchasing view that shows distributor contact information alongside current stock levels so that reorder decisions can be made with complete information. Each of these views is a distinct slice of the full database tailored to a specific operational role. Lessons 8 and 9 of this module address user views in detail.

Task 5: Document All Findings

Documentation is not a discrete final step — it runs concurrently with every other task. As entities are identified during the flat-file examination, they are recorded. As business rules emerge during interviews, they are documented. As data flows are mapped, the diagrams are saved. The formal requirements specification that the documentation task produces is the accumulated output of all the preceding tasks organized into a coherent reference document.

A complete requirements specification for a database project includes entity lists with preliminary attribute definitions, a business rules inventory, data flow diagrams, user view specifications, and a description of the software platform on which the database will be implemented. This specification becomes the primary input to the conceptual design stage, where entities and relationships are formalized in an Entity-Relationship Diagram. Lesson 10 of this module covers requirements documentation in detail.

The Goals of Requirements Analysis

The information gathered through the five tasks serves five specific goals. These goals define what a completed Requirements Analysis must deliver before the conceptual design stage can begin:

1. To determine the data requirements of the database in terms of primitive objects
2. To classify and describe the information about these objects
3. To identify and classify the relationships among the objects
4. To determine the types of transactions that will be executed on the database and the interactions between the data and the transactions
5. To identify rules governing the integrity of the data

The first goal — determining data requirements in terms of primitive objects — means identifying the entities that the database must represent. For Stories on CD, Inc., those primitive objects are customers, orders, products, distributors, and brochures. The second goal — classifying and describing information about these objects — means defining the attributes that characterize each entity. The third goal — identifying and classifying relationships — means establishing how entities connect: which customers placed which orders, which orders contain which products, which products appear in which brochures.

The fourth goal — determining transaction types and data interactions — means understanding the queries and updates the database must support. For Stories on CD, Inc., those transactions include order entry, stock level updates, shipping status updates, customer list segmentation for marketing, and seasonal sales analysis. The fifth goal — identifying data integrity rules — means capturing the business rules that constrain what data the database will accept. Each order must reference a valid customer. Each order line must reference a valid product. Discounted prices must be calculated at 40% off retail. These rules become integrity constraints in the logical design.

The Overlap Between Requirements Analysis and ER Diagramming

Although Requirements Analysis and ER diagramming are formally presented as sequential stages in the DBLC, in practice they overlap significantly. The information needed to build a data model is gathered during requirements analysis, but as that information is collected, data objects are immediately identified and classified as entities, attributes, or relationships. They are assigned names and defined using terms familiar to the end users. The objects are then modeled using an ER diagram that can be reviewed by the designer and the end users to determine its completeness and accuracy.

This concurrent approach has a practical advantage: the ER diagram serves as a visual validation tool during the requirements process. When a preliminary diagram is shown to stakeholders during an interview, they can identify missing entities, incorrect relationships, or attribute definitions that do not match their understanding of the business. The review and edit cycle continues until the model is certified as correct. By the time Requirements Analysis is formally complete, the ER diagram is often already in an advanced draft state rather than starting from scratch.

The next lesson defines business objects — the primitive entities that Requirements Analysis must identify — and examines their characteristics in detail.