Requirement Structuring

Don't.

Do add-in budgeting for the extra interface, integration and reporting steps [they are not 'problems']. Be 'honest' about the reality of the delays in resolving the test issue as they go up and down the hierarchy chains, and the extra cross function roles/staff needed. 

On one level, make it 'not your problem'. However, within that budget exercise, quietly flesh-out the alternate structure and system V diagrams.

This allows the 'management' to own the issues (again not a 'problem'), such that you can then buy into their solution which, hopefully, has extracted your nascent, poorly hidden ideas. 

In addition make sure that your problem actually matters. You may find that the whole project is marching to a different drum that no amount of local efficiency is going affect. There maybe a major platform aspect that is driving the overall project and the hierarchy is a response to the herding cats aspects of such projects. 

Pick your battles carefully. Stupidity [nobody knows the whole system] is to be managed, not eliminated. Ensure you have tolerances for [alleged] exact calculations (e.g. stochastic vs ergodic statistics). Learn from the mistakes of others, rather than ...]

 Remember Box's aphorism, misquoted : All interfaces are wrong, some are useful .

My experience was in military electro optic systems which cuts across the lot.

I have recently retired.  My former employer had software engineers, hardware engineers, mechanical engineers and systems engineers.  Amongst other things, the systems engineers were there to look at the requirements as a whole and ensure that they were correctly allocated to the different disciplines.  It was common that a single system requirement would map to sub-system requirements on several different disciplines.

I'm not sure how it would work to split things by logical/functional methodology.  You still need to know if it's a bit of software or implemented in electronics.

The role of 'integration lead' is a real one, and needs a real budget. This person is the one making sure the various teams agree on sensible interfaces while not worrying about the contents of the different bits that need to be interfaced. 'system engineering' if you like.

Like 'right first time' hardware, 'integrates first time' projects that are larger than a team co-located in a lock-up  garage are up there in occurrence with teeth for hens, unicorn hairs and rocking horse manure... or maybe I've been lucky ! 

Like it or not some folk seem unhappy to grasp more than the part they are working on, and prefer to see the project through a letter-box. 

Co-location into 'project team rooms' helps, but only if folk actually talk to each other to the right degree. Too much and no work occurs, too little and piles of square pegs are made for round holes.
Mike.

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.