Personal Blogs

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:

1. When in your project will you allocate time to uncovering the requirements for your project?
2. How will you go about gathering your requirements?
3. How will go you about describing your requirements in your EMA report (and to the examiner)?
4. 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:

1. Embedded software
2. Logistics software
3. 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:

1. 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.
2. Look at existing products, or study what existing products are currently used to solve the problems that your software product will ideally solve.
3. Ask users. Interview them individually or by using focus groups.
4. Observe users. Study, with permission, what happens within an existing system. Alternatively, ask users to record their own observations.
5. 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.
6. 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.

TM354 Software Engineering is an important module with the OU’s Computing and IT Q62 qualification. It is a module that has been around, in one form or another, for a long time. The current version of the module, which dates back to 2014 is roughly summarised in the blog post Exploring TM354 Software Engineering.

One of the interesting characteristics of TM354 is that it more theoretical than it is practical. Rather than using lots of software tools to work with and manipulate code and components, students are introduced to diagrammatic tools in the form of the Unified Modelling Language (UML). I don’t think this is necessarily a bad thing. It forces students to slow down, and to look at the detail, and to reflect on what it means to think about software. By deliberately pushing any practical tools aside, we avoid worrying about specific issues that relate to implementation. An implicit assumption is implementation is development, and engineering is about how we go about structuring and organising the building of software.

The practice of software engineering has moved on since 2014. Agile practices and cloud computing have now become mainstream, and there has been the recognition that artificial distinctions between ‘development’ and ‘operations’, the idea that you move software from one team to another, might not be particularly useful. The notion of technical debt has been defined, and this connects with older more established themes of software metrics. There is an increased recognition of tools: of requirement management tools, version management tools, and ticket management tools. All this mean that the notion of a theoretical module that is separate from the practical world of software engineering is harder to argue.

There are, of course, concepts which remain paramount: the importance of different types of requirements, understanding the different types of software development process, conceptions of software quality, principles of software architecture, and different approaches to software testing.

In the sections that follow, I share something of my own personal experience of software engineering education and then share some of my experiences of working as a software engineer. I then go onto share some rough thoughts about what a reimagined TM354 module might look like.

This opinion piece has been written with a couple of audiences in mind: colleagues who work on different modules, and tutors who may have a connection with the OU’s software engineering modules. The sketch that is presented isn’t a firm reflection of what TM354 might morph into (since I don’t have the power to enact that kind of radical change). It is intended to feed into future debates about the future of the module, and modules that accompany it.

A personal history

When I studied Computer Science as an undergraduate in the early to mid-1990s, I studied a software engineering module, and a complementary practical module that was all about software maintenance. I remember my software engineering module was also theoretical. We all had to sit a 3 hour exam which took place in a dusty sports hall. I remember questions about software cost estimation, software reliability and software testing. Out of these three topics, only software testing remains in TM354.

The complementary (and practical) software maintenance module was very different. We were put in a team, given a document that contained list of changes that were needed to be made, and 40k lines of FORTRAN code, and told ‘mind how you go’. 

We had a lot to figure out. We needed to figure out how to drive various software tools, how to get compilers to compile, and how to work as a team. At the very end of the project, each team had to make a presentation to representatives ‘from industry’. The team bit didn’t go as as we would have liked, but all that was okay: it was all about the learning. A key point that I took away from it was that the people bit was as hard (if not harder) than figuring out how to compile ancient FORTRAN code.

Software engineering as a postdoc

My first proper job (if you can call it that) was as a Research Officer at the University of Brighton. My job was to help colleagues with their projects. I was what you could call a ‘floating technical resource’ that could be deployed as and when required.

One memorable project was all about machine translation. It soon struck me that I had to figure out a client-server software architecture. A key bit to a software puzzle was a client program that was written in Java 1.1, which I took ownership of. The code I inherited was a pathological mess. There were classes and objects everywhere. It was a rat’s nest of bafflement. I rewrote it a bit at a time. I didn’t realise it at the time, but I was refactoring my Java code (and testing as I went) before it was known as refactoring. My client software sent data to a server program using a notation that now would look very similar to the JavaScript Object Notation language. 

Like the software maintenance project, there was a lot to figure out: tools, languages, code structures, software architectures, operating systems, and where code was hosted so it could be run. The end result seemed to work, and work well. I felt I had figured out OO programming.

Software engineering as a software engineer

After a year of being a research officer, I managed to get a job as a software engineer in a small company that manufactured educational equipment. They needed software to work with their hardware, which was used to demonstrate principles of process control, electronics and telecommunications. I worked on a lot projects, but I’ll just mention two of them.

