Personal Blogs

The term ‘software testing’ can be associated with a very simple yet essential question: ‘does it do what it supposed to do?’

There is, of course, a clear and obvious link to the topic of requirements, which express what software should do from the perspective of different stakeholders. A complexity lies in the fact that different stakeholders can have requirements that can sometimes conflict with each other.

Ideally it should be possible to trace software requirements all the way through to software code. The extent to which formal traceability is required, and the types of tests you need to carry out will depend on the character of the software that you are building. The tests that you need for a real-time healthcare monitor will be quite different to the tests you need for a consumer website.

Due to the differences in the scale, type and character of software, software testing is a large topic in software engineering. Chapter 5 of SWEBOK v4, the software engineering body of knowledge highlights different levels of test: unit testing, integration testing, system testing, and acceptance testing. It also highlights different types of test: conformance, compliance, installation, alpha and beta, regression, prioritization, non-functional, security, privacy, API, configuration, and usability.

In the article, The Practical Test Pyramid, Ham Vocke describes a simple model: a test pyramid.  At the bottom of the pyramid are unit tests that test code. These unit tests run quickly. At the top, there are user interface tests, which can take time to complete. In the middle there is something called service tests (which can also be known as component tests). Vocke’s article is pretty long, and quickly gets into a lot of technical detail.

What follows are some highlights from some Software Engineering radio episodes that are about testing. A couple of these podcasts mention this test pyramid. Although testing is a broad subject, the podcasts that I’ve chosen emphasise unit testing.

The first podcast concerns the history of unit testing. The last podcast featured in this article offers some thoughts about where the practice of ‘testing’ may be heading. Before sharing some personal reflections, some other types of test are briefly mentioned.

The History of JUnit and the Future of Testing

Returning to the opening question, how do you know your software does what it supposed to do? A simple answer is: you get your software to do things, and then check to see if it has done what you expect. It is this principle that underpins a testing framework called JUnit, which is used with software written using the Java programming language.

The episode SE Radio 167: The History of JUnit and the Future of Testing with Kent Beck begins with a short history of the JUnit framework (3:20). The simple idea of JUnit is that you are able to write tests as code; one bit of code tests another. All tests are run by a test framework which tells you which tests pass and which tests fail. An important reflection by Beck is that when you read a test, it should tell you a story. Beck goes on to say that someone reading a test should understand something important about the software code. Tests are also about communication; “if you have a test and it doesn’t help your understanding … it is probably a useless test”.

Beck is asked to explain the concept of Test Driven Development (TDD) (14:00). He describes it as “a crazy idea that when you want to code, you write a test that fails”. The test only passes when that code that does what the test expects. The podcast discussion suggests that a product might contain thousands of tiny tests, with the implication that there might be as much testing code as production code; the code that implements features and solves problems.

When considering the future of testing (45:20) there was the suggestion that “tests will become as important to programming as the compiler”. This implies that tests give the engineers useful feedback. This may be especially significant during periods of maintenance, when code begins to adapt and change. There was also an expression of the notion that engineers could “design for testability” which means that unit tests have more value.

Although the podcast presents a helpful summary of unit testing, there is an obvious question which needs asking, which is: what unit tests should engineers be creating? One school of thought is that engineers should create tests that cover as much of the software code as possible, also known as code coverage. Chapter 5 of SWEBOK shares a large number of useful test techniques that can help with the creation of tests (5-10).

Since errors can sometimes creep into conditional statement and loops, a well known technique is known as boundary-value analysis. Put more simply, given a problem, such as choosing a number of an item from a menu, does the software do what it supposed to do if the highest number is selected (say, 50)? Also, does it continue to work if the highest number just before a boundary is selected (say, 49)?

Working Effectively with Unit Tests

