Requirements are all that jazz
„If you know exactly what you’re looking for, you can’t find what you need“
Why do we require requirements?
Nowadays, every company has to cope with large amounts of data and has to be able to react quickly to changes, often with legal or commercial consequences. Various sources (such as SAP, BIM, GIS, ERP, etc.) are used, and it is necessary to keep track of them to make good decisions based on them.
The common thread, the connecting element of the asset creation process and asset management over the entire life cycle, are requirements. Therefore, companies and organisations need precise requirements management based on a comprehensive information model and information management. So far, we try solving these highly interconnected puzzles with tree structures and spreadsheets. Back in the day, we would split complicated projects into parts, solve each individually, and manage relations between the parts. With constantly more complex projects, this is not sufficient any longer.
Situation
We are experiencing a time parallel to increasing digitalisation and automation, with ever larger teams, more experts and rising specialisation, higher demands (environment, costs, quality) and projects failing colossally due to this complexity. It is not technical details alone that drive us, but primarily operational and strategic questions, the lack of clarity of responsibility and the lack of traceability of the effects of our decisions.
As traditional design-bid-build approaches no longer prove effective, alternative forms of collaborative contracts such as IPD (Integrated Project Delivery) are emerging that incentivise and mutually benefit participants rather than working against the project with addendas and claims.
Clearly defined requirements, as well as their status at any point in time of a project, are central for goal definition and goal achievement. These can be the actual functional or technical requirements of the systems or components, but also those requirements that arise from the mutual dependencies and interfaces between them. While some requirements only emerge through specifications in the planning process, scheduling, legal, organisational or commercial requirements are part of the task definition from the very beginning.
The process starts during the development of the project or earlier at the business planning level, during the planning, execution and commissioning of the project, and continues into operation and further maintenance. Just suppose, we were to represent requirements as continuous cause-effect chains. In that case, there are opportunities to incorporate the operational requirements into the development and design process or use findings from the project and operation as a learning process for subsequent projects and continued operation. This puts us in a position to develop and optimise both the tender, commissioning, and acceptance based on a single set of data.
Challenge
For the management of requirements, valid, up-to-date information is needed that is easily accessible to the decision-maker. This information is usually already available but poorly accessible, unlinked or untraceable since parts of it come from a wide variety of data sources (internal and external). Moreover, their multiplicity contains undiscovered contradictions and scope for interpretation, representing actual unaddressed project risks.
The big challenge, therefore, is not to create new data or to transform it into supposedly new and better formats but to use existing data and connect it to an intelligent, lean information management system that uses requirements as a guideline and shows the connections and risks as well as the potentials of decisions in a comprehensible way.
The solution
We need a comprehensive information model for projects or portfolios, with or without 3D model data. Information delivery in construction projects today is always a combination of models, drawings, text documents, spreadsheets, photos, videos, audio files etc. Much of this information builds on each other, is interdependent or reflects the same facts in a different form. Today, however, the requirements and their development, which define all these essential relationships and interrelationships, are often lost, but they need to be recorded in a standardised way; information breaks occur between project development, tendering, design, execution, commissioning and operation. So there needs to be ONE centre for all requirements.
The possibility of obtaining the relationships between an information element and the requirement behind it through standardised links can contribute significantly to the project’s success. The composition of such an information delivery results from superordinate requirements and framework conditions, the detailed requirements from the planning process, process requirements themselves, and the specific functional purpose. Thus, diverse sources from which requirements arise must be integrated.
Other industries, such as the automotive or defence industries, have already developed solutions to these problems for themselves. Today, there is much work on merging requirements and information into one system. As a result, unstructured, closed or poorly structured data (such as PDF, XLS, CSV) are converted into well-structured data (such as RDF, OWL), and their effects and dependencies become visible.
Application
Recognising requirements as such, merging them from diverse sources into a central system independent of formats and recognising the dependencies and connections requires an open and compelling system. With graph databases, we have such a system at our disposal.
Graph databases not only effectively store the relationships between data points but are also flexible in adding new types of relationships or adapting a data model to ever-changing requirements. Based on semantic web technologies and graph databases, we have developed an L-CDE (Linked Common Data Environment) that integrates all typical AEC sources, such as models, schedules and plans, and for which requirements management is an almost predestined use case.
We now have an effective way to match requirements with deliverables (see 5.), detect inconsistencies between parts (see 6.), and enable traceability to understand the impact of one decision on all others (see 7.).
The contents of all important AEC-specific information carriers (e.g. IFC) and almost all typical silos can be integrated. A kind of search engine is added to the existing system with its silos, and the puzzle pieces can be connected immediately without significant investments in IT or costly change processes. Depending on the task, a federated information model is created. It does not attempt to overload BIM models with information as a “single source of truth” but to provide reliable answers to the respective questions based on all available sources.
How to?
The first step is analysing the existing situation and processes and creating a practical concept of how information and requirements management can be set up based on the current systems. In this step, you should have a look at existing solutions explicitly developed for Requirements Management. If nothing suits you, start simply by grabbing one of the many graph databases available today and use it instead of spreadsheets.
But you can still make it “look” like a spreadsheet in order not to «scare» people away. Working with Graph here, a node becomes a requirement and for the beginning fill in the text manually from the documents. Yes, there are ways to do it automatically, but start easy. A possible mini “schema” to organise could look like the one below. (It is as Gist on GitHub so feel free to use it, add or comment: https://www.yworks.com/yed-live/?file=https://gist.githubusercontent.com/philoktetch/026d708b3e393ebe2074977355061ce8/raw/d6cfde7e008ae8eba2f9bfb49a94268fb656b177/Requirements%20Schema)
In the next step, you should agree with the stakeholders to do a POC (Proof of Concept) and implement it in the appropriate framework. People you trust and are willing to improve are key here. In particular, the current development towards a closed-loop asset management process or an IPD (Integrated Project Delivery) contract environment can benefit from implementing the proposed requirements and information management. Both contract models require high transparency and effective risk management. Having transparency of requirements here is a huge advantage.
In the last step, define your system based on the insights gained and efficiency improvements and possibly supplemented, maybe flanked and deepened by further POCs. With this step-by-step approach, you will reduce the risk of wasting time and money on huge IT projects. In our work, we are guided by the quality standard 5 Star Model by Tim Brenner Lee (https://5stardata.info/de/), and we try to follow the FAIR Data Principles (Findability, Accessibility, Interoperability, Reuse https://www.go-fair.org/fair-principles/) in all our activities. Taking these as a basis is certainly not wrong.
Projects, whether internal or external, fail due to lack of clarity, unrecognised risks and wrong incentives, this can be avoided today, but it requires a professionalisation of our handling of project information.
Today we have the necessary information technology. Let's make use of it. Requirements management powered by linked data and graph databases is a great way, even if it looks like a spreadsheet at the end. It will put you in control of your project because consistent requirements create coordinated projects. Let`s move from doubters who take decisions based on confusing incomplete and inaccessible files and become data-driven graph-empowered decision-makers.
Philipp Dohmen and Hanno Wiese Jan.2023
