3 - Describe what happens to the inputs until all the functions of the program have been described and all the outputs created. Again, when you're just starting out, text will do just fine. The goal is to be sure that YOU understand it. If you can't describe it, then you probably don't. While you're doing this, you can think about how some of these functions might be placed into their own procedures or modules using the technical ideas presented in the book. Look for functions that look like "black boxes". In other words, there are clear inputs and outputs and the processing inside the function can be cleanly separated from the rest of the program.
There are several good examples of this in the text. The clearest one is the TotalTax Function. How many places in a program might need a tax calculation? And it's likely to be either exactly the same or very similar in all of them. So, if a large system needs a tax calculation in, say, fifty places and suddenly they pass a new law and change the tax rate, would you like to change the program in fifty places or just one?
And ... perhaps most important of all ...
4 - Keep your design up to date. As you learn about the program, you'll change your mind about the design. That's good. Nobody thinks of the one, best way to do something the first time around. But don't go back to bad, "no design" habits. Rules one through three that worked the first time should be followed again.
