I am borrowing Mel Gibson's film title to critically examine the mystique of collecting user requirements. While this practice makes perfectly sense in transaction systems' design and as an overarching framework of your data management initiative, in BI there are some interesting twists. 

It is considered a best practice, every book on methodologies give for granted that this is the place to start. Even data scientist suppose that they should start their efforts upon a specific business question. This approach is widely used because it is considered the only sensible one. Risks on the user side are minimized and the BI professional has a comfortable, stable, point to start from.

However, it is widely accepted how, when it comes to BI and DW, it is difficult to establish clear requirements. An old adage says that projects are "done once to get the answers required by the users, and a second time to let them know what thy really need". This aspect is widely discussed in literature.

The reason for this is quite simple to pinpoint. Designing a transaction system implies translating into an IT system a process that already exists and can be described in detail by the users working on it. There is a high, but limited, number of ways to manage invoicing; with a good dose of patience, you can describe them all or, at least, all those which are of interest for a project. In BI, user requirements describe reports layouts and business rules to calculate measures; but as soon as you have created them, they start generating new questions that require new reports or entirely new data structures to be answered.
An invoice, when is done, is done; a report is never definitely done. Transaction systems mirror processes and actions, BI systems mirror, and influence, mental business maps, a more elusive substance.
This issue is often addressed by some flavor of agile methodology, where the work is broken down in very small bits, and it is done in close connection with the users. These methodologies generally work and those who do not know better are generally satisfied. Obviously they shouldn't.

As already explained in other posts, BI is about creating a business model that could be used to do analysis and, like every model, to make predictions.

If we start from this point, the logical consequence is that we have to create data structures that represent the fundamental facts and master data of the business that we are targeting. These should exist in an easily consumable form independently from users' requests. There is no point in modeling invoices and leave out the invoice operator field just because nobody asked for it. Obviously this approach should not be taken to the extremes; there is no point either in modeling the annual leave request modules if the project is focused on sales.
In a more general perspective, the overall architecture should be rich enough to sustain the scrutiny of the users and bring them real insight. And, mind, users won't ask for that the first or the second time; it is the BI professional who must be experienced enough to understand what will likely be necessary and include it from the beginning. There are specific architectures, relational or not, designed to achieve this result (I am not covering these architectures here, this is food for another, scientific paper like, post), where the necessity of changes and updates is minimized and generally occurs only when the business changes substantially.
All of this may seem the revival of the old monolithic DW architectures that used to fail in the past and we are all happy of having left aside. Obviously this is not the case. Projects should be organized "vertically", that is should be aimed at providing something to a group of users: domestic sales, international sales, logistic, finance etc. DW structures should be generic and not strictly related with the original systems they are sourced form; they should mirror the business model that, in turns, addresses the business mental image in the head of the users.

This kind of structures can, and should, be designed with minimal input from the users, whose vision will guide the BI professional to defining the scope of the project and the kind of answers that are going to be provided, but, critically, NOT the details. Thus the purpose is covering an entire area and not to answer a precise business question.

The obvious objection to this approach is "If the users are happy with something, why shouldn't I provide exactly that?", the simple answer is that the users think that they will be happy but they wont. In more formal terms, it is way less resource intensive, hence cheap, designing the right architecture the first time, something that will require limited servicing, rather than going over the same points over and over again to accommodate a never ending stream of further requests and refinement.
Doing this, it is obviously difficult; it requires a lot of foresight that comes only with experience. Ideally, the BI professional should know the users job, from the point of view of the information involved, almost as well as the users.
Acquiring this knowledge should be at the hearth of BI professional growth effort because, in terms of effectiveness, it is much more important than learning yet another  SQL dialect.

I am doing my best to be controversial and obnoxious, please let me know how successful am I!