Tutorial T3 Engineering Safety-Related Requirements for Software-Intensive Systems Donald Firesmith, Software Engineering Institute, USA

Topics 

Importance of Safety-Related Requirements



Automatic People Mover Example Overview



Basic Safety Concepts



Safety-Related Requirements:  Safety Requirements  Safety-Significant Requirements  Safety System Requirements  Safety Constraints



A Process for Producing Safety-Related Requirements Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

2

Importance of Requirements 

Poor requirements cause more than half of all project failures:  Major cost overruns  Major schedule overruns  Major functionality not delivered  Cancelled projects  Delivered systems that are never used

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

3

Difficulty of Requirements 

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” F. Brooks, No Silver Bullet, IEEE Computer, 1987

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

4

Importance of Accidents 

Accidents can have expensive and potentially fatal repercussions:  Mars Climate Orbiter ($125 million)  Therac–25  Bhopal (3–10K deaths, 500K injured)

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

5

Poor Requirements Cause Accidents 

Most accidents are caused by poor requirements:  “For the 34 (safety) incidents analyzed, 44% had inadequate specification as their primary cause.” Health and Safety Executive (HSE), Out of Control: Why Control Systems Go Wrong and How to Prevent Failure (2nd Edition), 1995

 “Almost all accidents related to software components in the past 20 years can be traced to flaws in the requirements specifications, such as unhandled cases.” Safeware Engineering, “Safety-Critical Requirements Specification and Analysis using SpecTRM”, 2002

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

6

Poor Requirements  Ambiguous Requirements:  Developers misinterpret Subject Matter Experts intentions.  The system shall be safe.”  How safe? Safe in what way?

 Incomplete Requirements:  Developers must guess SME intentions.  The system shall do X.”  In what state? When triggered by what event? How often? How fast? For whom?

 Missing Requirements:  What shall the system do if it can’t do X?  Unusual combinations of conditions result in accidents.  What shall the system do if event X occurs when the system is simultaneously in states Y and Z? Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

7

More Problems and Challenges  Inappropriate architecture and design constraints unnecessarily specified as requirements  Use ID and password for identification and authentication.  Separation of requirements engineering and safety engineering:  Different disciplines with different training, books, journals, and conferences.  Different professions with different job titles.  Different fundamental underlying concepts and terminologies Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

8

Safety Engineering 

Safety engineering is the engineering discipline within systems engineering that lowers the risk of accidental harm to valuable assets to an acceptable level to legitimate stakeholders.

Note:       

Engineering Discipline Systems Engineering (not just software) Risk Accidental Harm Harm to Valuable Assets Acceptable Level of Risk Legitimate Stakeholders Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

9

Tutorial Example: Characteristics 

Common Ongoing Example throughout Tutorial



Safety-Critical SW-Intensive System



Realistic Example System



No Special Domain Knowledge Needed



Understandable:  Requirements  Technology  Hazards

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

10

Tutorial Example: Overview 

Very Large New Zoo



Zoo Automated Taxi System (ZATS)



Typical Habitat



Typical Automated Taxi Station



ZATS Domain Model



Taxi Object Model

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

11

Tutorial Example: Very Large New Zoo Zoo Maintenance

Great Outback

Tropical Rainforest Great Cats

Aquarium Wetlands and Waterways

Wolves and Other Dogs Restaurants and Shops

Aviary

Bears Monkeys Great Apes

Children’s Petting Area

African Savanna

Zoo Entrance

Parking Lots

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

12

Zoo Automated Taxi System (ZATS) ZATS Control Zoo Maintenance

ZATS Maintenance

Station

Station

Tropical Rainforest

Great Outback Aquarium

Great Cats Wetlands and Waterways Stn

Stn

Stn

Restaurants and Shops

Bears Station

n

Station

Sta tio

Children’s Petting Area

African Savanna

Station

Station

Monkeys Great Apes

Wolves and Other Dogs

Stn

Aviary

Stn

Station

St n

Stn

Station

Station

Station

Station

Zoo Entrance

Parking Lots

Station

Tutorial T3

Station

Station

Station

Station

Engineering Safety-Related Requirements for Software-Intensive Systems

13

Typical Habitat

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

14

Typical Automated Taxi Station Guideway

Zoo Loop Line

T

Habitat Line

Direction of Movement

