Top down integration is basically an approach where modules are developed and tested starting at the top level of the programming hierarchy and continuing with the lower levels.

It is an incremental approach because we proceed one level at a time. It can be done in either "depth" or "breadth" manner.

- Depth means we proceed from the top level all the way down to the lowest level.

- Breadth, on the other hand, means that we start at the top of the hierarchy and then go to the next level. We develop and test all modules at this level before continuing with another level.

Either way, this testing procedure allows us to establish a complete skeleton of the system or product.

The benefits of Top-down integration are that, having the skeleton, we can test major functions early in the development process.

At the same time we can also test any interfaces that we have and thus discover any errors in that area very early on. But the major benefit of this procedure is that we have a partially working model to demonstrate to the clients and the top management. This of course builds everybody's confidence not only in the development team but also in the model itself. We have something that proves our design was correct and we took the correct approach to implement it.

However, there are some drawbacks to this procedure as well:

Using stubs does not permit all the necessary upward data flow. There is simply not enough data in the stubs to feed back to the calling module.

As a result, the top level modules can not be really tested properly and every time the stubs are replaced with the actual modules, the calling modules should be re-tested for integrity again.