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
B AS9102 - 3D printing a special tool required for assembly (counterfeit risk?) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 10
K Defining risk control measures IEC 62304 - Medical Device Software Life Cycle Processes 13
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 4
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 5
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 11
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 3
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
E Normal Condition Hazards in Risk Analysis ISO 14971 - Medical Device Risk Management 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
R Risk assessment on IT containers and the information they contain IEC 27001 - Information Security Management Systems (ISMS) 4
B Threat/Vulnerability Catalogue for risk assessment IEC 27001 - Information Security Management Systems (ISMS) 4
R Opportunity For Improvement vs Opportunity (Positive Risk) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
R FOD Risk Assessment - What tools would you recommend for assessing FOD risk? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
R Identify Medical Device characterstics as Annex C of ISO 14971 Risk Management ISO 14971 - Medical Device Risk Management 5
A ISO 14971 PFMEA Manufacturing Risk ISO 14971 - Medical Device Risk Management 2
Q Example of the Risk Template Document Control Systems, Procedures, Forms and Templates 1
K Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
A IEC 60601 11.2.2.1 Risk of Fire in an Oxygen Rich Environment, Source of Ignition IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
D Importing a general wellness low risk product Other US Medical Device Regulations 3
R AQL, Consumer Risk and MA Statistical Analysis Tools, Techniques and SPC 2
M Risk managment report of Surgical Mask Example ISO 14971 - Medical Device Risk Management 14

Similar threads

Top Bottom