Entry Elevator

T

T

Taxi Door Passenger

V M

Debit Card Vending Machine

Stairs

T V M

T T

Stairs

T V M

T T T Exit Elevator

T

T

T

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

15

ZATS Domain Model Daily Schedule keeps monitors and controls

Dispatcher Virtual Person

dispatches and monitors taxis via Taxi Drivers drive and monitor travels along Guideways

when necessary can communicate with

request trips and pay

Passengers

ride in

Taxis

enter and exit taxis at

stop at

connect Taxi Stations are in Regions

Habitats Tutorial T3

Parking Lots

Maintenance Facility

Engineering Safety-Related Requirements for Software-Intensive Systems

16

Taxi Object Model Taxi

s rm o f n co to

Acceleration Location Speed Speed Profile State

notifie s < con > trols

Schedule

has

is based on

Safety Policy

Computer

Passenger Compartment

Passenger Compartment Door

Card Reader

Zoo Map

Control Panel

Selection Button

Tutorial T3

Power Braking System (PBS)

Radio Transmitter Receiver

Sensor

Guideway Location Sensor

Position Display

Speed Sensor

Station Identification Sensor Speaker

Panel Display

Passenger Sensor

Engineering Safety-Related Requirements for Software-Intensive Systems

Accelerometer

Proximity Sensor 17

Basic Safety Concepts 

Safety as a Quality Factor of a Quality Model



Safety Quality Subfactors



Valuable Assets



Accidental Harm to Valuable Assets



Safety Incidents (Accidents & Near Misses)



Hazards



Safety Risks



Goals, Policies, and Requirements



Safeguards (Safety Mechanisms)



Vulnerabilities (system-internal sources of dangers) Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

18

Quality Model 

Quality Model – a hierarchical model (i.e., a collection of related abstractions or simplifications) for formalizing the concept of the quality of a system in terms of its quality factors, quality subfactors, quality criteria, and quality Quality Model measures. Quality Factor

Quality Subfactor provides evidence for existence of

provides evidence for existence of

is measured using

Quality Measure

measures

System-Specific Quality Criterion describes quality of

System Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

19

Quality Factors Quality Model

Quality Factor

Development-Oriented Quality Factor

Capacity

Configurability

Usage-Oriented Quality Factor

Dependability

Defensibility

Safety

Interoperability

Soundness

Survivability Security

Efficiency

Correctness

Continuity

Predictability

Operational Availability

Robustness

Reliability

Stability Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

20

Safety as a Quality Factor 

Safety is the quality factor capturing the degree to which: 



 

Accidental harm to valuable assets is prevented, detected, reacted, and adapted Accidents (and near misses) are eliminated or their negative consequence mitigated Hazards are eliminated or mitigated Safety risks are acceptably low

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

21

Defensibility Subfactors Harm

Prevention

Incident

Detection

Danger

Reaction

Risk

Adaptation

Defensibility Problem Type

Defensibility Solution Type

Safety

Defensibility

Quality Factor provides evidence for existence of

Defensibility Subfactor

Quality Subfactor provides evidence for existence of

System-Specific Quality Criterion Tutorial T3

is measured using

Quality Measure

measures

describes the quality of the

System

Engineering Safety-Related Requirements for Software-Intensive Systems

22

Safety Subfactors Accidental Harm

Prevention

Safety Incident

Detection

Hazard

Reaction

Safety Risk

Adaptation

Safety Problem Type

Safety

Safety Solution Type

Safety Subfactor provides evidence for existence of

provides evidence for existence of

System-Specific Safety Criterion Tutorial T3

is measured using

Safety Measure

measures

describes the safety of the

Engineering Safety-Related Requirements for Software-Intensive Systems

System 23

Valuable Assets 

A valuable asset is anything of significant value to a legitimate stakeholder that should be protected from accidental (or malicious) harm by the system. has legitimate interest in the System

is responsible for an

People

Data Tutorial T3

Asset

Property

Software

Hardware

is valuable to a

Environment

Facilities

Engineering Safety-Related Requirements for Software-Intensive Systems

Stakeholder

Services

Money 24

ZATS Valuable Assets 

What are the Valuable Assets for which ZATS is responsible for protecting against accidental harm?



How valuable are these assets to the Zoo (and society)?

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

25

Accidental Harm 