Another podcast on unit testing is SE Radio 256: Jay Fields on Working Effectively with Unit Tests. Between 30:00 and 33:00, there is an interesting discussion that highlights some of the terms that feature within Vocke’s article. A test that doesn’t cross any boundaries and focus on a single class could be termed a ‘solitary unit test’. This can be contrasted with a ‘sociable unit test’, where tests work together with each other; one test may influence another. Other terms are introduced, such as stubs and mocks, which are again mentioned by Vocke.

Automated Testing with Generative AI

To deliberately mix a metaphor, a glimpse of the (potential) future can be heard within SE Radio 633: Itamar Friedman on Automated Testing with Generative AI. The big (and simple) idea is to have AI helper to have a look at your software and ask it to generate test cases for you. A tool called CoverAgent was mentioned, along with an article entitled Automated Unit Test Improvement using Large Language Models at Meta (2024). A point is: you still need a software engineer to sense check what is created. AI tools will not solve your problems, since these automated code centric tools know nothing of your software requirements and your software engineering priorities.

Since we are beginning to consider artificial intelligence, this leads onto another obvious question, which is: how do we go about testing AI? Also, how do we make sure they do not embody or perpetuate biases or security risks, especially if they are used to help solve software engineering problems.

Different types of testing

The SWEBOK states that “software testing is usually performed at different levels throughout development and maintenance” (p.5-6). The key levels are: unit, integration, system and acceptance.

Unit testing is carried out on individual “subprograms or components” and is “typically, but not always, the person who wrote the code” (p.5-6). Integration testing “verifies the interaction among” system under test components. This is testing where different parts of the system are brought together. This may need different test objectives to be completed. System testing goes even wider and “is usually considered appropriate for assessing non-functional system requirements, such as security, privacy, speed, accuracy, and reliability” (p.5-7). Acceptance testing is all about whether it is accepted by key stakeholders, and relate back to key requirements. In other words, “it is run by or with the end-users to perform those functions and tasks for which the software was built”.

To complete a ‘test level’ a number of test objectives may need to be satisfied or completed. The SWEBOK presents 12 of these. I will have a quick look at two of them: regression tests, and usability testing.

Regression testing is defined as “selective retesting of a SUT to verify that modifications have not caused unintended effects and that the SUT still complies with its specified requirements” (5-8). SUT is, of course, an abbreviation for ‘system under test’. Put another way a regression test check to make sure that any change you have made hasn’t messed anything up. One of the benefits of unit testing frameworks such as JUnit is that it is possible to quickly and easily run a series of unit tests, to carry out a regression test.

Usability testing is defined as “testing the software functions that support user tasks, the documentation that aids users, and the system’s ability to recover from user errors” (5-10), and sits at the top of the test pyramid. User testing should involve real users. In addition to user testing there are, of course, automated tools that help software engineers to make sure that a product deployment works with different brewers and devices.

Reflections

When I worked as a software engineer, I used JUnit to solve a very particular problem. I needed to create a data structure that is known as a circular queue. I wouldn’t need to write it in the same way these days since Java now has more useful libraries. At the time, I needed to make sure that my queue code did what I expected it to. To give me confidence in the code I had created, I wrote a bunch of tests. I enjoyed seeing the tests pass whenever I recompiled my code.

I liked JUnit. I specifically liked the declarative nature of the tests that I created. My code did something, but my tests described what my code did. Creating a test was a bit like writing a specification. I remember applying a variety of techniques. I used boundary-value analysis to look at the status of my queue when it was in different states: when it was nearly full, and when it was full.

Reflecting Beck, I appreciated that my tests also told a story. I also appreciated that these tests might not only be for me, but might be useful for other developers who might have the misfortune of working with my code in the future.

The other aspect of unit testing that I liked was that it proactively added friction to the code. If I started to maintain it, pulling apart function and classes, the tests would begin to break. The tests became statements of ‘what should be’. I didn’t view tests in terms of their code coverage (to make sure that every single bit of software was evaluated) but in terms of simple practical tools that gave alternative expressions of the purpose of my software. In turn, they helped me to move forward.

