Jump to content
Writing Information Requirements - Report from the IADD4UK group

Writing Information Requirements - Report from the IADD4UK group

iain miskimmin

The attached guide was put together from discussions and knowledge share through the Infrastructure Asset Data Dictionary for the UK (IADD4UK) group between 2013 and 2018. Updated where appropriate to include the most recent standards and some additional thought leadership.


The IADD4UK initiative was formed of the foremost owners, major projects, delivery partners and interested parties under the chairmanship of the COMIT innovations group. A list of participants can be found at the rear of this guide.

Early in our BIM journey it was recognised that data and its slightly more refined form, information would be the key. We had standards as how to classify it, manage it, secure it, procure it, exchange it, but nothing about what “it” actually was.

It was also understood that this required information would have an impact on everything we do with our assets, across the entirety of its lifecycle. That impact had a relationship with the outcomes delivered to their respective clients, whether that was an end user, consumer, member of the public, a shareholder or the country itself. The delivery of the outcomes ensured that there was a value in the information, without which their upkeep would not be possible.

The IADD4UK group was put together with an agreement to research and document the best way to create information requirements, not to write them, but it was agreed that if organisations could come together when writing them, the costs and risk could be shared and the benefits doubled.

The reason for increased benefits, were that when assets were transferred from one owner to another, or between delivery partners they would be described in the same way, negating the risks of translation and converting information from one system to another. Key assets in infrastructure are basically the same, whether they are owned by a transport, communications, energy or water company. They will have the same questions, tasks and decisions during their lifecycle. The answers will be different, but the basic information requirement will be largely the same. This commonality across owners could help reduce the procurement costs and the risks of generating, managing and exchanging each information set with the side effect of reducing interoperability issues between software packages.

In 2017 the IADD4UK organisation was put on hold for various reasons, chiefly lack of funding to both create and curate a common information requirements dictionary. This meant that the participants in the initiative dispersed to create their own data dictionaries utilising some of the methods and processes shared with you in this guide.


Writing information requriements by IADD4UK.pdf

  • Like 2

User Feedback

Recommended Comments

Hi Ian,

This is a really great post!  I am part of the technical team working on the NDT Information Management Framework and one area I have been focussing on is a process and methodology for identifying and agreeing on information requirements that support decisions.  You capture the challenge well with your sentence "We had standards as how to classify it, manage it, secure it, procure it, exchange it, but nothing about what “it” actually was.".  This challenge isn't unique to the lifecycle management of large asset systems (which, in my view, makes it initially harder to address) but you make a great case for addressing it and it is central to the NDT work.

I recommend the document you attached to others on the DT Hub.  It mirrors what we are doing to address information management in support of the NDT Programme, as a Data Quality exercise that should be up to the task of enabling organisations to identify and meet **any** information requirement throughout the lifecycle of infrastructure asset systems (and more).  Rather than repeating what is in your document, here are some additional points that we are addressing to realise the Vision of data that is "fit for purpose":

- Data consistency.  Representing information that is required in a consistent manner across systems and organisations is key to making use of it in a distributed environment.  This is as important for people as it is for software.  The Foundation Data Model and the Reference Data Library that are principal parts of the IMF are being carefully created to address this.

- Process and methodology that is compatible with the IMF. As your document describes, working out and agreeing on [information] requirements is a human activity - supported by technology, we do want the information-technology to help us meet those requirements.  We therefore need the process and methodology work to be compatible with what needs to happen in the technical space too.  The IMF team have been working on ensuring that this is the case and we have started to publish documents on this.  One of the documents will be available on the DT Hub this week and there is a draft methodology document that is shareable too.

- Working at any required detail/scope.  It shouldn't matter where/how you start the process of managing integrated information to be at a sufficient quality, it should fit in to the greater information 'whole'.  The information should be re-useable as long as it is at a known quality.

- Extensibility. This is a something that most information systems will struggle to address (even if their marketing documents claim it to be the case).  However, as the world doesn't stand still, information requirements will change and each new system that seeks to manage its lifecycle activities with data will naturally have requirements that differ from what has gone before.  Extending models consistently is key to this.

I hope that the IMF work is picking up many of the points that you and the IADD4UK group raised.  I am happy to speak to you directly about it, get your views and share some of the work that is being prepared by the IMF team.  I liked the "engineers" language of your document.  If the IMF doesn't work for engineering (and operations) decisions then that's a large part of the benefit missed.  In my view, you have to engineer your data if you want to engineer with your data!


  • Like 4
Link to comment
Share on other sites

Many thanks @Al_

It was certainly a challenge to get all these organisations together and then to start agreeing commonality between them!

I would really welcome a conversation around this, as i think there are some common statements made by organisations in their business strategies that could be used to create a "starter for 10" to help infrastructure providers start to feel a benefit from business information.

Also, as you mention some way to automate the change detection in executive strategy that would mean the need to report on different information than before.

I am free Tuesday afternoon next week if you are?

best regards



Link to comment
Share on other sites

  • Create New...