The notion of stepwise refinement is a key component in the "Structured Approach" to Software Development, sometimes called, "Structured Design." The modules you are creating constitutes your Architectural Design (sometimes called Preliminary Design), because it shows the pieces of an overall design and how these pieces fit together: parent processes, child processes, and common processes.
All boxes in the structure chart are to proceed "down" the page - not across. It is to resemble an organization chart of a business. Lines are to be perpendicular or parallel with the page itself. All boxes are to be of the same size.
The extent to which we successively decompose modules into lower-level modules is a matter of taste and experience. The guideline that most people use is to decompose your modules until you can conceptualize the logic / algorithm of the module in fewer than 30-35 lines. (Probably fewer in a language such as C.) But this is not absolute. In many instances a complicated computation or series of computations might require its own module, while a long series of simple data manipulations that is easy to understand might make a module "longer" yet not complicated and quite cohesive.
The Detail Design of your program follows the Architectural Design phase. Your detail design consists of writing the pseudocode for each of the modules that you have identified in your software architecture. Because the modules should be single purpose (have high cohesion), the logic should be focused and provide a single function to the software. If your logic has multiple functions, then your module should probably be further decomposed.
Even the simplest program will have modules that are in *common*. These are discussed in any book on software design and in most books on programming. Common modules must be indicated in your Structure Chart by placing a diagonal mark (dog ear) in the upper right corner. For example, the reading of data from an external file, or perhaps printing to the screen are common activities and may be needed in your structure chart in various locations. Even though the module appears multiple times in your Structure Chart, common usage (and the dog ear indicator) clearly imply that a module is in common and really only defined one time, but called multiple times. Anytime a common module is to be altered in any way, your Structure Chart tells you other modules that are dependent upon it. These control modules must be checked to see if your proposed changes to a common module might have an adverse impact on their logic.
First level modules under main should normally be major functions, generally "subdrivers." Please note that read modules and print (display modules) are normally subordinate to these top levels and are usually "called" from a module "down the hierarchy." This is not to say that a read module cannot appear under "main," but frequently it is part of a "build" module, which is more likely to appear under "main" than a "read."
Don't forget. As your programs grow and your systems include more than one program, you will need a structure chart for each program and a single high level structure chart showing which "programs" call which "programs."