Necessity is the mother of all invention, the cliche goes, and requirements modelling is no exception. Creating ad-hoc color coding within models to effectively communicate within a project team can save time and prevent confusion.
As part of our Seilevel methodology, we use skittles, or color-coded dots, to convey the extra layers of information as part of our standard models. Color-coding can also be as simple as changing the color of a connecting line or the color of a box in a system flow.
RML models are adaptable to specific project environments, and open to iteration and creativity. In my project experience, I have adapted models to broadcast requirements status, layer different types of models on top of each other, and communicate scope or release date.
Status Reporting with Models
The obvious answer to communicate status within requirements models is stop-light color coding. On my current project, I am responsible for a great deal of interface requirements. We have a large set of system flows, and I have color coded the arrows to communicate interface requirements readiness. Green interfaces are ready for development, yellow are pending analysis, and red are blocked requirements. It sounds simple, but this system of communication has saved countless email threads and status meetings.
While data models are natural candidates for such status reporting, get creative with other types of models. Color coding could be used as a simple proxy for business priority on the business objectives models. Process flows and UI flows can also follow the same interface status format.
Layer Information from Other Models
In addition to communicating status, I have created models with additional information layered on top, essentially combining two types of models. Color-coding works well for this, for instance communicating which people or teams own systems on an ecosystem map.
In my own experience, I have combined data dictionaries and system interface tables to create detailed interface mapping requirements. This type of combination is particularly useful in the areas between larger groups of models (People and Systems, Data and Systems, etc.)
Communicate Scope and Release
Adding scope and timelines to existing models can help tell a richer requirements story. Feature Trees lend themselves nicely to such information. In a complete Feature Tree, some features must be identified as Minimum Viable Product and some can be deferred to a later release.
A complete Ecosystem Map is also a great candidate for communicating scope using color codes. In a complex ecosystem, a particular set of features will be impacted in a project and some will be completely out of scope.