Safety Unintentional (Accidental) Harm

e.g., caused to enemy forces by weapons systems

Harm is any significant negative consequence to a valuable asset

Authorized Harm

Accidental harm is any harm due to an accident

Tutorial T3

Harm to Property

Survivability

Attacker-Caused (Malicious) Harm

Unauthorized Harm

Harm

Harm to People

Security

may occur to a

Harm to Environment

Valuable Asset

Harm to Service

Death

Destruction

Destruction

Corruption

Injury

Damage

Damage

Unauthorized Usage (Theft)

Illness

Corruption

Loss of Use

Kidnap

Theft

Accidental Loss of Service

Corruption (bribery or extortion)

Unauthorized Access

Denial of Service (DOS)

Hardship

Unauthorized Disclosure

Repudiation of Transaction

Engineering Safety-Related Requirements for Software-Intensive Systems

26

ZATS Harm to Valuable Assets 

What kinds of accidental harm can occur to the Valuable Assets for which ZATS is responsible?



How should these kinds of harm be categorized in terms of harm severity, and how should the categories be defined?  Catastrophic  Critical  Major  Minor  Negligible Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

27

Safety Incidents 

An incident is an unplanned (but not necessarily unexpected) series of one or more related events that either did cause or could have caused (accidental or malicious) harm to one or more valuable assets  A safety incident is an incident involving actual or potential accidental harm

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

28

Incidents and their Relationships Successful Attack

Unsuccessful Attack DoS

Near Miss (Close Call)

Accident

Safety Incident

Probe or Scan

Attack

Virus

Security Incident

Incident

Man-inthe-Middle

causes

Attacker

Event

may cause Unauthorized Harm

may occur to Valuable Asset Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

29

ZATS Safety Incidents 

What kinds of safety incidents can occur if not prevented?  Accidents  Near misses



What kind of harm can these accidents cause to what valuable assets?



How likely can these safety incidents be allowed to be?

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

30

Safety Hazards 

Danger (Defensibility) is one or more conditions, situations, or states of a system that in conjunction with condition(s) in the environment of the system can cause or contribute to the occurrence of an incident: 



Hazard (Safety) is a danger that can cause or contribute to the occurrence of an safety incident. Threat (Security and Survivability) is a danger that can cause or contribute to the occurrence of security or security incident (i.e., a vulnerability combined with an attacker with means, motive, and opportunity). Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

31

Dangers and their Relationships Safety

Security

Hazard

Threat

Danger

Survivability

Attacker

involves the existence and profile of relevant

State

may result in Incident

Environment

System

may cause Unauthorized Harm

may occur to Valuable Asset Tutorial T3

is responsible for protecting or not harming any

Engineering Safety-Related Requirements for Software-Intensive Systems

32

ZATS Hazards 

What kinds of ZATS hazards (hazardous conditions) might exist?



What kinds of safety incidents can these hazards cause?



What kinds of events can cause these safety hazards to exist?



Can the existence of these hazards be detected?

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

33

Safety Risks Safety Risk

is the combination of the severity of harm to a valuable asset with the likelihood that the harm will occur.

Security Risk

Survivability Risk

 Risk

severity is usually set conservatively to the maximum credible category of harm.

is due to

 Harm

 The

likelihood of harm is the likelihood of danger multiplied by the likelihood that the danger results in a harmcausing incident (e.g., accident or attack).

likelihood of

Defensibility Risk

Harm Likelihood

Harm Severity

Danger

may result in Incident

Danger Likelihood

Incident Likelihood

likelihood of

may cause Harm

categorizes amount of

may occur to Asset

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

34

Safety Risk Matrix 

Safety Risks can be categorized (for example) as:    

Intolerable Undesirable As Low As Reasonably Practical (ALARP) Acceptable Safety Risks / Safety Integrity Levels (SILs) Frequency of Accident / Hazard Occurrence

Harm Severity

Frequent

Probable

Occasional

Remote

Implausible

Catastrophic

Intolerable

Intolerable

Intolerable

Undesirable

ALARP

Critical

Intolerable

Intolerable

Undesirable

ALARP

ALARP

Major

Undesirable

Undesirable

ALARP

ALARP

Acceptable

Minor

Undesirable

ALARP

ALARP

Acceptable

Acceptable

Negligible

ALARP

ALARP

