When I first started working at ArgonDigital, I worked extensively on editing our book, Visual Models for Software Requirements. Because of this, I knew the models inside and out and could tell you the “by the book” way to create and derive requirements from any of the 22 models in the book.
However, when I started working on more and more projects, I made an important discovery; the RML® models are not law written by God himself. They are, instead, guidelines or a toolbox, you might say. They give you the framework to document business needs and to derive meaningful requirements, but the “by the book” method of creating and maintaining various models that show different sides of the same information may not be applicable to every project’s needs.
After I discovered this, I started relying on and using, what I’m terming, “hybrid models.” These are models that take elements from several of the RML® models to more effectively get a point across. For example, when documenting existing features of an online system, I found myself integrating Process Flows with UI Flows, because you can’t document existing functionality of an online system without some aspect of UI or navigation infiltrating. On these same hybrid models, I found myself integrating aspects of Decision Trees with Process Flows- where instead of a yes/no decision commonly found in Process Flows, I was having one decision with up to eight choices to make the flow more readable. And all of this because my stakeholders were very busy and wanted one model that would show them all of the existing functionality for a given process.
These hybrid Process Flows, Decision Trees and UI Flows also helped to condense the final BRD because, for each section, we could show one model (albeit dense and completely violating the 7+/- 2 rule) to show the existing features before diving into the new features and requirements.
Alternatively, I’ve also found myself (and some of my coworkers too!) using a model for something not quite what it was intended for, and thus, creating a new model entirely. For example, one of my coworkers recently created a “calculation tree,” which uses the same shapes as a Process Flow, but instead traces calculations through a spreadsheet. I’ve also dubbed “content trees,” which look like Feature Trees, but show content to be migrated/ archived to help with testing after a migration to a new system or application.
So, what’s the point? You probably already know that the RML® models are not the end all, say all in visual models. But the point is this; it doesn’t really matter the methodology or “language” you are using to model business requirements, none will anticipate and address every possible need that might arise on a project. Thus, it is better to learn what you can from any methodology, adapt it to new situations and not be afraid of trying something new if it will get a point across more efficiently, or just make your customers/ stakeholders happier. It took me a while to realize this, as I was resistant to do anything that wasn’t strictly in the RML® methodology; but, once I got away from that, the true potential of visual models opened up and made me realize that really anything can be conveyed through models.
