Perception

Excerpt from Paper #6: "Recognizing and Understanding Human Behavior to Improve Systems Engineering Results"

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 Zuckerman1).

What we think people say and do may even be not 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). 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, they also don't need to press a "Save" button in order for the other person to start receiving the message, do they?

When I built a website with forms to fill in, without the need of a save button, the software developers asked "Where is the Save-button?" Other people never asked.

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 any more 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.

  1. Åfors, Cristina and Zuckerman, Marilyn, 2001. A Quick, Accurate Way To Determine Customer Needs. Quality Progress, Vol. 34, No. 7, July 2001, pp. 82-87. ASQ. www.culturalimprint.com/resources/customer_needs.pdf