ALARP

Acceptable

Acceptable

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

35

ZATS Safety Risks 

How would you develop a safety matrix for ZATS?  How would you categorize and define harm severity?  How would you categorize and define likelihood?



How would you categorize, define, and assign safety risks to the safety risk matrix cells?



What would be some of the ramifications of your choices? Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

36

Safety Goals  Safety Goals are high-level stakeholder desires regarding safety:  “The system must be safe.”  “There can be no serious accidents.”  “The system will never kill or injure its users.”  Goals are typically ambiguous or unrealistic (i.e. impossible to guarantee).  Goals are not requirements.  A major problem is safety goals that are specified as if they were verifiable requirements. Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

37

ZATS Safety Goals 

What do you think some of the safety goals for the ZATS should be?



Are they realistic and verifiable?



Do different stakeholders have different safety goals?

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

38

Safety Policies  Policy – a strategic decision that establishes a desired goal.  Safety policy – a policy that establishes a safety goal:  “The overall responsibility for safety must be identified and communicated to all stakeholders.”  “A hazard analysis shall be performed during early in the project.”  “All users will have safety training.”

 Tend to be process rather than product oriented.  Safety policies are collected into safety policy documents.  In practice, safety policies are confused with requirements and policy documents may sometimes include requirements. Why is this a problem? Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

39

Requirements 

A requirement is a statement that formally specifies a necessary capability or characteristic of a business enterprise, application (system or SW), component, or application domain.



Good requirements must be:          

Mandatory (i.e., required) Cohesive Consistent Correct Feasible Relevant Unambiguous Uniquely Identifiable Verifiable and Validatable What, not how (architecture, design, or implementation)

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

40

Safeguards (Safety Mechanisms) 



A safeguard is a kind of defense that fulfills a safety-related requirement and thereby eliminates or reduces the impact of a safety vulnerability.

A safeguard is a part of the system (e.g., component, procedure, training)

Safety

Security

Safeguard

Countermeasure

Defense fulfills



Only relevant to requirements if specified as safety constraints. Tutorial T3

Defensibility Requirement

Engineering Safety-Related Requirements for Software-Intensive Systems

eliminates or reduces

Vulnerability

41

Safety Vulnerabilities 

A safety vulnerability is a weakness in the architecture, design, implementation, integration, or deployment of a system that enables a hazard to exist or an accident to occur.



Only relevant to requirements if a requirement needs to be specified to prevent the vulnerability or mitigate its negative consequences



For example, if taxi doors did not have locks or lock sensors.

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

42

Putting the Safety Concepts Together Safety Goal

Requirement

states the importance of achieving a target level of

establishes a Functional Requirement

Non-Functional Requirement

mandates a desired criterion of

Safety Policy

Safety

Quality Criterion Quality Requirement

specifies a

mandates a minimum amount of

Quality Measure Safety Requirement fulfills a

Safeguard

Safety Risk exists because of actual or potential

eliminates or reduces

Quality Factor

mandates elimination or reduction of a

describes a quality attribute of a

includes relevant states of the

Environment

is due to Hazard

includes relevant states of the

may result in exploits Vulnerability

Safety Incident

Accident Near Miss

may cause Accidental Harm

has

Asset

may occur to an is responsible for an

System

is valuable to a People

Property

Environment

Services

has a legitimate interest in the Stakeholder

Tutorial T3

Data

Software Hardware Facilities Engineering Safety-Related RequirementsMoney for Software-Intensive

Systems

43

Safety-Related Requirements 

Safety Requirements



Safety-Significant Requirements



Safety System Requirements



Safety Constraints

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

44

Types of Requirements Requirements System Requirements Process Requirements

Non-Functional Requirements

Interface Requirements

Safety Requirements Tutorial T3

Hardware Requirements

Product Requirements

Functional Requirements

Data Requirements

Software Requirements

Main Mission Requirements

Safety System Requirements

Quality Requirements

Constraints

Defensibility Requirements

Safety Constraints

Security Requirements

Survivability Requirements

Engineering Safety-Related Requirements for Software-Intensive Systems

Security System Requirements

45

Safety-Related Requirements 

Safety-Related Requirements are any system requirements having significant safety ramifications: 







