CMMI Technical Solution (TS) talks about this is detail. You want to learn CMMI right ?
You need to establish a high-level architecture. No, really.
You need to have someone who understands what hardware does, someone understand what software does to avoid all the problems being shoved into one category or the other.
Otherwise you get a block on the diagram best labelled "magic happens here"
You can create a diagram of the architecture, and assign requirements to elements.
Then in discussion with a hardware person, requirements move around from software to hardware elements and vice versa.
Each hardware sub-system is usually two boxes: one hardware, and a software layer atop that. The interface between the two should be specified at architecture time.
If the top level designers can't imagine it, nobody can ever make it work.
If software people write the diagram, it's often the hardware people get left holding it.
Hardware guys are just as bad at leaving software guys holding it.
Hardware guys that write firmware sometimes bite off more then they can chew. You can make testing and integration easier by giving the hardware people simpler software-facing interfaces to implement, ( which don't have magical internal states or processing) and get the software people to do the stateful stuff. It's quicker to test the hardware, and easier to simulate in unit test.
TL;DR: Use CMMI.