Who takes the accountabilty

I find that the user is held accountable for all software deliveries. The requirement artifacts that are produced are expected to be signed off by the user of the software, if there is any misunderstanding or ambiguity or incompleteness, once the sign off is done the noose is on the users neck. After the software is built, it is again the users responsibility to do a user acceptance test and if any test conditions are missed out or defects not detected in the acceptance test, it again is the users responsibility that it was missed out.

Requirements can any one get them right

We have all been struggling in eliciting requirements that stay invariant from users and if not in all in most cases, we have had a variety of mechaisms from DFDs to Use Cases for the user to verify that the requirements have been captured accurately and completely. However, there is always a gap is what is in the users mind and what is put on paper. We expect the user to sign off hundreds of pages requirements and carve them in stone. IMHO getting requirements down is like writing an instruction manual on how to swim or bicycle or walk. We know how to do it but we cannot describe it so that a person by following the description will be able to swim, ride a bicycle or walk. A user makes a decision, after experience, during a business process automatically, he does not refer to a procedure manual which tells him the exact way a decision is to be made with a long nested if then else. If the user is unaware on how to make a decision as a new situation has come, he just asks a more experienced person who is around. I think we have unreasonable expectations that the user should be able to speak out all the possible permutations and combinations which is required to create a system and hold a Change Request against his head.

We need to accept that getting 100 percent of requirements down to the minutest detail is not paossible and stop holding Cahnge Requests on the Users Temple