Featured field and capability
Linked Data
Model-Based Systems Engineering
Featured industry
Services
Featured case
Data Libraries
In 2011 an article in the Dutch OTAR Magazine titled ‘Explicitly specifying: from requirement text to model’* explained (in Dutch) how textual requirements can be transformed into computer-interpretable specifications for the development and maintenance of physical assets, like infrastructure and buildings. Many companies were transferring from text files to Requirements Management Software (RMS) back then. Today, eight years later, we see more ambitious topics like Predictive Maintenance, Building Information Modelling (BIM), and Artificial Intelligence (AI), all demanding leaving text-based ways of working behind and supplying software with more intelligent and processable content.
Owner-operators, contractors, and manufacturers need to make their data suitable for computers to process to realize their ambitions. Requirements need to become reusable and extendable in multiplicity in different RMS tools from different software suppliers for various types of use. Requirements must be transformed from textual prose into explicit requirements, structured data, fit for purpose, interpretable, and interoperable by computers.
When transforming textual requirements into structured data, there are a couple of criteria to consider. There is a scale of explicitness when making libraries of requirements. This scale evolves from a bit of interpretability by software to a lot, depending on the need for automation in a use case (see Figures 1 and 2). Making requirements unambiguous is not enough to make data interpretable by software. A prescribed semantic standard is needed to express concepts like ‘requirement,’ ‘text,’ ‘characteristic,’ ‘unit of measure’ and the interdependencies between these ‘building blocks’ in a manner that both software developers and the community that will use the standard will understand and agree upon.
Second, the format in which requirements will be read and written by software needs to be flexible enough to express any meaning requirements could address and extendable to cope with future changes and additions for new and different types of use.
The level of explicitness should fit the level of automation that is desired. Some use cases concern only explicit text parts and coherence with single subjects and maybe verification methods. The requirements must be explicit in these basic use cases to be distributed across RMS tools. The texts must comply with implicit rules like “use a single subject in the text and only a measurable qualification or quantity” (like the ‘text part’ level in Figure 1 and level of automation 3 in Figure 2). Implicit methods for formulating requirements are countless (examples**).
But on the other side of the scale are explicit qualitative and quantitative characteristics and metadata on how software should read or write a date or number, for instance. When the use case expects the software to do all sort of reasoning, for instance, to verify if a design complies with a contract automatically, then textual requirements with an explicit subject is not good enough. The software needs to know what (for instance) ‘a length’ is and whether ‘the length of this beam 1001’ is within predefined boundaries, expressed in decimal numbers (see Figures 1 and 2). The chosen semantics for a lesser automated use case may never block a future use case requiring more ambitious automation.
A challenge with the often-used format XML (or, to be more precise, XML schema, called XSD) is that it lacks flexibility and scalability. XML uses tags and structure to imply interdependencies between building blocks like ‘requirement’ and ‘text’ but doesn’t make these explicit. This makes XML less suitable for reasoning and more cumbersome to implement because software developers require additional agreements on implementation. This is not desirable when we consider Predictive Maintenance, BIM, and AI ambitions.
The format currently adopted in industries like; infrastructure, construction, and aerospace are RDF (Resource Description Framework). RDF allows storing and accessing requirements in an Open Standard (that overcomes the limitations of XML/XSD). Instead of XML/XSD, in which the data structure implies meaning, RDF makes this meaning explicit. RDF offers just one simple structure in which data can be read or written by software: namely, a three ‘columns’ structure of object-relation-object. Consequently, no additional agreements are necessary between software developers on interpreting data structure; interdependencies are made explicit (meaningful), which benefits reasoning, and building blocks are easily extendable.
A major advantage of RDF as a format is the ability to link building blocks just as webpages can be linked (think of content on Wikipedia referring from page to page). Users can now align standards by linking entire datasets, which we call Specification Libraries (SPLs). For example, a national standard can refer explicitly to an international standard regarding requirements for a road, building, or marine vessel. Linked Data can be queried as one coherent whole (see Figure 3). Using Linked Data, our clients no longer have to manage requirements in a single overcomplex siloed database but can manage different SPLs as a coherent whole and align their own SPLs to other standards in their ecosystem.
Appropriate standards can be found in ISO’s standards for data interchange, European (like CEN) and national standards (like NEN in the Netherlands), and Open and free-of-charge solutions. In conclusion: creating and managing requirements is not easy. It requires both understanding of the domain as well as a deep understanding of Information Technology (IT). Unfortunately, standardization programs are organized top-down, which takes time and leads too often too rigid solutions that lack scalability. But with Open Standards for semantics and interoperability (Linked Data), it is feasible for companies, teams, or even individuals to create, manage and publish requirement standards of their own now that the technology becomes available and the need for useable data grows. Everyone can now become a publisher of his or her own Specification Library. And a successful one if the criteria that make an SPL fit for purpose are considered.
