Today I would like to share some thoughts about collecting the right requirements.

The problem I see sometimes

What is usually done while doing agile development is that there is a product backlog containing the users' requests. Then, regularly, the development team picks things to implement from the backlog.

That's all well and I personally work this way. 
The problem is that sometimes the items in the product backlog is not really what customers are really looking for. So development teams are wasting time on things that don't matter.

The discussion here is how to make sure that the product backlog is relevant.

Look for what is best for the business

For sure, most items from the backlog originate from some form of request. But we have to process differently the items depending on their origin. You should give a higher priority to items that will have a positive impact on the business. The priorities in the tool you use to manage your backlog should reflect that.

Don't artificially bump the priorities of secondary requests just because you don't have enough high priority items. You should really be honest about the business value of what you are doing. 
This means that sometimes the highest priority in your backlog might only be medium. That would be the case if you have no business centered items only minor technical items.

How healthy is your backlog?

Again, what I think is important is that the priorities should be a honest representation of the business.

If you have no high priority items in your backlog, that's a valuable piece of information. Does this mean that you are not talking to the right people? Does this mean that no body care enough about the product? Is it time to pivot? 
Problems vs solutions

You should not hesitate to log ideas in your product backlog. But those items often need to be clarified afterwards. 
Some users will give you their solution instead of the problem that need to be solved. Sometimes that's OK but you should always try to understand the real problem behind a request. Finding the problem is also a good way to understand if you are solving business issues or not.

Non-business requests must still be considered

Not all backlog items come from the business side. Some technical enhancements will also have a positive impact on the business. For example, doing backups will obviously be a very good thing for your business but no customer will create such request. Such requests should not necessarily be put lower than customer requests but this is something to consider when you evaluate the health of your backlog.

Which process?

To sum up some of the parts discussed above: you should understand the business value of your product backlog items, you should review them regularly, you should distinguish solutions and problems.

I don't think there is a definitive process to handle this. Some tools and processes include notions of product backlog management. I personally don't worry to much about tools and processes. The most important part in my opinion is that you understand your own product backlog and that you don't wait for it to grow out of control.

You might use an agile methodology. That's great. But in the end it doesn't matter to be agile if you don't build the right things.