It is interesting and useful to reflect on the differences between the test pyramid and the SWEBOK test levels. In some respect, the UI testing of the pyramid can be aligned with acceptance testing of the SWEBOK. I do consider the integration and system testing to be helpful.

An important point that I haven’t discussed is the question of when should a software engineer carry out testing? A simple answer is, of course, as soon as practically possible. The longer it takes to identify an issue, the more significant the impact and the greater the economic cost. The ideal of early testing (or early problem detection) is reflected in the term ‘shift-left’ testing, which essentially means ‘try to carry out testing towards the left hand side of your project plan’. Put even more simply: the earlier the better.

Returning to the overriding aim of software testing, testing isn’t just about figuring out whether your software does what it supposed to do. It is also about managing risk. If there are significant societal, environmental, institutional and individual impacts if software doesn’t work, you or your organisation needs to do whatever it can to ensure that everything is as correct and as effective as possible. Another point is that sometimes the weak spot isn’t the code, but in the spaces where people and technology intersects. Testing is socio-technical.

To conclude, it is worth asking a final question. Where is the software testing heading? Some of these podcasts suggest some pointers. In the recently past, we have seen the emergence of automation and the engineering of software development pipelines to facilitate continual deployment or delivery of software. I do expect that artificial intelligence, in one form or another, will influence testing practice, but AI tools can’t know everything about our requirements. There will be testing using artificial intelligence and testing of artificial intelligence. As software reaches into so many different areas of society, there will also be testing for sustainability.

Resources

JUnit is one of many bits of technology that can help to automate software testing. Two other  tools s I have heard of are called Cucumber which implements a language called Gherkin, a formal but human-readable language which is used to describe test cases. I’m also aware of something called Selenium which is “a suite of tools for automating web browsers”.

Since software testing is such an important specialism within software engineering, there are a series of industrial certifications that have been created by the International Software Testing Qualifications Board (ISTQB). As well as offering foundation level certifications, there are also certifications for specialisms such as agile, security and usability. Many of the topics mentioned in the certifications are also mentioned in Chapter 5 of SWEBOK v4.

I was alerted to a site called the Ministry of Testing which shares details of UK conferences and events about testing and software quality.

One of the points that I picked up from the podcasts was the point that, when working at forefront of an engineering subject, there is a lot of sharing that takes place through blogs. A name that was mentioned was Dan North who has written two articles that resonate: We need to talk about testing (or how programmers and testers can work together for a happy and fulfilling life), and Introducing BDD (BDD being an abbreviation for Behaviour Driven Development).

Acknowledgements

Many thanks to Josh King, a fellow TM354 tutor, who was kind enough to share some useful resources about testing.

Software architecture is quite a big topic. I would argue that it ranges from software design patterns all the way up the design and configuration of cloud infrastructures, and the development of software development and deployment pipelines.

Software architecture features in a number of useful Software Engineering Radio podcasts. What follows is a brief summary of two of them. I then share an article by a fellow TM354 tutor and practicing software architect who shares his thoughts from 25 years of professional experience.

An important point is that there are, of course, links between requirements, non-functional requirements and architectural design. Architectures help us to ‘get stuff done’. There are, of course, implicit links and connections to other posts in this series, such as to the one that is about Infrastructure as Code (IaC).

On the Role of the Software Architect

In SE Radio 616: Ori Saporta on the Role of the Software Architect Saporta suggests that design doesn’t just happen at the start of the software lifecycle. Since software is always subject to change, this means that a software architect has a role across the entire software development lifecycle. Notably, an architect should be interested in the ‘connections between components, systems and people’. ‘You should go from 30,000ft to ground level’ (13:00), moving between the ‘what’ problem needs to be solved to the ‘how’ problems can be solved.

