Requirement Structuring

In terms of project lifecycles, the "donor" project is right at the start of its lifecycle - so its requirements are actively being changed and updated as the design develops. Not so much out of date, more, immature currently.

However, its the structuring of those requirements that I'm questioning here.

Effectively, any given systems can be represented by an architecture that has many views. At the core, you often have a logical/functional architecture and a physical architecture. Physical architectures I often seperate into views for Electrical, Mechanical and Software. But you would add views to suit the needs of the stakeholders of the system (ISO/IEC/IEEE 42010).

If you take some form of networking which most systems have.

I would defined Networking as a functional block in the logical architecture. The corresponding section in the requirements is going to capture the external interface you need to meet and the services you need to supply (as defined by the user). This might reference a seperate ICD.

If you have multiple network interfaces, you would have multiple functional blocks.

The Electrical architecture blocks relate to the microcontroller, the transciever chip, any isolation circuitry and filtering and then the connector itself.

The Mechanical blocks are essentially the board and the connector, but may also touch of any clearences around key components and touch downs for heat dissipation.

Software architectures are usually more abstract. I would expect a 5 or 7 layer ISO model here. Despite them being seperate electronic components, the microcontroller port configuration and the tranceiver configuration are usually seen as one sofware block.

Often you can show relationships between elements in the different model views, but that needs a good MBSE tool to be manageable.

If I had a blank sheet, those conceptual architecture views are where I would start from.

But I have a preference to structure the top level system requirements and the systems architecture according the the logical architecture module. You can tag requirements to lower level architecture elements (based off the physical archtiecture) in the requirements tool to show how they allocate to the different disciplines.

Where it gets challenging is when you have cross-cultting issues that apply to the system as a whole (but may impact elements to a greater or lesser degree), such as security, safety, EMC, etc.

if the requirements ae in a database, that is the purpose of keywords

Andy Millar said:

the correct format evidence

Should that be 'formal'? Guessing so

Andy Millar said:

It MUST be formally recorded in in a structured way where you can find it

Certainly that's the ideal, but it's hard to capture all the implicit knowledge. One often only finds out in retrospect what was important, in a niche way.

The worst parts for younger engineers is when the answer is 'we didn't have that technology back then, hence..'. 

Philip Oakley said:

Should that be 'formal'? Guessing so

Maybe both - formal and in a (sensible) format!

Philip Oakley said:

One often only finds out in retrospect what was important, in a niche way.

Oh absolutely, we can only do our best. But at least if people realise they have a problem it's a step towards it. I find it's easier with safety critical systems, as it's easier to make people aware of what could go wrong if requirements get forgotten or misinterpreted. But even in that world people make lots of assumptions along the lines of "we know we're going to design it like this" - no you don't, not unless it's written down as an clear and unambiguous requirement. Or "we've already designed it like this" - again that will only stay designed like that if you have a requirement to control it. (Spent this morning chairing a HAZID with the usual issue of the supplier responding to potential hazards by explaining how they couldn't happen in their system because of xyz feature...and explaining to that supplier that we had to capture that as a safety requirement to ensure that it was recorded that they would do what they were planning to do, or indeed had done, anyway. Fortunately we've been working with that company for a year or two now so they've learned that that's what needs to happen - I've known some equipment suppliers take this as a personal insult.)

I now tend to separate Requirements from Specifications - it took me decades to understand the distinction. 

The ideal Requirement is a narrative, without numeric limits.

Meanwhile the consequent Specification is all about setting the testable numeric limits for blind testing of the product or it's sub-system in a test environment.

There are very few cases where the narrative requirement is actually achieved: E.g. President Kennedy's "landing a man on the Moon and returning him safely to the Earth before this decade is out", (old now) Quantel Paintbox drawing software "the capability of an HB pencil", and Steve Jobs mouse pointer to operate on "a pair of jeans" (maybe apocryphal).

Also noted is that the functional technical performance often fits within three quarters of a page - the other 60 pages are environmental survival aspects (power provision, EMC, vibration, temperature ranges, etc.) They are all zero function requirements - input this, get out zero change. Hence the Gold Plated Brick requirements that can turn up every now and again.

Finally, given some "requirement", look at how big the pile of lower level part specifications become, all from that simple short narrative - where did all that come from? Have a look at Knowledge levels (similar to TRLs - Technology readiness levels), and the Knowledge tree.

1 Bohn, R.E.: ‘Measuring and Managing Technological Knowledge’, in ‘The Economic Impact of Knowledge’ (Elsevier, 1998), pp. 295–314,

Also as article in Sloan Management Review · January 1994 (MAM) DOI: 10.1016/B978-0-7506-7009-8.50022-7

EMC is one of the worst because it is a non-functional requirement and is mainly caused by metallic couplings, hence it's the "metal bashers", rather than the "sparkies" that create a lot of those metallic bonds. 

EMC also suffers from a mind set that its not solvable for any form of decoupling of requirements (see coupling surfaces above). So a load of waffle gets copied between sub-systems, with no responsibility or analysis of problems. Been there with imaging systems and 'synchronous' noise.

Mark Tickner said:

they will reuse aspects of a previous design.

One of the classic "Grandfathers Axe" re-use cases.

New mounting plates. Different bulges and cut-outs. PCBs relaid. Alternate connectors. Identical in almost every way [M. Poppins 1964]

Philip Oakley said:

Identical in almost every way

I know a very serious product where the EMC argument was that the new product was "similar" to the old product. The similarity was that they both had the same name, which had in fact been kept purely to try to claim "similarity". By the time the CE marking authorities found this out, many years later, the business manager who'd made the "similar" statement had left the business (and, sadly, had in fact left the human race) and I was called to explain this. Not a position I ever want to be in again...even though we'd carefully documented at the time that the EMC team did not endorse the "similar" statement, and that we did not consider that the EMC case applied to the new system, it was still a very very embarrassing meeting. (Fortunately for the company the product had been supplied and commissioned just before the EMC directive came into force, so the company was able to demonstrate that it hadn't actually broken the law, and in fact we'd ignored some of the "requirements" from that business manager and had surreptitiously taken reasonable EMC precautions in the design, but it was definitely not good practice.)

In the rail industry we have the Common Safety Method for Risk Assessment regulation, which allows the use of "similar reference systems" to argue that reapplication of a known system does not require a new risk assessment (I'm heavily simplifying there). It's a really sensible and pragmatic idea, and should be really useful, but in practice it's proved incredibly complicated to demonstrate that systems genuinely are "similar". Both that they are technically sufficiently identical and that they are used in sufficiently similar operational and environmental conditions. As an independent assessor I am forever asking "are you sure you've identified all the differences?" Again, it all comes down to how well the requirements, and compliance to those requirements, of the baseline system were stored in the first place.