In a nutshell one is what you want, the other is what you’re getting !
Requirements describe what is needed, what the solution will need to achieve but not the how. Requirements must not describe a solution. Separating requirements and design allow proper consideration of both.
I find users often volunteer an idea for a solution at the same time I am gathering the requirements. Often there are some good ideas but equally I find people try to replicate their existing processes without considering alternatives, or it is focused purely on their needs and may not include other affected parties, so a requirements document must talk about the business need without mentioning the system.
For example a project might be to enhance an existing invoice system to eliminate the user having to type in a customer details each time. Customer info is be added automatically to invoices, these details may include names and addresses, before storing the details they may need to be checked by an authorisor. All of these items are requirements. At the requirement stage it might be tempting to say the customer information should be stored in the invoice system and make this a requirement, but what if there was already a customer info system that you could interface to instead? Or what if there was a parallel project that required similar customer information? This opportunity could be missed with solution driven requirements.
Similarly a functional design must not drive requirements, although as I capture the requirements I know some things will be challenging to deliver I never filter out requirements early on. Users must feel free to talk about anything, if I were to start filtering out information then the users might start to do the same and important requirements could be missed. Also what I might think is challenging may actually be simple for the developer, they are better placed to make these decisions.