Actually this is the reason for most of the problems occur in SAP implementations. If the users themselves are not clear on what they want, it is very hard to configure a good solution for them. Especially this is true when it comes to reporting. Most of the users want reports with tons information on them. But when it comes to entering data they are not willing to do it. Most of the times complicated reporting means complicated data inputs. So every user must analyze their requirement before they pass it to the blue printing. Every requirement must be analyzed to check their actual requirement and the benefit in the bigger picture. This is why it is always better to have a group of final decision makers who have the knowledge to analyze the requirement in the bigger picture and authority to make the decisions to filter and pass the requirements to the blue printing.

User requirements should represent the requirement of the business not the managers. In simple terms when managers change, there should not be any drastic changes to the requirements. This might sound funny, but most of the implementations suffer due to this.

Everyone involved in this process of requirement capturing must be educated on the importance of this step. And if they want to do a change to the requirements they proposed during blue printing, there must be a proper channel of approval and reasoning process to the change. Otherwise sometimes the solution will suffer due to the irresponsible actions of this nature.

Simple thing to remember, requirement is the foundation of the solution. If it is not stable solution will certainly not be stable.