Can you model requirements?

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

As much as we all like modeling (why else would you read this blog?), requirements won’t go away any time soon, especially the kind written in prose: All stakeholders understand them (or can pretend to do so), and they can be jotted down quickly. SysML acknowledged the need for requirements by including them as a first-class citizen.

But look at industry, especially where safety-critical systems are developed, like cars or trains.  Requirements tools like IBM Rational DOORS or PTC Integrity are prevalent. Why? I think there are a few reasons.  First, requirements are still reviewed in a linear fashion, especially for reviews. They like the document metaphor.  They also like to include all kinds of information: Notes, pictures, etc, – some requirements, some not.  It is also not unusual for a supplier in the car industry to receive tens of thousands requirements from the manufacturer.  SysML requirements have not been designed for this scale.

Taking this into account, it is not surprising that OMG, the body that standardized SysML, published another standards a few years back, theRequirements Interchange Format (ReqIF).  While it was initially designed just for the lossless exchange of requirements, it has been recognized as a great way for modeling requirements as well.

ReqIF is actually quite simple: It consists of a hierarchical requirements structure.  The requirements can have an arbitrary number of named attributes, using a simple type system that includes plain text, formatted text, enumerations and some more.  And it supports traces between the requirements.  The traces can also have an arbitrary number of attributes.

Even though it is simple, it hits the sweet spot between completely unstructured requirements and pure requirements modeling.  In fact, all serious requirements tools now support data import and export as ReqIF.  This is a huge argument for organizations with an existing tool infrastructure: They can continue using their tools, but add new ones that previously had no interoperability.  This opens the door for a tighter integration of requirements within system engineering environments.

With the Eclipse Requirements Modelilng Framework (RMF), there is also an open source reference implementation of ReqIF available, which has been around for a few years now (please g+1 us on the top of that page!). As it is part of the Eclipse ecosystem, RMF has been used to demonstrate how seamless model integration can be realized with other Eclipse-based modeling tools like Papyrus or Rodin.  The following screenshot shows the integration of an Event-B (Rodin) model, with color highlighting and tracing into the model.

Integration of requirements models

I can already hear the objections: “What about OLSC? Hasn’t it been designed for exactly this purpose?” Yes, it has, but based on a very different approach.  OSLC assumes a loosely coupled environment, where data is made available through services.  ReqIF works better in a file-based environment. There are organizations that like to put their artifacts in a repository like Subversion and git, and ReqIF is well-suited for this.  Also, it allows asynchronous exchange across long distances, without a data connection.

To sum it up: Yes, requirements can be modeled, and there is more than one modeling language to do so.  ReqIF may not be the most sophisticated one, but it has industry acceptance, a solid open source reference implementation, and it provides interoperability with many commercial requirements tools.  Please check it out!

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
  1. Lee Riemenschneider
    • Michael Jastram
      • Lee Riemenschneider
        • Michael Jastram
  2. JJ Dubray
    • Michael Jastram
    • Juha-Pekka Tolvanen
      • Michael Jastram
  3. JJ


Your email address will not be published. Required fields are marked *