We recently conducted a training on Functional Safety Software. We started to discuss Software Safety requirements (SSRs), stating something like “SSRs are derived from the Technical Safety requirements (TSRs). Start by looking into those requirements in TSR that are assigned to SW”. Immediately, one of the trainees asked “oh, all we need to do is to filter out the TSRs for SW, and put them into a new document, name this document as SSR and that’s it we are done?” No marks for guessing that we shouted a loud and clear “NOOOO!!!” This is the subject of this blog. Once you have the TSR, how should you derive the SSR? We will tell you the actionable steps that you can take and also give you an example of how we have derived SSRs from TSRs. Firstly, let’s look at the actionable steps in the process of deriving the SSR: Read and understand the TSRs assigned to SW. What is the Software supposed to do? Is this clearly specified? The first step before starting the SSR is to ensure that SW Requ...