My preferred method for stress testing is to setup a pure test system, with only one user on it. Use SQL Profiler to record their session, and have them put the application you wish to stress test through its paces, giving the application the kind of usage that they expect power users to give it.
Examine the script, looking for what data is session driven (for example client number, invoice id, etc), since these things need to change for each test session. Create a large number of test scripts by editing copies of the original profiler session, changing the session dependant data... Generate WAY more scripts than you expect to need.
Start to run the scripts in parallel with each other. Start with two, then four, etc.
Watch for conflicts caused by "bottlenecks", where a single process (like searching for a client) might be single threaded by design, because these can kill your test. The most obvious sign of this is when all of the scripts seem to "gang pile" on a single SQL statement, which is often a stored procedure. If there are any, these single-threaded bottle necks need to be corrected before you can do the real stress test.
Now you need to switch to testing on the proposed production configuration (hardware, software, etc). You also need to decide if caching is acceptable, or if you need to restart the server before each flight of tests.
Once you've cleared any single threaded bottle necks, you can start real testing. Run the first script, and time it. Run two, then four, then more, timing from the start of the first script to the end of the last script in each "flight" of scripts. This gives you the total time needed for that test, even though individual sessions might finish much faster for any number of reasons.
Increase the load (more sessions per flight) until you reach 200-300 percent of your expected production load. At the very least, I'd recommend five tests at every 25% (25, 50, 75, 100, 125, 150...300) of your expected production load. For presentation, throw out the fastest and slowest run at each testing threshold, since they'll tend to skew your test data.