Requirements

Possibly the most important part of the documentation! 3 Sides minimum

A detailed numbered list that clearly states what is needed to solve the problem (conduct the investigation).

Each numbered requirement must be SMART (Specific, Measurable, Achievable, Realistic, Time bonded,)   

How to create a list of requirements: 

Read your analysis, especially the dialog... Make short notes as you read it... list the parts of the problem/investigation and the actions required to solve it...  this long list needs to be organised and clarified so, your 3rd party can clearly understand and agree that your list is what is required to solve the problem.

Specific:   Start with High Level (Top-Down) requirements that cover an area that is required:  THEN split it into it's constituent parts..... Keep splitting until you have individual elements  (feel free to combine IF it help readability).  Make sure there is only one way of interpreting what is required 

Measurable:  At the end of the project you need to state if your system satisfies the Requirements. How are you going to measure if your system provides what is required?   Are you sure that you will be able to assess if that requirements has been met?

Achievable, Realistic, Time-bonded :   Can you create a system that will meet the requirements... By the end of February?  using the tech and skills you have (or can acquire) .

YOU DON'T NEED TO JUSTIFY WHY EACH REQUIREMENT IS SMART! BUT you may wish to include a list of elements of the system that you have excluded because you felt they were unachievable in the time...   a list of Constraints and Limitations is also useful to help justify why you are not addressing some parts of the system.

There are marks for how "COMPLETE" your system is ....   if your requirements meets all the needs of the user AND you complete all the requirements in your system and it is clearly documented you get full marks :) 

  From the Mark Scheme:

• Fully or nearly fully scoped analysis of a real problem, presented in a way that a third party can understand.
• Requirements fully documented in a set of measurable and appropriate specific objectives, covering all required functionality of the solution or areas of investigation.
• Requirements arrived at by considering, through dialogue, the needs of the intended users of the system, or recipients of the outcomes for investigative projects.
• Problem sufficiently well modelled to be of use in subsequent stages.