The first project was a maintenance project. There was a lot of software written in a combination of Visual Basic for DOS (yes, this was an actual product) and assembly language. The challenge was to rewrite the software in a combination of Java and C++. The Java bit would display results from experiments, and the C++ bit would take voltage measurements and turn digital switches on and off. Eventually, the code would go deeper. I had to learn about device driver development kits and how to begin to write functions for microcontrollers that drove USB interfaces.

The second project was different. The idea (which came from the marketing department and the managing director) was to make a learning management system that wasn’t too different in intent to the software that generates the university’s module web pages, but at a much smaller scale. Rather than providing files and resources to tens of thousands of students, this system was to allow educators to rapidly deploy materials to workstations within a single engineering laboratory. The big question was, of course, how do we do this?

From a technical perspective we ended up doing what these days is called ‘full stack’ development. We created code for the client side using JavaScript at a time when there were not any fancy JavaScript frameworks. On the server side, we had client side ASP.NET supported by stored procedures that were run in an SQL database. There was also content to deploy that contained Java applets, metadata to figure out, XML documents to parse, a quiz engine to build and report writing facilities to master. Books about eXtreme Programming and Test Driven Development had just come out. We tried pair programming and had a go to apply JUnit. Everything we built had to be installed relatively painlessly with the click of a mouse (but, of course, everything is never that straightforward). My key learning was, of course, that software is so much more than code.

There’s a third point that is worth labouring, and that point relates to process. When I joined, the engineering efforts were just ramping up, which meant there wasn’t much legacy when it came to software engineering processes. A ‘release’ had previously involved transferring software from a development machine to a production machine using a floppy disk. 

A new hire (let’s call him ‘Alan’) joined the team. Having cut his software engineering teeth having worked on an early generation of mobile phone software, Alan had a huge amount of experience and a desire to make sure that we knew what was in every release. He introduced what will now be known as a ‘ticketing’ system to document software defects, and a formal release process, which also involved the use of version management software.

Software engineering as a research fellow

The experience of working on a learning management system led me to a research project that was hosted at the OU that explored how to enhance the accessibility of virtual learning environments (VLEs) for disabled students. 

Before we ever got to code, there was a lot of discussion about architecture, which came to define the project’s output. The key question that we had to solve sounded quite simple: how do we find a way to present users with content that matches their needs and preferences? To answer this question, we need to answer other questions, such as: how do we define what a user needs? Also, how do we describe digital learning materials using metadata in such a way they can be efficiently chosen by a VLE?

These simple sounding questions hide complexity. Conditions can vary on a day by day basis. The digital content needed on one day may be different to what is needed on another. Learners are, of course, the experts of their own condition, and learners (who are all different) need to have ways to express their needs and preferences. What is really important is that a VLE offers learners choice about the types of learning materials. If we were to look at this project through a software engineering lens, the most important element of the whole project was the user’s requirements.

Mid way through this project, I stepped into another role: I became a Computing staff tutor. This meant that I stepped away from the technical aspects of computing and software engineering, and into a role where I had more involved with delivering the presentation of modules and supporting tutors.

Similarities and differences

These projects differed in terms of the users, the tasks, and the environments in which the software was used. They also were different in terms of the technologies that were applied. There were different databases, operating systems and programming languages. I had to make choices from different frameworks and tools. I’ve mentioned a unit testing framework, but I also used a model-view-controller inspired PHP application framework. There were also different software development kits and libraries to work with. There were also different ways to consume and to invoke webservices.

Turning to the similarities, one of the biggest similarities doesn’t relate to what was chosen, but what was done. In every project, I had to carry out some form of critical assessment and evaluation, to make informed decisions that could be justified. This meant finding things out in terms of what things did, and then how they worked.

Software engineers need to be multi skilled. Not only do the need to know how programming languages, data structure and operating systems work, they need to be systematic researchers, be creative problem solvers, and also be effective communicators. There was a reason why, as an undergraduate, we were asked to give a presentation about our software maintenance project.

Software is invisible. Software engineers need to know how to talk about it.

A quick look at QAA

Before writing this piece, I wrote an article called A quick look at the QAA benchmarks (OU blog). When considering the design of a new module, it is worth reviewing the QAA guidance. One aspect that I didn’t extensively review was the Higher Education Qualifications of UK Degree-Awarding Bodies framework.