Safety Requirements are requirements that specify mandatory amounts of pairs of subfactors of the safety quality factor. Safety-Significant Requirements are non-safety primary mission requirements with significant safety ramifications. Safety System Requirements are requirements for safety systems or subsystems (as opposed to primary mission requirements). Safety Constraints are constraints intended to ensure a minimum level of safety. Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

46

Safety-Related Requirements Safety Integrity Level (SIL)

Safety-Intolerable Requirements SIL = 5 Safety-Critical Requirements SIL = 4 Safety-Major Requirements SIL = 3 Safety-Moderate Requirements SIL=2

Protection of Valuable Assets Requirements Asset Harm Requirements Security Incident Requirements

Reaction to Safety Incidents Requirements

Hazard Requirements

Safety-Minor Requirements SIL = 1

Safety-Significant Requirements SIL ≥ 1

Detection of Safety Incidents Requirements

Adaptation to Safety Incidents Requirements

Safety Risk Requirements Non-Safety Quality Requirements

Safety Requiresments

Safety-Independent Requirements SIL = 0

Functional Requirements

Interface Requirements

Data Requirements

Quality Requirements

System Requirements

Tutorial T3

Safety Constraints

Constraints

Main Mission Requirements

Safety System Requirements

Engineering Safety-Related Requirements for Software-Intensive Systems

47

[Pure] Safety Requirements 

A safety requirement is a kind of defensibility requirement because safety is a type of defensibility. (Safety requirements are like security requirements.)



Safety requirements specify minimum required amounts of:  Safety  A quality subfactor of safety:  Defensibility Problem Type: Accidental Harm, Safety Incident, Hazard, Safety Risk  Defensibility Solution Type: Prevention, Detection, Reaction, Adaptation



A safety requirement is a combination of a safety criterion and a minimum threshold on a safety measure. Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

48

Quality Requirements 

Quality Requirements are based on a quality model: Quality Model

Quality Factor

Quality Subfactor

provides evidence for existence of

Quality Measure with Threshold

measures

provides evidence for existence of

SystemSpecific Quality Criterion

describes quality of

System

Quality Requirement Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

49

Safety Requirements 

Safety Requirements are a kind of quality requirement. Quality Model

Safety

Quality Factor

Quality Subfactor

provides evidence provides evidence for existence of for existence of

requires minimum amount of

Safety Requirement Tutorial T3

Quality Measure with Threshold

measures

SystemSpecific Quality Criterion

describes quality of

System

Quality Requirement Engineering Safety-Related Requirements for Software-Intensive Systems

50

Safety Requirements (Simplified) 

Previous figure with supertypes removed for simplicity:

Safety

Safety Subfactor

provides evidence provides evidence for existence of for existence of

Measure with Threshold

measures

SystemSpecific Safety Criterion

describes safety of

System

requires minimum amount of

Safety Requirement Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

51

Based on Safety Subfactors Accidental Harm

Prevention

Safety Incident

Detection

Hazard

Reaction

Safety Risk

Adaptation

Safety Problem Type

Safety

Safety Solution Type

Safety Subfactor provides evidence for existence of

provides evidence for existence of

System-Specific Safety Criterion Tutorial T3

is measured using

Safety Measure

measures

describes the safety of the

Engineering Safety-Related Requirements for Software-Intensive Systems

System 52

Safety Requirements 

Based on the previous figure, there are twelve types of safety requirements:  Accidental harm prevention, detection, and reaction  Safety incident prevention, detection, and reaction  Hazard prevention, detection, and reaction  Safety risk prevention, detection, and reaction

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

53

Example Safety Requirements 

“The system shall not cause more than X amount of accidental harm per year.”



“The system shall not cause more than X safety incidents (accidents, near misses) per passenger mile traveled.”



“The system shall not cause hazard X to exist more than Y percent of the time.”



“The system shall not allow a safety risk level of X to exist.”



“The system shall detect accidents of type X Y percent of the time.”



“The system shall react to accidents of type X by performing Y.” Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

54

ZATS Safety Requirements 

What are some reasonable ZATS safety requirements related to preventing:  Accidental harm to valuable assets?  Safety incidents from occurring?  Hazards from existing?  Safety risks from being too high?



How about:   

Detecting accidental harm, safety incidents, hazards, and risks? Reacting to the detection of harm, incidents, hazards, and risks? Adapting ZATS to better handle future harm, safety incidents, hazards, and risks? Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

