We all know the requirement gathering process and how important it is in software and product development. To start the work, we need to gather all of the requirements.
We use this to initiate work. Starting a kickoff, identifying resources and planning for the work. It is an important step and, requirement gathering is a required part of the process, right?
What if I told you that requirement gathering is a myth and it is one of the biggest hurdles teams face?
I call requirement gathering a myth, in that it is an expectation that you will gather all requirements up front. Enabling an understanding of the work to be done, before you start. And that you can actually do that successfully.
Knowing all info from requirement gathering is a myth
That idea is a myth, and does a dis-service to the process and teams that follow full and exhaustive requirement gathering efforts. They give a false sense of security, that the requirements tell all there is to tell. That you know all about the software and product work to be done.
Teams need to understand this is an issue. They need to understand the trap that this idea is. The more you dig and dig for all the information, the more time, energy, and money is burned without actually delivering any work. All the while, you will never figure it out anyways. There are things that can only be learned by doing. There are also things to be learned that only come from delivering some work and getting real feedback.
Don’t forget how rigid that idea is. Of trying to figure everything out before you even start the work. What if that takes some time, and things change. The business or product needs shift, before you even start. You either start over with the requirement gathering, or, you plod forward.
Now, don’t get me wrong, requirement gathering has it’s place. Especially if balanced. By that, I mean that you use it to figure out some of the info. You layout a framework or a scaffolding of the work to be done. Then as you complete work, you will learn and you will refine. You will fill in the blanks and gaps, painting the complete picture.
This is a great process to use, especially on larger projects. Sometimes the complexity in larger projects is such that you will take a very long time to understand everything. Or, like I said before, you just won’t know everything without starting on the work. Actually digging in and starting, to enable more learning than from requirement gathering alone.
Additional ideas and reading that bolster processes around requirement gathering
Some great practices exist to help fight these ideas of exhaustive requirement gathering. Things like Just In Time Requirements, or ideas like Vertical Slicing. Basically, they are Agile concepts and practices, helping to go get requirements in a better way. I would highly recommend you try them if you have not and don’t practice these ideas. Especially Just In Time.
There you have it! Take this info and decide how best to use requirements for yourself. There is a lot of great info out there. I also enjoy the info at Object Computing, and the 9 myths of software requirement gathering.