THE TERMS OF REFERENCE

The Terms of Reference are a critical element of the project and the yardstick against which the project will be measured. Give your Terms of Reference a cover page that shows:
- The module name and number (CM0645: Individual Project),
- The heading ‘Project Terms of Reference',
- Your full name, student ID and course,
- The project title,
- The names of your supervisor and second marker.
- The project type: General Computing Project, Investigative Project or Software Engineering Project.
The Terms of Reference should contain the following sections:

a) Project title
Give the project a short, clear, title that identifies the main subject of the project. This is a working title and can be changed if necessary.

b) Background to Project
This should describe the "context" of the proposed project and answer the question, "Why this project?", both from your own perspective as a student undertaking a final year computing project, and that of any client. It should show what makes this proposal a worthwhile computing final year project. It must make clear both the application area or area of investigation and the computing aspects of your work.
It will be helpful to start by briefly stating the nature of the product that you intend to produce or the research question that you intend to investigate.

After that, describe the problem domain you will be working in. This may include a practical context - for example, a client organisation and its needs. It will certainly involve introducing the field in which you will be working. For example, what previous work suggested your research question?What ideas will be important to defining and carrying out your project? For software engineering projects in particular, it will usually be appropriate to introduce the general features of the kind of application you are trying to build, and ideas related to the problem that you will investigate in your literature review.

You should by now have done a fair amount of reading about the area, to put your ideas into context and to ensure that the project idea is valid and viable, and identified some useful literature about the problem that you are trying to solve or investigate; One reason for doing this is to show that you will be able to find the useful and interesting ideas and information that your project will need. This requires references! It is also a good chance for you to practise the academic style of writing needed for your report.

Indicate why the proposed projectis of interest, both to you and more generally, and why it is useful and to whom. For example, where did the idea come from? Was it requested by your client, or does it arise from your supervisor's research? Did some problem you encountered in real life or a paper that you read in the literature suggest a research question? Will it benefit a client - and how? What problems will you need to solve? Will you be using interesting or unfamiliar technologies? What is challenging? (Remember that the project will stretch you beyond what you have achieved in other assignments.)

A common fault with Terms of Reference is for the background section to be too short and superficial. A good background is usually at least two pages in length, and a very short background suggests that you haven't explored the area in sufficient depth to know that the project is interesting and feasible. Note that you will usually have to carry out some sort of investigation to develop the background and rationale section of your ToR; in other words, you will have started on the reading that you will continue into your analysis work.

c) Proposed work
This section follows directly from the background, and should give more details of what you are proposing to do. The project must exhibit a level of difficulty appropriate to final year honours BSc work, and be of a size that can be attempted in the time available; this section should define the topic and project work in enough detail for the markers to be sure that it is suitable. The more detail and discussion you produce at this stage, the stronger the foundation for the actual project work.
You should emphasise the computing aspects you expect to be involved in, including those specifically relevant to your programme. Remember that you are undertaking the project as part of a BSc programme in a computing-related discipline, and avoid being side-tracked into areas that are not relevant to your course.)
Make sure that you include the following:
- A brief description of the work involved in carrying out the project and your approach to the development or investigation. Bring out the technical aspects as well as the general processes.
- What areas or questions will you need to investigate in order to carry out the project work? What topic(s) will your literature review cover and how does it help the project?
- Any further details of the product to be built or practical investigative work that will help to define the size and scope of the project.
- What computing technologies will be used and why? (If you will be deciding this as part of the project work, say so, and indicate the possibilities.)
This is one of the most important sections of your ToR. After reading this part of your ToR, the reader should know what would be involved in undertaking the project.

d) Aims of project
An overall statement of what the project is intended to accomplish. This should be expressed in terms relating to the project, not personal achievements. There will normally be only one or two aims. If you have more than three, then revise them since they will normally be inappropriate as aims.
The following are examples of project aims:

Project 1 (General.):
- "To investigate and analyse the importance of the role of schedulability of real time systems.
- To develop a learning tool that would help people to understand the importance of schedulability and carry out a schedulability analysis of real time systems."

