I recently finished a nine-month assignment as a Product Manager working with Seilevel to define business requirements for several software projects. Seilevel has an interesting approach to requirements visualization that they call the Requirements Modeling Language (RML®). As I worked with their methodology I started to consider how the role of Product Manager or Business Analyst differed from the role of Requirements Engineer in the systems engineering world. My initial conclusion is that they are very similar. So similar in fact that I have begun to explore a mapping between the RML® diagrams and Unified Modeling Language (UML)/Systems Modeling Language (SysML) diagrams. I will be presenting a tutorial on this topic at the INCOSE San Diego Chapter Mini-Conference on Nov. 18. Here are some of my initial observations:
Advantages of RML®
- The approach is inherently agile. There are many types of diagrams but the descriptions include suggestions for when the requirements modeler should use each of the different diagram types and when they should not.
- Requirements Visualization helps to eliminate ambiguity. A picture is worth a thousand words, especially when the requirements modeler augments the picture with a few words of explanation.
- RML® is not constrained to a requirements modeling language or tool, so it is very flexible.
Disadvantages of RML® in Model Based Systems Engineering (MBSE)
- It is not constrained to a modeling language or tool, so the reader may misunderstand the semantics of the visualization.
- Requirements Traceability is a separate model that can not take advantage of modeling tool capabilities.
Every system architecture or development methodology that I am familiar with (e.g. VAP, OOSEM, INCONIX) all have requirements as an initial input. One of the often stated advantages of SysML was the ability to use models for developing those requirements, but most of the tutorial material seems to emphasize the interface between the modeling tools and the requirements management tools. RML® seems to offer a proven methodology for using models to fulfill the vision of those developing SysML. Future posts will include my thoughts as I work through how to adapt it to MBSE.