A bachelor's degree is Level 6 of the FHEQ, and it is worth looking at descriptor 4.15, which states that students must gain “the ability to manage their own learning, and to make use of scholarly reviews and primary sources (for example, refereed research articles and/or original materials appropriate to the discipline)”.  Students attaining level 6 should also be able to “communicate information, ideas, problems and solutions to both specialist and non-specialist audiences” and have “the qualities and transferable skills necessary for employment requiring: the exercise of initiative and personal responsibility. decision-making in complex and unpredictable contexts, the learning ability needed to undertake appropriate further training of a professional or equivalent nature”.  Another point that jumps out at me is: “the holder of such a qualification will be able to evaluate evidence, arguments and assumptions, to reach sound judgements and to communicate them effectively”. It is clear from this guidance that an entire degree must help to develop student’s critical communication and critical thinking skills.

It's worth also digging into the Computing Benchmark statements to see what it says. When it comes to demonstrating computational problem-solving, to demonstrate excellence, students must “be able to demonstrate sophisticated judgement, critical thinking, research design, and well-developed problem-solving skills with a high degree of autonomy” (QAA Subject Benchmark Statement, Computing, March 2022, p.20). This means that modules must work with students to develop those critical thinking skills.

What the QAA guidance lacks is specific guidance about what a module or programme should contain. This is where something called the IEEE Software Engineering Body of Knowledge comes in (SWEBOK v4.0). There’s enough detail in here to cover a whole degree, never mind a single module. Of particular note is chapter 14, which is all about Software Engineering Professional Practice.

As well as the SWEBOK, there is are also the Association of Computing Machinery Curricula Recommendations, which contains a sub-section that concerns Software Engineering. Of these two documents, the SWEBOK is a lot more comprehensive and more up to date than the older 2014 guidance, which is clearly in need of a refresh.

A vision for a new level 3 software engineering module

I hate exams. I also hate end of module assessments (especially when I have to complete one of them), but I hate them less than exams.

An EMA makes a lot more sense in a module like TM354 than a written exam, since it gives students a lot more space to demonstrate their understanding and their professional communication skills.

My proposal is to design a module that combines the teaching of software engineering ideas and concepts with a practical investigation of a software product of a student’s choice. The choice of a product being, of course, guided by a tutor. Like with TM354, I’m suggesting three TMAs, each of has some emphasis on the development of research skills. By the time students complete TM354, they should end up being better equipped to complete the computing dissertation capstone module, which currently goes by the module code TM470.

Students should ideally arrive at this module having studied a level 2 module, where they have developed an understanding of the principles of object-oriented programming and problem decomposition. They may also be aware of some diagramming languages, such as UML.
Drawing on an interesting approach adopted in other modules, I would like to see independent study options, which enables students to demonstrate (and develop) their reading and investigation skills.

Here’s a suggested structure.

Block 1: Processes and Tools

This module will begin with a reminder about software the software development lifecycle (which should have been already covered on an earlier module), which are then discussed in greater depth. The term ‘tools’ is broad. Tools can be used to capture requirements and manage requirements.

Tools also support processes. A discussion about processes would lead us to a discussion about version and configuration management, and onto testing. This is linked to the topics of continuous integration and continuous deployment (CI/CD).

Independent study would include reading articles about materials that are provided within this week.

In terms of the assessment, students must demonstrate their practical understanding or use of tools, and also to draw upon a case study (which may well be written by the module team) where students relate their independent reading to the case study. Students must be able unambiguous reference both articles and software.

Block 2: Technology and Architectures

This block focuses on teaching important and essential ideas, such as software architecture and design patterns. This block should also cover software engineering abstractions that can have different meanings, such as component, containers and frameworks. Drawing on what is covered in an earlier web and cloud module, the link and relationship with cloud computing and cloud architectures should also be explored. The point here is that software engineers need to be able to recognise decisions that have been made, and to be able to begin to articulate alternative decisions. There might also be the space to highlight AI frameworks, but this is very speculative.
Independent study would involve looking at articles about different aspects of architecture. A point of doing this is further help students understand what the academic study of software engineering looks like.

Regarding assessment, students must demonstrate knowledge and understanding of key concepts that are introduced in this block, ideally by sharing potential designs and research with each other.

Block 3: Research and Investigation

This final block is about further developing software research skills. Since software maintenance is a significant part of the software lifecycle, software engineers need to be able to find their way through software stacks that are unfamiliar to them. Software engineers need to be critical thinkers; they need to understand what has been done, and why something has been done.

To help students what they need to do, students might be guided through an investigation, which could then intersect with different tools, teams and stakeholders. This would lead towards the EMA, which is all about producing a report that describes a software system in terms of processes used, tools applied, technology deployed, and its overall architecture.

