Data Requirements: Why They're Awesome and How to Work with Them (Part 1)

Let’s talk about an awesome and crucial thing in requirements work: data requirements. In this article, I’ll try to convincingly explain why data requirements deserve your time and attention, what can happen if you ignore them (and, conversely, what perks you get when you handle them properly), and what exactly working with these requirements entails.

A bit of context. As IT analysts, we work with information systems. And information systems work with — surprise — information. Their very essence is to allow that information to be manipulated, either autonomously or by providing users with functionality to do so (create, update, delete, view — the magic acronym CRUD that analysts have heard many times). What are data requirements? They are the requirements for the information the system must operate on.

Personally, I’m a strong believer in this approach: the more angles from which we examine requirements, the better the final system requirements will be in terms of completeness, consistency, and so on. Sure, there are times when speed trumps thoroughness. But data requirements are not the aspect I recommend sacrificing for the sake of faster delivery — and I’ll explain why shortly.

Data requirements are about looking at the target system not through the lens of its behavior or quality attributes, but rather through the lens of the information that behavior operates on.

Where do data requirements fit in requirements classifications? Most analysts are familiar with classifications by Mr. Wiegers and BABOK, and maybe have even seen the term "data requirements" mentioned — but try to recall where exactly they’re placed. Kinda hard, isn’t it? Exactly — because they're not explicitly placed anywhere. And that’s… not ideal. Let’s dig into some of the well-known theories (useful, by the way, if you're preparing for interviews): what do the big names say about data requirements?

a) The gurus (Karl Wiegers, Joy Beatty — Software Requirements, 3rd edition):

"Data requirements are not shown explicitly in this diagram. Functions manipulate data, so data requirements can appear throughout the three levels."

Honestly, I have no idea how data requirements can “appear” at all three levels of their hierarchy. Either Mr. Karl has ascended into realms inaccessible to mere mortals, or he got distracted by cat videos. What, for instance, are data requirements at the level of business requirements (i.e. business goals)? To me, data requirements only make sense at the level of solution requirements, because it's the solution that works with the data.

b) BABOK v3:

"Functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage."

That’s it — BABOK doesn’t sweat the details. It briefly mentions data requirements within functional requirements.

c) IREB:

"Functional requirements concern a result or behavior that shall be provided by a function of a system. This includes requirements for data or the interaction of a system with its environment."

Again — data requirements are part of functional requirements.

I agree with the last two sources. Since software functions operate on information, I recommend explicitly recognizing two key subtypes of functional (solution-level) requirements:

• Behavioral requirements (what the system does)
• Data requirements (what information the system works with)

What does it mean to work through data requirements?

It means giving them a dedicated space in your documentation, and just like with any other type of requirements — eliciting, analyzing, documenting, and managing them. I even recommend working through them in parallel with behavioral requirements, or sometimes even before. That’s because a system’s behavior often amounts to “CRUDing” the data described in these requirements.

Let me walk you through a simple process for working with data requirements, suggest a few techniques, and explore a sample case along the way.

We’ll skip business requirements and stakeholder (including user) requirements here, since we’ve already decided we’re at the solution requirements level (i.e. the third level in classic waterfall business analysis).

A basic analyst might now reach for familiar tools: time to write user stories, maybe use cases, or some other way to break the system down into chunks and describe their behavior.

1) What I recommend instead — and what Karl Wiegers himself recommends — is starting with a Context Diagram.

Now, the context diagram isn’t part of data requirements per se (it's more about defining the scope of the solution), but it’s a great starting point for working on them.

Mr. Wiegers offers this great insight:
"A good place to start with data requirements is with the input and output flows on the system’s context diagram. These flows represent major data elements at a high level of abstraction, which the BA can refine into details as elicitation progresses."

I won’t go into detail on how to build such a diagram — Mr. Karl covers that beautifully in his book. Let me just recap the essentials.
A context diagram shows:

• The boundary of the system (but not its internal workings — it’s still a black box)
• External actors (people, hardware, or software systems interacting with it directly)
• The essence of those interactions, in terms of the information exchanged between actors and the system

It’s built using DFD (Data Flow Diagram) notation.

Let’s build such a diagram based on our example.

Note: the arrows show data, not actions. That’s why this diagram is such a great launchpad for data requirements.

2) At some point in your BA process (perhaps even now), I recommend applying the CRUDL technique, as it ties directly into data requirements.

Just a quick overview (there are many deep dives out there, for instance):

CRUDL helps assess the completeness of solution scope by analyzing operations on known data requirements:

• Create – add a new object
• Read – view object details
• Update – edit object details
• Delete – remove the object
• List – view a list of objects (secondary but almost always necessary: you usually need to list items before reading or updating any one of them)

Let’s define two key terms here:

• Data entities (also known as data objects or data classes): major chunks of information composed of smaller pieces.
• Attributes: atomic pieces of information.

If something can be broken down into smaller information units — it's a data entity. You’ll find more elaborate definitions out there, but this simple one will serve us just fine.

In our context diagram, we can already identify data entities: Order, Company Info, and Product — all are clearly structured sets of data. Note: I went straight to the concept of “Product,” because a catalog is not a data entity in itself — it’s just a collection of many Products. Same with Orders — the system may have many. In some systems, you might have separate entities like “Catalog” or “Product Category” (especially if the system supports customizable catalogs), but that would go beyond our simple case.

Let’s apply CRUDL to these entities and build a table showing the typical operations we expect for each, along with basic questions to the stakeholders and the answers we received:

Now that we understand the solution scope better, let’s add this information to our initial description:

A simple e-commerce store where the key features are a general info page, browsing a product catalog, and placing orders. Admins (via a single pre-created account) can view submitted orders. They can also add/remove products from the catalog and view them.

