You need the following mark scheme headings in a(ii) of your project:

• Describe how the user requirements were ascertained.
• Results of the investigation.
• Analysis of the results of the investigation.
• User requirements.
• Hardware and software requirements.

Remember - approach this section as if you were providing information for someone else to design the system. Your final Requirements Specification must so detailed that someone else could pick it up and design a system that meets the requirements in this document.

Describe how the user requirements were ascertained.
What don't you know that you need to know? Think about the different areas in this project you need to know about. (What hardware / software does your user have, what skills do they have, who needs access to the data, what data needs to be stored, what rules for each of the data items need to be applied, what do they want the system to do, what printouts are required, what information on the printouts etc etc etc ). What exactly do you need to find out? How will you find out what you need to find out? Describe how you prepared and planned any interviews? How did you arrange any interviews? What about follow-up questions? Did you need to ask follow-up questions? (I'd be surprised if you didn't - few people get all the information they need from one interview first time!) How did you do this? Why that method? Describe in detail the process. Any other methods used? Why did you use them? Describe how? Mention your user by name.

Results of the investigation.
Clearly document the results of your fact-finding: interview Q&A, emails sent and received, example documents collected, questionnaires done and so on. Make sure each piece of paper clearly describes what it is. Don't assume that someone will know what that example of a membership form is and why you collected it.

Analysis of the results of the investigation.
Summarise what you found out. What did you learn? What information do you now have that you needed, that you didn't have before?

User requirements.
Produce a Requirements Specification that specifies what you will do for your user. By the end of the project, what will your user be able to do with your system? Typically, you should start by producing a 'Draft Requirements Specification'. you then state that you need to check this with your user. You may also identify gaps where it isn't detailed enough for someone else to use to design a system. You then go back to your user and get further information to clarify points. You them produce a 'Final Requirements Specification'. You then go back to your user to check it. If they are happy, both you and they sign and date a copy of the final User Requirements Specification on headed paper (your school's is fine). (You sometimes need to see your user to modify the specification quite a number of times). All of the above needs to be clearly documented. Don't forget the diary entries.

Aim for 6 User requirements - any more and you really are making a lot of work for yourself. They should include requirements that allow the processing of data to occur, searches to take place, data to be reorganised, for example. Your Requirements should be selected so that you can demonstrate clear programming skills. If they are trivial, you won't have opportunities to collect lots of marks in Section C.

Hardware and software requirements.
Now you have the Requirements Specification, you know what you need to design and make for your user. Now describe a suitable hardware and software specification, taking into account what they already have and use. What hardware do they need? What software do they need? Justify your choices by discussing the needs of your user.

CHECK:

ARE YOU USING YOUR TEMPLATE(S)?

ARE YOU USING REPORT WRITING STYLE?

HAVE YOU BEEN UPDATING YOUR DIARY?