To help students, this block would present some materials that offer some guidance about how to structure a report. For their block assessment, students would propose a software system or product to investigate. The system might be one that they are familiar with in their workplace, an open source software application, or software component or framework that can be used or applied within other software systems. In return, tutors would offer some practical advice, and perhaps follow up with a one-to-one session if they need further advice and guidance.

End of module assessment

A theoretical EMA is to be delivered in two parts: a formal report (70% of the EMA result), followed by a short presentation (30% of the EMA result). Both components need to be passed to pass the EMA (if this is theoretically permissible by the university assessment guidelines). 

The report is to contain:

• A description of a software component, product, or service that is the target of an investigation.
• A rationale for the choice of that component.
• A summary of its architectural elements, and any software components that it uses, or how the software component is used in other products or services.
• A summary of software technologies or components that are important to its implementation or realisation, such as technology standards, libraries or languages.
• A description of software development methodologies that may have contributed to its creation, or a summary of methods that may currently be applied.
• A summary of any tools that are important to its use and development. This may include, for example, version or configuration management tools.
• A commentary about how the software is to be deployed, and what supporting software or infrastructure may be needed to facilitate its deployment.

For the presentation component, students are to prepare a ten minute PowerPoint presentation that summarises their report, with an additional ten minutes for questions. Their presentation is to contain:

• A summary of their chosen software component or product and what it is used for, and who the users or stakeholder might be.
• Highlight what software technologies it makes use of, or what technologies it might be a part of.
• Any significant ethical or professional concerns that need to be considered.

Students will deliver their presentation to two people; a tutor, and someone who plays the role of a technical manager, who needs to make use of the report that has been created by the software engineer. For accountability and rigour, the presentations are to be recorded, but these recordings will only be used for quality control purposes.

Reflections

All ideas have to come from somewhere. The vision that is shared has been shaped by my own undergraduate studies, industrial experience, by chairing TM354, and looking at other modules, such as M813 Software Development and M814 Software Engineering. In this article I have laboured points about educational and industrial history to emphasise a disconnect between the two.

What is proposed here is a practical amalgam of both my undergraduate modules, and both the OU’s postgraduate modules, but positioned as an undergraduate module. The idea for the presentation assessment comes from M812, where students have to present their summary of a forensic investigation to a pretend ‘court’. This ensures academic rigour of the written assessment, whilst also helping to develop student’s communication skills. 

One point that I have a clear opinion about is that software engineers need to be able be critical thinkers, and carry out applied research. They also need be mindful about the ethical consequences of their decisions. What is necessary (which is something that is emphasised in other modules I’ve been studying) is the need to develop research skills. By helping students to carry out their own research, students learn more about what it means to study software engineering as an academic subject, and learn more about what it means to carry out study and evaluate software products, which is a necessary and important industrial skill.

Over the last couple of months, I’ve been updating block 2 of the TM354 module materials as a part of a module refresh. This has meant I’ve had to reacquaint myself with the Unified Modelling Language (UML), which I first learnt as a postgraduate student. I went onto use UML for a short time when I worked as a software developer in industry. It’s a really useful tool; it provides a neat graphical language that helps software engineers to communicate with each other when put pen to whiteboard.

UML describes the structure of a number of diagrams. To explain everything very coarsely, there are two main types of diagrams: structural diagrams (which describes what something is), and behavioural diagrams (which describes what something does).

Introducing the sequence diagram

One of the behavioural diagrams is a sequence diagram, which is a ‘type of’ interaction diagram. A sequence diagram can show what messages can be passed between which modules at a particular moment in time.

Objects are presented using something called lifelines. Messages that are sent between objects are presented using arrows. There is a special type of message, which is called a create message, which (unsurprisingly) creates a new object, which is depicted as an object with a new lifeline.

Books and tools

One of my ‘go to’ books is UML Distilled (OU Library). I have a 2nd edition copy of the physical book, but more recently I’ve been referring to the 3rd edition which I can access through the OU library.

A tool I’ve started to use is Visual Paradigm (which is also used in M814 Software Engineering, the postgraduate module). Visual Paradigm enables me to draw UML diagrams, including sequence diagrams pretty easily.

Sequence diagrams can depict the creation of new objects, by the creation of a new lifeline. UML Distilled says that a ‘solid’ line is used. Visual Paradigm, on the other hand, insists on using a ‘dashed line’. After an hour of fighting with Visual Paradigm, and uncovering some relevant documentation, it would not relent. 

Which one is correct?

Digging into the standard

After a bit of digging, I discovered that someone else has been asking the same question (Stackoverflow).

