So, what on earth is this Requirements Management thing that I do for a living? Well may you ask - most people that I meet do need it explained to them, and that includes the engineers that I work with.
Requirements management is a somewhat strange sort of world. When you are buying something (usually a big something), it isn’t quite engineering, and isn’t quite contract management, but sits on the borderline between them. And it takes a long history of experience before you’re any good at it. When you're just doing the engineering, it might be more straightforward - or not.
Let’s start with a simple example of what happens if everything is done properly – which of course it never is. Any contract has a list of things that have to be done. If you are getting a house built, then you will have a house design that is what you expect to end up getting. You expect that the roof will look like it does in the picture you were shown, the rooms will be where they are supposed to be in the plan, water will come out of the taps when you turn them on, the lights will work, you can open and shut the windows, and no end of other things that you assume will end up being what you expected.
But as anyone who ever had a house built knows, there are always unexpected (and usually unpleasant) things that happen along the way. The doors might not quite shut properly, and you end up in an argument about whether they are "good enough". The paint might be a slightly different colour to what you thought you had signed up for. Maybe the ceiling is a bit lower than you expected it to be, but perhaps that really is what you agreed to without quite realising how badly it would turn out after you'd didn't pay for the option to get a higher ceiling. There is no end to the list of things that can go wrong, and all too often it's a bit vague about whose fault it really is.
So you end up arguing about what it was that you had really signed up for, and all too often, you find that the builder has done this many times before and you haven't, so you've been caught with not getting what you wanted - and you have a bad feeling that the builder knew about this all the time. So either you end up paying more money to get what you thought you were going to get, or you decide to take what you've been given - and stay grumpy about it for ever.
Welcome to the world of requirements management. Your problems are that you didn't understand all the details that you had signed up for, you don't know exactly which problems you can demand be fixed, and you are all too aware that you knew less about house building than the builder did. If only you could have your time over again - you'd make different mistakes.
Buying something big like a ship or an aircraft really is just like that, except that it costs much, much more money, and so you end up in much bigger arguments.
Solving that is what I do for a living. From one week to the next, I often don't know what kind of problem I will be having to get resolved. One week it is a power supply that's not quite as good as it was supposed to be, but nobody is quite sure whether it is good enough to still do the job, so what do we do? Another week there may be paint flaking off, and nobody is too sure whether it wasn't put on right in the first place, or it has got damaged since then, or someone didn't specify paint that would be good enough to do the job. Then there is the expensive equipment that was supposed to last for a decade and failed just before the one year warranty ran out - so, will just replacing it solve the problem, or is it a defective design that will keep failing expensively every year after the warranty expired, or are we using it wrong? What do we do about the places where we get complaints that it is too noisy, and yet we were given measurements that showed the noise met the standard that is in industrial law - were the measurements really legitimate, and if not then what do we do next?
That's the kind of problems that I get to solve. What they all have in common, is that they are in part the science or engineering which is needed to understand what the real problem is, but the rest of it is about understanding exactly what it says in the contract we signed, so that we have a robust case to argue about whose fault it is. My philosophy is that you can't fix it until everyone can agree on who has to pay for fixing it. Often that isn't a black-and-white question of guilt or innocence, the real world is more nuanced than that. As I sometimes end up saying to our suppliers, we need to have an adult discussion. You can't do that until you really understand exactly what the problem is.
What I have learned over the years is that nobody gets the entire contract specification completely right on a complicated purchase. We are all human, so we don't know everything, and sometimes we just miss stuff. So when I'm up against a contract clause that says what the range of a radio has to be, but it turns out that I can calculate that achieving it would have defied the laws of physics, then no amount of money thrown at the problem is going to fix it. In my world, first of all you have to find out how the problem happened - whether it was a wrong calculation, or believing the salesman's promises, or forgetting that the earth isn't flat - because only then can you have that necessary adult discussion about what will be a fair compromise. At least you can learn to not make the same mistakes next time.
It all really does keep my brain active.