Data Requirements - Should a business analyst care?
Hi There!
This is a translation of the article " Norman Thuswaldner from the BA Times website ." The article of 2014, but it seemed to me very relevant in 2018 as well.
Getting started!
Data Requirements - Should a business analyst care?
One day, the IT director told me not to think about data requirements and focus only on business requirements. The system should have been developed in 6-8 months, but it took more than two years, and few were satisfied with the final result. [reading this text, I can’t rejoice at how well we have a well-organized project, I work on the creation of an IT product, in almost every project we have a separate person who cares only about the data]
Should business analysts care about data requirements? What do you think?
Unfortunately, business analysts spend much more time analyzing business processes than analyzing business information. This often leads to requirements that tell only half of the story. When it comes to building IT systems, understanding data is as important as understanding processes. In the modern world, few organizations can afford to rebuild only a built system.
There are ways to help collect requirements and create a complete picture of what is needed (and only what is needed) in order to get the most out of the project the first time. [intrigued]
So what about the data?
As business analysts, we are experts in finding the root of a problem or opportunity, and we have many methods for doing so. The choice of methods we use depends on many factors, including the business environment, preferences of stakeholders (stakeholders), availability of subject matter experts (SME), availability of systems, relevant documentation, etc. When we develop business process models, we often model current “as-is” and targeted “to-be” business processes. Usage examples, data flow diagrams, functional expansions, sequence diagrams, and state diagrams are just a few of the methods available. When it comes to business process modeling, we have a full arsenal of methods in our toolbox, but the concept of documenting information is often missing.
Business analysts sometimes forget or ignore data requirements. This may be because they think it is not their job, or that someone else will take care of it. Perhaps they are intimidated by the sight of those diagrams with all these rectangles and lines. Regardless of the reasons, if you are part of a team that builds an IT system, and you document business processes without any idea about the data, you only do half of your work.
Why should I care?
If you understand the data requirements, you have many advantages. When a business analyst understands business processes and data, there is a great opportunity to cross-check both areas. For example, if there is a business process that does not use (or does not produce) data, most likely it is not a business process. Similarly, if there is a data element in the data model that is not used by any business process, we may have missed the business process or the data element is not included in the system. In any case, this knowledge can be used to fully complete the analysis of business processes and take into account all data requirements.
There are four key methods that I use to document data requirements. The method you choose will depend on the business environment, the amount of time and money, and the preferences of the Stakeholders and SMEs.
Data requirements
1. Modeling data
The data model is one of the most powerful tools used to collect information requirements. This is an excellent approach, because each data element can be carefully documented, including its data type, field length, and its relationship to other data elements. As mentioned earlier, the data model is an excellent means of checking the completeness of a business process model.
Another aspect of data modeling that makes it powerful is that once it is installed and tested by SME, a business analyst can work with a database administrator to redesign the model into a physical database, especially if the model was developed using the tool data modeling.
Data modeling takes practice, and if you do not have experience with this method, you may need to take a course and work with an experienced colleague or mentor who can help you learn.
2. Data dictionary
A data dictionary is a necessary part of a data model, but it can also be developed separately. The data dictionary is a written description of the data elements of the system, which describes the entities, attributes of each object and the relationship between them. Developing a data dictionary does not require significant preparation, but this is not a trivial exercise, and this will require perseverance.
Verifying data vocabulary can be a daunting task, as a business analyst often faces disagreements between interested parties regarding definitions. Reconciling these differences early in the life cycle of a project is mandatory, and ignoring them can be disastrous in the later stages.
3. Analysis of reports and prototypes
Another way the business analyst can describe the data requirements is to develop a series of report layouts. It is assumed that all data entering the system are displayed in one form or another in a report. In the end, if the data will not be displayed in the report, why even put them in the database? Theoretically, once a business analyst has a set of report layouts that have been verified by the SME, he has all the data elements that he cannot miss.
Usually, a business analyst will not have to create report layouts 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 in some existing reports. This is one of the simplest methods for developing data requirements, as well as one that does not require significant training.
4. Reverse engineering
Many IT development projects focus on commercial off-the-shelf Commercial Off-The-Shelf Solutions (COTS), as most organizations are aware of the risks and costs of developing customized solutions. When introducing COTS, organizations that do not do their homework, in terms of defining their business processes and data requirements, risk to fail. It is not enough to simply entrust the supplier; you yourself must be completely sure what you will get at the exit.
The reverse engineering technology includes the acquisition of a trial version of the COTS under consideration and the copying of a software database into a data modeling tool to create a physical database schema. The schema is then compared with a data model that represents the data requirements of the organization. An analysis of the differences between them will determine the areas in which decisions are to be made. For example, if the solution does not support certain data requirements, the organization will have to decide whether it can live without it, or add manual work or determine whether the product can be customized. There are many reasons why it is not always possible to reverse engineer a supplier’s database, and even if it is possible, some technical know-how is required.
Yes you can!
You do not need to be a data modeling expert to collect data requirements. You just need to be curious, have a desire to try something new and be ready to work with other IT specialists who may know something that you do not know. It's easy, get out of your comfort zone and enter a zone that is business analysis.
In the next article, I will explain how we use some of the tools described to collect data requirements.
Cheers!
')
Source: https://habr.com/ru/post/354084/
All Articles