One of the replies directed me to the UML 2.51 specification (PDF).

Page 577 contains the following line: ‘An object creation Message (messageSort equals createMessage) has a dashed line with an open arrow head.’

My conclusion? Visual Paradigm implements a more recent version of the UML language than is described in my textbook.

Reflections

Does all this matter? Yes, and no. It depends on how you use UML.

If you use sequence to occasionally figure out what is happening within a nest of objects, drawing informal diagrams for either yourself or other developers that you work with, it won’t matter whether you use dashed or solid lines.

If you apply UML in a more formal way, it might matter.

My own view is that I prefer the solid lines. I’m more familiar with dashed lines showing the return control flow from objects. On the other hand, a different line highlights a ‘special’ function, of which object creation is one of these. 

Over the last year I’ve taken over as the incoming module chair for TM354 Software Engineering, taking over from Leonor Barroca, who has done a brilliant job ever since the module was launched back in 2014. I first learnt about TM354 through a module briefing which took place in September 2014.

What follows is a summary of the various elements that can be found within the TM354 module website. I’ve written this blog whilst wearing my ‘tutor hat’; to help students who are new to this module.

It goes without saying that two of the most important elements are, of course, the module calendar, and the assessment page which provides access to all the TMAs. One thing that I tend to do whenever I study a module is to get a printout of each of the TMAs, using the ‘view as single page’ option, just so I get an early idea about what I have coming up. You should also take some time to review the module guide and the accessibility guide.

Key resources: the blocks

TM354 is based around three printed blocks which can also be downloaded as PDFs by visiting the resources tab:

• Block 1: Units 1-4 From domain to requirements
• Block 2: Units 5-8 From analysis to design
• Block 3: Units 9-12: From architecture to product

Complementing these blocks is, of course, the module glossary, which can be accessed through the resources pages.

In OU modules, the glossary is pretty important. It presents the module team’s definition of key terms. If there is an exam or an EMA question which calls for a definition, you should always draw on terms that are defined by the glossary. A practical tip is: do spend time looking at and going through the module glossary.

Software

There are three bits of software that you will need to use, and the first of these is optional:

A sketching tool: In your TMAs you will be required to draw some sketches using a graphical language called the unified modelling language (UML). UML is a really useful communication tool. It can be used to depict the static structure of software (which bits it contains), and the dynamic interaction between components (which is how they are used with each other). How you draw your diagrams is completely up to you. You can draw a sketch by hand, draw a sketch using the tools that you have in your word processor, or you can download a tool to help you. My recommendation is to use a tool that specifically helps you to draw UML diagrams. This way, the software gives you a bit of help, saving you time (although you have to spend a bit of time learning a tool). I use a tool called Visual Paradigm, which is available under a student licence, but other tools, such as UMLet might be useful. There are a lot of tools available, but if you’re pressured for time, a pencil, ruler and paper, and digital photograph will be sufficient.

ShareSpace: this is an OU tool which you will use to share some of your software designs with fellow students. Software engineering is a team sport. ShareSpace is used to simulate the sharing and collaboration between fellow software engineers. As well as posting your sketches, you will be asked to comment on the design of fellow students. When you leave comments, you will be able to see comments about your own design.

NetBeans: Netbeans is an integrated development environment; a tool for developing software. You will use Netbeans in the final block of the module to look at, and change some software code that relates to design patterns. If you’re familiar with other development environments, such as IntelliJ, or even BlueJ (from earlier studies with M250) you could use those instead.

Forums

The module has a number of forums. A practical recommendation is to subscribe to each of these, so you are sent email copies of the messages that are posted to them. 

There is a module forum, where you can ask questions about the module, and a forum for each of the TMAs. You can use these TMA forums to ask questions about the assessments if you’re unclear about what you need to do. Do bear in mind that the moderator can only offer guidance and might direct you towards relevant bits of the module materials.

There is a tutor group forum, where you can interact with your TM354 tutor. Your tutor may well share some materials through this forum, so it is important that you subscribe to it, or check it from time to time.

There is what is called a ‘online tutorial forum’. Tutorials are run in clusters. What this means is that groups of tutors work together to offer a programme of tutorials (which are sometimes known as learning events). These tutors will use this forum to share resources that relate to their tutorials. They may, for example, post copies of PowerPoint presentations that formed the basis of their tutorials, which may contain useful notes in the notes section of each slide.

Finally, there is the café forum. This is an informal area to chat with fellow students about TM354 and OU study. This area isn’t extensively monitored by the forum moderator.

