Estimating what you will need without having a working system to extrapolate from is very, very difficult. If you must do so, you need to have a very well defined use case. From that, you should be able to extrapolate the necessary tables, queries, frequency of access, etc., and come up with ballpark CPU, disk size, and disk performance characteristics (IOPS and throughput).
Unfortunately, the way most people do it these days is they get the basic system working first, test the system with X users and then extrapolate what would be needed for Y users. Database scale is generally fairly linear if the schema and code are written well. Then when the requirements change (which seems to happen much faster than servers get depreciated), they upgrade or downgrade servers to compensate. This is where AWS and other cloud providers shine because if you're constantly changing what you need, it's much easier to switch systems if you don't own the hardware.
Here are some hints for capacity planning:
- If the vast majority of disk access isn't writes or your cache hit ratio is less than 99.5%, you don't have enough RAM. Average Page Life is also an important metric
- SQL server does writes in batches every minute or so. It will max out your disk IOPS no matter how many IOPS your system has during that time. The thing to look at is how long the flushing lasts relative to the period between the flushes
- Logical disk reads often appear as CPU usage (because the pages are in cache), and may indicate the need for an index
- Database data files should be on separate drive sets from other files and IOPS is generally the most important factor for these drives. Temp database should probably also be on it's own drive set and IOPS is also most important here. Log files are on yet another drive set, but throughout is most important for this set
