Please see the first entry of the Requirements Management blog series here.

The concepts of allocation and derivation are sometimes misunderstood when it comes to requirements management.  This can lead to confusion and even to safety problems.  The process of derivation involves the writing of a new requirement,  based on a parent requirement, that incorporates changes (usually more or different details) that adapt the parent requirement or a portion of the parent requirement to a specific context (e.g., adapting an architectural requirement to a board or software component design).  This has the effect of “specializing” the requirement in terms of the specific context.  An example would be a parent requirement of “Check temperature input for boundary conditions for the range -40o C to 80oC.” This might be derived further into (at least) two child requirements:  “The device shall be able to measure input temperatures down to -50o C and up to 90oC,”, and “The device shall detect when input temperature goes below -40o C or above 80oC.”

Allocation of a requirement simply assigns the requirement to a specific context.  For example, the derived temperature boundary requirements in the last paragraph might be assigned to the temperature measurement hardware, and to the diagnostic software module, respectively.  The allocated requirements could be:  “The hardware shall be able to measure input temperatures down to -50o C and up to 90oC,” and “The software shall detect when input temperature goes below -40o C or above 80oC.”

The IEC 61508 standard requires that software safety requirements are derived from the safety requirements and allocated to the software implementation.  The intention here is to identify all of the requirements which are related to the software, and to completely specify the behavior and attributes of the software in testable terms, in order to fulfill the product safety requirements. 

Many organizations insist that hardware requirements are defined and organized in a similar matter.  Other organizations leave the more detailed hardware requirements at the product level, deriving the requirements to a detailed level, but not necessarily allocating them to hardware.  Both approaches are acceptable from a compliance point of view.
In my next entry, I will discuss validation test planning and how requirements can be verified using the validation test plan.