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

Quite Involved in Discussions
#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

Quite Involved in Discussions
#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
S 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
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
R ECG Risk Analysis Standards ISO 14971 - Medical Device Risk Management 2
N Device Labeling - Medtronic Ventilator Files (Risk Management documents) Coffee Break and Water Cooler Discussions 2
A 5 x 5 Risk Matrix - Looking for a good example Manufacturing and Related Processes 2
F Risk for Quality Assurance Department in a Hospital - Hospital Incident Reporting ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
M Should volume of sales be factored into risk probability assessments? ISO 14971 - Medical Device Risk Management 33
T How do you define your Hazards? <a Risk Management discussion> ISO 14971 - Medical Device Risk Management 16
adir88 Documenting Risk Control Option Analysis ISO 14971 - Medical Device Risk Management 8
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
K Identification of hazards and Risk file IEC 62366 - Medical Device Usability Engineering 7
S Risk based internal auditing Internal Auditing 6
Robert Stanley I'm @ RISK of not showing my RISKS! ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 20
M Estimating the benefit-risk ration under MDR EU Medical Device Regulations 1
adir88 Information of safety can reduce risk now? ISO 14971 - Medical Device Risk Management 12
G Any good examples of CAPA forms that include a risk based approach? ISO 13485:2016 - Medical Device Quality Management Systems 8
adir88 MDR requirement: Risk Management Plan for "each device" ISO 14971 - Medical Device Risk Management 5
M Has anyone heard of Run at Risk? Manufacturing and Related Processes 15
Tagin Is SARS-CoV-2/COVID-19 on your risk register? Misc. Quality Assurance and Business Systems Related Topics 11
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
J ISO 14971 applied to ISO 13485? Low risk class 1 devices ISO 13485:2016 - Medical Device Quality Management Systems 3
DuncanGibbons Classification of aerospace parts depending on their risk and criticality etc. Federal Aviation Administration (FAA) Standards and Requirements 3
D Performance specification as a Risk Control Measure, EN 14971 ISO 14971 - Medical Device Risk Management 7
M Risk Classification For Supplier - Clinical Research Organisation (CRO) Supply Chain Security Management Systems 3
Sidney Vianna IAQG SCMH explains "positive risk"..........but does it? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
MrTetris Unacceptable risk and information for safety ISO 14971 - Medical Device Risk Management 16
M IATF 16949 (6.1.1 - Planning and Risk Analysis for a remote site) Process Maps, Process Mapping and Turtle Diagrams 5
D Risk Analysis & Technical File - What detail goes in the Risk Management Report ISO 14971 - Medical Device Risk Management 5
C AS9100 Rev D 8.1.1 & APQP - Operational risk management process AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 0
B ATP 5-19 "Risk Management" Misc. Quality Assurance and Business Systems Related Topics 2
D Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
N Risk Management besides mandated FDA requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1

Similar threads

Top Bottom