One thing to note is that sometimes the names of these forum areas can and do change. The names of the forums here might not be the names of the forums that you have on your module website.

Study guides

Although most of the module materials are available through the printed blocks, there are some important elements of the module that are only available online. Within the module calendar, you will see study guide pages. To make sure you go through each of these. Sometimes, these guides are presented along side other accompanying online resources that you need to work through to answer some of the TMA questions.

Resources pages

The Resources pages (which is sometimes known as the resources tab) is a place that collates everything together: all the guides (module, accessibility and software guides), PDF versions of the blocks, online version of each of the units (which can be found within each of the blocks), and any additional resources that need to be studied:

• Choosing closed-box test cases
• Monoliths versus microservices
• Introducing Jakarta EE
• Implementing use cases

Towards the bottom of this page, there is a link to a zip file which contains some source code that is used with TMA 3, along with some NetBeans software installation instructions.

The final bit of the Resources pages that I would like to emphasise is the Download link, which can be found on the right hand side of the page. Through this link, you can access all the module resources in different formats. You can, for example, download some of the media files onto your mobile device for you to review later, or you can download ePub versions of all the study guides and units onto an e-reader.

iCMAs

TM354 also has a set of interactive marked assessments (iCMAs). These are designed to help you to learn and to remember some of the key module concepts. The iCMAs do not formally contribute to your overall assessment result.

Tutorials

Before my final section, I’ll say something about tutorials. Do try to attend as many as you can. There are tutorials that introduce you to each of the block, and help to guide you through what is required for the TMAs. There are also a series of exam revision tutorials. Do try to attend as many as you can, since different tutors will present ideas in different ways.

Reflections

There is quite a lot to TM354; there are a lot of resources, which take a lot of reading. To familiarise myself with the materials I’ve taken an incremental approach: studying a bit at a time. Although the printed blocks are central to the module, it is important to pay attention to the online materials too.

My biggest tips are:

• Get a printout of the module guide.
• Get a printout of each of the TMAs.
• Make sure that you thoroughly read the module guide. You might want to get a printout of this too.
• Do remember to regularly refer to the module glossary. These definitions are important.
• Attend as many tutorials as you can.

On the TM354 Software Engineering module forum, the following question was posed: ‘does anyone know of any software engineering podcasts?’  TM354 tutor, Tony Bevis gave a comprehensive reply. With permission, I am sharing selected elements from Tony’s post, listed in no particular order.

SE Radio

This SE Radio (se-radio.net) is pitched as the podcast for professional software engineers. The following sentences are drawn from the SE Radio about page: ‘The goal is to be a lasting educational resource, not a newscast. …  we talk to experts from throughout the software engineering world about the full range of topics that matter to professional developers’. It is interesting that this podcast has a formal link to a recognised publication: ‘SE Radio is managed by the volunteers and staff of IEEE Software, a leading technical magazine for software professionals published by the IEEE Computer Society. All content is licensed under the Creative Commons 2.5 license’. Episodes appear to be quite long; an hour or so.

What the Dev?

What the Dev? is a podcast from SD Times magazine. It is said to ‘cover the biggest and newest topics in software and technology’. The magazine has an accompanying weekly email newsletter which contains a summary of current technology news items and a weekly podcast. Each podcast appears to be relatively short. The ones I have listened to were approximately 20 minutes.

Agile Toolkit Podcast

Agile is an important software development approach. The Agile Toolkit podcast 

aims to share ‘conversations about agile development and delivery’ through an archive that runs from 2005 through to the current day. They appear to be pretty long, so if listening to podcasts to learn more about agile, it is important to be selective in terms of the podcasts that are listened to. 

Open Source Podcasts

Open Source technology is an important subject to software engineers. When doing a bit of internet searching, I discovered something called the Open Source Podcasts last.fm channel which aims to share ‘conversations and advice from Open Source technologists on a wide range of topics’ and summarises links to a range of different podcasts.

A quick search for the term Software Engineering on last.fm takes me to a podcast channel called Software Engineering Daily. It really does appear that there is a topic or a technology made available practically every day. These podcasts range in length between half and hour and an hour.

Hello World

Hello World is a magazine published by the Raspberry Pi Foundation. It is free for computer science educators. I am regularly send email updates about new episodes. The focus is primarily about computing education in schools. The Hello Word podcasts are a good and interesting listen, especially if you're interested in moving towards computing education.

Reflections

There are a lot of resources out there. There are so many podcasts and recordings, that I feel overwhelmed. I have yet to establish a regular podcast listening habit, and I have yet to find a convenient way (that works for me) to access these different channels.

