Requirements and Levels of Verification
A requirement is either:
1) a source requirement or
2) a derived requirement.
Source Requirements
A project's source requirements are stakeholder and user requirements that specify the challenge to be addressed. These requirements are owned by the respective stakeholders and users and should be documented by appropriate source documents.
Derived requirements
Derived requirements are derived from the source requirements through the engineering effort. As such, a derived requirement will have a refined relationship to a source requirement. This establishes a requirements tree with the upper requirements being source requirements that trace back to source documents; and their respective owners.
Verification requirements
Verification requirements are developed by the systems engineering team to enable the evaluation of the system design against the source requirements. They help to define the process and environment in which verification happens. Every derived requirement must be verified by at least one verification requirement at the level to which the derived requirement has been allocated. A verification requirement, however, is not limited to the level of its associated derived requirement.
The Level of a Derived Requirement
The level of a derived requirement depends on the level of the implementation in the design that satisfactorily addresses the requirement. In other words, the derived requirement may reference the system, a subsystem, or even a lower level element in the system hierarchy. A requirement may be the origin of a function that is performed by a system element. Again, this element's position in the system hierarchy (component build from / build in relationship in Vitech Corporation's CORE) determines the level of the requirement.
Verification at Different Levels
When we verify our design we do so at the level of the requirement, but we also do so at higher levels of the system hierarchy. The design is verified at higher levels during integration and evaluation to ensure the requirement is still met at these higher levels. For example, let's consider a house alarm.
A derived requirement may be:
[REQ-00XYZ]
Upon activation of the motion sensor, the motion sensor shall send a detection signal to the alarm control unit within 5 milliseconds of the activation.
This is clearly a requirement on the motion sensor of our alarm system.
It is nonsensical to attempt verification of this requirement at a level below that of the motion sensor, for example, this requirement is not verifiable at the level of design for the detection signal. But during development, it is likely that we will verify the requirement at the level of the motion sensor. We have a motion sensor on a test bed, testing that when we activate the sensor, a signal is produced within the specified time. Great, it passed the test!
Further along development we verify this requirement again, at the level of integration with the alarm control unit. We activate the motion sensor to verify that at the control unit a signal arrives within 5 milliseconds. Can you see that the same requirement is verified at two different levels in our system's hierarchy. Similarly, we will again verify the requirement when the entire alarm system is installed in the house, possibly with a simulated intruder activating the motion sensor. Therefore, a requirement is likely to have more than one verification requirement, one for each of the integration levels appropriate to the verification of the requirement.
What's interesting is that test engineers can achieve high efficiency for their test cases when they get good verification requirements. When system engineers develop good verification requirements it may be possible, for example, to verify a number of requirements with one well designed simulated intruder test case.
To recap, a requirement's level is inherent to the level of the system element in the system's hierarchy that it specifies. Therefore it will be error-prone duplication of information to assign a level attribute to a requirment. However, a verification requirement does not necessarily relate to the level of a requirement or its associated implementation in design. For test efficiency, we need to know at which level a requirement is verified, for example the system level, subsystem level, etc.
The process by which levels in a system's hierarchy are identified and defined should be explicitly stated in a project's systems engineering management plan. The process is likely to be industry specific, even more reason to ensure this information is clear and accessible to the whole team.