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.
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.
TM470 Considering software requirements
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:
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.