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.
In the A-SPICE, there are various kinds of requirements; System Requirement, System Design, SW Requirement, SW architecture, SW Unit design. ISO 26262 requires similarly .
To manage traceability rigid decomposition of requirements into these are beneficial.
You can integrate all kinds of requirements into one documents. Then you will face a fact that managing traceability is not a easy task.
To specify, it requires different kinds of technical skills. It is not related engineering knowledge. It is closely related to logical thinking and writing technique.
You may wonder if I emphasize that writing technique is core skill to comply engineering process, because writing technique seems not to be related to engineering knowledge.
To Know it and to explain what you know are different. Sometimes it takes much time or infinite time to understand a document, because it is hard to understand. Requirement obfuscation is not good for team’s productivity and team’s communication. It also makes hard to achieve A-SPICE or functional safety standard.
So, engineers are required to learn how to specify requirements. It shall be educated.
To engineers, please do not blame readers because of their poor engineering knowledge, and do not think that it is a reason they do not understand your document. It is not good.
- Requirements_Engineering_Management_Handbook explains how to specify requirements.
- safety driven model based system engineering methodology(Part 1, Part 2) shows example.
- AUTOSAR Use Case Example CP Release 4.3.1
DO-178C basis, it is very good practice. In the standard there are SW HLR(high level requirements), and SW LLR(Low level requirements).
But A-SPICE and ISO 26262 basis, 3 steps of process are considered. SW Requirement, SW Architecture, and SW Unit design.
I prefer DO-178C to A-SPICE, because it feels natural to me.
There are so many good practices. Waterfall development model, Agile development model, DO-178C, and A-SPICE. They are not consistent.
When they have a belief that SW codes should be developed after unit design is finished as standard specified, such a rigid question during a design review is a burden to me.
Refer to development life cycle model(in Korean)