Suppose you are a business analysis trying to discover the local government’s requirements for clearing snow from roads and footpaths. You ask the road-engineering supervisor for his requirements and he tells you, “We want more staff dedicated to snow clearance”.
But is that really the requirement? It sounds more like a solution, but you cannot be sure of the problem. When you ask, “Why do you need more staff?” the supervisor tells you that, when the conditions are extreme there are not enough people to shovel the snow and spread salt and gravel on the sidewalks. Now the real problem starts to emerge – you now understand that under certain snow conditions, sidewalks have to be made safe for people to walk on within a short period of time. One way – the supervisor’s way – of solving the problem is to have more people to shovel the snow. However, now that you understand the problem – clearing the sidewalks – there must be other solutions to choose from.
Instead of using manual shovels perhaps a few small mechanical snow shifters (rather like lawn mowers for snow) could be used to clear the sidewalk with less person power. Or, if you were in Iceland, you could take advantage of the copious geo-thermal energy and install heating pipes under the sidewalks to melt the snow. Perhaps you could farm the problem out to the neighbourhood kids, and pay per metre of sidewalk cleared (the kids would have to prove they actually did it with before and after smartphone photos). There are so many possibilities that you can come up with providing you understand the problem.
But a clear statement of the problem is not usually what you hear first. Just like the road engineering supervisor, most people are likely to give you their solution, and not state the problem to be solved. So why does this happen?
Naturally enough we all see the world in terms of our own personal, tangible world. We do not, generally speaking, think in abstractions. Instead, we give our attention to the concrete things that we can see, touch and hear – things that are real for our view of the world. So when we want to make an improvement to our world, we look at how things work now and ask for some incremental improvement. This, as in the case of the road engineering supervisor, usually results in a solution rather than a statement of the underlying problem. And often it will not be the best solution because the requestor lives in his own world and is probably not aware of other possibilities for solving his problem.
We have heard analysts despair over peoples’ lack of ability to state the real problem, “How can they expect to get a good solution when they don’t tell me their real requirements?” But it’s wiser to face the reality that the stakeholders who have the requirements are not trained analysts and are unlikely to realise, unaided, that they are asking for a solution, not stating the requirement.
Our experience has been that the most effective approach is to accept the fact that people ask for solutions, and then make the abstractions that are necessary to uncover the real problem.
We suggest that you start by accepting whatever the requestor asks for. Don’t discount what they have asked for, and don’t say (out loud) that it is a solution not a requirement. Instead ask, “Why is this important to you?”. Make it clear that you are trying to understand the overall business impact and it’s likely that you will make some mistakes unless you understand how this requirement fits into the overall business.
Sometimes you need to ask why more than once:
Stakeholder: “I need this extra total on the screen”
Analyst: “Why is this important to you?”
Stakeholder: “Because I need to compare the figure with the previous month”
Analyst: “Why do you need to make this comparison?”
Stakeholder: “So that I can identify the best selling product and make sure there is enough stock.”
By asking these why questions the analyst is getting closer to the stakeholder’s real requirement: to be able to monitor the best selling product of the month and ensure that there is enough stock. And once the analyst has this level of understanding she might be able to do much more to help the stakeholder to find and solve the real problem.
Perhaps for this stakeholder it would be more useful to make a progressive daily analysis and projection of which products are selling best and compare these trends with the inventory; the purpose being to raise a stock alert if needed. The stakeholder probably won’t ask for these things because he is limited by how things work at the moment in his world. It takes analytical thinking to look past the perceived constraints and discover the real problem and the opportunities that presents.
One of the components of a Volere atomic requirement is the Rationale – a statement that explains why the requirement is important to the requirer. This justification of the requirement is not only useful to the business stakeholder and the analyst, but is also vital input to making the best development and testing choices.
Unless you know why something is needed, and why it is important, it is very difficult to choose between alternative ways of achieving it.
Taking the idea of rationale further, it is also very valuable to record the rationale for making a particular design decision:
“We considered alternatives A, B and C. We chose B because it will provide the fastest responses given our current systems architecture, and performance requirements are the most critical to this part of the solution.”
Additionally a trail like this is very helpful to the many people who need to maintain the system into the future. Keep in mind that whatever it is that you are building today, it needs to last and be maintained for probably a decade. Without an understanding of why design decisions were made, maintainers could well make changes that have disastrous side effects.
28 november 2017Workshop met BPM-specialist Christian Gijsels over business analyse, modelleren en simuleren met de nieuwste release van Sparx Systems' Enterprise Architect, versie 13.Intensieve cursus waarin alle basisfunctionaliteiten van Enterpris...
20 en 21 maart 2018 We worden al jaren geconfronteerd met een niet-aflatende stroom van nieuwe technologieën, ontwerptechnieken, architecturen en ideeën, zoals Hadoop, streaming, self-service data preparation, logical datawarehouse, data lake, de...
27 maart 2018 Wat zijn de mogelijkheden van low code application platformen en hoe kunt u deze succesvol inzetten in uw organisatie? Aan de hand van Microsoft PowerApps, Flow en de Common Data Service wordt besproken maar vooral ook live getoond hoe ...
10 april 2018 API Management gaat enerzijds over het promoten van API’s en anderzijds over het actief ondersteunen van ontwikkelaars bij het gebruik ervan. Tegelijkertijd gaat API Management over het gecontroleerd en centraal beveiligd ont...
11 april 2018Praktisch seminar waarin Sander Hoogendoorn u laat zien hoe u microservices kunt inzetten in uw softwarearchitectuur.Het nieuwste architectuurprincipe microservices lijkt veelbelovend: verkorte time-to-market, schaalbaarheid, autono...
17 mei 2018 Iedere organisatie heeft te maken met het integreren van systemen en applicaties. Maar welke technologie zet u in bij welke vorm van integratie? Guy Crets bespreekt de verschillende oplossingen voor integratie. Integratie van IT-sys...
30 en 31 mei 2018 Praktische tweedaagse workshop met internationaal gerenommeerde spreker Alec Sharp over herkennen, beschrijven en ontwerpen van business processen. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbruikbare r...
11 t/m 13 juni 2018Driedaagse workshop over requirements management door James Archer. Opstellen, testen en ondubbelzinnig vastleggen van requirements. Unieke driedaagse workshop over requirements management op basis van de Volere methodiek door Jame...