You could go back and update the design spec with this information. Or take the spec and create a lower level spec where you describe in more detail what you are going to do and why, ideally before you start schematics :). Then update as you go along and archive with the schematics.
Answering questions below:
Well what we usually do is start with marketing requirements, then maybe a formal engineering response or just informal discussion. This is followed by an MRD (marketing requirements document), in word, using our template. That includes requirements, competitive analysis, market size, opportunity, estimated development cost etc. Usually this is written by a marketing person (or someone above my pay grade).
This is followed by the PRD (product requirements document) written usually by engineering, also in a word template. This describes in more technical detail what the product will do, what pieces are required, and at a high level how each one of them will function. Often we will include target performance, price, power, size and other metrics here.
That's followed by detailed functional specs for each of the sections. Some design work is actually done here well before it's put into the schematic. For example power will be calculated, parts will be selected, and a lot of research done. This is the place we would document any non-obvious design decisions.
Finally we'll get to the schematics which is the easy part at this point because a lot of the hard design work was done in the specification stage. Where it should be done in my opinion :) If something changes during the schematic stage, for example we figure out something won't work or a marketing person comes running down the hall saying it needs to be red now instead of blue, then we will go back and update the specs.
All the specs, PRD, MRD are kept in SVN with links to the docs on a internal wiki. A change to spec will result in an update to SVN and a notification to interested parties. You could of course just keep it manually in a shared folder somewhere.
That's more or less my process, I feel like you might want to document every tiny decision made about a design and we definitely don't do that. Not saying you shouldn't, I could see where it would be helpful. I guess we usually document the how and not the why all the time.
Ok maybe I should have also addressed each question :)
If you are making calculations, in excel maybe? Or on paper and you think the results and the method are important to the understanding and design of your circuit, then you should include those in the appropriate section of the design specification. Even if that means taking a picture of your hand drawing :)
Why did a choose this component?
I think the functional spec is a good place for this, no need to go crazy but just a simple line or two about what it's advantages were. I'd reserve this for critical components, I don't think you want to describe why you chose a pull-up resistor for instance.
Why/how did I choose these particular parameters for this component?
Combine this with above.
What does this part of the circuit do?
This would be part of your functional spec, if the circuit is important enough to warrant this question it should have it's own section of the spec.
What is the power dissipation through this component?
If you're talking power supply put this in the power section, also I like to note this on the schematics. Really though all my parts come from a database and the schematic is direct linked to them so we can easily see the parameters, datasheet etc. But if you just have a print out it's nice to know some of this.
What is the total power consumption of this circuit?
I think this belongs in the power supply section of your specification.
Can I replace this component with this other one? Are there any equivalent components to this component? etc.
This I think belongs in your BOM or whatever process you use for manufacturing. Alternate parts are to make sourcing easier. Again for us this is all coming out of a parts database.