Flowcharts are mostly meant to illustrate a process that embodies an algorithm (a recipe for solving a problem). The flowchart illustrates the procedural steps that the computer would take to solve the problem.

Flow charts have been around a long time. For developers, they are time consuming to produce, particularly in the quantity that would be needed for a commercial scope project. They also have the disadvantage of going stale pretty fast once developers start coding to them and integrating logic discovered during implementation and test.

In casual conversation with Dr. Bill Curtis, who was one of the authors of the SEI CMM 1.1 and a person with some background in software process and psychology (a PhD), he said to me and others that our diagrams depend on people being high-spatial to understand them, but people who were high-spatial could pretty easily form a mental picture from text representations of software like pseudo code.

Most of the object oriented methods advocate leaving behind flow charts and also data flow diagram as artifacts of structured programming and even pre-structured programming. More useful are techniques like use cases annotated with alternative flows. Use cases tend to start with a nominal flow that may describe some conditions, but not much branching of the control flow. Branching is covered in alternative cases, and typically references the nominal flow for brevity, accentuating only the differences. Another good reason to consider use cases instead of flow charts is that they can easily include as much text as is needed for clarity, although all but the shortest text can cause problems with gracefully sliding text into flow charts, and combined with routing and other manual manipulations, can eat up a lot of time, sometimes with good benefit, sometimes without.