In the first part I wrote about common pitfalls when creating requirements documents. In part 2 I tryed to give an example and describe the outcome should one fall into one or more of the pitfalls.
This final part is based on a speech, I had to give a few months ago. The goal of the speech was to get the listernes to value the points, I’ve written about in my series on Mr. Work, especially the points from The Story of Mr. Work and the Love for UATs
Basically I wanted the audience to experience some of the challenges, that developers and Architects face every day.
Instead of just giving a speech, I decided to take a chance (this was when I was preparring the speec h not some last minute decisions, which would not have work).
I asked one of the listerners (they were 6) to come to my white board and describe Bathroom of his dreams (you know you had dreams about bathrooms, so of cause he’d had them too). He was to describe it in the form of a bullet list.
He wrote stuff like: 2 sinks, a lot of light and spacious. Actually most of the bullets were rather detailed, so I think every one a picture in their mind of a bathroom, that fullfilled that list just nicely.
I had given him a minute and when the time was up, I asked the next guy to draw a blue print of that bathroom. I hadn’t told anybody at the moment but as you might have guessed, that list was going to be my spec analogy later on and the blueprint the architectural documents analogy.
3rd one at the white board was the only woman present and her task was choosing all the elements based on the two previous “documents”. She had to decide what specific sink should be used (brand/model), which tiles, basically all the hardware, or you could call them all the modules for her job was the module design analogy. The last person at the board had to do all the plumbing and wireing.
With those 4 “documents” on the white boards I asked each of the first three, starting with the woman, if the result of the previous stage was as she expected and if not what was different. In the end I asked the first guy, if it was the bathroom he’d dreamt of. Of cause the answer was no.
In plan of my head that was the first goal to have him say no. So we were still on track.
Keeping to my prepaared plan, I started from the buttom again, asking about what we could do prevented there erros they had pointed out at each transition.
All my questions had been preparred before hand and was all questions I ask my self, when I do peer review or write unit tests, so I was pretty certain, that the answers I got, would fit nicely into and entire hierachi of arguments for using the w-model. (which was my over all goal)
When we were done, all the listeners had a clear Idea of why so many errors are actually based in lack of requirements.
We all agreed, that what they had first thought to be requirement specifications for a bathroom at best was requirements but no way near specifications and that the lack of specifications was the source of the problem or in the terms of the first part by making those dreaded decisions they would actually increase the PPV not decrease it as they had first thought.
I’ve tryed getting that point across so many times and fail horribly in most tries. Taking something every one can relate to, a bathroom and making them make the errors, forcing them to take decisions based on lack of information, the point was suddenly much clearere.
They realized that no matter how hard you try to do your work as an achitect if you only have informations like: “spacious”,”lots of light” and “2 sinks” you are bound to fail. You can be the best Bathroom architect but you will never design the bathroom the guy who wrote the bullet list envisioned.
What I learned, was to use analogies everyone can related to and instead of telling people the conclusions of some arbitrary scientific study, to guide them with preparred questions to make those same conclusions them self.
So in the future when I’m have to tell people about write requirement documents. I’m not going to talk about building Applications or abstract things such as the v-model. I’m going to tell them about building bathrooms
Failing fast to learn a lot 