I quite like What the Dev? since the episodes are quite short; I can be listening to a couple of these whilst getting on with other things. It is good to note that the first one mentioned on this blog is recognised by the IEEE Software magazine, and this deserves a more detailed look. The daily software engineering podcast looks to be of interest too. 

What is surprising to me is how many bits of technology that feature in these podcasts that I don’t recognise; a lot is new to me. I’m hoping that some of these podcasts will enable me to learn more about new technologies, understand their role and purpose, and how software engineers might use them.

Acknowledgements

A big thank you to Tony. I’m going to be doing a lot of listening!

When I started to do some background reading into how TM354 Software Engineering might need to be updated, I was guided towards two curious novels. 

From October 23 I start to study A233 Telling stories: the novel and beyond, as a part of my gradual journey through a literature degree. For quite a while, I have been thinking there have been very little to connect novels and software engineering, other than obvious: the development of Word processing tools that can be used to write novels, and the Amazon cloud infrastructure used to distribute eBooks.

What follows is a very short (and not very through) review of two books that are all about DevOps: The Phoenix Project, by Gene Kim (and others), and The Unicorn Project, which is also by Kim. 

The Phoenix Project

I shall begin by sharing an honest perspective: the idea of a novel about software development did not excite me in the least. The text has a subheading that seemed to strengthen my prejudices: “a novel about IT, DevOps, and Helping Your Business win”. This is no crime drama or historical novel. The closest genre that one could attribute to The Phoenix Project is: thriller. I feel it occupies a genre all of its own, which could be labelled: IT business thriller.

The main protagonist is Bill Palmer, who has the unenviable job title of “Director of Midrange Technology Operations”. Bill works for a mysterious American company called Parts Unlimited. A lot happens in the early chapters: Bill is invited in to have a chat with a manager, who gives him a promotion. He is then asked to take a lead in getting the Phoenix Project, a new mission critical software system to work. Failure means the business would lose any potential competitive advantage, and the IT infrastructure might be outsourced, which means that people would lose their jobs.

Before Bill can get settled, he is hit by a payroll outage, which means the employees and unions are angry. He also quickly realises that the whole IT setup is in a complete state. Kim and his co-writers do a good job at attempting to convey a sense of paralysis and panic. The reason for this is expressed through the notion of ‘technical debt’, which means that existing IT infrastructure has become increasing complicated over time. Quick fixes now can, of course, lead to further problems down the line. Parts Unlimited has not been ‘paying down’ their technical debt.

An important element of the novel is the division between the Ops (operations) bit of IT, and the development division. There are other competing teams, which also play a role: there is the QA (quality assurance), and the security team. Security is important, since if an organisation doesn’t keep its auditors happy, the directors may face legal consequences.

I think I would be mean to describe the characters as one dimensional, since plot clearly takes precedence over characterisation. The main protagonist Bill is the most richly described. His organisational skills and sense of calm in the face of chaos is explained through his military background. 

Ubergeek Brent plays an important role, but I really wanted to know what made him tick. Erik Reid, an unofficial mentor to Bill plays the role of a Yoda-like mystic who provides insightful advice, who draws on his extensive knowledge of lean manufacturing. A notable character is Sarah Moulton, the Senior Vice President of Retail Operations, who takes on the unenviable role of the villain.

What struck me was the amount of technical detail that exists within the text. There are references to services, languages, and source code management. There is also the important notion of the ‘release’, which is a persistent problem, which pervades both this text, and its follow-up. Whilst I enjoyed the detail, I’m unsure about the extent to which the lay reader would grasp the main point that the book was making: to gain efficient business value from IT, it is best to combine together operations and development. Doing this enables the creation of tighter feedback loops, and reduces operational risk. Along the journey, there are these moments which raise an eyebrow. An example of this is where there is unambiguous contrition from a security manager once he sees an error in his thinking.

Bill identifies barriers and instigates change. After a “challenging” release of Phoenix, he ultimately prevails. During the updates, there is the emergence of a ‘side project’, which makes use of new fangled cloud technology to deliver value to the business. In turn, this generates income that makes shareholders happy. Political battles ensue, and Bill then gets on a fast track to a further promotion.

Apparently, The Phoenix project was popular amongst developers when it first came out, but I’ve been peripherally distant from the domain of software engineering, which means I’ve been a bit late to the party. Before providing further comment, I’ll move onto the sequel: The Unicorn Project.

The Unicorn Project

