OU blog

Personal Blogs

Christopher Douce

TM470 Considering LSEPI (again)

Visible to anyone in the world
Edited by Christopher Douce, Friday, 4 Oct 2024, 16:03

This post follows on from an earlier post: TM470 Considering LSEPI. The difference between this blog and the earlier one is that this article places more emphasis on the ethics bit, specifically, how to treat participants ethically.

Before looking at anything specific, it’s useful to remind ourselves of what learning outcomes in TM470 relate to ethics:

LO10. Identify and address the legal, social, ethical and professional issues (LSEPIs) and the equality, diversity and inclusion (EDI) concerns that may arise during the development and use of computing and IT systems.

To gain a distinction for this learning outcome, you need to provide evidence to show that you have “comprehensively identified the relevant LSEPIs and EDI concerns arising during development and use and modified their project work to take these into account and behaved professionally in all aspects of [your] project work.”

At the beginning of your project it is very likely that you will be gathering requirements from stakeholders. During the middle of your project, you may well ask stakeholders for opinions about your intermediate designs, or emerging solutions; maybe asking their opinions about some prototypes. Towards the end of your project, you may (or may not) choose to carry out an evaluation. Your final project evaluation may involve stakeholders, who might be potential users of whatever product or system you have created.

Treating participants ethically

Given that you are likely to use participants throughout your project, what do you need to ensure they are treated in an ethical way?

A fellow TM470 tutor, Kawal Banga, offers the following useful summary: “you will need to consider how you are collecting data, where you are storing it, what stakeholder contact details you are storing, how you are ensuring anonymity and confidentiality, what will happen with the data on completion of the project, etc.“

Hold onto these points. 

Planning your project

TMA 1 is all about identifying a project, describing its aims, creating a plan and sharing it with your tutor. TMA 2 is all about showing that you have made some progress on your project and beginning to write about the ethical issues.

TMA01 states that:

“You will be considering in detail any legal, social, ethical and professional issues relating to your choice in TMA 02, but at this point you should consider whether these are likely to be serious enough to mean your project choice is inappropriate.”

It directs you to read some resources that have been prepared by the module team.

Before you begin writing your first TMA, do make sure you find the time to have a discussion with your tutor about your project and its aims.

In many cases, one of the first activities that you will carry out will be to establish requirements which may mean that you will need to talk to stakeholders. A stakeholder is, of course, anyone who has a vested interest in your project, or will be affected by its implementation or creation. Before you speak with anyone, you need to consider (as Kawal pointed out) how to collect data, what data you are collecting, and where you might be storing it.

TMA02 states that:

“If your project involves you working with human participants, you should include, as an appendix, your TMA02 LSEPI Form, found in the LSEPI Templates folder.” 

The point being made here is that you may need to address ethical issues before you get to your second TMA. Gathering requirements may mean working with people.

Working with stakeholders

When gathering requirements, if you need to consult people, it is important that you seek permission from those who you speak with and their line managers. Here is a suggestion about different resources that you should consider preparing before you interview anyone:

A project information sheet. This could be a single printed page, which you could then read before you go ahead with any data collection.

A consent form. This form is used to secure permission to gather data, and also to store data. More information about storing data can be seen in a related blog: Writing successful data management plans.

A set of interview questions, a set of survey questions and forms that can be used to gather responses.

Do consider sharing each of these with your tutor; they may well have some good ideas about how they might be improved.

Evidencing an ethical approach

When your examiner reads your project report, they will look for a description of what you have done and evidence that shows you have done what you have said you have done. Using a concept from creative writing, it is important to show the reader, rather than to tell the reader. 

You can show the examiner you have adopted an ethical approach by sharing evidence. You might, for example, share the following appendices:

  • Provide a copy of a project information sheet.
  • Provide samples of signed consent forms. You don’t need to provide copies of all the signed consent forms; one of each broad group of stakeholders will be enough. Make sure you hide any names and signatures. There is no reason why the examiner needs to see these.
  • Provide copies of any interview scripts or data collection forms.

Each appendix should, of course, be referenced within the body of your report.

Resources

