So surprisingly, functional safety starts with requirement engineering ! Requirements are describing the system as it should be, and therefore, they are the base for verification and validation of the system. Roughly said, verification means to demonstrate that the system fullfil the requirements. Simple consequence: no requirements, no verification possible.
Validation means to demonstrate that the requirements are stated such that the system is usable as intended in its operational environment. But to check this doesn't make any sense if the system could not be verified. Conclusion from a wrong preposition gets nothing.
Later activities of the functional safety identify risks which arise if the system goes operational, and which additional functions the system are needed to mitigate the risks down to an acceptable level. Example: a cutting machine induces the risk that you get you hand cut off if you pull it in in the wrong moment. So the mitigation would be a protection system that would stop the machine immediately if any body part crosses a safety border.
Such additional system functions or properties will be noted as additional requirements. And checking if the system is safe includes to verify these safety requirements.
Conclusion: much effort of the functional safety activities can be done efficiently if there is a good requirement engineering in place. It helps to verify and validate the system according the safety functions and the overall safety and to render which are the safety relevant parts of the system.
But how requirements stated will be issue of another post, because this is very important for the value of requirements.
Enjoy !
