You have already specified in your functional specification who is responsible for providing data and when. It is prudent to let people know well ahead of time when you need the data and at what point the project will be delayed without it. While you may be able to place blame on someone else for causing a late project, it is far better to work together to ensure that the project is on-time and successful.
Building a model is the process of creating a representation of the real system adequate to support meeting the stated objectives. Verifying the model is the process of ensuring that the model really does what you think it is doing. While building and verifying the model are two different tasks, they are covered under a single topic to emphasize the importance of always doing them iteratively.
Novices will sometimes build a large part of the model, or perhaps even the entire model, before starting verification. This is a significant cause for project failure. When you start verifying a large model, there is so much going on that understanding the detailed interactions becomes difficult or impossible. It is much more effective to instead take an iterative approach – build a piece of the model, verify it, then continue adding additional pieces of logic to the model. Two very effective approaches to model building can be summarized as ‘breadth first' or ‘depth first'.
In ‘breadth first' modeling, you might build the entire model or a major section of it with a minimal level of detail. You can then verify the model works before continuing on. This has the advantage of immediately generating a potentially useful model. Your first pass could actually be the prototype used in the functional specification. Another advantage is that you can more easily get stakeholder feedback from a complete (albeit not fully detailed) model, and get regular feedback on where more detail is required. You can sometimes even do some measure of validation (discussed later) as part of the iterative cycle.
In ‘depth first' modeling, you select one small section of the system and model it in the full detail required. You can verify this model section completely and in the extreme case never have to review it again. An advantage of this approach is the ability to modularize the model – particularly important if several people could be working on the model at once. A novice might choose to build an easy section of the model first to gain experience.. A more experienced simulationist might implement the hardest or trickiest sections first to eliminate some project risk early on. A modeler with some "agile" background might do the highest priority or most important sections first. With this latter approach, at any stage the most important aspects of the model have been completed. This helps reduce the risk of running out of time or budget without being able to produce any meaningful results.
‘Breadth first' and ‘depth first' approaches can also be combined by alternately adding some detail at the entire model level, then adding some detail to (or completing) a particular subsection. But the most important aspect is to add relatively small sections of model logic and then verify each section before adding more logic.
In each cycle of verification, you want to definitively answer two questions. Does the section of model I just built perform as I intended (e.g. are there bugs in the logic of this new section)? When this new section interacts with previously built sections of the model, does the entire model still perform as intended (e.g. are there bugs in the interactions between sections)? As your model gets larger, you might want to make your new sections smaller to make answering the second question easier.
The most obvious ways to find and diagnose model problems are to watch the animation and to examine the output results. Unexpected results are not a problem – they are a primary reason for doing a simulation. Unexplainable results are a problem. When the model generates an unexpected result, you need to use all your available tools to find the explanation. In some cases that might lead to discovery of a bug that must be fixed. In other cases it leads to an "ah-ha" moment – a flash of enlightenment about how a complex system works.
Most products have a variety of tools to support model verification. Model trace is often available that can provide great detail on exactly what is happening step by step in your model. You may want to start by watching a single entity go through the entire process. Typically there will be controls in your software to allow you to step through a model or to "break" execution at a particular location, time, or condition. Often there will be a watch window that allows you to explore the detailed system state at any time or for any object to help further clarify what is happening. And certainly take advantage of any dashboards or other interactive statistics and graphics offered by your software. The verification process is certain to be an enlightening and quite necessary part of the project.
Even with all of the above, you might find that you have a situation that just doesn't look right, but you cannot explain why. It's time for a model walk-through.
Find a good listener, ideally a simulationist or one of your stakeholders, and go through all of the relevant model sections and explain to them what is going on. If your listener has the ability to understand what you are explaining, that's a bonus.
But in a large percentage of the time, you will find your own problem by methodically walking through the interactions. Keeping this in mind opens up wide possibilities for a candidate listener. An uninvolved co-worker, a spouse, or even a pet are good candidates. While dogs and cats can sometimes be good listeners, nothing beats a pet goldfish for a captive audience. The key is that explaining your model out loud seems to open up a different part of your brain and allows you to solve your own problem.
As mentioned earlier, a model is just an approximation of a real system. Usually the modeler and the stakeholders want the model to be as accurate and comprehensive as possible. To avoid never-ending, late, and over budget projects, you need to go back to your functional specification document. Your goal is to build a model with just enough detail to meet the stated objectives and no more!
Animation is an area where it is easy to "get lost". Animation can be the most fun and instantly gratifying work in the project. It is easy to let it take more time than it should. Most packages have some level of automatic animation. This is typically good enough for model verification. Likewise, many packages have some level of 2D or 3D animation that is very easy to generate. Some amount of this can make validation easier by providing an additional measure of reality and recognition by stakeholders. But again you must go back to that section of the functional specification. Your final animation should be just good enough to meet the previously identified customer objectives, and no more!
Model validation needs to be done to determine if the model represents reality to the extent necessary to meet objectives. You can sometimes complete some measure of validation as you do the model building and verification iterations and should take advantage of every opportunity to do so. But you will still need to do additional validation on the completed model. Perfect verification and validation is usually impossible because the only perfect model is the real system. But there are some ways that you can attempt to demonstrate that the model is valid enough for project purposes.