Projecting Simultaneous Database Queries

I'm after some thoughts on how people go about calculating database load for the purposes of capacity planning. I haven't put this on Server Fault because the question is related to measuring just the application rather than defining the infrastructure. In this case, it's someone else's job to worry about that bit! I'm aware there are a huge number of variables here but I'm interested in how others go about getting a sense of rough order of magnitude. This is simply a costing exercise early in a project lifecycle before any specific design has been created so not a lot of info to go on at this stage.

The question I've had put forward from the infrastructure folks is "how many simultaneous users". Let's not debate the rationale of seeking only this one figure; it's just what's been asked for in this case! This is a web front end, SQL Server backend with a fairly fixed, easily quantifiable audience. To nail this down to actual simultaneous requests in a very rough fashion, the way I see it, it comes down to increasingly granular units of measurement:

Total audience
Simultaneous sessions
Simultaneous requests
Simultaneous DB queries

This doesn't account for factors such as web app caching, partial page requests, record volume etc and there's some creative license needed to define frequency of requests per user and number of DB hits and execution time but it seems like a reasonable starting point. I'm also conscious of the need to scale for peak load but that's something else that can be plugged into the simultaneous sessions if required. This is admittedly very basic and I'm sure there's more comprehensive guidance out there. If anyone can share their approach to this exercise or point me towards other resources that might make the process a little less ad hoc