With RAM sizing it is important to know what your likely "working set" is, and make sure you have enough RAM for that multiplied a couple of times as a minimum. Your normal working set is all the index and data pages that are commonly used and being able to hold it all in RAM with sufficient space to spare for "more exceptional but still not uncommon" queries will reduce disk I/O needed for read operations considerably.
For instance a 10Gb database (smaller than yours by a considerable amount, but the theory holds what-ever your data size) for one of out client's applications contains about 1Gb of active data pages: indexes and table rows that are likely to be accessed routinely as users go about their normal business. Another ~4Gb is older data that isn't read in most normal sessions (as most views default to only showing at most a month or three of data, and the data, indexes and queries are well planned enough that older data pages aren't going to be read unless the user asks to see something further back in time (which is relatively rare in day-to-day use). The final ~5Gb is blobs - documents that the users have attached to records and that are rarely accessed more than a short while after being added except during an audit. Even with this size of data, I doubt 2Gb RAM would be enough to maintain speedy access (the DB I'm talking about lives on a 4Gb server dedicated to running MSSQL, another machine acts as web server and other services related to the app) so you might need to rethink you RAM size for your data size - RAM is relatively cheap these days so assuming your server can manage the extra bumping it up to 8, 12, or even 16Gb may give your a good return on investment performance wise.
For when disk I/O can not be avoided, I would move away from RAID5 and RAID6 if you data sees a lot of write activity. Standard RAID10 (or slightly less standard RAID10 arrangements like those offered by the Linux RAID10 driver and some hardware solutions) will perform as well for most read loads, noticeably better for most write loads, and offers similar redundancy (any one drive can fail). If you don't want to jump to four drives, you can try three-drive RAID10 (called RAID1E by most IBM controllers) if supported by your environment. Also it is very much worth considering splitting your array into two as TomTom suggests. For write operations you are likely to find that having the transaction log on on RAID1 array of two drives and the data files on another will perform significantly better than using RAID10 - the near-RAID0 bulk-read performance of RAID10 can quickly be killed by the random access nature of database writes (updating data and index pages that may be spread over the filespace, updating the transaction log before committing data to the data files and marking it as committed in the log when done, and so on). Separating log and data file activity over different spindles can significantly boost database performance in many cases. If you have enough room for the required drives, keeping tempdb (or what-ever your RDBMS's equivelant to MS's tempdb) and such on a third array can make a significant difference too if your queries and stored procedures make heavy use of temporary tables (it can sometime be surprising in how many circumstances the query planner will consider using tempdb behind your back!). Of course using SSDs can be an answer to random access performance too - whether you'd get better a better price/performance ratio with those or other array arrangements (or those and other array arrangements) depends significantly on your DB(s) and typical access patterns.
One other thing: before investing time+effort+money in rearranging your I/O subsystem, make sure you run some performance metrics at busy times to make sure you don't have any bad procedures that are heavily CPU bound. Sometimes complex procedures (particularly those that use cursors in less than optimal ways) can peg the CPU+memory subsystem for lengthy times (adding more RAM and better I/O capability will make little difference here) and can often be optimised significantly by rethinking the cursors/loops or managing to remove them altogether. A mix of custom SQL trace logging and Windows Performance Monitor logging (or equivalent monitoring tools for people using a different OS+DB combination) can be a great help in finding where your key bottlenecks really are (memory starvation, I/O performance, less than optimal code, ...) and you should trying to fix a problem until you are relatively certain you are fixing the right problem.