55

Safety-Significant Requirements 

Are identified based on safety (hazard) analysis



Subset of non-safety requirements:  Functional Requirements  Data Requirements  Interface Requirements  Non-safety Quality Requirements  Constraints Safety Integrity Level (SIL) is not 0:  May have minor safety ramifications  May be safety-critical  May have intolerable safety risk



Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

56

SILs and SEALs 

Safety Integrity Level – a category of required safety for safety-significant requirements.



Safety Evidence Assurance Level – a category of required evidence needed to assure stakeholders (e.g., safety certifiers) that the system is sufficiently safe (i.e., that it has achieved its required SIL).



SILs are for requirements



SEALs are for components that collaborate to fulfill requirements (e.g., architecture, design, coding, testing)

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

57

Safety-Significant Requirements (cont) 

Require enhanced Safety Evidence Assurance Levels (SEALs) including more rigorous development process (including better requirements engineering):  Formal specification of requirements  Fagan inspections of requirements



Too often SEALs only apply to design, coding, and testing:  Safe subset of programming language  Design inspections  Extra testing Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

58

Example Safety-Significant Requirements 

Requirements for controlling elevator doors:  Keep doors closed when moving  Not crush passengers



Requirements for firing missiles from military aircraft:  When to arm missile  Controlling doors providing stealth capabilities  Detecting weight-on-wheels



Requirements for chemical plant:  Mixing and heating chemicals  Detecting temperature and pressure Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

59

ZATS Safety-Significant Requirements 

What are some reasonable ZATS functional requirements with safety ramifications?



What is a reasonable data requirement with safety ramifications?



What is a reasonable interface requirement with safety ramifications?



What SIL level (e.g., intolerable, undesirable, tolerable, insignificant) should be assigned to these safety-significant requirements?

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

60

Safety System Requirements 

Systems or components strictly added for safety:  Emergency core coolant system for nuclear power plant  Fire detection and suppression system for aircraft  Emergency full pump cut off for gas station  Emergency stop for escalators



All requirements for such systems are safety-related

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

61

Example Safety System Requirements 

“Except when the weapons bay doors are open or have been open within the previous 30 seconds, the weapons bay cooling system shall maintain the temperature of the weapons bay below X C.”



“The Fire Detection and Suppression System (FDSS) shall detect smoke above X ppm in the weapons bay within 5 seconds.”



“The FDSS shall detect temperatures above X C in the weapons bay within 2 seconds.”



“Upon detection of smoke or excess temperature, the FDSS shall alert the pilot within 1 second and begin fire suppression.” Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

62

ZATS Safety System Requirements 

Would the ZATS system need a safety subsystem?



If so, what would that subsystem be and what would a few of its requirements be?

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

63

Safety Constraints 

A constraint is any engineering decision that has been chosen to be mandated as a requirement. For example:  Architecture constraints  Design constraints  Implementation (e.g., coding) constraints  Testing constraints



A safety constraint is any constraint primarily intended to ensure a minimum level of safety (e.g., a mandated safety control).



Safety standards often mandate best practices safety constraints. Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

64

Example Safety Constraints 

“When the vehicle is stopped in a station with the doors open for boarding, the horizontal gap between the station platform and the vehicle door threshold shall be no greater than 25 mm (1.0 in.) and the height of the vehicle floor shall be within plus/minus 12 mm (0.5 in.) of the platform height under all normal static load conditions…” Automated People Mover Standards – Part 2: Vehicles, Propulsion, and Braking (ASCE 21-98)



“Oils and hydraulic fluids shall be flame retardant, except as required for normal lubrication.”

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

65

ZATS Safety Constraints 

What would be reasonable safety constraints to specify on the ZATS system?

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

66

Safety Engineering Process Safety Engineering

Safety Program Planning

Safety Analysis

Safety Monitoring

Safety Incident Investigation

Asset Analysis

Safety Incident Analysis

Hazard Analysis

Safety Risk Analysis

Asset / Harm Requirements

Safety Incident Requirements

Hazard Requirements

Safety Risk Requirements

Safety Requirements

Safety Compliance Assessment

Safety Significance Analysis

Safety-Significant Requirements

Safety System Requirements

Safety Certification

Safety Control Analysis

Safety Constraints

Safety-Related Requirements Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

67

