Ethical Guidance

The university has a duty of care to ensure that projects are conducted in an ethical manner, that human participants are treated fairly, and that human data is processed in line with current regulations such as GDPR. The university's Policy on Research Ethics provides a framework to ensure that all projects are conducted in accordance with fundamental ethical principles.

Computer Science projects are classified as low risk. Many involve no other human participants or human data at all, but you should still follow the Code of Conduct of the Chartered Institute for IT throughout your project. The department has collective ethics approval for projects that involve humans only in requirements analysis and evaluation activities, and human data only in aggregated, anonymous formats. The permitted types of activity are explained below. Please read this guidance fully before embarking on the project, so you know what to expect and understand the ethical boundaries.

If your project involves human participants or human data in any activity that is not covered by this guidance, or you are concerned that your supervisor is asking you to do something outside these general ethical boundaries, you should not proceed. Cease work immediately and inform the module coordinator.

If you want to suggest your own project topic, your plans must fall within the activities for which we have collective approval, since it would take too long to apply for and receive individual approval for anything else. Supervisors can apply for individual approval for projects that fall outside this guidance, provided they do this well in advance of the project launch. This should be noted in the project description. If you are in any doubt about the ethics of a listed project, please check with the module coordinator before selecting it.

You are reminded that the module learning outcomes expect you to articulate ethical issues and follow relevant professional codes of practice. Your assessments must include a statement of ethical compliance. If you do not include the statement in the required format, you will not have met the learning outcomes for the project module and might receive a failing mark.

Public & Research Data Sources

You are allowed to use open data sources provided by governments and other organisations, open resources generated by publicly funded research, and data from public APIs. Check licensing terms, copyright notices and fair use policies to be certain you have permission to use the data before you access or download it. If you are in any doubt, check with your supervisor. In your first assessment you should describe the data you will be using, explain how it will be obtained, and confirm you are using it with permission. If the data forms a substantive part of your project, you should mention it in your dissertation acknowledgements. In all cases, you should properly cite and reference the source.

Human Subjects, Human Tissue and Animals

Your project must not directly involve any experiments with human subjects, human tissue, or animals, as this falls well outside our ethical boundaries. Note that you can use data derived from experiments or studies that other people have published, provided it is fully anonymised and does not identify any individuals. For example, you could train a machine learning model with a database of urine samples, or build a visualisation from a database of bird migration patterns. Data must be fully anonymised before you access or download it, and you must have permission to process it.

Data Categories

Your project will fall into one of the following data categories, depending on what type of data you are using. Note that ethical considerations only apply to data about humans and animals. If you're using another kind of data (or no data at all), you would select category A.

Social media companies usually provide public APIs through which you can access data, and these fall within category C. Provided you access them with permission, you can use these APIs to extract anonymous data, such as the text of tweets. However, you must not store usernames or real names that could be used to identify individuals. If these are provided as part of the API data, you should discard them or use a one-way hash function to obfuscate them. You should not access images from social media if they are likely to contain identifiable humans. Other images can be accessed according to the terms and conditions for the relevant API.

Category D includes medical data derived from humans, provided it has already been fully anonymised before you access it. This also includes images of small parts of the human body from which no individual could be identified. You might be building an app to detect diabetes by looking at retinal scans, or an app to detect melanoma from photos of skin blemishes. These types of project are permitted provided the database of images comes from an open source, and you have permission to access it.

Data from category E can only be used in very limited circumstances. For example, if you are building an app to scan faces and detect emotion, you will need a large database of face pictures to train your machine learning model. Such databases do exist for academic and research purposes, and should have already been identified as suitable by your supervisor before the project starts.

You should not be involved in generating new data sets via surveys, experiments or any other activity involving humans or animals. Nor should you access or use any data that contains personal identifying information. If you do, this will be treated as academic misconduct.

Human Participant Categories

Our collective approval covers the use of human participants only in requirements analysis and software evaluation activities. Your project will fall into one of the following categories.

Very few projects involve requirements analysis in the software engineering sense. The most likely reason for this would be if your project has an external client and you need to speak to them or their colleagues. Your project falls into this category if you will need to speak to anyone other than your supervisor about what they want or expect your software to do. Talking to your supervisor about their project idea, or to help flesh out your own idea, does not fall under this guidance.

Most software development projects will benefit from evaluation with other users. Your project falls into this category if you will ask other people to use your software (or watch you using it) and provide feedback via any of the permitted activities. Testing your own software as it is developed, and then running the software to check for issues, does not fall under this guidance if you are the only person involved.

Please note that conducting a survey is explicitly not permitted as a primary project topic. It meets neither the module learning outcomes nor the project criteria of our programme accreditation. You can use a small questionnaire as part of your requirements analysis or evaluation, but any other kind of survey using human participants will be treated as academic misconduct.

Obtaining Participant Consent

If you plan to conduct requirements analysis or software evaluation with other people, you must ensure you recruit and treat them ethically. The following guidelines must be followed.

