Database Requirements Analysis — Conclusion

Requirements Analysis turns stakeholder needs into clear, testable, and traceable specifications for the database life cycle. Although this module presented the work in a sequence of eleven lessons, many activities occur in parallel — interviewing users while drafting business rules, sketching data flow diagrams during stakeholder conversations, beginning the preliminary ER diagram before all requirements are finalized. Documentation spans every step. The goal throughout is to produce a requirements specification that is accurate enough to hand off to the conceptual design stage with confidence that nothing important has been omitted.

This conclusion summarizes what each lesson covered, restates the module learning objectives, and describes what comes next in the Database Life Cycle.

Module Learning Objectives

The learning objectives stated in Lesson 1 for this module were:

1. Explain the purpose of Requirements Analysis.
2. Identify business objects and describe their characteristics.
3. Explain the importance of business rules.
4. Explain the purpose of interviewing data users.
5. Explain the purpose of a data flow diagram.
6. List reasons for creating user views.
7. Describe the documents produced during Requirements Analysis.

Each of the eleven lessons addressed one or more of these objectives through the Stories on CD, Inc. case study, which followed the Requirements Analysis process from the initial examination of Ted's flat-file system through the complete documentation of business objects, characteristics, rules, user views, and data flows needed to design the relational database for Bob and Jane Martin's business.

Lesson Summaries

Lesson 1 — Intro to Requirements Analysis established Requirements Analysis as the first and most critical stage of the Database Life Cycle. The lesson introduced the Stories on CD, Inc. case study — a small family business selling children's audio CDs through in-store and mail-order channels — and identified the five primary business objects the new database must represent: customers, orders, products, distributors, and brochures. It explained where Requirements Analysis sits in the DBLC, why errors at this stage propagate forward into every downstream stage, and what the module would cover lesson by lesson.

Lesson 2 — Requirements Analysis Purpose defined the overall purpose of Requirements Analysis: to gather every piece of information needed to design a database that meets the organization's informational needs. The lesson listed the five tasks that accomplish this purpose — examining existing databases, conducting user interviews, creating data flow diagrams, determining user views, and documenting findings — and explained why the sequence of these tasks is flexible rather than fixed. It also addressed the overlap between requirements analysis and ER diagramming, showing that the two activities are conducted concurrently in practice.

Lesson 3 — Define Business Objects defined business objects as things — both tangible and intangible — in a business environment that are related to each other and about which data is or needs to be stored. The lesson explained where to look for business objects (existing databases, paper-based records, stakeholder interviews), established the rule that a database should address one subject category, and showed how business objects are converted into entities in the logical design stage and ultimately into database tables expressed in SQL.

Lesson 4 — Business Object Characteristics examined the properties that describe each business object. It introduced the two-characteristic rule — if a candidate business object cannot be described by at least two characteristics, it is probably not a business object — and applied it to the Stories on CD entities. The lesson showed how characteristics map to entity attributes in the logical design and how attributes become table columns in SQL, tracing the Customer business object from its characteristics through a complete CREATE TABLE statement. It also covered the preliminary relationships between business objects and how those relationships are documented during Requirements Analysis.

Lesson 5 — Business Rules Importance explained that business rules translate organizational policies into constraints the database must enforce. The lesson covered the types of business rules that arise during Requirements Analysis — domain rules governing acceptable attribute values, entity integrity rules governing primary keys, referential integrity rules governing foreign key relationships, and derivation rules governing calculated values — and applied each type to the Stories on CD, Inc. context.

Lesson 6 — Interview Data Users established why interviewing both producers and users of data is essential to Requirements Analysis. The lesson identified the five purposes served by stakeholder interviews — identifying user requirements, uncovering implicit knowledge, detecting data anomalies, encouraging user acceptance, and supporting change management — and provided practical guidance on interview techniques. For Stories on CD, Inc., the interviews with Bob Martin (purchasing and distributors), Jane Martin (marketing and customer lists), the store manager (inventory and point of sale), and the fulfillment staff (shipping workflow) each surfaced requirements that no other technique would have revealed.

Lesson 7 — Data Flow Diagram introduced the data flow diagram as a tool for visualizing how data moves through the business — where it originates, which processes transform it, and where it comes to rest. The lesson covered the Yourdon/DeMarco and Gane & Sarson notation styles, explained the distinction between a DFD and a data model, and demonstrated context DFD decomposition through Level-1 and Level-2 diagrams. It applied DFD thinking to the Stories on CD, Inc. mail-order workflow and showed how each data store in the DFD corresponds to a table candidate and each cross-boundary flow corresponds to a foreign key candidate.

