This is in the requirements phase so isn t it more about identifing the minimum specification of machine that the application has to run on than estimating the resources your application will use?

I ve developed systems for corporate clients where they have standard builds and are able to identify the minimum spec machine that will be used. Often you won t know the minimum specifications of the machines that you will be installing on but you will know the operating systems that you have to support, and may be able to infer them from that.

I have specified this before but its always been a ballpark figure using the Standard specification of the day. For example at the moment I would simply say that my App was designed to be deployed to servers with at least 4GB of RAM. Because that s what we develop and test on.

For client apps you might need to get a bit more detailed, but its generally best to decide on the class of machine you are targeting and then make sure that your app fits within those constraints. Only when your application has particularly high requirements in one area (eg if it stores a lot of images, or needs a powerful graphics processor) do you need to go into more detail.

These sure are considerations in the early stages of some projects I ve worked on. A lot of scientific codes boil down to working with large matrices. It s often possible to identify early on that code X will need to manipulate a dense matrix with, say, 100,000 rows and columns of complex doubles. Do the sums. Sometimes the answer is (a) pack a PC with RAM, sometimes it is (b) we ll have to parallelise this for memory even if it s not necessary for performance.

Sometimes our users would like to checkpoint their programs every N iterations. Checkpointing with very large datasets can use a lot of disk space. Get out your calculator again.

I know it s all very niche, but it matters when it matters.

Machine memory is a tricky one with virtual memory being so common, but disk space isn t that hard depending on the system. We ve got a system at work that was built to deal with a number of external devices (accepting input, transforming data and delivering to a customer) and that was fairly easy to size given that we knew the current and projected data volumes that the devices were generating.

You can check how much memory is used by your software during testing, and then estimate how much more you may need if you process bigger chunks, i.e. if you process 1000 items in your biggest test suite and you need 4 MB, then you will probably need 4 GB to process 1 million items.

I ve seen software in embedded systems have minimum machine memory requirements - often derived from limitations on the custom built hardware. If the box can only be X by Y by Z dimensions, and has to have other physical requirements satisfied, the limitations on available memory for the software can be absolute and the bare minimum should get set up front.

It s never been a big deal for me in the web app world - after all, there will probably be a new model of the target hardware released before I m done with the code and memory will be cheaper... so why waste time trying to fit a small size when you can just add on?

I ve seen large data projects mention free space - you can really gunk up a system if your database doesn t have some amount of slack to move data around. I ve seen requirements that specify bells and whistles and emergency measures to make sure that there is always enough room to keep the database humming.