Fundamentally, Operating Systems manage tradeoffs. These tradeoffs are driven by observed user behavior. For example, if all the processes were observed to be short, then the OS schedulers are optimized for short tasks. Note the chicken and egg problem here - the first studies don't have enough users and hence initial policies are built based on unrealistic models. Once you optimize the OS for small tasks, future application writers change their program that could have benefited from large tasks to instead use small tasks so as to achieve good performance. Thus, the initial workload defines future systems (perhaps unintentionally).
Regardless, there had been some classical measurement papers which have heavily influenced systems development. For example, the file system measurement study (scheduled for 11/4/08) have had enormous impact on file system study. An excellent presentation on how to measure Computer Systems was presented by Prof. Seltzer @ Harvard (PDF). A word of caution, as half of a course project, I am not expecting you to measure something to the same scope as what Prof. Seltzer mentions. Regardless, a simple measurement project that is scientifically valid is preferable to a large measurement project where we have no idea on what is being measured.
Measuring systems tend to be the first step before proposing solutions to solve some problem. On the other hand, it pays to be open to go where the data takes you. The key to a successful measurement project is: a) have a clear idea on what you want to measure. Try to understand what you are measuring, what the expected behavior will look like and how you might recognize such a behavior. Try to think of what might be surprising and what might be expected. b) Device a data collection methodology which will capture your system. This involves researching some exiting tools to measure the system. More importantly, you need to clearly understand the limitations of what you are collecting. You ability to convince others that you had measured something interesting depends on your ability to convince others that your collection methodlogy was sound. For example, suppose you want to measure file system write calls. Suppose that you observe that a particular system was creating a million writes a second. You need to clearly understand (and be able to explain) how your measurement system did not perturb the system and that the million writes are not really caused by you (say by your data collection tool logging write updates to the same file system). c) Clearly describe what you learnt from the collected data. Elementary statistics suggests that you need to repeat experiments in order to produce statistically valid results). Such an understanding will make the solution to this problem fairly obvious.
Note that, once you started working on project 1 and find that you can extend it to perform a more thorough measurement that might be useful/publishable on its own right, talk to me.