Data Requirements – Should the Business Analyst Care?

I was once told by the director of an IT branch of a federal government department not to concern myself with the data requirements of an in-house information system project and to focus only on the business requirements. The system should have taken about six to eight months to deliver, but it took more than two years and few people were happy with the end result.

Should business analysts care about the data requirements? You bet! Unfortunately, business analysts spend much more time analyzing business processes than they do analyzing business information. This often leads to requirements that only tell half the story. When it comes to building information systems, understanding the data is no less important than understanding the processes. In this new world of fiscal restraint, few organizations can afford to build a system more than once. There is a way to ensure that the requirements that are captured represent a more complete picture of what is needed (and only what is needed), to deliver maximum value, and to get it right the first time.

What about the Data?

As business analysts, we are experts at getting to the root of the problem or the opportunity at hand, and we have many techniques to do so. The techniques that we use are dependent on a variety of factors, including the business environment, the preferences of the stakeholders, the availability of the subject-matter experts, accessibility of systems and related documentation, and so on. When we develop business process models, we often model the current “as-is” and the target “to-be” business processes. Use cases, data flow diagrams, functional decompositions, sequence diagrams, and state diagrams are just a few of the techniques available. When it comes to modeling business processes, we have a full arsenal of techniques in our toolkit, yet the notion of documenting information is often put aside.

Business analysts sometimes forget or ignore the data requirements. This may be because they think it isn’t their job, or that someone else will take care of it. Or it may be that they are intimidated by some of those diagrams they see with all those boxes and lines going every which way. But regardless of why data requirements are not documented or understood, if you’re part of a team that is building an information system, and you’re documenting business processes without any notion of the data, then you’re only doing half of your job.

Why I should care?

There are all sorts of benefits in understanding data requirements. When the business analyst has an understanding of the business processes and the data, there is a great opportunity to cross-check both areas. For example, if there is a business process that uses (or produces) no data, the chances are it isn’t a business process. Similarly, if there is a data element in a data model that is not used by any business process, there may be a missing business process, or the data element is not in the scope of the system. Either way, this knowledge can be used to ensure that the business processes are complete and that all of the data requirements have been captured.

Many of the questions that business analysts ask subject-matter experts and stakeholders that pertain to business functions and activities invariably involve business information. This is the best time for the business analyst to get a sense about what information is important to the stakeholders. There are four key techniques that I use to document data requirements. The technique you choose will depend on the business environment, the amount of time and money and the preferences of the stakeholders and subject-matter experts.

Data Requirements Techniques

Data Modeling

A data model is one of the more powerful tools used to capture information requirements. It is powerful because every data element can be thoroughly documented, including its data type, field length, and its relationship with the other data elements. As previously mentioned, the data model is an excellent means to validate the completeness of the business process model. Another aspect of data modeling that makes it powerful is that once it has been established and validated by the subject-matter experts, it is possible for the business analyst to work with a database administrator to forward-engineer the model into a physical database, especially if the model has been designed using a data modeling tool.

Data modeling takes practise, and unless you have experience with this technique it may be necessary to take a training course and work with an experienced colleague or a mentor who can help you learn.

Data Dictionary

The data dictionary is a necessary part of the data model, but it is possible to develop a data dictionary independently. A data dictionary is a written description of the data elements of a system that describes the entities, the attributes of each entity, and the relationships of the entities with each other. No significant training is required to develop a data dictionary, but it is not a trivial exercise and it will require persistence to complete.

Validating the data dictionary can be challenging since the business analyst will often be faced with disagreements amongst the stakeholders about the definitions. Reconciling these differences early in the project lifecycle is imperative, and ignoring them can be catastrophic.
 

Report Analysis and Prototyping

Another way the business analyst can describe data requirements is to develop a series of report mock-ups. The assumption is that all of the data that goes into the system comes out, in one form or another, in a report. After all, if the data is not going to appear in a report, why put it in a database at all? In theory, once the business analyst has a set of report mock-ups that have been validated by the subject-matter experts, every data element should be accounted for.

Usually the business analyst will not have to produce the report mock-ups from scratch because there will already be reports that the organization uses. There may be new or different reports that will lead to additional data requirements, and there may be changes to some of the existing reports. This is one of the more straightforward techniques to develop data requirements, and one that does not require significant training.

Reverse-Engineering

Many information system delivery projects focus on commercial off-the-shelf solutions (COTS) because the majority of organizations recognise the risk and expense of developing custom solutions. When deploying a COTS solution, organizations that do not do their homework in terms of defining their business process and data requirements, quite simply, risk complete failure. It is not enough to trust the vendor, because at the end of the day you will either know exactly what you bought, or you will soon find out.

The reverse-engineering technique involves acquiring a trial version of the COTS solution in question and copying the software’s database into a data modeling tool to create a physical database schema. The schema is then compared with the data model representing the organization’s data requirements. An analysis of the differences between the two will identify the areas where decisions will have to be made. For example, if the solution doesn’t support certain data requirements, then the organization will have to decide if it can live without it, or implement a manual work-around, or determine if the solution can be customized. There are a host of reasons why it not always feasible to reverse-engineer a vendor’s database, and even if it is possible there is some technical know-how required.

Yes You Can!

You do not have to be a data modeling expert to capture data requirements. You only need to be curious, have a willingness to try something new, and be willing to work with other IT professionals who may know something that you don’t. This is an opportunity to step outside of your comfort zone and venture into in an area which is business analysis but unknown to more than a few business analysts.

Don’t forget to leave your comments below.