Soft skills are considered to be really important. Saporta was asked how might engineers go about ‘shoring up’ their soft skills? A notable quote was: “it takes confidence and self-assurance to listen”. Some specific soft skills were mentioned (29:20). As well as listening, there is the need for empathy and the ability to bridge, translate or mediate between technical and non-technical domains. Turning to the idea of quality, which was addressed in an earlier blog, quality can be understood as a characteristic, and a part of a process (which reflects how the term was earlier broken down by the SWEBOK).

A software architect means “being a facilitator for change, and being open for change” in other words, helping people across the bridge. An interesting point was that “you should actively seek change”, to see how the software design could improve. An important point and a reflection is that a good design accommodates change. In software, ‘the wind [of change] will come’ since the world is always moving around it.

Architecture and Organizational Design

The second podcast I would like to highlight is SE Radio 331: Kevin Goldsmith on Architecture and Organizational Design. Goldsmith’s is immediately asked about Conway’s Law (Wikipedia), which was summarised as “[o]rganizations … which design systems … produce designs which are copies of the communication structures of these organizations”. Put more simply, the structure of your software architecture is likely to reflect the structure of your organisation.

If there is an existing organisation where different teams do different things “you tend to think of microservices”; a microservice being a small defined service which is supported by a surrounding infrastructure.

If a new software start-up is created by a small group of engineers, a monolith application may well be created. When an organisation grows and more engineers are recruited, existing teams may split which might lead to decisions about how to break up a monolith. This process of identifying and breaking apart services and relating them to functionality can be thought as a form of refactoring (which is a fancy word for ‘structured software changes to software code’). This leads to interesting decisions: should the organisation use their own services, or should they use public cloud services? The answer of, course, relates back to requirements.

An interesting question ‘was which comes first: the organisational structure or the software structure’ (13:05)? Organisations could embrace Conway’s law, or they could do a ‘reverse Conway manoeuvre’, which means that engineering teams are created to support a chosen software architecture.

A really interesting point is that communication pathways within organisations can play a role; organisations can have their tribes and networks (49:30). It is also important to understand how work moves through an organisation (54:50). This is where, in my understanding, the role of the business analyst and software architect can converge.

Towards the end of Goldsmith’s podcast, there was a fascinating reflection about how Conway’s law relates to our brain (57:00). Apparently, there’s something called the Entorhinal cortex “whose functions include being a widespread network hub for memory, navigation, and the perception of time” (Wikipedia). As well as being used for physical navigation, it can also be used to navigate social structures. In other words, ‘your brain fights you when you try to subvert Conway’s law’.

Reflections

In my eyes, the key point in Saporta’s podcast was the metaphor of the bridge, which can be understood in different ways. There could be a bridge moving from the technical to the non-technical, or could be moving from the detail of code and services to the 30,000ft view of everything.

Goldsmith’s podcast offers a nice contrast. I appreciated the discussion about the difference between monoliths and microservices (which is something that is discussed in the current version of TM354). An important point is that when organisations flex and change, microservices can help to move functionality away from a monolith (or other microservices). A microservice can be deployed in different ways, and realised using different technologies.

I found the discussion about the Entorhinal cortex. Towards the end of my doctoral studies, I created a new generation of software metrics that was inspired by the understanding that software developers need to navigate their way across software code bases. It had never occurred to me that the same neural systems may be helping us to navigate our connections with others.

On a different (and final) note, I would like to highlight the work of an article called Software Architecture Insights by Andrew Leigh. Andrew is a former doctoral student from the OU School of Computing and Communications, a current software engineering tutor, and a practicing software engineer. He shares four findings which are worth having a quick look at, and suggests some further reading.

References

Leigh, A. (2024) Software Architecture Insights, ITNow, 66(3), pp. 60–61. Available at: https://doi.org/10.1093/itnow/bwae102.

