Agree with
@Tidge and it seems to me you may be coming at this at the micro view. Your assignments from the SCRUM probably aren't "requirements" as the standard considers; instead, you're probably implementing some aspect of a requirement. I could be wrong but it doesn't sound like you're abstracting requirements from the user stories but considering those drive implementation activities as requirements.
And regarding risk management, it seems you may be coming at it kind of an inside-out approach. Have you looked, at a system level, what the risks to the patient / user are if the system fails to perform its intended functions? If you first start with this top-down view, you can set the baseline for what the risks are, what the hazards are, what the hazardous situations are, etc. As
@Tidge points out, this drives requirements, not the other way around. We normally start with a system hazard analysis (top down) and then do a software
FMEA to look at individual functions and how they might contribute to the risks. You can layer this on top of your user stories to drive implementation. Your specific implementation, though, would not drive the risk management activities although they could be a point where you review the appropriateness of previous work.