Project 2 (Investigative.):
- "To compare the effects of flat and deep menu structures on users' website navigation performance."
Project 3 (Software Engineering):
- "To investigate how an e-card service is made and the types of database that can be used to store images."
- "To build an e-card service to allow a user to manipulate images and create their own e-card."
Note the English style in which aims are expressed, and use the same style yourself.

e) Objectives
Each objective should identify an expected outcome. By the end of the project, it should be obvious to you and your supervisor whether you have accomplished an objective or not, although it may be debatable as to how well you have accomplished it. Thus each objective must be clear, measurable and concrete. (The ‘SMART' acronym is helpful here.) Phrase them so that it is clear what will show that the objective has been achieved. For example,
‘Create a requirements specification for...' is more exact than,
‘Identify requirements for...'.
Projects for this module typically have 7-12 objectives, relating to areas such as:
- Literature review
- Establishing requirements
- Learning new/enhanced knowledge/skills,
- Creation of designs for a product
- Implementing a product
- Experimental work
- Production of items of systems/software documentation
- Testing a product
- Production of chapters of the project report
- Analysis of investigation results
- Evaluation of a product.
- Evaluation of the project process,
- Etc.
If you have more than one aim, then you should be able to associate objective(s) with each aim. To produce your project plan, you will identify the tasks needed to achieve your objectives.

f) Skills
The purpose of this section is to help you and your supervisor to assess how strong a base of learning you are building on, and whether the enhancements of your knowledge and skills that the project will require are feasible. Projects should generally be relevant to your degree course, e.g. students taking Web Design and Development should do projects that use skills relevant to that area and build on modules from that course.
Identify and list the skills that you will need to carry out the project work. You should explicitly identify both familiar areas of knowledge and skills and new/enhanced ones that the project will require. Against each, indicate which module that you have taken or are taking gives you those skills. If you will be acquiring skills during the course of your project, say how this will be done.

g) Sources of information / bibliography
This is simply a reference list and bibliography, presented in the usual format. Include the sources have you consulted in preparing the Terms of Reference and any additional sources that you anticipate using during the work. It is not expected that you will yet have identified all the information that you will use. Ensure that you follow standard referencing guidelines.

h) Resources - statement of hardware / software required
The purpose of this section is to ensure that all the resources needed for the project are in fact available for it.
Identify and justify the software, computer hardware or any other equipment that you require for the project. You should also indicate how it will be provided, and its purpose in the project. A bulleted list that gives this information for each item is sufficient.
Consider carefully how you would cope if resources were not available; what alternative resources might be employed. This is particularly important if you intend to use your own equipment or that of an external body.
Note that you will need to demonstrate your product at the university. It is important to plan how this will be achieved. Your list of resources should include those needed for the demonstration.

Where relevant, you may use your own computer for part or all of the practical work, provided that it is suitable for the purpose, as agreed by the supervisor, and that all proprietary software is properly licensed for the machine on which it is running.Similarly, hardware and software provided by a client may be used, under the same conditions.

All software used in your project at any point must be used with the necessary licenses or permissions for that machine. This includes software on your own machine and software used in the demonstration/viva. Do not make illegal copies, whatever the cost of the software in question. You may be able to find a free alternative, or to use software that is available in the School labs, or to choose a different approach. Software piracy is not acceptable under any circumstances.

i) Structure and contents of project report
The report structure must correspond to the chosen type of project (General Computing Project, Investigative Project or Software Engineering Project.) You should produce the following::

(i) Report structure.
Give a list of planned chapter titles with a brief description of each - see the sections of this handbook that discuss the report for your chosen type of project.
All the chapters should be cross-referenced to the objectives in (d).
The headings given in the marking scheme may provide an appropriate basis for the report structure.

(ii) List of appendices.
An agreed list of documents to appear in the appendices; e.g. requirements specification, design documents, source coding, test plans and results, experimental data, documents used in investigative work. It may not be necessary for full documentation for a software product to be included in the report - for example, extensive code or large files of test data may be best presented on CD. However, it should be available for assessment - see the section "The Product and Documentation." For all projects, Appendix A must be the agreed Terms of Reference.
It should be possible to see a clear relationship between the report contents and the objectives.

