Requirement Structuring

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.

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.

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.

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.