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.
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!
Dr. Michael Jastram is Systems Engineer with a focus on requirements modeling. He is founder and project lead of the Eclipse Requirements Modeling Frameworks, an open source project for requirements modeling and the reference implementation of the open ReqIF standard. As an advocate for openness, he shares his knowledge via books, articles, talks and even organizer, as well via his weekly German blog System Engineering Trends and his monthly English Formal Mind Blog. Michael has 20 years of professional experience, including ten years in the USA, where he acquired a Master’s degree at M.I.T. and worked as a software engineer and architect in various start-ups. He is founder of the Düsseldorf Java User Group (rheinjug e.V.). Today he is general manager of Formal Mind GmbH and operates ReqIF.academy, an on-line library for requirements exchange knowledge. He further supports Jama Software as Senior Solutions Architect.
Has the software world already forgotten about SA, OOA, etc.?
Lee,
No, the software world has not forgotten – large parts have not yet discovered SA and OOA in the first place. IMHO this applies more to systems engineering than software engineering, however.
If your company is already creating analysis models of the requirements, where’s the benefit? IOW, people have been modeling requirements for 20 years. Is RMF a linkage between EMF and ReqIF, or are we inserting yet another model?
Lee,
You guessed right: RMF is based on EMF and thereby provides interoperability. In fact, there is a generic EMF traceability plugin, that was developed by the openETCS research project.
In a sense it is “just another model”. And not very special at that. But: It is currently being added to almost every serious RE-tool in the market. We never had that level of interoperability before. That’s what makes it special.
Jordi,
apologies, for always bringing back the same topic (state), but requirements should be defined as “problem statements”. In particular they should never express what a system should do (as actions) but what state/outcome should be reached.
A problem is a missing transition between two states, or an unwanted transition from a high value state to a low value state.
Actions belong to the solution definition, and should be defined in relation to specific problem statements/definition.
This is important because the “hierarchical” requirement structure is vastly unnatural (i.e. makes no sense at all). Why would that structure be hierarchical? Just because hierarchies are the default structure when we cannot come up with one?
Actions and states are connected in a graph, which is a much more natural structure, and far easier to manage compared to hierarchies.
http://www.ebpml.org/blog2/index.php/2013/04/26/reinventing-agile-from-value-to
JJ,
I completely agree that requirements should describe problems, not solutions. And thanks for your link – it reminded me of the work of Jackson (Problem Frames) and van Lamsweerde (KAOS), which you probably know.
But if you take your ideas to industries like automotive or telecommunications, they laugh at you – the quantum leap from the status quo is just too large. Also, at the end of the day, these users still want a printout that they can decorate with a real signature – hence the desire for those linear, hierarchical structures.
I was trying to express this sentiment: ReqIF is a huge step forward, as it gained industry acceptance: All big industry tools support it (or claim to do so). This paves the way for little steps that industry can digest, instead of a quantum leap that is rejected outright.
The ReqIF “model” itself is not impressive at all. But we now have interoperability, and we already used this in practice to prepare an incremental path to real modeling for our customers.
+1 to hierarchy statement on requirements.
For me the particularly hard part of ReqIF metamodel has been that SpecHierarchy is expected to refer to one SpecObject only. Perhaps this makes sense for serialization in XML but looks unnatural from pure requirements management point of view.
Juha-Pekka,
> but looks unnatural from pure requirements management point of view.
I think that the scenario for using ReqIF as a data model had just not been considered. We can consider ourselves lucky that we can have at least multiple references to the same SpecObject: Considering that DOORS compatibility was a major driver behind RIF/ReqIF, this is not to be taken for granted, as DOORS does not support it.
We’re experimenting with synchronizing trees of SpecHirarchies, as part of a reuse strategy, but this is more of a hack on top of ReqIF than anything else. 🙂
Michael,
I appreciate the hard work put behind RefIF, but it’s hard for me to function in a context such as that one: “the quantum leap from the status quo is just too large”.
I also appreciate the difficulty in beating the status quo and it appears to me that our industry shifts away from the status quo when hype is at his highest, and reflection is at its lowest, which often leads to NoXXX movements, agile being a “No Requirements” movement, which other people might see as: just-in-time-for-coding requirements.
With all that being said, I cannot support an approach “I deliver X because this is what people asked for”. For an industry connected to high tech, software is actually one of the most conservative and retrograde industries of all, where the nostalgia of returning to the origins (of what-was-taught-in-shcools) always beats the inspiration of progress.