Collecting and managing requirements is the first step to ensuring data quality. Despite the development of digital tools, most requirements are still formulated in an unstructured way: through letters, meeting minutes, phone calls and verbal discussions. This form of communication makes it difficult to automate, validate, and reuse information. In this chapter, we look at how to translate textual requirements into formal structures, ensuring that business requirements are transparent and systematic.
Gartner’s research, “Data Quality: Best Practices for Accurate Insights,” emphasizes the critical importance of data quality for successful data and analytics initiatives (Gartner, “Data Quality: Best Practices for Accurate Insights,” 1 Jan. 2025). They note that poor data quality costs organizations an average of at least $12.9 million annually and that reliable, high-quality data is essential to creating a data-driven company.
The lack of structured requirements leads to the fact that the same element (entity) and its parameters may be stored in different systems in different variations. This not only reduces the efficiency of processes, but also results in wasted time, duplication of information and the need to re-validate data before it can be used. As a result, even a single omission – a lost parameter or a single incorrectly described element – can slow down decision-making and cause inefficient use of resources.
For want of a nail, the horseshoe was lost.
For want of a horseshoe, the horse was lost.
For want of a horse, the rider was lost.
For want of a rider, a message was lost.
For want of a message, the battle was lost.
For want of a battle, a kingdom was lost.
And all for the lack of a nail in the horseshoe.
– Proverb (“For Want of a Nail”)
Analyzing and gathering requirements for the process of filling and storing data starts with identifying all stakeholders. Just as the proverbial loss of a single nail leads to a chain of critical consequences, in business, the loss of a single stakeholder, an overlooked requirement or the loss of even a single parameter can significantly impact not only an individual business process, but the entire ecosystem of a project and the organization as a whole. Therefore, it is extremely important to identify even those elements, parameters and roles that at first glance seem insignificant, but later may turn out to be critical to business sustainability.
Let’s imagine that a company has a project in which the client puts forward a new request – “add an additional window on the north side of the building“. The small process “client’s request to add a new window to the current project” involves architect, client, CAD specialist (BIM), construction manager, logistics manager, ERP -analyst, quality control engineer, safety engineer, control manager and real estate manager.
Even a small process may involve dozens of different specialists. Each process participant must understand the requirements of the specialists with whom they are connected at the data level.
At the text level (Fig. 4.4-1), the communication between the client and the specialists in the process chain takes place as follows:
Customer: “We have decided to add an additional window on the north side for better lighting. Can this be realized?”
Architect: “Sure, I will revise the project to include the new window and send updated CAD plans (BIM).”
CAD Specialist (BIM): “Received a new project. I update the CAD (BIM) model with the additional window and after coordination with the FEM engineer provide the exact location and dimensions of the new window”.
Construction Manager: “A new project has been received. We are adjusting the installation dates for 4D and informing all relevant subcontractors.”
Facilities Engineer (CAFM): “I will enter the 6D data on the new window into the CAFM system for future facility management and maintenance planning.”
Logistics Manager: “I need the dimensions and weight of the new window to organize the delivery of the window to the facility.”
ERP -analyst: “I need the scope tables and exact window type for the 5D budget update in our ERP system to reflect the cost of the new window in the overall project estimate.”
Quality Control Engineer: “Once the window specs are ready, I will make sure they meet our quality and material standards.”
Safety Engineer: ‘I will be assessing the safety aspects of the new window, with a particular focus on compliance and evacuation scheme 8D “.
Controls Manager: “Based on the exact scope of work from ERP, we will update our 4D timeline to reflect the installation of the new window, and store the new data in the project’s content management system.”
Worker (installer): “Need instructions on installation, assembly and timing of work. In addition, are there any special safety rules that I have to follow?”
Property Manager: “Once installed, I will document warranty and maintenance information for long-term management.”
Asset Manager: “Equipment Engineer, please submit final data for asset tracking and lifecycle management.”
Client: “Wait, maybe I’m in a hurry and the window won’t be needed. Maybe I should make a balcony.”
In such scenarios, which happen frequently, even a small change causes a chain reaction between multiple systems and roles. In this case, almost all communication at the initial stage is in text form: emails, chats, meeting minutes (Fig. 4.4-1).
In such a text-based communication system for a construction project, a system of legal confirmation and recording of all data exchange operations and all decisions made is very important. This is to ensure that every decision, instruction or change made is legally valid and traceable, reducing the risk of future “misunderstandings”
The lack of legal control and validation of decisions in the relevant systems of a construction project can lead to serious problems for all involved. Every decision, order or change made without proper documentation and validation can lead to disputes (and litigation).
Legal fixation of all decisions in textual communication can only be ensured by a large number of signed documents, which will fall on the shoulders of the management, which is obliged to record all transactions. As a result, if every participant is required to sign documents for every action, the system loses flexibility and becomes a bureaucratic maze. Lack of transaction confirmations will not only delay project implementation, but may also lead to financial losses and deterioration of relations between the participants, up to and including legal problems.
Such a transaction approval process, which usually starts with text-based discussions, gradually evolves into a multiformat document exchange format in the following stages (Fig. 4.4-2), significantly complicating the communication that used to take place only through text. Without well-defined requirements, automating such processes filled with multiformat data and a large number of textual requirements becomes almost impossible.
Text communications require each professional to either familiarize themselves with the full correspondence or attend all meetings on a regular basis to understand the current status of the project.
To overcome this limitation, a transition from textual communication to a structured requirements model is necessary. This is only possible through systematic analysis, process visualization, and description of interactions in the form of flowcharts and data models (Fig. 4.4-3). Just as in data modeling (Fig. 4.3-7), we moved from the contextual-idea level to the conceptual level by adding the systems and tools used by the participants and the links between them.
The first step in systematizing requirements and relationships is to visualize all connections and relationships using conceptual flowcharts. The conceptual level will not only make it easier for all process participants to understand the entire process chain, but also visualize why and for whom the data (and requirements) are needed at each process step.
