Today, some of us may still have traditional requirements as a base of what we develop, some of us have just User Stories and work off of that. But throughout this article, I will use the word requirements to mean all of that input: traditional requirements, User Stories and whatever else form of "that-which-is-needed" we may have.
Traditional way of thinking about how requirements are created is that they are defined. That is, a clever person sits down and writes them down. In this article, I will try to make a point that they are not that much defined as discovered.
In software endeavours where the requirements are expected to be defined upfront, the person or the people who define them inevitably miss the factors that influence the way requirements are defined. There is no way to avoid this it is true no matter how knowledgeable and experienced requiremens author(s) are. Conversely, by refraining oneself from going too far with definition, the authors get a chance of opening their minds to factors that help them discover that which they have possibly never conceived otherwise.
Factors that help us discover requirements:
And last but not least, the Proof of Concept (or Spike) activity can shed light on what we can or cannot do and strongly influece the requirements at an initial stage.
To sum it up, we should open our heads to factors described above, and any other that we can spot in our work. We need to accept the fact that we are not able to do a good "definition" job sitting at the desk and staring at computer screen. Instead, go discover what's waiting out there. Then work on the definition for a while and then go discover again. This is how great features emerge.