It's wise to also be aware of an "hidden agendas". Is the real reason for performing simulation analysis that someone required them to build a model? Sometimes a customer or source of funding will require a simulation model be built as a condition of a contract. In this case, the stakeholder's main objective may be to have a model that supports what they intend to do anyways. To quote a popular robot… "Danger, Will Robinson!" Starting out with the answer you must "prove" is a situation to be avoided at all cost.
Knowing how your most important stakeholders define (and hopefully even measure) success, now you are ready to write your high-level objectives. This will be the starting point for further project discussions so that everyone has a shared vision. This information also provides a good start for the detailed functional specification you will be doing at a later point.
If you are lucky, this is your system that you are modeling and you know it well. More typically, even if the system is owned by your company, you do not know it well enough to accurately model it. Every system has subtleties which are often important. While it is not reasonable to expect a simulationist to know every system, a good simulationist should know the important questions to ask and be able to understand the answers.
One good way to start is to review the process so that you understand the key aspects. What are the entities? How are they being transformed? What are the constraints? If possible, take advantage of the opportunity to literally walk through the actual or similar facility to discover things that might be missed in a discussion or diagram review.
Ask questions. Ask more questions. Ask different people the same questions and don't be surprised that you get different answers. Your goal at this stage is not to solve the problem, but to understand the problem and the system well enough that you can describe and estimate the work. Part of this stage is to identify what you don't know so that you can allow time and risk in the project for that enlightenment.
There is an old adage that says "If you don't know where you are going, how will you know when you get there?" That is especially true in simulation projects. A functional specification clarifies the model scope and level of detail. And most importantly, it clearly defines the deliverables. It defines the objectives as well as the deliverables and determines how everyone will know when you are done.
A functional specification should clarify the project and bring everyone into a common understanding of the deliverables. Topics should include:
Developing a prototype during the functional specification phase can be enlightening to all parties. You might find that it is easier or harder than you thought. Even on the smallest project it is generally worth showing a quick model and asking the question: Is this what you mean? You might find that you have a totally different understanding than the stakeholders. Often a prototype model can be made that addresses a large percentage of what the stakeholders say they need. But as soon as they see the prototype, they remember the complex situations and all the other needs that they neglected to identify earlier.