1) This depends on your server and document settings. If you do not keep these documents in memory (no pre-load, reasonably short document timeouts) - I would not consider these in the calculations, or would account for one of these to be loaded during any specific time period if I wanted to be conservative.
2) As far as I know, the number in the governance dashboard is safe to use. You can also cross-check this with live values which you can get from the QMC at any time point under Status / QVS Statistics.
3) The rule of thumb I am familiar with for calculating RAM footprint is the full size of the document as loaded (or as saved to disk with no compression), and an additional 10% per user (e.g. 200% of the base size if 10 users are active at once). If you allow more than one copy of the document in memory (another QVS setting), you may have to account for the possibility of multiple copies at once depending on your reload frequency and timing.
If you are running your QV reloads on this machine, you should account for those as well - each one will eat up varying degrees of RAM and CPU during the reload cycle.
Keep in mind that this applies primarily to RAM requirements - CPU requirements are going to have a lot to do with QVW reloads and specific CPU load of individual QV objects. I/O requirements should also be considered if you frequently reload your documents, as the need to regularly save QVWs or QVDs to disk and read from these files can result in slow performance, particularly when opening a document that is not pre-loaded or that has just been re-loaded.
to aggregate RAM requirements for multiple documents. I note there is a possible bug in the multi-user calculation in the Server Sizing sheet. But you can manually calculate using the "Per User Memory" figure on the DA Memory sheet.