I learned about Systems Engineering from this Part 1

Look back at the history of procurement by governments. You will find a series of disasters. Mismanaged, mistakes, full of errors, etc.

Examples are Gordon Brown's tax credit system, the Phoenix Project, a drone built for the Iraq War, and the new Nimrod Project.

They all have one thing in common they were disasters; they cost the UK Tax Payer a lot of money. Why? They were mismanaged. Systems Engineering was not carried out correctly. The requirements were ignored; the contractor knew better.

I am going to discuss the most successful project I worked on. The contract was placed by the most demanding customer I have ever known. The project will not be named.

I was involved with the contract from the start and was in a different area to Systems Engineering. My colleagues took a guess and nominated a Systems Engineering Tool not based on its merits, but because it looked the best tool.

The customer came to visit us, and we were not even allowed to buy them a coffee. They were incredibly professional. They looked at everything. Then much to our amazement, we won the competition. I had always fancied getting involved with systems engineering, so I was allowed to assist. This person who knew everything about systems engineering took control. Being not very experienced, I just played along, but I learned a great deal by just listening and watching. Plus, I bought myself some Systems Engineering books and found out what Systems Engineering was about.

After three weeks of getting nowhere, the person in charge of us gave up and walked away. I had a good idea of what the customer wanted; I had read the contract and read the standards. Using the Systems Engineering Tool, I took a simple subsystem, created a requirements hierarchy, a functional model, and an architecture. I then linked them all together. I produced some reports from the tool. Then went to see the customer and asked, is this what you want?

The customer smiled and said, yes. They made a few recommendations, that I implemented and then got back to them. They were delighted it was what they wanted. I went to see my boss and informed them this is what the customer wants. I have taken a simple subsystem and modelled it; we only have to do it with the other fifteen subsystems.

This started a lot of meetings, and I found myself learning about requirements management very quickly. I used the standards that we had been given and then used common sense to create a set of rules for the requirements. The customer had created around six hundred requirements. They knew what they wanted and had taken requirements from standards, plus lessons that they had learned on other projects.

The first thing we did was to create a requirements hierarchy, with the top-level requirements at the apex of the hierarchy and a requirement at the top of each subsystem. Some of the requirements made sense, but lots of them did not make sense. But gradually, the requirements hierarchy began to appear. When there was a hole in the hierarchy, a requirement was created to fill the gap. The contact with the requirements was captured into the tool and linked to the requirement hierarchy. This began the painstaking task of creating the traceability back to the contract.

Then the great fun started; I created fields for each requirement and a list of methods to test the requirement. The list of methods created was

Similarity

Inspection

Analysis

Demonstration

Trial

Then using the Systems Matter Experts (SME) on the project gave them their requirements. I told them that they owned the requirements and asked them to allocate one or more test methods to each requirement. I went back and gathered the results from each SME and updated the Systems Engineering Tool.

I shall continue my experiences in my next article.