DO-178C or DO-178B requires two level software requirements, that is, high-level requirements and low-level requirements. But generally except the very small software, the hierarchy structure of most embedded software is: (the whole) embedded software -> component -> unit.
hierarchy structure of embedded software
If we develop software requirement for each level, then it will be:
(1) embedded software level requirement: normally this level requirement will be "The embedded software shall xxxx"
(2) component level requirement: normally this level requirement will be "The compoent A shall xxxx"
(3) unit level requirement: normally this level requirement will be "The unit A.1 shall xxxx"
embedded software level requirement is a typical functional requirement which define "what", while both component level requirement and unit level requirement are "design requirement" which define "how".
Does the high level requirement of DO-178C covers both embedded software level requirements and component level requirements, and does DO-178C merge these two level requirements into one level?
If they are merged into one level, I feel that there will be some issue because one high level requirement may not be testable in the hardware/software integration testing because that requirement actually define the requirement for one component, and the internal information of that component are not able to be observed during the hardware/software integration testing.
If there are three level software requirements, the tracibiltiy between requiremets and testings is easy for me to understand.
tracability between three level requirements and tests
But if there are only two level requirements, does it mean the traceability will be like as below?
tracability between two level requirements and tests
