How do organizations procure their IT? Do they get what they asked for? Do they get what they need? These questions will be the theme for my attention for a while.
Requirements and Acceptance
The first thing that came to my mind when I first started discussing these issues with Robert Feldt a few months back was naturally requirements and acceptance process. Your requirements are your way of asking for something. Your acceptance process is how you ensure that you got what you asked for, and not something else.
I performed an informal survey among my friends on Facebook and those who answered all agreed that good requirements engineering is essential for successful IT projects. Yet, common wisdom has it that 2/3rds of all IT projects fail to deliver the planned results on time. Is this caused by a lack of clear requirements?
Back in the old days, there was a dream that it should be possible to generate the desired software solution from formally specified requirements. The concept has more or less failed and what remains is probably just formal proofs of software correctness.
We have learned a lot since then on how to specify requirements in more or less formal ways. We have also learned a lot on how to work with requirements. For many and complicated reasons a complete and unambiguous set of requirements is impossible to achieve at any point in a project. Nevertheless, I have never, ever worked in a projects where at least not some requirements have been of a very low quality. For instance:
- The system shall provide an interface XX (ok so far), and it shall be the preferred interface in department YY (How do you measure that? What if the people in YY prefers another interface?)
- The supplier understands the requirement, I can understand how you could possibly arrive at a requirement stated like this after a long discussion where no one is able to formulate what they are after, but how on earth will anyone at a later date understand how to test or implement this?
What requirements say about us
But what do requirements really say? It has occured to me that what they ultimately say is that they themselves require a division of labor between the person(s) stating the requirements and the person(s) who come up with something meeting the requirements. More about that in a later post…