The module website contains a number of helpful resources and pages. In particular, within the Legal, Social, Ethical and Professional issues resource, the following two sections are particularly useful:

  • Working with human participants
  • Appendix A Guidelines for conducting research with human participants

There is also a folder called LSEPI templates which can be found within the study materials section. At the time of writing, this folder contains the following files:

  • TMA02 LSEPI Form
  • consent-form-template
  • participant-information-sheet-template
  • EMA LSEPI Form

Do take the time to have a look at each of these files, and reflect on how they might be used within your project. 

When you submit your EMA you need to include a completed copy of the EMA LSEPI form as an appendix (which is something that be easily forgotten).

These above points offer some very practical advice about what you need to do to provide evidence of working with participants. This is, arguably, a very narrow treatment of the connection between your project and ethics. 

Thinking in an ethical way means that you need to consider the impact on any digital tool or product. If you are interested what this means, a good starting point is Carissa Weitz’s Oxford Handbook of Digital Ethics (Oxford University press). You might find a chapter in this handbook that connects with the aim of your project. 

There is a requirements that your write about legal, social and ethical issues within your TMA 2 submission. If you're unsure about what this mean, or how to begin, a good bit of advice is, of course, find some time to speak with your tutor.

Acknowledgements

Many thanks to Kawal Banga and the TM470 module team.

Permalink Add your comment
Share post
Christopher Douce

TM470 Considering software requirements

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 11 Apr 2024, 09:30

If your TM470 project is all about the developing software to solve a problem, requirements are really important. Requirements are all about specifying what needs to be built and what software needs to do. A good set of requirements will also enable you to decide whether or not your software development has been successful. They can help you to answer the question: “does it do what we expect it to do?” There is a direct link between requirements and testing.

The exact nature of your requirements will depend on the nature of your project. There are different types of requirements. Two high level types of requirements are: functional requirements and non-functional requirements. Modules such as TM354 Software Engineering provide some further information about the different types and categories, and different aspects you might want to consider. 

One thing that you need to decide on is: how to you write down your requirements? The decisions that you take will, of course, relate to what your project is all about. Some projects will need formal approaches, perhaps using Volere shells, whereas other projects may use something like use case diagrams. If your project is interaction design heavy, your requirements may be embodied with artefacts such as sketches, prototypes, scenarios and personas. To learn more about these different approaches, you need to refer back to the module materials for some of the modules you have studied. You should also consider having a look in the OU library to see what you can find.

There is also, of course, also a link between your chosen project model, and your choice of requirements. Stakeholders are also of fundamental importance: you need to know who to speak with to uncover what your requirements are. You need to make a decision about how to record your requirements, and justify why you have adopted a particular approach. Different people will, of course, understand requirements in different ways. How you speak to fellow software engineers will be different to how you speak to end users.

I recently listened to a really interesting podcast about requirements engineering from something called Software Engineering Radio, which is associated with the IEEE Software magazine. Here's a link to the podcast: Software Requirements Essentials: SE Radio 604 Karl Wiegers and Candase Hokanson.

Although this is just over an hour (and I know everyone is busy), it is worth a listen.

Some key themes and topics addressed in this podcast includes:

  • What do requirements mean?
  • What is requirements elicitation?
  • How can requirements be presented? Or, what is does a requirement specification look like?
  • Do users know what they need?
  • How much requirements analysis is needed?

The podcast concludes with a question which begins: what tips would you share for someone who is involved with an ongoing project? (The answer to this question is very pragmatic)

Reflections

An interesting reflection (and comment that emerged from this podcast) is that the requirements approach that you adopt relates to the risks that are inherent within your project, and the implications of any potential software failures. This, in turn, is linked to the LSEP issues which are starting to be explored within your TM470 TMA 2.

When you are addressing requirements, you can highlight different requirement gathering approaches in your literature review. Do use module materials that you have previously studied as a jumping off point to do some further reading about the subject by looking at resources you can find in the OU library, but do be mindful about getting sucked into various ‘rabbit holes’; requirements engineering is a subject all of its own. When it comes to your TM470 project, you need to make practical decisions, and justify your decisions.

Permalink Add your comment
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 2338116