It turns out that systems may have millions of lines of code.   When a failure occurs, the call stack has dozen of function calls.  This implies that the design process of such a system includes dozen of abstraction levels.  In each level, you define what the system should do and then how it is done using some use cases.  Then you decompose that abstraction level into components that help implement the use case.   This process is repeated many time going from a declarative "what" the system is doing at some abstraction level to an "imperative" how it is done using the use cases.  

One way to look at requirements is the definition of what the system should do.   If you consider a user as a person that defines "what" the system is doing and take into account the decomposition process described above, a "user" assumes a new meaning - its the person that defines what we need to do at a certain decomposition level of the system.   Under that definition reducing the risk by getting the user in the loop gets a totally new meaning as well.

Groups developing systems needs the above definition to help identify their user, otherwise, they are lost and can not work with the agile concept of putting the user in the loop...