Filling the requirements hole

In a previous article I wrote that: “it must be possible to create a product that can capture requirements and detail how they should be fulfilled, which can be understood by both technical and business users, and represents a genuine automation of this process rather than an automation of white-boarding without going to the extremes of a full-blown requirements management system. Such an application probably needs to be based on some sort of flow charting, but just supporting flow charting (you can do that in Visio) won’t be enough.”

What would such a solution look like? It has often been the case, as a comment to my first article indicates, that the approach has been to capture requirements using an approach based upon natural language. In isolation I think this is fine. But requirements don’t live in isolation—they are the basis for new developments—and an approach based on natural language doesn’t easily lend itself to automation. So, I think that natural language is a red herring, at least with the current state of technology: right now, I don’t think that semantic technology is good enough to derive a process flow from natural language.

Why do I think that a flow chart is the key ingredient to requirements specifications? Because I can’t think of any other way to automate the process. Once you’ve got a fully defined process flow (captured in a flow chart) then you should be able to derive all possible paths through the flow, and if you also define the data that needs to be entered/read at each stage in the process flow then you can generate all possible test cases from the data/process flow diagram. Finally, the diagram itself should be expressible using both business and technical terms (separately and together) to enable collaboration and at this level some understanding of semantics may make sense (a business glossary would do as well).

There are some things you would like any such tool to automate. Perhaps the most complex would be to prompt the user for definitions. For example, suppose that a step in your process flow calls for orders to be treated differently depending on whether they were over or under the value of £5,000. Then you would like the software to prompt you for error conditions: what if the value is in dollars and not pounds? What if this is a credit note? What if no value has been entered? Given that no product of the type we are talking about has yet been released this might be a bit much for a first release but this is certainly the sort of automation that will be required eventually. Other requirements would include conversions between business and technical terms, the generation of paths through the process flow, the calculation of probabilities for each path (probably based on some degree of profiling – how many records from the database will flow down each path?), and the generation of test cases.

The other point to bear in mind is that once you have a product like this it’s not limited to development processes but can equally be used for other sorts of decision processes, especially by business users. However, the bottom line is that a single tool that is employed by business users, business analysts, developers and testers would have the potential to bring closer collaboration between all of these users, which in turn should result in fewer bugs and faster delivery of high quality software.