A top-down approach is the breaking down of a complex system into smaller subsystems. The "opposite" strategy is called the bottom-up approach.
When decomposing a system top-down, the designer is focused on the problem being solved and has a tendency to create modules that are too specific to the problem.
In particular, programmers have a tendency to think in terms of flow of control and break down a problem into a series of steps. I believe this tendency comes from the fact that we're introduced to programming using the concept of algorithm.
However, in doing so, the programmer often makes the interface between the modules specific to the current problem. This loss of modularity makes the system harder to maintain because the modules share design decisions. This issue is discussed by Parnas in "On the Criteria To Be Used in Decomposing Systems into Modules".
Moreover, even if the design decisions are hidden in each module, the programmer will have to make those decisions and will make them based on the problem being solved. This will limit the reusability of the module. This issue is discussed by Gregor Kiczales in "Towards a New Model of Abstraction in the Engineering of Software".