Adapting SW Requirements Visualization to MBSE

October 25, 2011

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.


SAC 21 Workshop: What was right, what was wrong, and what was missing.

June 12, 2009

Now I know the answer to the question of what will it take for me to actually start writing in this blog.  Now I need to figure out how WordPress works.  In the meantime, here’s a really long post.

On June 8th I attended the Software Architecture Challenges for the 21st Century workshop (http://csse.usc.edu/csse/event/2009/Arch-Workshop/pages/program.html) held at the University of Southern California.  The IEEE Software blog (http://www2.computer.org/portal/web/computingnow/sac21) described the event this way:

“Members of IEEE Software’s editorial board and faculty from USC’s Center for Systems and Software Engineering and the University of California, Irvine’s (UCI’s) Institute for Software Research came together for a wide-ranging discussion of the role and value of architecture in software development in the age of grid, cloud, Web, and volunteer computing.”

On the three hour drive home from USC I decided that I wanted to say something about the workshop.  The more I thought about it, the more I realized I had a lot to say about what I liked and where I saw room for improvement.

What Was Right

There was a reasonably large group split between academicians and practitioners.

In general, the speakers were erudite and articulate and the event was relatively information dense.  Thankfully, there were differing opinions on several topics so we got a chance to consider the different viewpoints.

Several speakers made the point that agile software development does not mean don’t do or have architecture.  Philippe Kruchten made the point that he was both an architect and a co-founder of Agile Vancouver.  That was especially interesting to me as I was teaching both  an architecture class and an agile software development class in the spring quarter at UCSD Extension.  My experience has been that requirements and architecture provide the necessary foundation and context for agile software development to be effective.

I am especially indebted to Kruchten for his point about two different kinds of architects – Architectus Reloadus and Architectus Oryzus.  I have explored that topic in more detail already, reading Martin Fowler’s IEEE Software article – “Who Needs an Architect?” (http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf) and going through a set of comments on that article from Venkat Subramaniam’s students at the University of Houston (http://www2.cs.uh.edu/~svenkat/fall2006SE/yousaid/yourcommentsonwhoneedsanarchitect.html).

What Was Wrong

SAC 21 wasn’t really a workshop, it was more like a mini-conference.  What was missing was sufficient time for discussion and serious interaction between the attendees and the hosts/presenters.

In talking about UML, many of the presenters focused on the documentation aspects of UML.  Grady Booch went so far as to state that he threw away some UML diagrams.  Andre Van der Hoek presented a tool that was intended to capture whiteboard style sketches.  In the first case, one must (might?) assume that there was value in creating the UML that was discarded.  Just as people learn differently, so some people design differently.  For one, text and table might be sufficient.  For others, visualization is the key to understanding.  UML provides the syntax and semantics necessary for such visualization.

Once understanding has been achieved, it is reasonable to limit the maintained documentation to summary level descriptions.  I would argue that rather than throw away the rest of the model, it should be maintained in a CM repository for possible future use.  On the other hand, I often create a robustness analysis diagram as a preliminary design step.  Once we have created the diagram, we have developed sufficient confidence in our understanding of that part of the problem, and the diagram can be discarded.  The value of the diagram is in the creation.

One participant asked a question about executable architectures.  The question was answered as if it was regarding executable UML.  There is a significant difference between the two.  Executable architecture (aka simulation) is a technique that supports early system verification and validation.  To the extent that the execution can be tightly coupled to the architecture models, then we can avoid translation errors in developing the simulation.  There is significant value in avoiding such errors in complex system development (think FCS combat vehicle http://www.globalsecurity.org/military/systems/ground/fcs-mgv.htm).

Executable UML (http://en.wikipedia.org/wiki/Executable_UML) offers an opportunity to do model-based development, with transformation of the Platform Independent Model to the implementation model.  As it is explained in the Wikipedia article, xUML does have a limited scope, unlike executable architecture.

What Was Missing

The most glaring omission was methodology.  Philippe had one slide on the topic that didn’t say much.  Others ignored the topic.  This is possibly the most crucial aspect of what architects need – a method like the Visual Architecting Process from Bredemeyer Consulting.  I recommend the article “Less is More with Minimalist Architecture” by Ruth Malan and Dana Bredemeyer, published in IEEE’s IT Professional, September/October 2002, as well as the VAP.

Systems Architecting!  Software Architecture can no longer be considered as a specialty engineering element to be addressed after the systems engineering has been completed.  I totally agree with Mark Maier (http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?r=1&ISBN=9781420079135&ourl=The-Art-of-Systems-Architecting-Third-Edition%2FMark-W-Maier) when he says that architecting of software must begin early, before the system architecting is complete.  USC needs to lead in this area.  They are, after all, the Center for SYSTEMS and Software Engineering, offer an MS in System Architecture (http://www.usc.edu/dept/publications/cat2006/schools/engineering/systems_architecture.html#masters), and are leaders in the Systems Engineering Research Center.

  • During his presentation, Booch mentioned a satellite system that he is working on where software architecture has been negatively impacted by systems decisions regarding the number of processors made before the software architects got involved.
  • One systems engineer attendee asked the same question several times – how long does the software architecture last?  The answers he got were a little non-specific (e.g as long as the system lasts).  One of my colleagues suggested that perhaps the answer should have been another question – how long does the system architecture last?
  • The Software Engineering Institute (http://www.sei.cmu.edu) has recognized the need to expand their focus.  They invited John Zachman and Mark Maier to offer their perspectives on Enterprise and System architecting respectively, at the 2009 SEI Architecture Users Network conference (http://www.sei.cmu.edu/architecture/saturn/2009/).  The theme of SATURN 2009 was “architecture at all scales.”

What Now?

The time has come for a holistic architecting approach.  Software pervades our modern systems and we need to learn how to work concurrently and cooperatively, as effectively and efficiently as possible.  A lofty goal but one I believe is achievable.