Hey there, what you refer to is "bottom up" development. It's a good way of handling messy real world problems that are not easily soluble with a formal mathematical approach. See the following links
DSDM - an early approach I used when it first came out
Extreme Programming
SCRUM methodology

In essence, by repeated prototyping you move closer and closer to an approximation of the real world problem. It helps uncover what is "unknown" about the problem and is a great tool for helping an end user (typically untrained in systems thinking) work with you to reach a deeper understanding of the problem they are asking you to solve. In programmer terms, the use of strictly limited timeboxes and regular reviews with the business user ensures you don't wander too far off course.

It contrasts with the historical waterfall method of top down development popular in the 1980s, which is based on the belief you can fully specify the domain of a problem from Justification Study to Feasibility Study to Requirements Analysis to Architectural Design and then down to detailed program spec.

It really depends on the kind of system you are writing. For a system worked on by 500 developers, you're probably better off with a top-heavy PRINCE 2 project management and top-down design approach. Of course, this has led to some classic disasters in developing large scale government systems, for example the DSS client-server replacement system (£500M wasted). I think that's more a function of the complexity of the problem and the limitations of how much one human brain can understand rather than any inherent flaw in the methodology.

For smaller systems, or ones with unclear requirements, a bottom-up approach is better provided someone (the tech project manager) has the discipline to ensure documentation is completed properly and an adaptive approach is taken.

Good luck!