Risk Number for each software requirement

akp060

Involved In Discussions
#1
In a SCRUM's Sprint, when you are starting to work on your requirements, you may look for risks in each requirement but will you physically document every requirement in the risk analysis sheet with all the numbers and evaluate the risk control effectiveness, if you know that the risk is negligible, example my JIRA ticket says "Add name field" or "Create navigation button" as you know that there is practicable no control measure for these type of requirements. We can discard it per Section D.8.2 and Annex ZA of 14971:2012, right? If 14971:2019 says anything different, please let me know
 
Elsmar Forum Sponsor
#2
I don't think the intend of both ISO14971 or IEC62304 is to link a risk to each requirement or user story.

In practice, you start with your intended use, risk characteristics, hazard list and make an overall risk analysis (black box /grey box). In this analysis, you find risks where mitigation is required. If the defined control measures are implemented in software, you will need to include them in your software requirements (IEC62304, 5.2.3). It's an iterative process and your risk analysis gets more mature when your design evolves.

Still, checking your list of functions / requirements can be good method to ensure the risk analsysis addresses all functionality. And it might be good to document that for a specific fucntion, you don't see any risk. However, I have not yet heard about regulators expecting a line in your risk analysis for each requirement.
 

yodon

Staff member
Super Moderator
#3
Agree with @PaulGr but I'd like to address something you noted.

You say your Jira ticket says "Add name field" for example. That's not a requirement but an implementation details. Requirements should be at a higher abstraction level and address things like functional and capability requirements, system inputs and outputs, security, etc. (recommend looking at IEC 62304 section 5.2.2).

Similarly, risk management needs to be addressed at a higher level. See section 7 of the standard for more on that.

Once you get into design controls, you will need to assess the risk of changes but that's geared towards the impact on the current risk analysis (new hazards arising or contributing to ones, if additional risk controls are required, etc.). See section 7.4.

P.S. There can be risk controls associated with those features you describe; e.g., check name fields for invalid inputs (like SQL queries!), ensure navigation button is only enabled if proper actions are taken, etc. These should be driven by your risk management efforts.
 

akp060

Involved In Discussions
#4
There can be risk controls associated with those features you describe; e.g., check name fields for invalid inputs (like SQL queries!), ensure navigation button is only enabled if proper actions are taken, etc. These should be driven by your risk management efforts.
Agreed. But not document these risks as they can be negligible per assessment and use-context, right? I was referring to D.2.8 in 14971:2012 for the "discard" part. Not sure if the same is retained in 14971:2019 edition

"Add name field" for example. That's not a requirement but an implementation details
Agreed. What I mentioned was not detailed enough to qualify as a requirement, it would be more detailed and comprehensive per requirement analysis in 62304.
 
Last edited:

Tidge

Trusted Information Resource
#5
@akp060 - can you clarify two things:

1) What activity do you consider happening during a "SCRUM sprint for requirements development"

2) What you are referring to when you write "document these risks in requirements"
 

akp060

Involved In Discussions
#6
@akp060 - can you clarify two things:

1) What activity do you consider happening during a "SCRUM sprint for requirements development"

2) What you are referring to when you write "document these risks in requirements"
1) SCRUM is considered as an activity inside the SDLC procedure. As JIRA is used for User stories, detailing out requirements using Atlassian Platforms for a JIRA ticket constitutes requirement development

2) "These risks" implies where you know there is no HAZARD or SERIOUS INJURY, and you are sure that your scores would be "negligible" per section D.2.8 of ISO 14971:2012. "Document" implies document them in a hazard analysis document for regulatory purpose
 

Tidge

Trusted Information Resource
#7
Thanks for the reply. I can offer my reactions:

1) I only use JIRA as a ticket system, and only during development of the implementation. I wouldn't use it to develop requirements. I feel that requirements are a necessary input to direct SCRUM activities. I'm willing to learn alternative methodologies.

2) My implementations of 14971 start with risks and then allocate requirements (as necessary and/or applicable) as risk controls. I'm less willing to learn an alternate methodology (for medical device development) here, but I'll read responses.
 

yodon

Staff member
Super Moderator
#8
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.
 
