Safety Requirements

Definition

Safety Requirement

the defensibility requirement that specifies a minimum required amount of a quality subfactor of the quality factor safety

Objectives

The typical objectives of a safety requirement are to:

• Asset Protection. Protect valuable asset from accidental harm by reducing (e.g., via elimination or minimization) to acceptable levels:
  • Accidental harm to valuable assets
  • Safety incidents (accidents and near accidents)
  • Hazards
  • Safety Risks
• Safety Incident Detection.
  • Identify and record the occurance of safety incidents
• Safety Incident Reaction.
  • Analyze and report safety incidents
  • Degrade and restore service
  • Support prosecution of malfeasance

Measurements

Safety requirements are typically specified in terms of the following measurements:

• Accidental Harm:
  • Maximum [number | average number] of [injuries (of a specific severity) | illnesses(of a specific type and severity) | deaths] [caused | permitted | N/A] per [unit time | number of operations | number of service requests] whereby Injury and illness severity may be measured in terms of hospitalizations or days of work lost.
  • Maximum [replacement cost | repair cost | initial cost] of [data | hardware | software | facilities | third party] property damage [caused | permitted | N/A] per [unit time | number of operations | number of service requests]
• Safety Incidents:
  • Maximum [number | average number] of [safety incidents | accidents (of a specific type and severity) | near accidents] [caused | permitted | N/A] per [unit time | number of operations | number of service requests]
  • Minimum mean time between [safety incidents | accidents (of a specific severity) | near accidents]
• Hazards:
  • Maximum [number | average number] of [one or more simultaneous] [hazards (of a specific type)] [caused | permitted | N/A] per [unit time | number of operations | number of service requests]
  • Maximum percentage of [one or more simultaneous] [hazards (of a specific type)] that result in [safety incidents | accidents (of a specific type and severity) | near accidents]
• Safety Risks:
  • Maximum [amount | level] of safety risk [total | of a specific type] [caused | permitted | N/A] [per [unit time | number of operations | number of service requests] | N/A]
