Even when a child starts to learn to read, the most simple sentences have both a noun and a verb. “Fetch the ball.” “Run, Spot, Run.” If we take this sentence concept and apply it to the requirements analysis process, process models define the verbs and data models define the nouns. Just as a sentence needs a noun and a verb – a requirements document needs to specify both the nouns (data) and the verbs (processes).
Why do analysts more often create process models to document the results of their analysis efforts, but rarely do they create data models? Is it that process models are easier for the business users to understand — or is it that most analysts do not understand data models and therefore don’t even attempt to develop them?
If we don’t worry about the “rules” and “terminology” of data models, but rather understand what we are trying to capture with this tool – we might be more inclined to develop these models as the companion to the process model.
As someone who has been in the “data” field most of my career, I have been responsible for developing various forms of data models (which have been called information models, enterprise data models, logical data models, physical data models, class diagrams, ERDs, etc) as part of requirements specifications. Rather than get obsessed with the “rules” regarding the various types of data models, I have always concentrated on the value that models of information can provide.
There are only two main components to a data model used during analysis – the entity and the relationship. But maybe those terms are the problem. What if we used “noun” and “verb” instead?
When I first started teaching data modeling techniques my daughter was in the first grade and had been helping me copy course material. So when her teacher said – “A noun is a person, place or thing” she immediately tried to correct her and said that “my mommy says an entity is a person, place or thing.” If a first grader can understand that – why not others? But should we be using our terminology when trying to understand the business, rather than focusing on the business terminology?
Creating a model of information
If we look at what activates a process, we often see that it is stimulated by a business event such as: A customer places an order for a product(s). The process needs data in order to perform the work and that data will probably come from existing or new files or databases. But in order to completely analyze the process, we need to fully understand the “nouns” in the sentence.
The “nouns” in this business event are: Customer, Product, Order and it is the “noun”, Order that is created by the business event. We have to fully define the process that requests the information need about a Customer, and the selection of the Product(s) that the company is selling — to create the Order. If fact, we say that the “noun”, Order is born out of the relationship between the Customer and Product and as such they must be defined and exist before the process (ie Order) can be completed. So we must clearly understand the “nouns”, Customer and Product, and identify the information we need (that are call “data elements” or “attributes” – but the name aren’t important) about these to complete the process.
This simple diagram is drawn for each business event.
In my diagram (Figure 1) I use the hexagon symbol to represent the business event that binds the “nouns” together. This type of data modeling technique is often referred to as an Information Model (a term which has been used in the past by various authors) and represents the results of analyzing the “nouns” that are discovered during requirements analysis. (I don’t want to confuse this with a data model since most data models are used to design a database.)
Most business events bind multiple entities together and that is why I like to use them as the basis for my questioning. I like to start working with business stakeholders by making a list of business events. For each event I write the name on a large square Post-It Note which I have cut off the corners to create a hexagon. I then attach it to the white board or flipchart paper to start creating a diagram. As the discussion mentions nouns I put the name of each noun on a Post-It Note and placing those nouns around the event.
After the initial discussion of the event has finished the business stakeholder are asked to define and/or clarify everything they know about a Customer and Product.
- Can a Customer be a person or a company?
- Do they have to have established credit to place an Order over a certain amount?
- Are there certain Products that can be ordered only by certain Customers?
- Are there any restrictions that we place on a Customer or a Product?
- Are discounts offered to certain Customers?
During this clarification I do not use any technical words, but rather only use the nouns that have identified in the initial discussion. As the business person continues to think out loud I capture the additional information in a Word document. By keeping the discussion focused on business terminology and clarification of business rules, the business stakeholder is able to feel comfortable defining more information about each “noun,” saving the entire team from discovering missing information during development or testing.
In asking these questions we are defining the business rules around the Customer, Product and Order nouns as well as identifying all of the information we need to know about these “nouns.” We also start to identify that there may different types of Customers, Products and Orders (which are usually depicted by a Class Diagram, that looks like an org chart or “noun breakdown structure”)
Of course more information will be identified during these question and answer sessions than what the individual process you are analyzing needs — but that’s OK since that additional information will probably be used by another process later.
All of this information that we have learned about “nouns” can be captured in a text document that is written in the business terminology used during these sessions. This document is meant to be read, reviewed and have corrections made by the business stakeholders involved in the event. The objective of this model is not to design a database, at least not yet. The purpose is to identify and define the information required by understanding the “nouns.”
At a later point in time these individual diagrams can be combined or integrated into composite diagram, like a data model that designers will understand. This process and resulting diagram(s) and documents are a concise way to define the information required to complete the data portion of the business requirements from a business stakeholder’s point of view.
