Requirement Structuring

Hi Mark,

I'd totally agree with Simon, assuming sw, hw and mech are all implemented by individual teams then each needs their own subset of requirements. And a single system level requirement may result in a tree (or maybe better root system) of different sw, hw and mech requirements to implement it. 

A good way to think about this is by thinking about the verification and validation of requirements, at the low level you will want software verification of all the software requirements etc, hardware verification of hardware etc. Then you will want higher level integration verification and validation. 

However, at the highest level yes I agree it can be useful to group requirements by functionality, both to aid V&V again, and also to make it clearer that any have been missed. But the breakdown to lower levels is best done by the teams they will be devolved to to implement them.

Outsourcing parts of the design work is a way of getting really good at this, if you don't give a clear requirement set to the outsourced team within their implementation scope then you will not get back what you expect! So I always recommend imagining that this is what will happen: it tends to encourage the production of really good well structured requirements.

And don't forget the basic requirement of whatever it is supposed to do, we once spent a year or two developing about 200 high level requirements for a train  detection, but realised we'd forgotten to say that it should actually detect trains!

Thanks,

Andy

Andy Millar said:

we'd forgotten to say that it should actually detect trains!

Appears to be a common feature. In many ways its the confusion between requirement (abstract) and specification (concrete)

Mark Tickner said:

the intent is to make reuse and leverage of requirements for future projects

This 'future project reuse' is the hard part.

Commonly we are too busy specifying the parts for the current project, and can't see the woods for the trees to define those wider requirements. 

Nobody wants a power supply, but we end up specifying endless details for them. I remember an anecdote for requirements management/breakdown for a radar that started "The radar system shall .." which then needed 5 pages of ancillary specs to breakdown all the parts to cover the existence of power supplies, antennas, etc. before they could start on the other half of the sentence!

The other problem is that all the examples are for solved problems, such as the requirements for a car, another car. They never ask you to decompose the "horseless carriage" requirement (or as Henry Ford would state "faster horses").

Brooks' Mythical Man Month is a good read about the problems of rationalising requirements and starting [implementation] too soon.

Some interesting thoughts in reply to my thread, but I want to pick up on reuse.

I've fairly commonly come across a scenario where someone in the bid team has stated that in order to keep the project costs down, they will reuse aspects of a previous design. This is another one of those situations.

As a concept, its generally sound. Many products are essentially iterative evolutions. Sometimes you are reusing an exact component. This also fits in with structuring for buy/make decisions.

However, where it falls down is when the definition of the candidate design hasn't completely been verified. Do you understand why that design decision was previously made, does that decision still hold true for this product? What is the maturity of the system that you are reusing from?

Commonly, the reuse is taken before the previous design is fully verified and in some extreme cases, its actually co-development, as you are relying on another project to develop that design so you can use it in your project. Have you considered the risk if that source project doesn't deliver?

The best example I recall, from many years ago, was where it was discovered that there was an error in the requirements set for a project that had gone into production. Those requirements had been flowed down to multiple other projects, but these had been taken before it went into production.

Fortunately that flow down had been reasonably documented, so it was possible to identify the impact of the issue and fix the requirement in all the places it had been used as well as the original project. The defect had managed to escape through the peer review and V&V processes - which is pretty rare. The child projects of course didn't test it because it was carryover.

Of course, there is the case where it is stated as "reuse" but in reality something is being changed...

My "reuse" is in reality leverage with a certain aspect of co-development due to the maturity of the source.

One interesting thing I found in my assessment of suitability for reuse of the existing requirements set was evidence of satisfies links that go horizontally between the lowest level requirements modules in different sub-systems... This is because those sets of components are intrinsically linked, but are the responsibility of diffferent teams.

Absolutely, this is one of those issues that keeps me in gainful employment! In the rail industry we have incredibly long product lives, e.g. I'm just starting an ISA review of a major update to an electronic product that was originally developed in 1963! And of course in these cases there is usually no structured requirement specification, and equally no validation to that specification (of course). So one of the key areas I will be assessing is how the project have demonstrated that they have reverse engineered a sufficiently complete requirement set - not an easy task.

Although in a way that's an easier case, because they absolutely have to do it. A tougher case, which again I work with a lot, is justifying relatively minor modifications to "proven in use" equipment, where the scale of the mod can't justify that complete reverse engineering approach, but equally the project must justify that they have sufficiently understood the underlying product so that they can argue that the change will only have a positive impact. And there is a huge risk here of "unknown unknowns", projects not realising that a feature they have disturbed (which they may not even realise was present) has a potential impact.

Sometimes in discussions like this I'm tempted to say "I could write a book about how to do that". This one, even though it's formed a large part of my career over the last 20-30 years, I honestly couldn't - every single case is so different to each other. I will frequently be heard to mutter about how useless the standards are on advising us on what "good" looks like here, but to be fair to them it's phenomenally difficult to do so. That said, IEC61508 does have probably the best guidance I've come across - if you can find it in there.

The best approach I've found to this is to make sure you have a development team who are worried that they've missed something. However structured the analysis approach is, a team that is too bullish can always make it sound like they've thought of everything - and this is, in my experience, where it goes horribly wrong.

And remember reuse is good. However thorough a theoretical reliability (and safety where applicable) analysis is (or appears to be), actual field data is always better - provided it is a credible sample over a credible period of time. Of course that still begs the question as to whether the field data has actually been captured thoroughly (e.g. were all faults actually reported back to the manufacturer), plus of course then the delta between the proven in use system and the new design / application / environment.

I give multi day training courses on all this to our clients, but even then I'm only barely scratching the surface...but again, if the development team are a team of worriers they'll probably be fine!

£1 for the chalk mark, £1000 for knowing where to put it...

Yes, we're lucky in the rail industry (at least on the infrastructure side) that generally clients appreciate that...

One more thought I had, from your thoughts: it's really useful - but hard work - to try to explain to projects that if they get this right now then their future modifications will be so much easier. Because they'll have the correct format evidence of the baseline system in the first place. Again I've been lucky across two companies that they happened to have their mainstream products in production for very long periods of time: about 20 years in one case, and 62 years and counting in the other! It really teaches you the importance of retaining all information as you'll need it again one day. For example, for those of us who use hazard logs or similar, a hazard log is not just to get you through an audit, it's for life...

And in the second of these companies, where we had exceptionally low turnover of staff, realising that even with the same staff you don't fully remember the rationale for the product design decisions 5 years later, or indeed 6 months later - or sometimes even a week later! It MUST be formally recorded in in a structured way where you can find it. 9 years after I left that company I still occasionally get messages from them asking if I can remember why we did things, and that's from somewhere where we were really pretty good at capturing this stuff.

Yes, we're lucky in the rail industry (at least on the infrastructure side) that generally clients appreciate that...

One more thought I had, from your thoughts: it's really useful - but hard work - to try to explain to projects that if they get this right now then their future modifications will be so much easier. Because they'll have the correct format evidence of the baseline system in the first place. Again I've been lucky across two companies that they happened to have their mainstream products in production for very long periods of time: about 20 years in one case, and 62 years and counting in the other! It really teaches you the importance of retaining all information as you'll need it again one day. For example, for those of us who use hazard logs or similar, a hazard log is not just to get you through an audit, it's for life...

And in the second of these companies, where we had exceptionally low turnover of staff, realising that even with the same staff you don't fully remember the rationale for the product design decisions 5 years later, or indeed 6 months later - or sometimes even a week later! It MUST be formally recorded in in a structured way where you can find it. 9 years after I left that company I still occasionally get messages from them asking if I can remember why we did things, and that's from somewhere where we were really pretty good at capturing this stuff.