How to understand the meaning of high level requirement and low level requirement in DO-178C?

685 views Asked by At

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

1

There are 1 answers

0
Chris Hubbs On

DO-178C High-Level Requirements are intended to specify functional and operational requirements along with HW/SW interface requirements. Low-level requirements are supposed to be so detailed that you can code from them without needing more information.

If you want to create three levels of requirements with traceability between them, there is nothing in DO-178C that would prevent you from doing it. I have seen projects that used multiple levels of High-Level Requirements before getting to LLRs. This in the end may be more costly than two levels, but if this is what makes sense to your team with the architecture you have, you can be compliant with DO-178C this way.