Thread starter Similar threads Forum Replies Date
C Quantifying risk in choosing the number of parts, operators and replicates in a GR&R Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 4
W Is the RPN (risk priority number) in the PFMEA really a RPN without the detectability ISO 14971 - Medical Device Risk Management 4
Moncia Recalculating RPN (FMEA Risk Priority Number) - Customer Request APQP and PPAP 10
C PFMEA for Risk Management - Action Number? ISO 13485:2016 - Medical Device Quality Management Systems 1
A FMEA Risk Priority Number Reduction Worksheet ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 17
O Should a Covid vaccine and testing policy be included as part of ISO9001 or AS9100 risk management? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
M Does 4.5 - Alternative RISK CONTROL apply to the Particular Standards? IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
Q Measurement Equipment Revocation - Looking for a Disposal Form with Risk Assessment IATF 16949 - Automotive Quality Systems Standard 10
B ISO13485 Risk managment implementation for suppliers ISO 14971 - Medical Device Risk Management 2
Moncia Chemical risk assessment / COSHH Manufacturing and Related Processes 5
E Supply chain main policies ,scope, risk assessments & relavant KPI Supply Chain Security Management Systems 2
D Use Error Risk Controls and Control Verification ISO 14971 - Medical Device Risk Management 6
J Risk Assessment of Lithium Ion Batteries FMEA and Control Plans 3
Melissa Risk Management Process, How far do I need to go? ISO 14971 - Medical Device Risk Management 10
D Does Risk Management apply to re-labeler (MDR) EU Medical Device Regulations 1
H Risk Management Plan in agile process ISO 14971 - Medical Device Risk Management 14
H Risk Analysis and Probability of Occurrence ISO 14971 - Medical Device Risk Management 3
B Risk analysis for defective measuring or measuring equipment out of calibration General Measurement Device and Calibration Topics 2
P Benefit risk analysis on pFMEA ISO 14971 - Medical Device Risk Management 9
B AS9102 - 3D printing a special tool required for assembly (counterfeit risk?) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 12
K Defining risk control measures IEC 62304 - Medical Device Software Life Cycle Processes 14
U Supply risk management Manufacturing and Related Processes 4
T Biological Evaluation (10993) & Risk Management ISO 14971 - Medical Device Risk Management 9
D Cybersecurity and Risk Management: Loss of confidentiality IEC 62304 - Medical Device Software Life Cycle Processes 5
Q FMEA and Risk assessment in Microsoft Access FMEA and Control Plans 6
I Realization processes input into overall risk ISO 14971 - Medical Device Risk Management 2
M Need Help With Information Security Asset Risk Register IEC 27001 - Information Security Management Systems (ISMS) 2
thisby_ Post Market/Production Risk Assessment ISO 14971 - Medical Device Risk Management 0
S Risk Management Review ISO 14971 - Medical Device Risk Management 4
D Low risk IVD study in the UK, do I need MHRA approval? UK Medical Device Regulations 1
S Risk Management and other Files ISO 14971 - Medical Device Risk Management 8
silentmonkey Overall Benefit/Risk Analysis - Risk Management VS Clinical Evaluation ISO 14971 - Medical Device Risk Management 3
N ISO 27001 for Jumb Burger - Risk Assessment sheet IEC 27001 - Information Security Management Systems (ISMS) 11
C Risk Assessment Tools ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
qualprod Examples to mitigate risk from Covid ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
G Risk of stopping your customer's line IATF 16949 - Automotive Quality Systems Standard 4
C Risk Matrix vs FMEAs ISO 14971 - Medical Device Risk Management 12
S IVD risk class II devices for Brazil and MDSAP Other Medical Device Regulations World-Wide 0
M ISO 14971:2019: Criteria for overall residual risk ISO 14971 - Medical Device Risk Management 11
M ISO14971:2019 - Verification of implementation and effectiveness of risk control ISO 14971 - Medical Device Risk Management 5
Aymaneh Medical Device Cybersecurity Risk Management IEC 27001 - Information Security Management Systems (ISMS) 2
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
R Risk control measures as per ISO 14971 ISO 14971 - Medical Device Risk Management 6
D Deciding whether or not pre-market clinical investigation is required for low risk device EU Medical Device Regulations 5
R The term "Benefit Risk Ratio" in EU MDR, do I need to present benefit risk analysis as a RATIO Risk Management Principles and Generic Guidelines 4
_robinsingh Security Risk Assessment Tool IEC 27001 - Information Security Management Systems (ISMS) 0
A 21 CFR 820 - Risk Management - Looking for some guidance US Food and Drug Administration (FDA) 3
bryan willemot Contract Review and risk managment AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
D Risk Analysis using Monte Carlo Simulation instead of Scoring and Heat Map Risk Management Principles and Generic Guidelines 2
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8

Similar threads

Top Bottom