j) Marking Scheme
This section contains three items: the type of project, the allocation of report chapters between sections of the report marking scheme, and criteria for marking the product or practical work.
You should study the marking scheme for your chosen project type before writing this section.

(i) Project Type.
State whether this is a General Computing Project, an Investigative Project or a Software Engineering Project. Your work will be marked according to yourchosenmarking scheme. The general framework for each marking scheme is fixed, and given elsewhere in this handbook. However, some aspects need to be specified here.

(ii) Project Report:
For the body of the report, specify which chapter(s) and/or section(s) of chapter(s) correspond to each section of the marking scheme. This can be done by listing the chapters in each of:
- Introduction
- Analysis
- Synthesis
- Evaluation, Conclusions& Recommendations.

The third element of this section will be either Product or Quality of Practical Work. This is the part of the TOR that many people find the most difficult, as you are asked to agree the criteria on which your product or practical investigative work will be assessed.

You should agree these criteria with your supervisor and second marker at the TOR review meeting, and you are strongly advised to review them with your supervisor early in semester 2, to ensure that they still reflect the planned direction of your project. Changes may be agreed at that point, and recorded in your log book.

(iii) Product (General and Software Engineering Projects only)
The product does not only consist of the final software or hardware, but also of all the associated deliverables that you use to product it, e.g. requirements specifications, design models, test plans and results, etc.

Product marks are divided between two main criteria: ‘Fitness for Purpose' and ‘Build Quality'. The breakdown between these is as follows:

Fitnessfor Purpose
Build Quality

General Computing Project 50% 50%

The criteria are described fully in the product marking schemes for each type of project, which you should study carefully before writing this section of your TOR.

Listall the deliverables (finished software/hardware, specifications, prototypes etc.) that will form part of your product.
Then list the criteria on which fitness for purpose and build quality will be assessed. Some of these are provided in the marking scheme, and you may add others. Marks for these elements may also be apportioned within the weighting for Fitness for Purpose and Build Quality.(Looking at the marking scheme will probably make this clearer!)

For a General Computing Project:
Fitness for Purpose always includes the meeting of requirements, but other criteria are defined as appropriate to the project. Where the product is software, the criteria used for Software Engineering Projects are often appropriate.

In the event that you do not specify criteria, a set of default criteria and weightings is provided; however, these may be less suitable than criteria defined specifically for your project.

(iii) Quality of Practical Work (Investigative Projects only)

The Synthesis section of the marking scheme for Investigative Projects includes assessment of the practical work that you have done. In this section of the TOR, you must specify the criteria on which your practical work will be assessed. These will vary widely between projects, and you should choose criteria appropriate to the kind of work that you are doing. Some of these criteria may relate to the quality of deliverables produced, such as an experimental setup that you have built, a dataset that you have constructed, a questionnaire, simple prototype, etc. Others may relate to the way that you have carried out your investigation. Ensure that the deliverables and criteria chosen will demonstrate your use of practical computing skills relevant to your course. The criterion, ‘Compliance with any relevant ethical and safety guidelines,' must always be included and is printed on the marking form.

Remember that your markers will need to be able to assess your work on these criteria. You should indicate what evidence will be provided; this will usually be included in your appendices, but may be elsewhere in your submission.
k) Project Plan - Schedule of activities

A detailed statement of the stages of the project is required. A Gantt chart should be used for expressing the schedule, together with supporting information. Identify the tasks needed to achieve each objective, estimate how long they will take, plan when they should be done, and include these tasks in your Gantt chart.

Your schedule must clearly indicate for each task the number of hours' work required to accomplish it and the elapsed time over which this work should be done. The schedule should be expressed in weeks. Months do not allow for sufficiently detailed planning and control. Days are too detailed; in practice you will not yet know your daily workload in the second semester, so you cannot meaningfully plan down to the day. It is sensible to consult your assignment schedule when you make your project plan, and to avoid overloading yourself at times when you have other major commitments, but remember that your project is the largest and most important module of the year!