2. A Systems Approach

Previously I introduced the idea of making a water rocket to take to schools. Compared with previous ideas I’ve had, this is very simple: take a water bottle and put some water in. The only tricky bit really is to produce something that allows the bottle to be pressurised prior to launch. The classic approach is to use a cork, insert a needle valve and attach it to a bike pump. Once the pressure exceeds the friction of the cork, the rocket launches. To add a bit more excitement, a few fins can be added for stability; similarly a nose cone with a bit a weight will make for more impressive flights. Simple!

There is a (possibly apocryphal) story related to the early development of jet engines. Frank Whittle had been extolling the virtues of how simple his engine design was. In response, Ernest Hives of Rolls Royce remarked that “we will soon design the simplicity out of it!"1 Indeed, the principle of a jet engine is simple, but the implementation of a modern engine that is incredibly powerful, efficient and reliable, is anything but simple. So it goes with many things in engineering.

Much of my day job involves the interaction of multiple systems, and the challenge is often understanding how one thing affects another. The discipline of systems engineering grew out of increasing complexity in engineering, and aims to avoid problems by properly understanding and managing the complexity. There is a lot written about systems engineering; indeed, there is an entire wiki that can be read for free.

Systems engineering, or systems thinking is a necessary aspect of modern engineering and is often sold as the solution that would have prevented numerous problems in past programmes. Because of this, I think that there is value in including it in my STEM project. It’s also just good practice. However, it can be a very dry topic, so I will need to find a way to incorporate it such that it can be portrayed to different audiences in an engaging manner.

A few years ago, a senior member of our team would invariably ask “what is the requirement?” at key meetings, with various degrees of exasperation. It seems so simple to know the answer to that question, until you realise that no two people have the same idea of what the requirement is.

I will most likely be a team of one, as well as being the customer and supplier. Despite that, I want to spend some time producing a decent set of requirements to document how an engineering life cycle should begin.

It is important not to solutionise the requirements. For example, I have decided that what I want to end up with is a water rocket that can be used to demonstrate STEM concepts to schools. But beyond that I need to be as open as possible. I don’t want to prematurely constrain the project by, for example, saying that the rocket needs to be based on a 2-litre bottle, or how it will be launched. Instead, my requirements should be based around the result I am hoping to achieve. In this case that’s an enjoyable educational experience.

In the next instalment of this series, I’ll dive into requirements a bit more. But for now, I’ll briefly cover other elements of the engineering life cycle.

I suspect that most people involved in engineering will have used, or at least heard of, the V-model, the systems development life cycle, or something with a similar name. It defines the process of development from requirement through to detailed design, and component test through to acceptance and delivery. Its “V” shape allows the different levels of test, verification and validation to be mapped across to detailed design, system requirements and user requirements respectively, as well as providing a good visualisation of the level of technical detail at each stage of the process.

The V-Model could be used to both manage the development of this project and also to teach the principles of it. However, it is a model that I have some reservations about. One problem I experience is that the left-hand side of the diagram is the first to be sacrificed when there is time pressure. Failure to adequately capture requirements leads to problems later in the life cycle which can be expensive to put right. Most people seem to understand the importance of getting requirements right, and yet time spent here can often seem like time being wasted that could instead be spent producing.

I don't have time pressure unless I choose to impose it; I have no customer for this project at the moment. But there is still a risk that I rush to start making. So long as I can find a way to stay engaged with the requirements development and design, this risk should be small. However, there are a couple of other things I would like to try:

• Change the model

• Iterate the life cycle in a more agile manner

There are a few points about the V-model that I dislike:

• It is shown as essentially linear despite benefiting from iteration

• “Gravity” acts against you

• The “work” is lost at the bottom of the diagram

Although some versions of the diagram show the test, verification and validation elements, the process is still mostly linear. There is no suggestion that there could (should) be several iterations of capturing and decomposing requirements, or planning and re-planning work as the strategy is finalised. It seems that once a step has been completed, it is never revisited in normal use.

For the more visual thinkers, you may find that the moving down the left hand side is a simple, fast part of the project. Once that’s out of the way, you get to do the exciting stuff – designing and making. However, the consequence of all that is that you have to clamber out of the valley you have found yourself in if you’re ever going to reach delivery and (hopefully) customer acceptance.

Not all stages of the life cycle take the same amount of time, and I think that the hard work of actually acting on the plan to meet the requirements of the strategy to deliver something that works and that the customer wants can be underappreciated. In a way, this is a management model and you could imagine a group of unenlightened systems engineers praising themselves for doing all the complicated bits of the V-Model, merely handing off the plan to the workers and waiting impatiently for it to be delivered for them to test.

A few years ago I drafted an alternative way to see the same model.

By simply turning it over, two new concepts are demonstrated:

1. Requirements and validation form the foundation of the project

2. The project “gravity” works against you until a good plan is in place, but from that point on it works with you as the project is designed and tested

This change doesn’t solve the problem of losing the significance of the work. I am developing another way to visualise that, but that’s for another time. Meanwhile, I found the following alternative that I like, proposed by BMT: the "O-diagram:"2

Everything described so far has been largely based on the traditional engineering approach; a very linear process where requirements are (thought to be) completed before moving on to design, manufacture and test. The reality is that changes are inevitably required, and programmes have to change to accommodate them. But it is not typically built in to the process.

An alternative approach is to expect change to be required, and to shrink the “revision loops” both in terms of time taken and the size of the change. Now, this is the point where I move from the world I know into the world I think would be better. But I do think this project will be a good opportunity to experiment with a more agile or flexible approach. Note also, that I'm not talking about Agile as practised in the software development world, not formally at least. I hope to take adapt some of those principles to what I'm doing, but the main aim is to have short-duration requirement-design-manufacture-test loops and accept that I might have to change quite a lot as I go.