Skip to content

Risk

Learning outcomes

Learners ...

  • understand what a Risk is
  • understand how to evaluate risk and creating a risk matrix
  • Have added risks to the requirements of an SRS including mitigation

Risk analysis

Risk analysis is central in some systems like RDD (Risk Driven Development), FDA (FDA-1997-D-0029) splits into two types Business risks and Technical risk. Where Business risk relates to direct requirements while technical risks are from derived requirements. One type of risk assessment is the Failure modes and effects analysis commonly abbreviated FMEA which calculate the risk in Probability of occurrence x severity of risk RISK = P x S a risk matrix is used to define what level of severity and occurrence warrants what action.

How big should the risk analysis matrix be?

It is common is to divide it in 5 severity categories and 5 probability levels then establishing a table as below to asses which needs are the most important to address.

  • Risk probability goes from P1 (very unlikely to occur) - P5(Happens in all execution)
  • Risk severity goes from S1(minor or no effect), S2(Some Impact or noticeable by user), S3(Major impact on execution of program or result with minor loss of resources at end user), S4(Prevents execution of software or cause major loss of resources to user), S5(major injury or death cause by unhandled risk)
Probability/Severity S1 S2 S3 S4 S5
P5

5

Supplementary issue

10

Issue

15

Unacceptable

20

Unacceptable

25

Unacceptable
P4

4

Acceptable

8

Supplementary issue

12

Issue

16

Unacceptable

20

Unacceptable
P3

3

Acceptable

6

Supplementary issue

9

Supplementary issue

12

Issue

15

Unacceptable
P2

2

Acceptable

4

Acceptable

6

Supplementary issue

8

Supplementary issue

10

issue
P1

1

Acceptable

2

Acceptable

3

Acceptable

4

Acceptable

5

Supplementary issue

Where to focus?

Focus on the risks that are issues or unacceptable first. Then develop towards risks that are acceptable

Turning Requirements and Risk matrix into actionable Feature list

Using the Requirements and risk matrix we can design a feature list which can be tracked using issues or project tab in Git or in a separate document. The feature list describes how to solve a requirement in plaintext english and with flowcharts. This initiates a design phase in the development.