Various work that I have done points to the criticality of the role of the
customer or user, hereinafter called the CU, in a requirements engineering
effort. The traditional view is that a CU is fountain of information about
the domain of and the requirements for the system to be built. However, at
least one person, Joseph Goguen has observed that not all requirements can
be obtained from the CUs. Many have to be invented in a social process
involving the requirements engineers and the CUs.

If RE is to work properly, then the CU has specific duties in the process.
These include, but are not restriced to:
<ul>
<li>
providing domain knowledge,
<li>
providing requirements knowledge,
<li>
providing rankings of requirements,
<li>
recognizing what he or she wants when he or she sees it (IKIWISI),
<li>
negotiating with the requirements engineers,
<li>
demanding answers to questions about computers and software,
<li>
demanding clarification of unclearly specified requirements, and
<li>
demanding creative ideas from requirements engineers.
</ul>

A first attempt to characterize this role came out of the work on
<a href="house.building.metaphor.html"> house building as a metaphore for
software engineering.</a> I had used my knowledge of RE processes to play a
tougher than usual client in a house building and in two house remodeling
efforts, and ended up being far more satisfied with the results than most
such clients.

Also, there were lessons learned in my being the client in several cases
studies reported on in the work on <a href="users.man.spec.html"> user's
manuals as requirements specifications.</a>