… it could blow up your system or delay your project by several months!
Note: As a tribute to christmas time, this blog-post is the result of the challenging question, if there is a connection between “requirements engineering” and “xmas“.
It is!
You want to know why?
Read about a system with an interesting requirements weakness and the resulting effects below:
The Challenge:
The story happened in Denmark some years ago, after the new Electronic Land Registry system “e-LR” had been launched, designated to become the only way to register land ownership, all online via web-interface.
However, around 30% of the registration cases were planned to be selected for manual checking.
So far, so good.
Requirements had been collected before, roles been identified and usage assumptions and scenarios for interaction of the users – citizens, real-estate agents, lawyers or governmental employees – defined. In the backend the system should be integrated to several governmental systems, e.g. for ID check, tax or land registry.
Deployment scheduled for spring 2008. Tender material had been prepared, RfQ’s sent out, suppliers selected, work started. In parallel legacy documents were scanned and employees and other ressources scheduled for the assumed new business scenarios.
The Problem:
However, development took much more effort than planned, time doubled and costs increased by 40%. To not lose more time, eventually the system was launched in fall 2009 – in a big-bang approach, overnight, without pilot testing in advance.
What happened?
From technical point of view, everything worked as specified, 70% of the land registration – the purely online ones – indeed could be executed within a minute. But the 30% other ones quickly piled up to over 50000 (!) cases in the land registry office – all to be handled by that (reduced) team of employees and checked manually.
This extreme overload was completely unexpected. It caused delays of up to 2 months to get your land registration confirmed – which caused huge financial stress e.g. for a young family who wanted to build a house!
The Investigation:
As a consequence of this an investigation was initiated afterwards. It identified several reasons that contributed to the huge overload. Besides the already mentioned big-bang launch without sufficient testing being, several more reasons were identified.
Two of them were based on significant weaknesses in the usability of the system. Agents and lawyers simply often didn’t understand the interface, what should be entered and what their interaction would cause in the background-processes.
It is quite obvious, that all this development of a complex land registry system and its usability has a lot to do with proper requirement engineering and specification.
Now, what does it have to do with “xmas“, the 2nd keyword in our intro question?
Here comes the answer:
The Relation to Christmas:
During the investigation the real-estate agents and the lawyers reported, that sometimes they had absolutely no idea, why a certain case had been picked for manual checking.
And mystically, the number of these manual-case selections increased when time approached Xmas.
What was the root cause and the dependency behind this this strange effect?
After closely examining and backtracking certain scenarios, it turned out, that when some clients wanted to send their personal season’s greetings to the service staff at the registry office, they found a way to do precisely that:
They found a field “message to the registry staff” in the web-interface and here they typed in their “Merry Xmas”-message.
What they didn’t know: to allow the service guys to really see the incoming message on their screen, they interactively had to classify this particular issue as case for manual checking – and thereby automatically and implicitely put another case onto the pile of work on the desk of their colleagues!
None of the two parties, neither the sender nor the receiver of the xmas-greeting was aware of this effect.
But this friendly intention of the xmas-greeting-senders made the difference between having your application in the 70% automatically processed cases, that were confirmed within 1 minute and the 30% manual cases taking up several months of processing time!
Lessons Learned:
When specifying your system, …
- don’t underestimate the importance of a good risk analysis,
- don’t forget to consider user performance and organizational processes in the requirement specification
- and take care to express clearly what shall be developped — well-structured, unambiguously, testable and complete!
Having said that …
… merry christmas and a happy new year to all our readers!! ! 😉
Read the full investigation story here:
“Why the Electronic Land Registry Failed“,
by Soren Lauesen, IT University of Copenhagen, Denmark;
in:
Requirements Engineering: Foundation for Software Quality :
18th International Working Conference,
