Data Management Requirement Lists

Learn more about the DMRL and how we create them

Check-out our online learning portal

Data Management Requirement Lists

The S1000D DMRL is a fundamental building block of a successful S1000D project.

Whether you refer to the DMRL as the Data Management Requirement List(s), the Data Module Requirement List(s) or some other strange acronym I’ve heard on the circuit. The role is the same, an essential component to project scope and expectation management for the supply and customer chain.

The DMRL is for many projects, organic.

By this, I mean that the project has a good idea upfront what content needs to be defined and developed, but due to the nature of the product and information plan, the DMRL will likely change. So it grows or shrinks in line with product development or new and emerging customer demands.

The DMRL protects us from he-said-she-said

A clear DMRL scoping the S100D requirement protects us all from scope creep and he-said-she-said.

DMRL definition even if only partial is vital for the tech pubs team to have a clear vision and goal. I’ve seen many a project think that the idea is to get going on module creation as quickly as possible, which is typical for most tech pubs teams. The content of a DMRL must still be explicit and agreed.

Often when it comes to a DMRL creation task, we are faced with the issue of not having all of the necessary information at hand and therefore, we skip the job and get down to writing. Yet we are expected to deliver a DMRL for authorisation or agreement before contract award or project kick-off.

When I am advising clients facing this typical situation, I show them how I define a DMRL for a typical project and what to do if the full project definitions are still to be determined. My methods get us on a clear vision path to DMRL creation and project scoping even if our codification rules are yet undefined.

We can then deliver the DMRL in a way that the authorisation team (often non-tech pubs or indeed XML people) can review and agree, they do not want to be delivered an XML structure that means nothing to them and is full of detail that is irrelevant.

Getting the DMRL defined, produced and agreed upfront would save a tremendous amount of pain, argument and unnecessary delay.

Anyone who has done my classroom course will know the example I use on poor DMRL definition only identified when a platform had a failure while on an operation.

Watch the full 50-minute tutorial on our portal, where I show you the tools and processes I go through when scoping an S1000D requirement building up to an S1000D DMRL ready for CSDB import.