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:
A first attempt to characterize this role came out of the work on
house building as a metaphore for
software engineering. 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
Also, there were lessons learned in my being the client in several cases
studies reported on in the work on user's
manuals as requirements specifications.
providing domain knowledge,
providing requirements knowledge,
providing rankings of requirements,
recognizing what he or she wants when he or she sees it (IKIWISI),
negotiating with the requirements engineers,
demanding answers to questions about computers and software,
demanding clarification of unclearly specified requirements, and
demanding creative ideas from requirements engineers.