Bloggo back to the blog
Johan Zandhuis’ Response to Fiona Charles’: Requirements suck? Get over it!-->
We recently published a video that was recorded at the 2012 EuroSTAR Conference during a 5 minute Soap-Box session. In the video Fiona Charles discusses ‘Requirements suck? Get over it!’ You can watch the video below or here.
Johan Zandhuis doesn’t agree and here is his response to the video:
‘Requirements suck? Get over it!’ … No, go get them!
Last week the video ‘Requirements suck – get over it’ by Fiona Charles was published. Always a good thing, when experienced people pour out their heart and soul to give their vision of reality and share their experiences with what does and doesn’t work in practice. But the video triggered something in me so intensely that I had to respond to it. Hence this blog.
A quick summary of what I get from the film is: ‘Just give that requirements rubbish up and, as a tester, go and get your information yourself so you can test properly’. My summarised response: Sorry Mrs Charles, but I don’t agree with you. Maybe you’ve landed flat on your face too many times already when it comes to requirements but I haven’t got that far yet. With giving requirements up that is.
Why don’t I give up? I don’t give up because I believe that when developing software systems we should utilise the proven methods and techniques better. Methods and techniques that do work in other disciplines, like the construction of bridges, roads, nuclear power stations, airplanes and other complex things. Techniques that, if known and used, do raise the right questions. Questions that you then pose to stakeholders, product owners or users, and answers are elicited before you start making something.
It has to be improved, because ICT is slowly being forgiven for everything. And slowly but surely mistakes in ICT developments are becoming directly visible in end products, products that used to work fine without ICT. Great bridge, but if the ICT governance doesn’t work properly, the bridge can’t be used. Great plane, but errors in the software, so no flying. Today, once again, I had to ‘reset’ my car on the hard shoulder because the telephone’s hands-free function suddenly ceased.
As an example of proven methods and techniques, I take the so-called system context diagram. A wonderful aid to clarify what your system development route is all about, which systems you will or won’t include in its scope and what you actually define under ‘the system’. A very simple scheme, a child could make one. A very legible scheme too, you immediately see which conceptual errors have been made when someone is talking about ‘the system’. Why then is such a simple sketch almost always structurally lacking in project proposals concerning ICT? Is it because it cannot be applied or is it because we have insufficient understanding in order to apply it? I am convinced it’s the latter, that insufficient understanding is the cause. Then we shouldn’t only give training and discuss it, we have to just do it!
I do agree with Mrs Charles on one point. “As a tester, sit round a table to discover the testable-information- on- how -the-system-should-work”, is a message that I wholeheartedly endorse. But then with the addition: “…and get that ‘tester’ to expressly, and particularly, share that information with the rest of the team. And do that before and during development, don’t wait until it’s finished.” Now, I do find testable-information- on- how -the -system-should-work a bit of a mouthful, so can I also call that ‘requirements’? And may I simply call the tester in that role a ‘requirements analyst’? And have I then not got a single approach that basically boils down to the fact that as a tester you should also be able to establish requirements and that as requirements analyst you must also be able to make test cases? It is for this reason we long since train all our employees in testing, and explicitly in requirements techniques, and we see the results in practice. It doesn’t happen in one day, not from ‘requirements suck’ to ‘perfect requirements’ (that actually don’t even exist, but that’s another story); but increasingly better and with fewer repairs.
In short, I’m sorry Mrs Charles that you have since tired of battling with requirements and have chosen a different path but I am not giving up yet. Collecting requirements and making them communicable is a job in itself and you have to accept that it’s simply part of system development. That still isn’t standard practice in ICT but it should be. Just like it’s normal to look before you cross the road. Requirements suck, so go get them!
You will find the video ‘Requirements suck – get over it’ below.
Do you agree with Fiona or Johan? Or do you have different thoughts completely on requirements?
Blog post by Johan Zandhuis.
Before his career in IT Johan Zandhuis worked in a production environment. There he was responsible for planning, logistics, IT, work study and quality management. Then he decided to focus on quality management, especially in IT. He is currently working as product manager at SYSQA, www.sysqa.nl (Dutch) www.sysqa.com (English). SYSQA is a firm specialised in quality management in IT. Johan coaches organisations and individuals on the following topics: requirements, IT commissioning, process improvement, quality assurance in projects, CMMI, testing and information management. What drives him: make IT work! He is (co-)author of several publications, amongst which there is ‘Succes met de requirements!’ and ‘Succes met opdrachtgeverschap!'(both in Dutch). You can find him on Twitter @JohanZandhuis or send an email to [email protected]