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.

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.