Requirements you don't want

If you are building software, you need requirements. They are input for implementation and test and they can serve as means of acceptation. Requirements can be as explicit, implicit, formal or informal as long as it works in your particular situation.

That said, if you have requirements, they must make sense. I often see the 'too many requirements syndrome' in projects. Most often caused by someone that obviously had too much time on her hands.

Ok, time for an example:

It looks like there is a requirement that states a name can only contain alphabetical characters. The example shows that this requirement obviously was one too many, unless I miss the important point behind it.

How can this be prevented? Think like a kid! Question everything: why? Ask yourself why for every single requirement. Ask why, when you get the explanation. Ask why even when you think you get it.

Why? Because requirements are expensive. Why? It's expensive to come up with requirements, it's expensive to write em down and once they are written down, they become even more expensive. Why? Because they need to be implemented and tested and accepted and the implementation contains bugs and bugs need fixing. And when bugs get fixed, that possibly changes the requirement.

And that's quite a hassle for a requirement that should have never existed in the first place.