Software requirements are important. If you are building a software product, your software requirements will describe what your software product is intended to do. Since software has the potential to do so many different things and solve so many different problems, your requirements can have different characteristics.
This blog post follows on from an earlier blog post, TM470 Considering software requirements. In this earlier blog post, I shared some questions. In this post, I would like to further refine and develop these questions.
When considering your project, it is important to ask yourself the following:
- When in your project will you allocate time to uncovering the requirements for your project?
- How will you go about gathering your requirements?
- How will go you about describing your requirements in your EMA report (and to the examiner)?
- How will you go about testing your product to check to see if it meets your requirements?
It is quite easy to answer the important first question. You would have chosen a lifecycle model for your project. Whatever approach you choose, the requirements ‘bit’ of your project should (ideally) occur not long after the start of your project.
The final question is also especially important. If you don’t define your requirements in a clear way, it may not be possible to know whether your software product meets those requirements. In other words, if you don’t have a clear picture of what you are building, you won’t know whether or not your project is a success.
Answering the second and third questions is more difficult, since it very much depends on the type of software you are creating. Arguably, the approaches you will adopt for testing will also be different too – but the key point remains - you need requirements to know what you need to test. Testing, of course, also needs to fit within your project plan.
Functional and non-functional requirements
In TM354, a software requirement (or requirement) is defined as ‘a desired feature, property or behaviour of a software system’ (according to the TM354 glossary). This term can be broken down into two types of requirement. A functional requirement is defined as ‘a specified action that a system has to perform’. In other words, what a software product should do. A non-functional requirement, by way of contrast, is defined as ‘a quality that a system must have’. Expanding this slightly, the idea of a ‘quality’ relates to a characteristic of a software product, such as its performance, security, reliability or usability.
The activity of keeping track of requirements is known, perhaps expectedly, as requirements engineering. If you feel that you need to find a way to keep track of your product requirements in a systematic way, it might be worthwhile briefly doing a bit of background reading into requirements engineering (in the context of your project) and sharing evidence of your reading within the literature review section of your project. Do remember to critical evaluate any articles and sources that you uncover. You should apply methods and techniques which help you to solve whatever problem you are trying to solve.
Scenarios
One of the reasons why software engineering is such a fascinating subject is how software can be used to solve so many different problems. Here are three examples of very different contexts in which software can be used:
- Embedded software
- Logistics software
- Consumer software
Embedded software
Embedded software is software that makes physical hardware work. It is software that ‘does something’ that is often important, and is often invisible. A useful example of embedded software is the software that runs on your internet router that you may use to connect to your broadband connection (you may well have learnt more about broadband technology in other modules).
An internet router operating system must satisfy a number of important non-functional requirements: your router software must be efficient (it must not slow down your use of the internet), it must be secure, and must run effectively whilst using limited memory and processing power.
An important question is, of course, what does router need to do? From a very high level perspective, it must provide some kind of user interface that enables either yourself or an engineer to configure it so it can be used. It will also, of course, offer internet connectivity either through a wired connection, or through a WiFi interface.
This leads a lot of further questions, such as: how are these interfaces defined? Wireless and internet protocols are, of course, already very well defined. They have been created by international standards organisations (such as the IEEE), corporations and committees over a long period of time. Technology needs standards to be able to work, and software engineers who have the unenviable task of building software for consumer internet routers must know what they are.
When faced with complex functional and non-functionality complexity, software engineers need to express their requirements in a concise and clear way, and in a form that ensures they can be tested. Testing is, of course, important since we need to know whether our software does what we think it should do.
Some requirements are more important than others. With our internet router, we may be able to tolerate a slight degradation in performance if there is more than one member of our household using our broadband connection. We would not, however, wish to compromise on security, since this would put all users at risk. In other cases, some requirements are non-negotiable. Consider, for a moment, software used to control an engine (or motor) management system for a vehicle. The consequences of that software either failing, or not functioning as expected have the potential to be catastrophic. On one hand, the driver of a vehicle might be mildly inconvenienced if they can’t get it started, but on the other hand, there could be consequences for passengers, the pedestrians and the wider environment. A notable example is the
Volkswagen Diesel Emissions Scandal which is summarised by Jung and Park (OU Library). Since software that software engineers create impacts on people and society, software engineers have a responsibility to reflect on the decisions that they make, as well as the ultimate impact of the tasks they are asked to carry out.
Before moving onto the next example, a useful question to ask is: what project model is best suited to the development of embedded software for an internet router, where all the requirements are clearly defined? If everything is known from the start of your project, a traditional waterfall project model may well be most appropriate.
Logistics software
This second category can be thought of as ‘software that manages workflow’. The term ‘workflow’ can be used to describe any series of actions that contribute towards the solving of a problem or satisfying a need. The effect of some software isn’t immediately visible to us. Our experience at a supermarket or at a restaurant is often facilitated by software. Behind the scenes, requests for products are sent to one or more suppliers. These suppliers must then find a way of delivering your order to the shop or restaurant you visit. The importance of such software becomes very apparent when there are problems, as illustrated by a cyber attack on the Co-op chain of supermarkets (BBC News)
The functional and non-functional requirements for business-to-business logistics software will, of course, have a different character when compared to the formality that is needed for very highly specified embedded software. If is, of course, really important to clearly describe what is expected, by which stakeholder (who is defined as ‘anyone who is affected by the introduction of a software system’), and in what format.
It is also useful to reflect that they ways in which requirements may be gathered. Whilst the requirements for an internet router may exist within formal standard documentations, the requirements for logistical operations may have to be discovered by studying existing business processes and ways of working. Depending on the organisation, this may be the responsibility of a business analyst. In smaller organisations, it may be the responsibility of the software engineer to ask important questions and document their findings. Software is, of course, always about people.
What project model choice would be appropriate for this category of project? The answer, of course, depends on the detail, but let us assume that we know a lot about the operation of business processes and the underlying technologies we may wish to use. In this case, we might adopt a variation of the iterative waterfall, where more communication between the different stakeholders are embedded into the planning.
Consumer software
Consider a website that supports a community coffee shop. The website shares useful information for potential customers, such as its location, a menu of cakes and drinks, and its opening times. The manager has decided that it would be useful to enhance the website to offer more functionality. Some key ideas include a way to advertise special events, such as gallery evenings, book groups and a ‘toddler club’, and to provide a way to reserve tables during busy times, and even to allow some customers to order their coffee and cake before they physically visit the café.
Where there are requirements, there are also questions. In this scenario we might ask where our requirements come from. Do they come from the manager, or should they come from the staff who will be working in the café, or from its customers? The manager, for example, may have an idea about what may need, but might not have a very clear vision of what they want.
The software requirements for our coffee website are a lot less clear than the requirements of a logistics product, and much less clear than the requirements for an embedded system. In each scenario, the requirements need to be discovered, but the approach for discovering those requirements are different in each example.
When we are faced with unclear requirements and have access to potential users (who may have strong opinions about what they do and don’t want) we may adopt an interactive project model where we create a series of prototypes of what a product might look like. We might even apply something called an ‘agile method’ that emphasises producing versions of working software as early as possible, whilst also fostering collaboration between developers and communication with key stakeholders.
Discovering requirements
These three scenarios implicitly suggest there are different ways of uncovering requirements. The first scenario suggests that some essential requirements are likely to exist in the form of detailed standards and protocol documents. The second scenario suggests that requirements exist within the business, and may need to be discovered, perhaps by business analysts or by working with other who have a detailed understanding of the problem area. The third scenario suggests that although end users may have a solution in mind, they might not have a clear idea about what form it might take.
Here is a summary of some methods that could be used to learn more about software requirements:
- Study documents that are connected with the problem that is being solved. As well as standards, this could include documents that describe national or international legislation, sector guidelines, or corporate policies.
- Look at existing products, or study what existing products are currently used to solve the problems that your software product will ideally solve.
- Ask users. Interview them individually or by using focus groups.
- Observe users. Study, with permission, what happens within an existing system. Alternatively, ask users to record their own observations.
- Examine the context or wider environment of the problem to identify any further stakeholders, social or technical constraints, and concerns that need to be thought about.
- Build a prototype which is then evaluated. The process of evaluation can then lead to the discovery of more questions, and more requirements.
The information you gather from each of these approaches must be analysed. Analysis is a critical and creative process that must also take account of ethics; it is necessary to consider the impact of a software product on individuals, communities, and societies.
When you have decided on what are requirements are, how should you represent them? Should you write them down, or are there other approaches you could use? Your decision about which approach to use may well depend on your approach to risk, and the consequences of what might happen if your software product were to go wrong.
Representing requirements
The best way to represent or to describe your requirements depends on the characteristics of your software system. When looked at very simply, there a continuum which relates to formality. On one end of the requirements continuum there are very formal requirements that could be expressed in a formal mathematical language. On the other end, the requirements may not be very well known and are expressed using some slides or images created using a prototype tool.
What follows is a summary of different approaches you can use to represent requirements:
Formal methods: One of the main difficulties of using natural language to describe software requirements is that natural language can lead to ambiguity. To get around this challenge, software researchers have invented software specification languages that are based on mathematics. One of the advantages of a formal approach is that it becomes theoretically possible to formally verify whether program code (software) logically satisfies (matches) a specification. You would use a formal approach in safety critical systems, which are often embedded software systems. The difficulty of suing formal methods lies, of course, with their formality. Since they use a formal language, they can be very difficult to work with.
Volere shells: Although natural language can express ambiguities, one way to manage this is to control the way in which language is used. Volere shells are essentially templates which contain sections that presents a concise description of a requirement, the motivation for the requirement, and a fit criterion that can be used to measure or determine whether it has been implemented successfully. For more information about Volere shells, do consult the OU’s software engineering module and Mastering the Requirements Process by Reed, Robertson and Robertson (2024) (OU Library).
Use cases: Use cases are all about describing what happens when a stakeholder interacts with a software system with the intention of carrying out a task or completing a goal. OU module materials describe two types of use case: textual use cases and graphical use cases. Textual use cases present a set of steps that are numbered, with alternatives. Graphical use cases are described using the Unified Modelling Language (UML) and summarise actions and actors (which can be stakeholders). Use cases are given names, which allows software engineers to easily discuss them with others.
User stories: The OU software engineering module describes a user story as ‘a story written by an intended user of a system; it describes some functionality that is of value to the person(s) writing the story. It represents a user’s expectation of the system’ (TM354 module glossary, 2025). User stories can take the form: ‘As a <user> I want to <description of activity> so I can <explanation of why activity is important>’. Like use cases, user stories can be given names (or even numbers) to help groups of software engineers to discuss them between each other, and within meetings. Since software requirements are, of course, related to software testing, an approach known as Behaviour-driven Development (BDD) builds on the concept of user stories, allowing them to be embedded within software test scenarios.
Prototypes: There are many different types and forms of prototype. A very simple prototype could be created from a series of pencil sketches, or prepared using one of many user design tools. Alternatively, a prototype could be a simulation of a software product, perhaps built using a presentation tool such as PowerPoint. A prototype might also be a semi-functional product. Sometimes the terms ‘horizontal’ or ‘vertical’ are used. A horizontal prototype that shows a lot of functionality but in not much depth; a vertical prototype that shows a small amount of functionality in a lot of depth. Unlike other representation techniques, prototypes embody requirements rather having them written down. It may, of course, be necessary to add additional description, especially regarding non-functional requirements, to provide further information and context for software engineers.
Planning for implementation
You have used different approaches to gather your requirements, and you have decided on a way to represent them. The next question is: how should you prioritise your requirements? The process of prioritisation, like the identification of requirements is also a creative process. There are, however, tools that can helpful. One tool is called the MoSCoW prioritisation tool (DSDM Agile Project Framework, MoSCoW Prioritisation).
MoSCoW is an abbreviation for ‘Must Have’, ‘Should Have’, ‘Could Have’ and ‘Won’t Have this time’. The most important requirements are obviously those that your stakeholders ‘must have’. The Agile Project Framework resource offers the following direct guidance: ‘ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project – there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement’ (Agile Business Consortium).
If you are considering running a project that adopts an iterative approach, it will be useful to highlight which requirements will be implemented within which iteration. If you have begun with a prototype, taking a practical approach, it will be necessary to convert requirements embodied within a prototype to a specific development task. Working with requirements is a process of making invisible needs visible, so they can be converted into working software.
A recommendation
If you are creating a software product include a separate requirements section in your account of project work chapter. Use your literature review chapter to show your awareness of different approaches to requirements, and use your project work chapter to show how you have critically applied your understanding to the problem that you are solving.
Use an appendix to present a summary of all your requirements. Use the body of your report to share examples of the most significant or important requirements in your project. In the reflection chapter, consider writing something about what you learnt by working with requirements in a systematic way, and which requirements were the most difficult to implement. If there were some requirements that were too difficult to implement or define, do say something about why you thought that was the case, and and what you might have done differently.
Resources
When writing your project report (your EMA) it is important and necessary to show your understanding of principles and ideas from modules you have studied before you got to your project. A number of the level three computing modules address the topic of software requirements. What follow is a very brief summary of three important modules. If you have not studied these modules during your degree, there is an opportunity to learn more about the topics they contain, and apply them to your project.
TM353 IT Systems: Planning for Success
This module helps you to consider the connection technology and people and the way in which they can both interact with each other to create a sociotechnical system. TM353 emphasises the importance of understanding broader and wider perspectives. It introduces a methodology, known as soft systems methodology and techniques such as the creation of rich pictures, which can be used to depict and explore the environment in which your software product inhabits. By considering the broader perspective, it is then possible to consider the way in which software may influence communities of users and stakeholders.
TM354 Software Engineering
TM354 introduces a number of practical tools that can be used to explore and share requirements. It describes a UML notation called an Activity Diagram which allows you to express business processes and accompanying interaction with software products. It also describes different types of use case, both textual and diagrammatic. It describes Volere Shells in quite a bit of detail, and offers some very clear examples about how to write user stories. It also draws upon the Reed, Robertson and Robertson text, and directs students to a useful interview.
TM356 Interaction Design and the User Experience
TM356 makes extensive use of a well-known textbook, Interaction Design: Beyond Human-Computer Interaction by Preece, Rogers and Sharp (OU Library). Although the text focuses substantially on the design of user interfaces in all their different forms, understanding user requirements is a fundamental theme for a very simple reason. If there is a mismatch between the user’s expectations and the design of a product, that product is not likely to be as usable as expected. If you haven’t studied the OU interaction design module, this text can be especially useful. It offers some practical guidance about what techniques can be used to gather requirements, and what approaches can be used to perform usability evaluations of prototypes.
To find your requirements, it is sometimes necessary to carry out applied research to discover what users do and need in the contexts and environments in which they inhabit. Like the software engineering module, the interaction design module discusses user stories, use cases, and also mentions Volere Shells. Notably, it adds a few further tools that can help to further uncover and develop requirement. Essential use cases are, for example, a use case that gets to the ‘essence’ of an interaction, without regard how an interaction is implemented. Personas, scenarios and storyboards are practical tools that help us to think about who the users are, what they will be doing when they use the software, and the context in which it will be used. Understanding requirements can then lead to the design of a prototype, which then can be evaluate and then further refined.
Reflections
I’ve been thinking about writing an article like this ever since I have noticed a lack a detailed discussion about requirements in TM470 EMA project submissions. Good projects will always consider them in depth. The best projects will also answer the question ‘how should I best represent my requirements to meet the needs of my project?’. There should, of course, be evidence of studying the topic of requirements within the literature review chapter. The best projects will also go onto use requirements within a testing process to determine whether a development has been successful.
The more you start to think about requirements, the more slippery the concept becomes. It is impossible to create one simple set of rules that works for all projects. There is a simple reason. Every project is different, and every project has its own unique set of characteristics. Gathering and describing requirements are creative activities, which takes software engineers towards onto other creative activities, such as software development and testing.
Differences between projects and problems can also mean differences in software engineering culture. Culture is expressed through differences in behaviours, practices and traditions. The culture of a software company that builds real-time safety critical embedded software is likely to be different to the culture of a company that builds consumer websites. How requirements are expressed are intrinsically linked to institutional values and non-functional requirements.
A final point is that software is always subject to change. Change can occur due to technology changes, changes in government legislation or corporate processes, or changes in work practices. Businesses are, of course, subject to mergers and acquisitions, and sometimes technology and software providers are changed for economic or practical reasons. In some cases, the speed of work-place change can outstrip the necessary changes that may need to take place within information systems. Since the role that software can play within organisations continually changes, so do the software requirements.
As well as supporting TM470, this blog serves a second purpose. Some of the ideas presented within this article may find their way into the new TM113 module, which features an important software engineering component.
Acknowledgements
Many thanks are given to the members of two module teams: the TM470 module team, and the TM113 module team. When I’m referring to ‘module teams’ in this section, I am also referring to tutors. I continue to hold the view that tutors are the most important people in the university.