We often spend the majority of our modeling time on use cases, process flow diagrams, and other tools that model behavior. These behavior models are great tools for driving out functional requirements but they don’t explicitly address all of the data objects, attributes, and relationships associated with the behavior. For that we need a set of data models and modeling techniques. In fact, it is hard to imagine a software requirements effort that does not include some data modeling effort. Switching your point of view from behavior to data and back is a great way to identify questions you should be asking about when and how data objects are created or used in the process. The answers to those questions will raise more questions about the process and will ultimately result in a much more complete set of requirements.

Here are three simple but powerful techniques for modeling Data:

First, start with any narrative description of the business process such as a write up of your notes from meeting with project sponsors and subject matter experts. Scan through the text and identify all of the nouns. The resulting list of nouns includes candidate actors and candidate business objects. At this stage we are looking for business objects that are real things in the real world, not things in the software. Like I said, simple but powerful.

Second, construct a business object model for each use case you write. This step is often overlooked because we know we will need a consolidated object model covering all of the use cases so modelers tend to start with the overall model and just update that model with new information as use cases are developed and analyzed. Developing an object model specifically for a use case is a great way to make sure we focus on the data requirements for that use case. We still need the consolidated model but the use case specific models are another simple but powerful technique.

Third, work through the object model, one object at a time, and ask about the things users can know or remember about the object. These are the attributes of the object, including attributes that define an object’s relationships to other objects. For example, for an order we can remember the order number, order date, items on the order, etc. Among other things, this tells us the order can have a relationship with many items. But, how many items? Can an order have zero items? Is there a maximum? Work through this step carefully as there can be a lot of attributes and relationships.

There are many other data modeling techniques but these three are easy to use and will really pay off by helping identify requirements you might otherwise miss.