• You should not expose participants to any sensitive topics or require them to reveal sensitive information. Where necessary, ask them to enter dummy (false) data into your software.
• You should only use participants who can give informed consent (so that means not using children or anyone with a learning or communication impairment).
• You should only carry out activities that are permitted under this guidance.
• You should explain to participants that their involvement is voluntary and they can drop out at any time. If they drop out, you should delete any data collected from them.
• You should make it clear that they are taking part in a University of Liverpool project that follows our policy on research ethics.

You should give a participant information sheet to everyone who takes part. This will cover the final two bullet points for you. Each person must also sign a participant consent form (it's okay to do this electronically by entering an X or initials into the box). Links to these documents are provided at the top of this page. Please use the documents provided, which have been approved by the university ethics panel. Do not make your own versions of these documents. You should email the completed forms to your supervisor. Scan them in if you used paper versions, then destroy the originals. They will be retained until the project module has been marked and processed by the boards of examiners, then they will be deleted.

Permitted Activities

You can involve participants in any of the following activities. Tick the relevant boxes on the participant consent form so they know what to expect. You can conduct these activities with individuals or with a group of people at the same time.

• Interviews — Asking participants a series of questions to find out what they want your software to do (requirements), or what they think of the finished product (evaluation). The questions should be included as an appendix in your dissertation.
• Discussions — Similar to interviews, but conducted in a way that allows follow-up questions, tangential conversations, and so on. You might start with a basic set of questions or things to find out, but let the discussion flow naturally.
• Observations — Watching participants use an existing piece of software or carry out a manual process that your software will automate or improve, or watching them use your finished product to see how they interact with it.
• Narrations — Asking participants to speak aloud as they use software or perform a manual task, to describe what they are doing and why they are doing it that way. This is the same activity as observations but with more structured talking.
• Questionnaires — The participants answer a set of questions, usually via an online survey. This is more useful when there are lots of participants or you don't need to be physically in the same room as them. The questions should be included as an appendix in your dissertation.

With the permission of participants, you can make audio recordings of what they say as they take part in these activities, so you can focus on running the activity instead of making written notes. If you do this, you should transcribe the audio as soon as possible afterwards and then delete the original recordings. Note that you cannot make video recordings of participants. If you need to see what they are doing, conduct a live observation or narration.

If the activity involves using software, you can use screen recordings to capture what participants are doing, where they are clicking, and so on. You can match this with audio recordings. You should take care not to record personal or private information by mistake. For example, if you are recording a mobile phone screen, ask the participants to turn off notifications from other apps so they are not accidentally captured. Make sure there is nothing personal in the background of desktop recordings. Do not record users as they enter login credentials, unless it's part of the evaluation of a login process for your software, in which case they should be using dummy credentials.

Protecting Participant Data

Participant data includes anything obtained from other people as you conduct your requirements analysis or software evaluation. This might include their name, initials, or some other way to identify them before you aggregate the results, along with the data they provide, such as interview transcripts, audio recordings, screen recordings, questionnaire results, the data they input into your software as they use it, and data about how they use it (for example, log files and crash dumps). Such data should always be treated according to the following rules.

• Should only be collected with the permission of the participants.
• Should be stored securely on a password-protected computer or your university file store.
• Should not be shared with anyone else.
• Should be deleted after graduation.

When you have collected data from all participants (or sooner if possible) you can start to aggregate it. That means taking the individual answers and combining them into anonymous results (tables, statistics, comments) that can then be included in your assessments. Unless you use an online questionnaire (which automatically aggregates answers), use a separate piece of paper or file for each participant. If they ask to withdraw from the activity, or later ask you to delete their data, you can do this easily by destroying the paper or file. After you have aggregated all responses into an anonymous format, you must destroy or delete the original data so there is no possibility of anyone being identified.

When you write your dissertation you will probably want to include text and comments from participants. In all cases this should be anonymised, and you should make sure you have their permission to use what they said. You should not use any comments (or any other kind of data) that could inadvertently identify anyone.

Software Evaluation with Dummy Data

It's likely that you will require participants to enter data into your software so they can fully evaluate it. They should be advised to enter 'false' data to avoid any possibility of personal information being stored or processed by your software. For example, if you are creating an app to advise on diet and exercise, you would probably want users to enter their age and weight, and possibly other personal items. During development, you can perform unit tests and input validation by pretending to be other people and entering dummy data. During evaluation, participants should not need to enter real data because their focus should be to provide feedback on things like appearance, overall functionality, navigation, and so on. This can be achieved just as successfully with 'fake' data.

If your software has a 'sign up' or 'registration' function to create user accounts, you will need to test that this works, but you can do so by pretending to be other people and creating fake accounts. If you ask participants to test the registration function during evaluation, advise them to enter false details. Do not under any circumstances collect real names, addresses, photos, location data, passwords, or any other personal information that could compromise anonymity or security.

If you are building a mobile app, you might want to use Apple's TestFlight facility or Google's Play Console. These systems allow you to deploy your apps to beta testers and collect data about how the app performs, along with other metrics. To do this, you will need to obtain the Apple or Google ID of each participant, which is usually an email address. You must obtain their permission to use their ID in this way (by including it on the participant consent form), and you should only use it for this purpose. If a participant doesn't want to give you their ID, they can still take part in your evaluation if you allow them to use the app on your own device.