In one way or another, all the previous blogs which draw on Software Engineering Radio podcasts have been moving towards this short post about software quality. In TM354 Software Engineering, software quality is defined as “the extent to which the customer is satisfied with the software product delivered at the end of the development process”. It offers a further definition, which is the “conformance to explicitly stated requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software”. The implicit characteristics can relate to non-functional requirements, or characteristics such as maintainability and readability.

The Software Engineering Body of Knowledge (SWEBOK) emphasises the importance of stakeholders: “the primary goal for all engineered products is to deliver maximum stakeholder value while balancing the constraints of development, maintenance, and operational cost, sometimes characterized as fitness for use” (SWEBOK v4, 12-2).

The SWEBOK also breaks ‘software quality’ into a number of subtopics: fundamentals, management processes, assurance processes, and tools. Software quality fundamentals relates to software engineering culture and ethics, notions of value and cost, models and certifications, and software dependability and integrity levels.

Software quality

After doing a trawl of Software Engineering Radio, I’ve discovered the following podcast: SE Radio 637: Steve Smith on Software Quality. This podcast is understandably quite wide ranging. It can be related to earlier posts (and podcasts) about requirements, testing and process (such as CI/CD). There are also connects to the forthcoming podcasts about software architecture, where software can be built with different layers. The point about layers relates to an earlier point that was made about the power and importance of abstraction (which means ‘dealing with complexity to make things simpler’).  For students who are studying TM354, there is a bit of chat in this podcast about the McCabe complexity metric, and the connection between testing and code coverage.

Towards the end of the podcast (45:20) the connection between organisational culture and quality is highlighted. There is also a link between quality and lean manufacturing approaches, which have then inspired some agile practices, such as Scrum.

Reflections

Software quality is such an important topic, but it is something that is quite hard to pin down without using a lot of words. Its ethereal quality may explain why there are not as many podcasts on this topic when compared to more tangible subjects, such as requirements. Perhaps unsurprisingly, the podcasts that I have found appear to emphasise code quality over the broader perspective of ‘software quality’.

This reflection has led to another thought, which is: software quality exists across layers. It must lie within your user interfaces design, within your architectural choices, within source code, within your database designs, and within your processes.

One of the texts that I really like that addresses software quality is by Len Bass et al. In part II of Software Architecture in Practice, Bass et al. identify a number of useful (and practical) software quality attributes: availability, deployability, energy efficiency, integrability, modifiability, performance, safety, security, testability, and usability. They then later go on to share some practical tactics (decisions) that could be made to help to address those attributes.

As an aside, I’ve discovered a podcast which features Bass, which is quite good fun and worth a listen: Stories of Computer Science Past and Present (2014) (Hanselminutes.com). Bass talks about booting up a mainframe, punched card dust, and the benefit of having two offices.

References

Bass, D. L., Clements, D. P and Kazman, D. R. (2021) Software Architecture in Practice [Online], 4th edn, Upper Saddle River, NJ, Addison Wesley.

In the last post of this series, I shared a link to a podcast that described CI/CD. This can be broadly described as a ‘software engineering pipeline where changes are made to software in a structured and organised way which are then made available for use’. I should add that this is my own definition!

The abbreviation CI/CD is sometimes used with the term DevOps, which is a combination of two words: development and operations. In the olden days of software engineering, there used to be two teams: a development team, and an operations team. One team build the software; the other team rolled it out and supported its delivery. To all intents and purposes, this division is artificial, and also unhelpful. The idea of DevOps is to combine the two together.

Looking at all these terms more broadly, DevOps can be thought as a philosophical ideal about how work is done and organised, whereas CI/CD release to specific practices. Put more simply, CI/CD makes DevOps possible.

A broader question is: how do we make CI/CD possible? The answer lies in the ability to run process and to tie together bits of infrastructure together. By infrastructure, we might mean servers. When we have cloud computing, we have choices about what servers and services we use.

All this takes us to the next podcast.

Infrastructure as Code (IaC)