When I read The Phoenix Project, one of my criticisms was about the identity of the main protagonist. Novelists can not only use their craft to share a particular reality, but they can also have the potential to effect change. Whilst I liked Bill and the positive role that he took within the novel, given the clear and persistent gender disparities in the sector, I did feel that a female protagonist would have been more welcome. This unarticulated request was answered through The Unicorn Project in the form of Maxine Chambers, the lead protagonist in Kim’s follow up novel. 

Maxine is collateral damage from the payroll failure. Despite being hugely talented, she is side-lined; temporarily reassigned to The Phoenix Project. Her starting point was to try to get a build of all the software that was being developed, but faced persistent complexity, not just in terms of software, but in terms of finding out who to speak with to get things done.

Whilst the main project was saturated with bureaucratic burden, Maxine gradually found “her people”; smart like minded people who were also frustrated by the status quo. She also spoke with the business mystic and mentor, Erik Reid, who was very happy to share his words of wisdom. Ubergeek Brent also makes an appearance, but his backstory continued to remain opaque.

A really interesting part of the text is where Maxine ‘goes into the field’ to learn what happens in the Parts Unlimited stores. Drawing on the notion of ethnographic observations, she learns first-hand of the difficulties experienced by the store workers. Another interesting element which occurs towards the end of the novel is the movement towards embedding institutional learning, and drawing upon the creativity that exists within the workforce. In comparison to The Phoenix Project, there is more emphasis about culture, specifically, developing a no blame culture.

A key theme of The Unicorn Project is shared with The Phoenix Project: it is important to combine development and operations together, and it is helpful to perform continually integration since users can gain access to the new features more readily. A notable section highlighted the challenge of carrying out code merges during marathon meetings. If code is continually integrated, then there isn’t the need for all those uncomfortable meetings. Significantly, the Unicorn project also goes further than The Phoenix Project, since it is also about the power of teamwork, collaboration and the potential of smaller projects positively affecting and influencing others. Like Bill, the formidable Maxine is successful. 

Reflections

My initial scepticism of these novels comes from my view that novels are made from story and character, not technology. What is very clear is that although technology plays an important role, people are, by far, the most important. The novels foreground the role of teams and their organisation, the importance of sharing knowledge, and the importance of collaboration and leadership. It is clear that soft skills matter for the simple reason that software is something that is invisible; developers must be able to talk about it, and to each other. This is also why organisational culture is so important.

An important reflection is that both Bill and Maxine have difficult and very stressful jobs. They are both shown to work ridiculously long hours, often over the weekend. In the novels, IT is depicted as a difficult occupation, and one that is far from being family friendly. The families of both protagonists are featured, and they both suffer.

Although both of these novels are stories about the success of heroes battling against impossible odds, the hyperreality of the chaos within Parts Unlimited makes their success difficult to believe. Conversely, the hyperreality that is expressed through the impossible administrative burdens of the ticketing systems offers a warning to those who have to work with these systems on a daily basis.

The mystical mentor Erik is, of course, difficult to believe. He is a device use to share the pragmatic business and manufacturing theories that are central to the themes that are common to both books. I didn’t mind Erik. Like with Brent, I wanted to know more of his backstory, but with a limited work count and a lot of themes to work through, I understand why creative trade-offs were made to foreground more pressing technical topics.

Whilst I found the broader context, automotive spares, mildly interesting, I found myself becoming bored by the theme of IT being used to gain ever increasing amounts of money through the persistent and relentless pursuit of the customer. Although I accept that IT can be thought of a product of capitalism, there are more interesting ways that IT can be used and applied. Technology can be used to reflect humanity, just as humanity is reflected in technology. Whilst capital is important, there are other subjects that are more interesting. I think I would like to read an IT business thriller about cyber security, as opposed to one about a business that has found a new way to sell engine monitoring apps.

To conclude, these two novels were fun. They were also informative without being overly didactic. Although IT business thriller books is not my favourite genre, I can say that I enjoyed reading them. I’m more a fan of Victorian romances.

Epilogue

In 2004, I was working as a Software Engineer in a small company that designed and manufactured educational equipment used to teach the principles of electrical engineering and computing. 

One day in April, the manager director bounded into the office where I worked.

“We’re selling our e-learning division! This means that we won’t be able to sell our flagship learning management system anymore. We need to find a solution. We had been working on an earlier project, but that didn’t work out. So, we need you to head up the development of a new learning management system”.

That new learning management system was given an internal codename. It wasn’t very original. 

We called it Project Phoenix.

References

Kim, G. et al. (2014) The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. 1st edition. Place of publication not identified: IT Revolution Press.

Kim, G. (2019) The Unicorn Project. IT Revolution Press.