The first key component of data requirements in our documentation — one that we should already begin developing (and later refining alongside user stories, use cases, and related artifacts) — is the Logical Data Model (LDM).

Let me clarify up front: in theory, there are more elaborate approaches where analysts are advised to develop several levels of data modeling, each with its own fancy name. But in my experience, one model has always been sufficient — what you might call a business analyst’s view of the information the solution will work with.

Since an analyst shouldn't tie requirements to specific implementations, this model is called logical — that is, independent of how things will be physically realized. The analyst (assuming they’re not a systems analyst or a part-time architect) doesn't know in advance whether a database (and what kind) will be used for storing data, or if everything will be dumped into plain old .txt files.

The logical data model shows what information the system will operate on and how this information is related. There are various notations for drawing such models (IDEF, ER, Crow’s Foot, UML). I personally prefer UML, particularly the UML Class Diagram.

How do we build such a model?

I've already covered this in more detail here and here, and below I’ll briefly walk through the key points. If at any point it feels like you need more detail or examples, I suggest checking out those links.

a) First, let’s add our data entities as rectangles (or “classes” in UML terms):

A couple of notes:

• Why didn’t I include “Company Info”? For beginners, this might seem odd. Including it wouldn’t be a major mistake, but from experience, I know it doesn't count as dynamic data. What we care about in a system are dynamic data — information that can change over time, not through code changes but through user interaction or automated updates. “Static” data, on the other hand, is hardcoded by developers. Based on stakeholder input, “Company Info” fits this latter category. It will be fixed in the page’s code, can’t have multiple instances (we won’t ever have multiple company infos), and concepts like CRUDL (Create, Read, Update, Delete, List) don’t really apply — except for reading.

• Why did I include “User” (which represents an admin, since customers don’t need accounts)? According to the same stakeholders, there’s only one admin account, manually set by developers. Still, after some reflection (or discussion with stakeholders), I decided it can change. Maybe not by users directly, but via direct database edits. It's quite likely that, in the future, we’ll need multiple admin accounts or will need to change login details without touching code.

b) Now let’s add relationships between entities.

Relationships show how large blocks of data (entities) relate to each other. If you’ve worked with databases, this part is straightforward. If you haven’t, try this analogy:
Imagine all this information stored in an Excel file. To display or save dynamic data, the system "looks" inside this file. Each sheet represents a data entity, and each row on a sheet is an object of this "class". For example, a “Products” sheet would contain rows for each individual product.

So, would any rows need to reference other sheets to show relationships between data? Probably yes:

• Orders are linked to Products, since each order refers to the products purchased.
• Users (admins) aren’t inherently linked to anything, but suppose we get a new stakeholder requirement: for audit purposes, we want to track which admin added each product. In that case, Products should be linked to Users, so we can trace back who added what.

UML lets us draw four kinds of relationships (not mandatory, but they help convey meaning — just make sure your readers understand them or that you’ve taught them):

• Generalization (Inheritance): A child class B is a more specific version of parent class A. For example, Product (parent) and Laptop (child).
• Aggregation and Composition: Both show whole-part relationships. If deleting the “whole” also deletes the “part,” it’s composition (strong). If not, aggregation (weak). E.g., Product (part) and Catalog (whole).
• Association: A catch-all relation between classes. Use it when the others don’t apply. Always make associations directional and name them — otherwise, they’re vague and hard to interpret.

Let’s now draw relationships reflecting what was discussed above. Both are associations because other types don’t make sense here.

Time to add multiplicities. Multiplicities are notes on the ends of relationships that indicate how many objects of one class relate to another.

Read each association and ask the right questions:

1.1) How many Products can be in one Order?
Let’s say the stakeholder replies: “Five — it’s our internal limit.” So, 1 to 5. (Make a mental note that the system must not allow empty Orders.)

1.2) How many Orders can include one Product?
0 (maybe it’s never ordered) to infinite.

2.1) How many Products can one User add?
0 to infinite.

2.2) How many Users can add one Product?
Just one — a Product is added by a single User.

Let’s update the model accordingly.

Now let’s move to attributes.

Recall: attributes are the atomic pieces of information that define an entity. That is, what information makes up an Order, Product, or User? After some thought and stakeholder discussion, we can add attributes to our diagram. This is our final modeling step. But don’t ask stakeholders vague questions like, “What attributes should the Order have?” You’ll either lose them or annoy them. Phrase questions in human terms: “As a customer, what info do I see when viewing a product card?”

Here are the attributes (which I’ll add to the diagram) with some comments.

Product:

• Who added — this is a linking attribute, a reference to the User who added the Product.

User:

• Only Login and Password — no need for Role yet, as all accounts are admins.

Order:

• Products — marked as [] to show it’s a list (i.e., multiple product references).

Don't cross the line: what makes this model logical?
As stated earlier, analysts shouldn’t tie requirements to implementation choices — we don’t yet know how information will be physically stored. Sure, as active participants in the project, we’ll eventually learn that. But at the requirement-gathering stage, it’s still a black box. And we shouldn’t make architectural or development decisions in place of those more qualified.

Some key points:

• No IDs. You might be wondering: why no unique identifiers? If you're used to databases, this seems wrong. But from a business perspective, IDs are irrelevant — no one needs to view or input them in the system. We don’t even know if a database will be used or if it will require such keys. Let the storage designers figure that out — they’re the experts.
• No junction tables. We’re not designing database schemas here. For example, no intermediate tables to handle many-to-many relationships — again, we don’t know if we’ll even use a relational database.

In the second part, we’ll talk about the data dictionary and how it ties into behavioral requirements.