In the ISO 26262, there are 4 kinds of safety requirements – FSR, TSR, SSR and HSR. But I’d like to recommend that you don’t have to divide into 4 pieces exactly.
FSR can be defined conceptually from customer side, and safety requirements can be identified for supplier side. If system is complex (i.e, a system of systems) it can be possible to consider a system that consists of sub-systems that consists of TSR, SSR and HSR. In this case, it is not a good practice just to think that level of safety requirements are system level, SW and HW level. if you have such category, it will prohibit to manage safety requirements. Managing in the unit of sub-system is easier.
To specify safety requirements, it should be identified from product requirements.
if they are identified, then detailed review with safety aspect should be perform (so we call it safety analysis)
Proper fault model and fault propagation model is prerequisite to conduct it.
After impact of considered failure mode, remedy(safety mechanisms, or additional processes) needs to be decided. So how to detect faults and how to handle faults should be considered.
All of safety mechanisms needs to be traceable to results of safety analysis, and all of evidence for identified additional processes needs to be traceable. They are required in order to build safety case.