Raid Configuration for MS SQL server
You're going to have to do quite a bit more work on requirements if you want to do this properly, or you could cheat and buy SSDs and do minimal benchmarking.

Prior to SSDs putting anything on RAID6 for SQL Server was planned out very carefully, and done mostly for read only scenarios.  With the advent of SSDs we can often use RAID 6 with no impact to performance outside of some negligent latency.  

Performance Metrics:

You will want to collect the following metrics at a minimum in Perfmon to see your usage.  Include all data and log files:

-Logical Disk 
--Disk Sec/Read
--Disk Sec/Write
--Disk throughput/sec


RAID Considerations:

You'd want to invest in a good raid controller and with RAID 6 you can suffer a 2 disk outage instead of a single disk outage from RAID 5.  This requires more parity to be calculated and written thus reducing performance but the Samsung 850 Pro line can churn through that very easily.  

File Placement:

The log file and tempdb were almost always split up and depending on your workload/high availability solution/acceptable data loss policy you might still be bound to some of that.  Just note that if you go with 1 big array and the disks go down, you lose the log file data that hasn't been backed up yet either; thus affecting your acceptable data loss policy.

I know it's rather unorthodox to recommend commodity hardware for SQL Server but after using thousands of these hard drives in high throughput and volume environments, I stand by it.

Do note that your disk controller and server are still a single point of failure.  You should also do real HA such as log shipping/mirroring/AGs/etc.