Perception

Looking in the dictionary for 'perception we can find:

• Merriam-Webster: Quick, acute, and intuitive cognition
  That isn't immediately very clear. Apparently it has to do with our sub-consciousness (intuition) recognizing something, without our consciousness taking part.
• (previously) Oxford Dictionary: Intuitive understanding and insight
  Again: apparently sub-conscious recognition.

What people say when asked, and what they do when they actually have to decide, may be different. 'Customers who said they wanted lots of different ice cream flavors from which to choose, still tended to buy those that were fundamentally vanilla' [Åfors and Zuckerman¹].

What we think people say and do probaby isn't the same as what they think they say and do. It's both about their perception and ours.
Different people perceive the 'same' things differently (remember the traffic accident, see 'Witnesses tell a story'). Because of this, we may even wonder whether we then still can speak of the 'same' things ... Perception is what we intuitively, sub-consciously observe and notice. These silent observations influence our interpretations, decisions and actions. We don't even realize that we logically (with the conscious mind) think one thing, and still with our emotions decide another thing: the head knows, but the heart decides.
Asking the customer to produce the requirements of the system will usually not produce the real requirements. Customers usually aren't even users of the system, which makes specifying the correct requirements of the system even more difficult. For customers, writing requirements isn't a core business. For Systems Engineers, it is. The problem with requirements engineering is, however, that it's not well taught in education, and that it's even partly a craft that has to be mastered by attitude and experience.

Furthermore, what the customer wants he cannot afford, so if we start making what the customer 'requires', we'll probably fail from the beginning. After all, the requirements are what the Stakeholders require, but for a project, the requirements are what the project is planning to satisfy. This difference often causes a problem, if the perceptions aren't managed well. Because of the perception issue, trying to find out the real value to the customer, or to the many Stakeholders, can show many paradoxes. Better not simply believe what they say: we have to check! An additional problem is that many people cannot very well imagine a system from a description, or from written requirements. They need to see more physical representations of the system to be able to understand what the requirements really mean. Asking such people to sign-off the written requirements is pointless.

Developers, engineers, Systems Engineers are deformed.
Developers, engineers, and Systems Engineers are deformed in their perception what 'normal' people find 'normal'. Software engineers find it quite normal if the system asks "OK or Cancel?" Normal people don't even expect to see that question. Software engineers think a "Save" button is quite normal. Normal people don't see any value in a "save" button. After all, if they talk to someone, do they have to press a "Save" button in order for the other person to start receiving the message?

If we as engineers try to imagine the right interface of the technical parts of the system with people, we are probably wrong. We simply cannot imagine anymore how normal people want to, or will use our system. Therefore it's better to mistrust our assumptions and check them all the time. Better assume that a lot of the requirements and our assumptions are wrong, and that we have to find out what the real and right ones are.