Safety & Requirements Engineering

Safety Team

Set Safety Goals

Safety Goals

Safety Program Planning

Safety Program Plan

Safety Significance Analysis

Application Visioning

Application Vision Statement (ConOps) System Requirements Specification

Requirements Team Requirements Specification

are categorized during SafetySignificant Requirements Safety Analysis

Safety Control Analysis Tutorial T3

System Requirements

Safety Requirements Safety System Requirements

Safety-Related Requirements

Requirements Elicitation

Safety Constraints Engineering Safety-Related Requirements for Software-Intensive Systems

68

Safety Program Planning Safety Team

Set Safety Policy

Safety Policy

Set Safety Goals

Safety Goals

Subject Matter Experts

Stakeholders

Asset Value Categories

performs

Harm Severity Categories

Project Documentation (RFP, Contract, ConOps) Legacy Documentation

Safety Program Planning

Hazard Likelihood Categories Determine Safety Categories

Safety Incident Likelihood Categories Safety Risk Matrix

Generic / Reusable Safety Categories Safety Integrity Levels (SIL)

Standard / Reusable Safety Evidence Assurance Levels

Safety Evidence Assurance Levels Develop Safety Program

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

Safety Program Plan

69

Safety Analysis Architecture Team

Safety Team Requirements Team

supports supports

helps perform

Prelim. Hazard Analysis

performs

Safety Analysis

Asset Analysis

Asset Safety Requirements

Safety Incident Analysis

Hazard Analysis

Accident Safety Requirements

Hazard Safety Requirements

System Hazard Analysis

Safety Significance Analysis

Safety Risk Analysis

helps perform

Safety Control Analysis

Safety Risk Safety Requirements

identifies

Safety Requirements

SafetySignificant Requirements

Safety System Requirements

Safety Constraints

Safety-Related Requirements Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

70

Asset Analysis Subject Matter Experts

Safety Team

Stakeholders performs

Project Documentation (RFP, Contract, ConOps) Generic / Reusable Asset Lists Generic / Reusable Asset / Harm Tables

Standard / Reusable Harm Severity Categories

Asset Identification

Asset List

Value Analysis Asset Analysis

Asset Value and Harm Table Harm Analysis

Asset / Harm Requirements Production

Asset / Harm Requirements

helps perform Requirements Team

Standard / Reusable Asset / Harm Requirements

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

71

Safety Incident Analysis Subject Matter Experts

Safety Team

Stakeholders

performs Project Documentation (RFP, Contract, ConOps) Generic / Reusable Safety Incident Type Lists Asset Value and Harm Table

Safety Incident Analysis

Harm Severity Categories Generic / Reusable Safety Incident / Harm Tables Standard / Reusable Safety Incident Likelihood Categories Safety Incident Likelihood Categories

Safety Incident Type Identification

Safety Incident Type List

Safety Incident Harm Analysis

Safety Incident Type / Harm Table

Safety Incident Likelihood Analysis

Safety Incident Type Likelihood Table

Safety Incident Requirements Production

Safety Incident Requirements

helps perform Requirements Team

Standard / Reusable Safety Incident Requirements

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

72

Hazard Analysis Safety Team

Hazard Identification

Hazard List

Hazard Categorization

Hazard Categories

Subject Matter Experts

Network of Causes Analysis

performs Stakeholders

Hazard Cause Analysis Hazard Analysis

Project Documentation (System Architecture) Generic / Reusable Hazard Lists

Root Cause Analysis Common Cause Analysis

Hazard Effects Analysis

Generic / Reusable Hazard Safety Requirements

Hazard Cause & Effect Diagrams and Tables

HAZOP/ FEMA

Hazard Likelihood Analysis

Hazard Likelihood Table

Hazard Reporting

Hazard Reports

Hazard Requirements Production

Hazard Safety Requirements

Standard / Reusable Hazard Categories Standard / Reusable Hazard Likelihoods

Fault/Event Trees

helps perform Requirements Team

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

73

Safety Risk Analysis Subject Matter Experts

Safety Team

Stakeholders

performs

Harm Severity Categories Generic / Reusable Safety Risk Matrices

Safety Risk Determination

Standard / Reusable Safety Risk Categories Safety Risk Analysis

Accident / Hazard Likelihood Categories Standard / Reusable Safety Integrity Levels

