Yesterday, I sat in a presentation about requirements virtualisation. I found this to be a very interesting topic as it again asked questions of how we communicate and how we convey meaning to each other.
The particular presentation that I attended was for a software tool that would allow business people to visualise what a software system would like at the requirements gathering stage of a software product. Another reason that I liked this idea is because, tools like this certainly support design thinking approaches for software development. The value proposition presented for this tool is one of reducing software project failure and increasing requirements coverage of the final solution. The premise is that if the business user is able to see what they are going to get they will better understand the implications and therefore be able to stabilise the requirements before it is handed over to technical people for implementation.
This is certainly not a new approach to the gathering of requirements, and it is also not limited to the IT industry as an approach. Old COBOL based screen design methods asked developers to “layout” there “green screen” on a page with grids, as part of the design process. If you asked a marketing company to build a website for you, the first thing they would do is create a graphic “mock-up” of what it would like for the customer to approve. Tools like Visio and Excel allow you to create screen mock-ups of MS application. Adobe Flash is another tool that can be used for this purpose to great effect.
So, if visualisation is such an effective tool to communicate with each other, why do IT projects not use it all the time? Certainly, the tools for it is readily available.