Because incomplete requirements have led to many a failed IT project, it has become an article of faith around the halls of ArgonDigital that visual models must be created before any requirements statements can be drafted. But what happens when you inherit requirements as part of a past project, or in collaboration with another dependent team? Should we just throw them out and start fresh with models and redraft as needed? Oftentimes project constraints limit our flexibility to follow the letter of the requirements law, so what are we left to do?

The answer is: break the rules!

Recently, I found myself in just such a quandary, working with software requirements created for 31 separate teams, all working to describe a different part of the same system. In total, we were asked to verify more than 1200 requirements with little more than a process flow. Under such conditions, I had little choice but to go rogue, and start retrofitting models to requirements.

Why such strict orthodoxy when it comes to requirements order of operations? Well, there is good reason. All too often, ArgonDigital executives had witnessed multi-million dollar IT projects crumble under the weight of missed, incomplete or changing requirements. The solution, they discovered, was simple: When trying to understand requirements, elicit models first.

Eliciting models, not requirements, may seem like an extra step, but we have found again and again that by focusing on creating models that capture the full scope and processes needed by a system’s users, and using these models to gain a shared understanding of a problem the project team is trying to solve, the requirements identify themselves.

If you can look at a process that you know is complete, all that’s left is walking step-by-step, capturing each requirement that enables that step. And because not every model in RML is linear, using a model from each model category (Objectives, People, Systems, and Data) we can be sure that we have considered the problem from every angle.

So what happens when you simply cannot elicit models before requirements? Would you retreat from the problem and cower in utter confusion? NEVER! We do what all good Product Managers and Business Analysts do: Improvise! So when it came time to dis-aggregate all 1200 of those requirements, that’s exactly what I did.

Using the requirements I had inherited, I began extrapolating processes from each requirement. Using actor lists and assumptions I was able to build approximations of the systems involved. After long hours staring into requirements, mapping them to parts of each model, I emerged with a series of Feature Trees (Objectives), Process Flows (People), Ecosystem Maps (Systems), and Data Flow Diagrams (Data). Because each of these models was essentially a well-supported strawman model, I had a solid starting point when meeting with project stakeholders. As we discussed and updated the models, missing, incomplete, and duplicate requirements began presenting themselves.

In this way, I was able to go through each feature section, capture the overall ecosystem and processes therein, and validate not only the models, but also each requirement the models represented. The results were 31 approved Business Requirements Documents with enough models and shared understanding to jump-start the creation of functional requirements.

It remains true that every good rule was made to be broken; so be sure to post comments below about a time when you had to improvise in order to delivery on a project. Its this sort of creativity that informs our best practices and ensures that we are all prepared for whatever we might encounter on the road toward better software.