Detailed Proposal
Weighting: 10% | 1,000—1,500 Words | GenAI Tier 2
The mark for this assessment combines two criteria with the following weights: 10% Ethics and 90% Proposal. Further guidance can be found in the marking overview, which also explains when and how feedback will be released. Make sure you know the deadline for this assessment and fully understand our submission policies. Remember that managing your time is an important aspect of the project module. We will be strict with deadlines.
How to Submit
Submit a single document as a PDF file via Canvas by the due date. You can submit up to 7 calendar days late without penalty. You do not need to ask for permission or approval in advance. Just submit when you're ready. Students with a support plan that allows extensions can submit up to 14 calendar days late without penalty.
The purpose of the word count is to give an idea of the amount of work required. It is not a fixed limit and there are no penalties for going over (or being under) the count. The markers will look at how readable and succinct your work is, but this doesn't directly relate to the word count. Say what needs to be said, in as many words as it takes to say it, but do so clearly and without repeating yourself.
Please note that supervisors are under no obligation to read full drafts of your work before you submit it. Most staff will be happy to provide guidance on the overall structure and general content during your regular project meetings, but please don't ask them to make detailed annotations.
Document Structure
The purpose of the detailed proposal is to show that you have a clear idea of what the project involves, and a well-defined plan for realising it. The document should be concise but clear, following the structure outlined below. Aim for around five pages of text and diagrams (not including the title page).
Key Questions
Writing the detailed proposal helps both you and your supervisor to understand what the project is all about, and what the end product will be. At the simplest level it needs to answer three broad questions.
- What will you do?
- How will you do it?
- What will it look like?
Title Page
On the first page you should clearly state the title of the project, your name, and your student ID. You don't need to include the names of the markers or any other details.
Statement of Ethical Compliance
At the start of your proposal you should state the data and participant categories for your project (a letter and a digit) with a sentence to confirm that you will follow our ethical guidance. This can be included on the title page if you like. It's okay if you later change your plans (such as adding an evaluation activity that you didn't mention in this document), provided you update the statement in future assessments and check with your supervisor before starting the activity.
Project Description
This should be a high-level overview of your project, suitable for a reader who isn't an expert in the topic area. This will be most useful for the second marker, who might have no prior knowledge of the project. This first section should be relatively short and succinct, but make sure you answer the key question of what you will be doing on the project. You can add more detail in the later sections.
Aims & Requirements
The aims of your project are broad statements of intent. In other words, what you expect to have achieved after completing the work. You will probably have two or three aims that capture the overall substance of the project, but you can have more if you like. They should be presented as bullet points so they are easy to read and quickly summarise what you intend to do.
You should also include a list of requirements. In other words, things that your software will do. They can be listed in order of priority, or categorised into essential and desirable items. In most cases you will think up this list on your own or in discussion with your supervisor, but in some cases you might want to conduct a requirements analysis activity with other people to find out what they want your software to do. If you involved other people, just list the requirements in this section and talk about how you conducted the analysis later in the document when you cover project ethics.
Key Literature & Background Reading
During the first few weeks of the project you will be conducting background reading and looking at various sources of information. Some will be technical (such as API documentation) and some will cover previous research in the area. In this section you should demonstrate a good knowledge of the topic area, discussing, citing and summarising key literature, and using it to justify your design and development decisions.
Development & Implementation Summary
Bearing in mind that you won't have fully started development when you write the proposal, this section should summarise your plans. Provide a brief overview of your proposed development environment and implementation language, and the reasons why you chose them. Then give a breakdown of the different components of your project, discussing how they complement each other and how they relate to your aims. Also make sure this section covers the key question of how you will implement (realise) your project, including how your workflow will be organised. From this you will be able to identify the different tasks that should appear in your project plan, as well as the activities to include during the testing phase. Each project is different, so you might have little or lots to explain here.
Data Sources
If you are using open source datasets, accessing or processing publicly available text, retrieving data from an API, or generating your own data as part of the project, mention it in this section. You should describe the data you will be using, state how it will be obtained, confirm you are using it with permission, and explain how you will ensure confidentiality and anonymity of any personal information. If you're not using or generating any data, you still need to include this section. Check with your supervisor that there is genuinely no data use, and then include a sentence to confirm that this section doesn't apply to your project. Remember that requirements gathering and evaluation activities will generate data.
Testing & Evaluation
Explain how you will show that your project works technically (testing) and meets your original requirements (evaluation). At this stage you don't have to include a detailed testing plan, since you probably don't know exactly what code will be produced or how everything will work. However, you should at least have a high-level idea of the type of testing and evaluation you will carry out. If you plan to use other people as beta testers, mention it briefly in this section and then explain what they will do in more detail in the next section.
Project Ethics & Human Participants
In this section you should cover any activities that involve human participants. If you conducted a requirements analysis with other people, describe what you did. If you plan to conduct an evaluation with other people, give a detailed overview of the things you will ask participants to do. Explain how you will anonymise, aggregate and protect participant data. Make sure your plans fall within the permitted activities outlined in our ethical guidance.
There could be other ethical considerations that are specific to your project, particularly if your supervisor has obtained separate approval for bespoke activity. If so, discuss them with your supervisor and clearly explain them here. If you think your project has no ethical issues and uses no human data or human participants, you still need to include this section. Check with your supervisor that there is genuinely nothing to say, and then include a sentence to confirm that this section does not apply to your project.
UI/UX Mockup
At this point in the project you probably won't have a full design for whatever you are developing, but you will have a rough idea of what the UI (user interface) and UX (user experience) will be. This section should answer the key question of what your project will look like. Include a mockup of the user interface, either as a wireframe drawing or a pencil sketch that you scanned in. It doesn't have to be perfect, complete, or show every possible user interaction, and you might change the design later. It just needs to be enough to show that you have thought about what the software will look like and how it will be used.
If your project involves building an API, framework, or web service, and there is genuinely no user interface, you should list some example interactions (such as API calls, service endpoints, subroutines, etc.) and explain how they will be used. If users will only interact with your software via a command-line interface, list some of the potential commands and outputs, and describe the user experience rather than drawing it.
Project Plan
Include a Gantt chart (or similar project plan) with enough detail to show each stage of your project and your estimates for their duration. Show aspects that can overlap, activities that have dependencies, and so on. Remember to include time for presenting the project and writing the dissertation.
Risks & Contingency Plans
This section should be presented as a table with four columns: Risks, Contingencies, Likelihood and Impact. Common risks for all projects include hardware failure, software failure, running out of time, and programming problems. List possible risks in the first column, and your plans for preventing or handling them in the second column. The third column should state how likely you think the risk is (low, medium or high) and the final column should state the impact. Sometimes things with very low likelihood, such as losing your backups, could have a very high impact on the project.
References
List references to articles, websites, videos, datasets, journals, and any other background reading you carried out while writing the document and planning your project. References should be cited properly in the main body of the document. You should use the Harvard or IEEE referencing style. Guidance is available on the university library website. Most references will come from online sources, in which case you should also provide relevant links. Almost all academic papers (and some other types of publication) will have a DOI (Digital Object Identifier). You should always provide the DOI if one exists, since it is more permanent than a normal web link.
References should be genuine and will be checked. There is no need to worry if you don’t have many references. Each project is different and your supervisor will advise if they think you have missed anything useful. Using generative AI to make your reference list look longer will be treated as academic misconduct.