Let us be up front on this: the discipline of System Requirements Definition and Management has a chequered history, even more so than system design and development. Certainly the creation and marketing of Agile development approaches has some roots in the failure of previous approaches to deliver quality requirements to design/development; it says that requirements will always be too vague, so be prepared to build and change as building helps the business articulate what it wants.
The problem lies in that last word: "wants". Asking business people, or any people, what they "want" is too open-ended (how do you know when all has been asked for?) and too imprecise (how do you know the right things have been asked for?).
The better question to ask is: what do you "do"? now, and in the future? Business people should and mostly do know what their business is, and the things they do to carry out that business. What they "need" Information Systems to do is to support carrying out that business, and help make that business more effective and profitable.
So, the root to defining requirements is to have business people describe their business processes. Each process needs to be detailed down to individual steps, to the point where a step defines something that is done by some person using some information. If the system is needed to perform or support a step, that is the requirement, as in "The system must have the ability to" perform the step.
A set of requirements defined in this way will be very stable; the only way it will change is if the business itself changes. Given such a set of stable requirements, everything else is design. If you build an interface that uses radio buttons but the business decides it prefers drop-down lists, that is a design change, not a requirements change. The system still has to have the same abilities, no matter what color a screen or window is.
The result is that business people are removed from the pressure of defining what they want. Skilled IT/Business Analysts work with business people to define the business proccesses from which requirements are derived. Yes, change happens, but much less often if requirements are based on what the business does, not what it wants.