When it comes to requirements “communication” is the name of the game. An analyst could crank out top-notch technical documents or business cases, but if their intended audience isn’t able to consume it then ultimately the work was for naught. It’s to this end that we use things like visual models to help get the point across that is separate from a system shall statement or a user story; so that our consumers can truly consume and then deliver.
However, there are small bits of information that can often go unknown, or unconsidered, because it doesn’t necessarily have a place in a model, or is not important enough to truly highlight, but rather mention in a model. Additionally, there are little tricks that can be used if you’re utilizing models in elicitation session in order to discover missing information.
Below is an example of a typical dimension of information being added to a model through a callout:
As you can see the information for the pre-population of billing information into shipping information is additional information that would otherwise make the model too complex/distract from the business process that is attempting to be communicated. This is just a typical callout, however. There are a few ways we can add additional dimensions to our models through text, color, and shapes.
Here we have an L2 system flow from that L1 we had earlier. It’s a typical process for submitting an order. However, the analyst doesn’t know what the name of the Order System is. The analyst could simply make a note of it in their issues list, and bring it up when they have time to comb through the list, but it may work better to get it finished in elicitation. Showing this model to a stakeholder it’s very easy to notice the yellow highlighting and the callout text accompanying it, and the question can be addressed right then and there.
If you stick the standard red, green, yellow associations that people typically have (i.e. yellow meaning caution/observance, red meaning stop or bad, and green meaning good or go) those colors can be used to communicated dimensions of questions you have on a model. In the above example of the Order System swimlane is colored yellow, as it is not necessarily critical to name, but needs to be observed and considered. Juxtapose that with the red step of 5.3 where the current state/future state consideration is so pressing that it must utilize red. This is useful, but if abused you can end up distancing yourself from who you are communicating with, so it should be used cautiously.
When you’re thinking outside the box there can be many other ways to call attention to specific details of a model in order to address them in requirements or use them in elicitation. Most recently, a colleague was working on a project that involved a large mix of features being requested by several companies that were merging with a customer. In order to demonstrate the various capabilities being requested/needed for each acquisition she utilized what has been dubbed “skittles” within her flows and UI maps.
Here we can see an example of a possible acquisition flow where each company’s capabilities are marked on the process steps through use of the skittles. These chiclets are good for specifying certain detail as well as tacking on another dimension of traceability such that each step must be analyzed for the capabilities of each company.
Communication extra dimensions of information can be accomplished in a lot of different ways, and is certainly not restricted to the methods I’ve listed here. In fact, any method of communication that ends up working best for everyone involved in a project, even if that means breaking from the status quo, is the best way. At the end of the day everyone just needs to understand each other, and small things can make all the difference between “huh?” and “oh!”