In SE Radio 482: Luke Hoban on Infrastructure as Code Hoban is asked a simple question: What is IaC and why does it matter (2:00)?  The paraphrased answer is that IaC can describe “a desired state of the [software] environment”, where that environment is created using cloud infrastructure. An important point in the podcast is “when you move to the cloud, there is additional complexity that you need to deal with”. This software environment (or infrastructure) can also be an entire software architecture which comprises of different components that do different things (and help to satisfy your different requirements). IaC matters, since creating an infrastructure by hand introduces risk, since engineers may forget to carry out certain steps. A checklist, in some senses, becomes code.

When the challenge becomes “how to compose the connections between … thousands of elements, infrastructure becomes a software problem”. Different approaches to solve this software are mentioned. There is a declarative approach (you declare stuff in code), and an imperative approach (you specify a set of instruction in code). There are also user interfaces as well as textual languages. Taking a declarative approach, there are models that make use of formalisms (or notations) such as JSON or YAML. A scripting approach, through the use of application programming interfaces may make use of familiar programming languages, such as Python, which allow you to apply existing software engineering practices. When you start to use code to describe your infrastructure, you can then begin to use software engineering principles and tools on that code, such as version control.

Towards the end of the podcast, a question was asking about testing (52:30), which is a topic that will be discussed in a later blog. Engineers may create unit tests to check to see what elements have been created and to validate characteristics of a deployed infrastructure. Integration testing may be carried out using a ‘production like’ staging environment before everything is deployed.

Reflections

A computing lecturer once gave a short talk during a tutorial that changed how I looked at things. He said that one of the most fundamental principles in computing and computer science is the principle of abstraction. Put in other words, if a problem becomes too difficult to solve in one go, break the problem down into the essential parts that make up that problem, and work with those bits instead.

A colleague (who works in the school) once expressed the same idea in another way, which was “if you get into trouble, abstract up a level”. In the context of the discussion “getting into trouble” means everything becoming too complicated to control. The phrase “abstract up a level” means breaking the problem down into bits, and putting them into procedures or function, which you can then start to manage more easily.

Infrastructure as Code is a really good example of “abstracting up” to solve a problem that started to become too complicated.

IaC has facilitated the development of a CI/CD pipeline. Interestingly, a CI/CD pipeline can also facilitate the development of IaC.

Software engineering is about the creation of large software systems, products or solutions in a systematic way with a team of people.

Since software can serve very different needs and has necessarily different requirements, there are a variety of ways that software can be built. These differences relate to the need to take account of different levels of risk. You would use different processes to create a video game, than you would for an engine management system. Software engineering processes are also about making the ‘invisible stuff’ of software visible to software engineers and other stakeholders.

One of the abbreviations that is sometimes used is SDLC, an abbreviation for Software Development Lifecycle. Software has a lifecycle which begins with requirements and ends with maintenance. Although software never wears out, it does age, since the context in which it sits changes. Processes can be applied to manage the stages within and between the software life cycle.

Different terms are used to refer to the development of software systems. There can be greenfield systems, brownfield systems, or legacy systems. Legacy systems can be thought of the ‘old systems that continue to do useful stuff. Legacy systems are also brownfield systems, which software engineers maintain, to make sure they continue to work. Greenfield systems are completely new software products. In the spirit of honesty, more often than not, software engineers will typically be working on brownfield systems and legacy systems than greenfield systems; systems that are towards the end of the software lifecycle than at the start.

The blogs that follow highlight different elements of the software development process. It begins with a discussion about the differences between waterfall and agile. It then goes onto say something about a technique known as Continual Integration/Continual Deployment (CI/CD), which has emerged through the development of cloud computing. CI/CD has been made possible through the development of something called ‘infrastructure as code’, which is worth spending a moment looking at (or listening to). Before we move onto the important subject of software quality, I then share a link to a podcast that discusses a process that aims to enhance quality: code reviews.

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

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

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

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

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

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

Some key themes and topics addressed in this podcast includes:

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

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

Reflections

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

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