Safety Risk Estimation

Safety Risk Requirements Production

Standard / Reusable Safety Evidence Assurance Levels (SEALs)

Safety Risks

Accident Type Safety Risk Table Hazard Safety Risk Table Safety Risk Requirements

helps perform Requirements Team

Safety Risk Categories Generic / Reusable Safety Risk Requirements

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

74

Safety-Significance Analysis Safety Team

Requirements Team

Identify Safety-Significant Functional Requirements

Subject Matter Experts

performs

helps perform Identify Safety-Significant Data Requirements Safety-Significant Requirements Identification

Stakeholders

Identify Safety-Significant Interface Requirements

Functional Requirements

Safety Significance Analysis

Categorization of SafetySignificant Requirements

Identify Safety-Significant Non-Quality Requirements

Data Requirements Interface Requirements Non-Safety Quality Requirements Safety Risk Tables Safety Integrity Levels Tutorial T3

Safety Integrity Level (SIL) Allocation

Safety Evidence Assurance Level (SEAL) Allocation

Engineering Safety-Related Requirements for Software-Intensive Systems

Safety Integrity Level (SIL) Allocation Safety Evidence Assurance Level (SEAL) Allocation

75

Safety Control Analysis Safety Team

Architecture Team supports

performs

helps perform

Subject Matter Experts Safety Controls Identification

Safety Controls

Safety System Identification

Updated System Architecture

Safety System Requirements Allocation

Safety System Requirements

Safety Constraints Determination

Safety Constraints

Stakeholders

Safety Control Analysis Safety-Significant Requirements

Safety Analyses

System Architecture

helps perform Requirements Team

Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

76

Conclusion 

Engineering safety-significant requirements requires concepts, methods, techniques, and expertise from both requirements engineering and safety engineering.



There are multiple types of safety-related requirements that have different forms and that need to be analyzed and specified differently.



Look for my upcoming book by the same title.



For more information, check out my repository of over 1,100 free open source reusable process components including many on safety at www.opfro.org. Tutorial T3

Engineering Safety-Related Requirements for Software-Intensive Systems

77

Engineering Safety-Related Requirements for Software ...

Engineering Safety-Related Requirements for Software-Intensive Systems. 2 ... Safeware Engineering, “Safety-Critical Requirements Specification and Analysis.

3KB Sizes 1 Downloads 233 Views

Recommend Documents

The Business Case for Requirements Engineering - Software ...
Sep 12, 2003 - The Business Case for. Requirements Engineering ... Implementation. • Integration. • Testing ... (e.g., use case modeling). • Requirements Tools ...

Engineering Safety-Related Requirements for Software ...
May 15, 2005 - ABSTRACT. Many software-intensive systems have significant safety .... Systems (RHAS) Workshop, in Kyoto, Japan, IEEE Computer Society,.

Engineering Safety-Related Requirements for Software ...
Engineering Safety-Related Requirements for Software-Intensive Systems. 2. Topics .... “A hazard analysis shall be performed during early in the project.”.

Engineering Safety-Related Requirements for Software ...
Mar 9, 2006 - F. Brooks, No Silver Bullet, IEEE Computer, 1987 ... ○The system shall be easy to use. ... subsystem, software application, or component).

Engineering Safety- and Security-Related Requirements for Software ...
Feb 5, 2007 - the engineering discipline within systems/software engineering ..... Safety and. Security. Engineering. Event. Analysis. Danger. Analysis. Risk.

IEEE Recommended Practice for Software Requirements Specifications
James J. Longbucco. Dieter Look. John Lord. Stan Magee. David Maibor. Harold Mains. Robert A. Martin. Tomoo Matsubara. Mike McAndrew. Patrick D. McCray.

IEEE Recommended Practice for Software Requirements Specifications
Carl A. Singer. James M. Sivak. Richard S. Sky. Nancy M. Smith ..... hidden assumptions they may have. b) Have developers make correct design decisions and ...

Agile Software Requirements
and the Enterprise (Agile Software Development ... Enterprise (Agile Software Development Series), Full PDF Agile Software Requirements: Lean .... author of Managing the Design Factory; and leading expert on rapid product development.

Software Requirements Specification
and Defect are entities that implement create, read, update and delete actions, but .... public String createDomain(String domainName) – Method creates a new.