Software requirements, by their nature, attempt to make many predictions. They predict that…

…the functions described will achieve all the features that the system is aiming for.
…those features will achieve the product concept envisioned by the project sponsors.
…this concept will solve the business problem that the project was funded around.
…users will adopt the system that is being developed.
…after the users adopt the system, the success metrics of the project will be achieved.

Clearly, we are expecting too much fortune-telling from our product managers if we expect them to foresee the future of every person or system that will ever interact with their project. The predictions above could not be accurately made by anyone but The Amazing Kreskin.

Thankfully, none of that prediction is necessary, so there is no need to start hiring psychics as product managers and business analysts. The solution is evolution. Your software requirements will evolve as you learn more through more information.

Your requirements will begin with a lot of guess-work, but then improve as they go through many survival-of-the-fittest trials throughout the life of the project:

You start with straw-man models which you know are not correct, but you use them to get your SMEs thinking and engaged.

From the SMEs, you get a more accurate set of requirements left standing after the straw-man models are torn apart. 

Then, you put those requirements in front of potential system users and determine which work and which don’t.

Eventually, you’ll develop prototypes and demos where the users may find problems with the requirements that could not be seen until the prototype was actually used in practice.

Finally, your requirements will launch as a finished product and you will see whether they really achieve the success metrics they intended to achieve. If not, you will alter the requirements again in order to make the system more effective.

Continually, all the way until the product lifecycle ends and the product dies, the requirements are changing to reflect a new reality. Sometimes the current requirements will be completely different than the original requirements, and sometimes the may be relatively unchanged. But the important thing is that they evolve if they must.

There is just one problem: every instinct we have resists evolution. We all want to be correct right from the start. We resist change because that involves admitting we were wrong, and in today’s business world being wrong can get you fired. Until your boss starts seeing evolution as necessary, instead of something you should apologize for, evolution will not occur at a fast enough rate and projects will continue to fail. The real world will give you feedback whether you want it or not; the only question is whether you are willing to listen and evolve.

In order to build a great product, without relying on getting lucky, you need to overcome those instincts and allow free evolution of your requirements wherever they may lead. Whether you like the direction that the new information is pushing the requirements, or you hate the direction, you must step aside and let the information and feedback change your product.

It takes courage to admit that your predictions were wrong, but the rewards will go to those who adapt their software requirements the quickest, and not those who continually hold on to their initial predictions out of pride and stubbornness.