Monday, 16 March 2009

The Requirement's Game

I wonder what the rules of this game are. It seems more and more obvious to me, that the requirement ‘phase’ of a project is way underestimated. Recently in James Bach’s blog (Quality is Dead) I saw something that explained a part of it: we don’t really know what the requirements of most (if not all) the systems and gadgets we’re using were.

But once upon a time, there was a project around, which ended up producing the programs and the systems that I’m using for writing this blog entry. These include – just to count a few – outlook, firefox, windows, google (the search engine), some rss-device – which I’m not sure about what is and who made, but it’s there and it does what I ask it to, a keyboard driver (part of windows, I guess, but it might not be made by microsoft) and so on.

Some of these projects have been huge and expensive, some might just have been made over a fourtnight by a single programmer.

But there were some kind of requirements around, and those involved in the project had some common understanding of them. But each probably had their own ideas and interpretation. Had they worked on some other part of the project, it might have turned out differently.

Some requirements were probably described by end users. Others by people imagining what end users might want. And again some other reqs would be dictated because of some choices made earlier. So – all the good ol’ stakeholders have been in use.

But – as an end user of all theses systems, which I use in a way to enable me to do something most of them weren’t directly intended to, although they do not work against me on it, I must be the last one to set up some requirements for theses systems. And now it’s all done. The development projects have gone. The projects are closed down. The bug back log is transferred to maintenance. Most of the people are now doing different things. .. so how come I can put out some requirements now???

Probably because that’s part of the requirement’s game. I can now buy or download some utility/program and see if it fits my needs. If not, it’s returned or simply discarded, despite the blood, sweat and tears that went into the projects that created these things. Despite the heavy arguments and discussions whether or not some bug report was fixed well enough or not.

That gets me to think that somehow seeing the requirements as being something captured in a project – whether at the beginning or during – that’s just a temporary thing. The real user will issue the real requirements and that’s when the real value will show.

No comments:

Post a Comment