• Safety Incident Detection:
  • [Minimum percentage | maximum number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [identified | not identified] per [unit time | number of operations | number of service requests]
  • [Minimum percentage | maximum number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [recorded | not recorded] per [unit time | number of operations | number of service requests]
• Safety Incident Reaction.
  • [Minimum percentage | maximum number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [analyzed | not analyzed] per [unit time | number of operations | number of service requests]
  • [Minimum percentage | maximum number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [reported | not reported] per [unit time | number of operations | number of service requests]
  • [Minimum percentage of the time | maximum number of times] that a [specific service] is [caused | permitted | N/A] to [degrade | not degrade] per occurrence of a [safety incident | accident | near miss | of a specific subtype]
  • [Minimum percentage of the time | maximum number of times] that a [specific degraded service] is [caused | permitted | N/A] to [be restored | not be restored] [within time limit] per occurrence of a [safety incident | accident | near miss | of a specific subtype]

Examples

The following are typical examples of safety requirements:

• Asset Protection:
  • Protection Against Accidental Harm:
    • “The medical gamma-ray control system shall not permit a patient to be given a full-body dose of more than 300rem.”
    • “The tape library control system shall not permit the rapid movement of the robot arm to cause harm to the tape librarian or any maintenance engineers.”
    • “The application shall not accidentally loose or corrupt valuable data belonging to either its users or owners.”
    • “The application shall not loose persistant data due to power failures.”
    • “The money transfer application shall not accidentally lose any of the money that it electronically transfers between banks and other financial institutions.”
    • “The automated airport subway system shall not injure passengers sufficiently to require hospitalization at an average rate greater than 0.000,000,1 passengers per passenger trip.”
      (Note that this is estimated to be no more than approximately 5 injured passengers per year.)
  • Protection Against Safety Incidents:
    • “The avionics system shall not permit the airplane to be piloted into a stall or into the ground.”
  • Protection Against Hazards:
    • “The avionics system shall not permit the airplane to be piloted within an unsafe distance of another airplane.”
    • “The nuclear power station control system shall not permit the removal of reactor control rods to produce a power of more than 100% of the reactor’s maximum certified power level.”
    • “To avoid friendly fire incidents, the military command and control application shall clearly distinguish all battlefield forces as being friendly, foe, or unknown.”
    • “To avoid friendly fire incidents, the military multiple rocket launcher control application shall provide a warning and require a manual override to target locations that the command and control application has designated as being occupied by friendly forces.”
    • “The automated airport subway system train shall not start moving when its doors are still open more than once per year.”
  • Protection Against Safety Risks:
• Safety Incident Detection:
  • Safety Incident Identification:
    • “The automated airport subway system shall identify a combination of a train moving with its doors open with a probability of at least 99.99%.”
  • Safety Incident Recording:
    • “At least 99.99% of the time, the automated airport subway system shall notify the operator when it detects that a train moving with its doors open.”
• Safety Incident Reaction:
  • Safety Incident Analysis:
    • TBD
  • Safety Incident Reporting:
    • “The automated airport subway system shall report to the safety officer occurrences of identified safety incidents at least 99.999% of the time.”
  • Service Degradation:
    • “At least 99.99% of the time, the automated airport subway system shall stop when it detects that it is moving when at least one of its doors are open.”
  • Service Restoration:
    • “At least 99.99% of the time, the automated airport subway system shall close its open doors and return to service within one minute of having stopped after detecting that it was moving with at least one of its doors open.”
  • Malfeasance Prosecution Support:
    • TBD

Guidelines

The following guidelines have been found to be useful when producing safety requirements:

• Accidental harm can include the following:
  • Life:
    • Injury
    • Illness
    • Loss of life
  • Property:
    • Corruption or loss of valuable data
    • Damage to or loss of hardware components
    • Corruption or loss of software components
    • Damage to or loss of facilities
    • Loss of money
    • Damage to or loss of third party property
  • Environment:
    • Damage to the environment
• Safety-related requiements include:
  • Safety requirements
  • Safety constraints
  • Safety-critical functional, data, and interface requirements
• The scope of a safety requirement can be:
  • A business enterprise
  • An application
  • A component
  • A center
• Safety requirements are typically only specified for safety-critical applications or components of such applications, whereby a safety-critical application is one that is capable of causing harm if it fails.
• Safety requirements are restricted to unintentional harm. Weapon systems should naturally cause intentional harm to or loss of the enemy’s life or property, while implementing safety requirements for its users.
• Safety requirements are system-level requirements that may be implemented by some combination of software, hardware, data, documentation, and personnel.
• By using the concept of ‘adequate safety’, safety can be improved by decreasing either the safety impact of failure or the probability that relevant failures will occur.
• Safety requirments may depend on the context in which the application is used. For example, the failure of a microprocessor-controlled drug infusion pump is much more critical when infusing a drug into a critically-ill patient than when infusing a relatively nontoxic drug into a laboratory animal during an experiment.
• Safety requirements concerning the accidental corruption of valuable data should not be confused with integrity (security) requirements concerning the intentional, malicious corruption of data.
• Requirements vs. Architectural Mechanisms.
  Great care should be taken to avoid unnecessarily specifying architectural mechanisms for fulfilling safety requirements as if they were safety requirements. The requirements team is often ill equiped to make architecture decisions, and doing so may cause problems in the relationships between the requirements team and the architecture team. If specific architectural mechanisms must be specified (e.g., to ensure regulatory certification), then specify them as architectural constraints, not as true requirements.
• Safety requirements are usually identified and analyzed using a combination of:
  • Hazard Identification including analysis of individual functional requirements (including commission and omission) for associated potential hazards.
  • Hazard Analysis including hazard categorization, hazard risk analysis, and hazard cause analysis.