Lesson 8 — Creating User Views covered user views as role-focused subsets of the database that provide different categories of users with the data they need without exposing data they do not need. The lesson explained why creating user views during Requirements Analysis — rather than after implementation — produces better database designs, and applied the concept to Stories on CD, Inc. by defining the views required by the sales staff, fulfillment staff, and Jane Martin's marketing function.

Lesson 9 — Calculated Fields Require User Views examined the role of calculated fields within user views. The lesson distinguished between stored calculated values — attributes whose values are computed and persisted in the database — and derived values computed at query time through view definitions. For Stories on CD, Inc., the discounted price (40% off retail for all CDs) was the primary calculated field, and the lesson showed how this calculation is best implemented as a derived column in a view rather than as a stored attribute, ensuring that the calculation remains consistent across all queries without requiring updates to stored data when the discount rate changes.

Lesson 10 — Requirements Analysis Documentation covered the formal deliverables that the Requirements Analysis stage produces. The lesson described the contents of a complete requirements specification — entity lists with attribute definitions, a business rules inventory, data flow diagrams, user view specifications, and a preliminary ER diagram — and explained how these documents serve as the primary input to the conceptual design stage. It also introduced the Requirements Traceability Matrix as a tool for linking requirements to design decisions, test cases, and implemented features throughout the DBLC.

What You Learned

1. Purpose of Requirements Analysis: Define scope, constraints, and success criteria so downstream design has a stable target.
2. Business Objects & Characteristics: Identify candidates for entities, their attributes, and how they relate.
3. Business Rules: Translate policies into enforceable constraints, validations, and access controls.
4. Interviewing Users of Data: Capture real workflows, edge cases, and future needs; increase adoption.
5. Data Flow Diagrams (DFDs): Visualize where data originates, how it moves, which processes transform it, and where it is stored.
6. User Views: Provide role-focused access and centralized calculated fields via stored queries.
7. Documentation: Produce concise artifacts (requirements specification, preliminary ERD, user views, RTM) that enable traceability and change control.

Quick Exit Checklist

• Preliminary list of business objects and relationships is complete and reviewed with stakeholders.
• Business rules cataloged with proposed enforcement method (constraints, views, RBAC, or application logic).
• User interviews synthesized into user stories or use cases and view specifications.
• Data flow diagram or context diagram created where multiple systems or handoffs exist.
• Draft ER diagram and data dictionary started from validated data requirements.
• Requirements Traceability Matrix links requirements to design decisions and tests.

Glossary

1. Attribute: A property that describes an entity; typically a column in a database table.
2. Base table: A table physically stored in the database, as distinct from a view.
3. Business object (Entity): A real-world thing about which data are stored (e.g., customer, order).
4. Business rule: A policy or constraint that governs data and processes; enforceable in schema or application logic.
5. Constraint: A rule (e.g., PRIMARY KEY, FOREIGN KEY, CHECK) that preserves data integrity.
6. Data flow diagram (DFD): A diagram showing external actors, processes, data stores, and the flows of data between them.
7. Data integrity: The accuracy, consistency, and validity of data across related tables.
8. Logical schema: The ERD-level structure of entities, attributes, and relationships, independent of physical implementation.
9. Requirements analysis: The DBLC phase that discovers and documents what data is needed and under what conditions it is accessed.
10. SQL: Structured Query Language — the standard language for defining, querying, and manipulating relational data.
11. View (virtual table): A stored SELECT definition that returns rows from one or more base tables at query time without physically storing the result.
12. Yourdon/DeMarco: A common DFD notation using squares for external entities, circles for processes, parallel lines for data stores, and arrows for data flows.

What Comes Next

The next module — Attributes and Entities — takes the preliminary business object list produced by Requirements Analysis and evolves it into a coherent entity-relationship model. Business objects become formally defined entities. Preliminary characteristics become formally typed and constrained attributes. Preliminary relationships become formally cardinality-specified connections between entities, expressed in an ER diagram that will drive the logical design of the relational database.

For Stories on CD, Inc., that means the five business objects identified in this module — customers, orders, products, distributors, and brochures — will each be examined for the completeness of their attribute definitions, the appropriateness of their primary key choices, and the accuracy of the relationships between them. The Requirements Analysis work done in this module provides the foundation. The Attributes and Entities module builds the structure on top of it.

Requirements Analysis — Quiz