Should we use SysML Modeling Tools for Requirements Management?
Recently I had an exchange with Fatih Erkan from Philips on the topic of whether SysML tools are suitable for managing requirements. We had a long chat on LinkedIn, followed by a meeting with the Philips MBSE Team (Louis Stroucken, Joshua Shreve, Patric Wender), and thought it would be a good idea to share it with you.
Fatih:
It has been getting closer to 10 years for me to be in the MBSE world now for 3 different domains, and one tooling discussion is popping up everywhere. Should we have a separate requirements management tool, or can we manage requirements in modeling tools like Cameo Systems Modeler, Sparx EA, Rational Rhapsody, etc.? In 3 domains so far, all companies could not decide to drop the requirements management tool from their landscape. I was wondering about your experience and customer knowledge on this. Are companies managing requirements in a modeling tool without a separate requirements management tool like Doors, Polarion, etc.?
Tim:
I think SysML v1 and also SysML v2 are both capable of storing all the necessary information about requirements. The limit is the tools that do not provide all functionality required by the projects, particularly for managing the requirements. However, for some projects, it would be sufficient. For example, the SysML modeling tool Cameo has good features to specify and manage requirements.
So, I think some projects could switch entirely to SysML models and avoid the gap between the tools. But it is also a change project. It is not only about tools. It is also about shifting responsibilities, changing processes, etc., with several involved departments, and so forth.
Fatih:
I tend to agree that it depends on the lifecycle scope of systems engineering and the project surrounding it. I also agree that Cameo seems to be really good in tabling textual requirements and other relevant artifacts – which can supply a similar user experience for the traditional-oriented systems engineers. Test management and risk & reliability aspects make the discussion more complicated in our current case. I’d like to give the word to my colleagues to hear their perceptions.
Louis:
We are being challenged by the managing aspect. Status approvals etc… What is this management according to you, Tim? – It is a difficult thing to explain to the organization.
Tim:
The SysML v1 requirement element has only 3 properties: a name, an identifier, and the requirement text. Using the stereotype extension mechanism, you can add further specific properties to the model element. However, the management of requirements is more about the functionality provided by the tool, which is out of the scope of SysML.
Joshua:
Many tools are based on a relational database. MBSE tools are actually better than many other traditional tools, but supporting the way of working (workflow) is another topic.
Tim:
SysML modeling tools provide functions for modeling with SysML and less support regarding workflows. In the end, it is the question: do I take only the SysML tool for the requirements and have limited functionality, or do I take a dedicated requirements management tool and have the break between two tools, which is not easy to overcome.
Joshua:
Tim, what are the patterns in the MBSE world? Separated or not?
Tim:
There are many different scenarios in real-world projects. A typical scenario is two separate tools, i.e., a requirements management and a SysML modeling tool.
Louis:
How did they solve the challenges?
Tim:
Some solve it by having the tools come from the same vendor, bringing the possibility of integration. However, this is still often limited, but at least you have a contact person to solve the problems. Others use standards such as OSLC.
Louis:
The gap is narrower when they are connected over OSLC.
Fatih:
I agree. How do we see the separation of concerns and capabilities between tools in the tool suites?
Tim:
It makes sense to separate the capabilities.
Patric:
A tool for SysML modeling and requirements management tool for requirements makes sense. However, the combination of them is also valuable.
Tim:
Combining things is not always possible at all. You have to look at what can be modeled meaningfully with SysML. CAD is an example. SysML v2 will support basic geometric modeling, but not the full CAD capabilities.
The first step should be an overall conceptual model for engineering artifacts, i.e. architecture elements, requirements, and so forth. This conceptual model should guide which tool is responsible of the artifact, and how they are linked.
Fatih:
This is the overarching data-model (meta-model) we are working on now in Philips.
Louis:
Exactly, we need this conceptual model before starting to map it to the tool. How do we keep it consistent is the question. Sometimes we are in a trap of just looking at tools, which creates fragility.
Joshua:
Tim, have you seen any good examples working on a single data model guiding bi-directional synch etc.?
Tim:
There are some working examples. However, they are only selective success stories.
Louis:
Do you think our ambitions are too high, Tim?
Tim:
Your ambitions are quite high, but exactly the right ones. From my point of view, working model interoperability is what projects urgently need at the moment.
Standards like ReqIF, XMIs, OSLC etc. are promising, but only a start. We need more tools, and above all, tools that support these standards so that tools can be easily plugged together, regardless of the manufacturer.
Louis:
Is a point-to-point connection making it a bigger problem than practical manual actions for the synch? Without the conceptual model, the point-to-point connection will not help. Should there be a standard guideline for this conceptual model?
Tim:
A standard for engineering concept models would certainly be helpful. The Essence framework goes in this direction. However, it is currently only available for software. However, it could be extended to systems engineering. Another example is the Unified Architecture Framework.
Then our discussion ended, as we had no more time. Regarding content, we could have continued discussing for a long time and will definitely continue our exchange.
