Some software requirements models just seem to be made for each other, like peanut butter and jelly. Every model has its own merits, but sometimes using them in combination during elicitation and review can break through a project logjam and open pathways for discussion and discovery.

On a recent project, I was documenting a complicated accounting process flow. Understanding this process well was key to project success, but the customer and I struggled through the review process, hampered by specialized vocabulary as well as schedule constraints.

However, once I created a data flow diagram (DFD) and introduced it to the review sessions, something magical happened. While the DFD showed the same high level steps that the process flow illustrated, somehow just seeing the process in this new format, in combination with the data stores, generated an ‘aha!’ response in the customer.

“No, no,” he told me. “You’ve got it all wrong. This process generates that data extract, which feeds this step!” Music to my ears.

Creating models early in the project has advantages and disadvantages. One advantage is that a draft model gives the customer something to critique, something to look at and change. One disadvantage is that once that pretty Visio is drafted and numbered and connected and labeled, it begins to develop inertia. It can be difficult for customers to really evaluate its accuracy because it has such visual authority.

Pairing models, like my DFD and process flow, can shake things up again and help generate new ideas. Some models have rather obvious mates, like a business objectives model paired with a feature tree, or a data flow diagram paired with a business data diagram. Indeed, if you’re creating these model pairs, it is important to ensure that they are consistent with each other. But to generate creative thought and critical feedback, try more unconventional combinations. How about reviewing the org chart and the ecosystem map together? Or perhaps a feature tree with a process flow? What works best for you?