One of my favorite things about working in operations research is diving into a new problem to understand all the complexities. Getting a non-OR person to list all the requirements for an optimization problem is almost like asking someone to explain all the steps to ride a bike. They know how to do it, but won't be able to explain all the steps.
Here are some useful strategies to go about it:
Get out in the real world You need to understand the fundamentals of the system you are modeling. If you are working with a factory, you should visit the factory, watch how it works and how the planners do their job and ask all the silly questions. Where does the planning process start? Why did you decide to do A instead of B? Would C be a possibility?
This will help you not just understand what the requirements are, but also why certain things are important and maybe even some things that aren't as important as someone told you.
Have a structured approach to uncover the full problem
Identify ways you can split the problem and dive deep into the different components separately. For example, when formulating the objective function, you can identify all the stakeholders involved in the system and determine what their objectives are. They shouldn't all be included in the model, but it can help you ensure that you didn't miss anything important.
Gather real-world solutions
Create some smaller datasets and discuss with the expert what the solution should be. They could also be real-life datasets you have collected. You can use them ongoingly to pressure test your solutions and see what the differences are between what business did and what your model proposes. Businesses often have an idea of how the ideal world should look like, but when reality hits, rules can be broken, and priorities can often shift.
This can also help you discover if you are getting contradictory requirements.
A model should always be judged by the solution it produces and the value it creates. It is easy to get caught up in writing an elaborate document to describe all the aspects. You will never find the right model in your first attempt, so it is important to get ongoing feedback on the latest version of the model. Build a prototype that includes a way to visualize solutions produced by your model, so it is easy for users to engage and validate your results. A way to do this is to have some fixed interval where you demo the newest version and discuss priorities, e.g., every 2-4 weeks.
I always see it as a goal to get as deep into the problem as possible. The deeper you are, the more you will be able to ask the right questions, challenge their assumptions, and build credibility with the business to ultimately create some real-life impact with your model.