Goal Structuring Notation and Claim Trees

1.1. Goal Structuring Notation and Claim Trees

1.1.1. A description of the technique, including its purpose

1.1.1.1.

Goal Structuring Notation (GSN) and Claim Trees are two similar techniques used to present an explanation of how the available evidence can be interpreted to indicate the achievement of a top-level claim or assertion, for example that a system is tolerably safe. Whilst similar, each technique has its own symbols (or Notation), and Claim Trees can be thought of as a simplified version of GSN.

1.1.1.2.

The techniques have developed from academic work on the nature of reasoning. They show how satisfaction of a top-level “Goal” (or “Claim”) is supported by arguments and evidence at progressively more detailed levels. A Safety Argument is “a logically stated and convincingly demonstrated reason why safety requirements are met.”

1.1.1.3.

GSN and Claim Trees provide graphical methods to present Safety arguments explicitly rather than relying on detailed textual descriptions which are often incomplete, unclear or contain implicit assumptions. Each technique presents the arguments visually in a logical way, providing interested parties with a clear representation of how the safety argument has been constructed to meet the top-level Goal (Claim).

1.1.1.4.

GSN and Claim Trees both have similar elements, including:

  • Goals for, or Claims about, a property of the system or a sub-system
  • Evidence that supports the specific Goal (Claim). These can be either facts (e.g. based on established scientific principles and prior research), assumptions or sub-claims derived from a lower-level sub-argument
  • Arguments linking the Evidence to the Claim, and these may be of several different types, in the following general order of merit:
    • Deterministic (e.g. formal proof, repeatably measurable attribute)
    • Probabilistic (e.g. based on statistical analysis to provide an estimate of a probabilistic parameter such as Reliability, with associated confidence level)
    • Review (e.g. independent review, supported by metrics demonstrating the effectiveness of the review process)
    • Qualitative / Indirect (e.g. process followed, staff competence)

1.1.1.5.

A safety argument provides the link between documented evidence and the safety Goal (claim) it is intended to satisfy. The safety argument comprises both statements, in the form of assumptions, justifications and strategies to provide the intermediate explanatory steps that describe the approach of the argument adopted and its relevance to the Goal (Claim). As such, Safety Arguments provide the rationale for progression through the levels of the diagram, and ultimately to the Top Level Goal (Claim).

1.1.1.6.

The main symbols used in GSN diagrams are:

1.1.1.7.

Goals, Assumptions, and Justification statements should be single unambiguous statements consisting of a noun phrase (subject) followed by a verb phrase (a statement which is either true or false). For example, “Component A has no critical failure modes”.

1.1.1.8.

The diagrams should require little supporting documentation apart from references contained within the contextual boxes (to remove ambiguities), assumptions, and justifications.

1.1.1.9.

Claims Trees and GSN diagrams are constructed either:

  • Top-down, identifying the top-level Goal (Claim) of the argument and decomposing this into sub-goals (sub-Claims) for which evidence can be provided;
  • Or bottom-up, where evidence exists which has to be structured in such a way to demonstrate achievement of a top-level Goal (Claim).

1.1.1.10.

Claim Trees and GSN diagrams are often constructed for complex systems composed of several distinct systems each with their own discrete Safety Requirements and Safety Case. The interactions between the systems should be documented within the associated GSN or claim tree, for example by use of an assumption or within the safety argument by looking at the safe operation of System A, given that System B is in a certain configuration.

1.1.1.11.

GSN or Claim Trees can be used within any Safety Case to present a clearly defined argument for the safe use of any system or equipment. However, it is not the only method of achieving this and therefore Safety Cases using other approaches should not necessarily be regarded as improper or inferior.

1.1.2. When it might be used

1.1.2.1.

For a new Project, GSN or Claim Tree diagrams should be developed early, to identify the approach for Safety Assurance and the evidence which is to be developed, in order to support a sound Safety Case. The Safety Plan should then show what activities are to be done to populate the GSN or Claim Tree with the necessary evidence of Safety.

1.1.2.2.

The GSN or Claim Tree diagrams should be refined to progressively more detailed levels as the system design develops and good evidence becomes available. Where the Claims were supported by Assumptions early in the project life-cycle, Safety Assurance activities such as testing and analysis should be used to replace Assumptions with evidence.

1.1.2.3.

If evidence is produced that contradicts the Claim of Safety, then the GSN or Claim Tree can highlight the shortfall and the need for remedial action.

1.1.2.4.

An example of a GSN is shown below:

1.1.3. Advantages, disadvantages and limitations to the defence sector or the particular domain

1.1.3.1.

Advantages

  • GSN, Claim Trees and similar approaches make explicit the reasoning behind Safety Cases. They therefore make it easier for stakeholders to check the Safety Case.
  • For complex arguments, GSN and Claim Tree diagrams can break down the argument into manageable sections and provide clear comprehension to all interested parties of how the safety argument has been constructed to meet the top-level claim.
  • GSN and Claim Trees can also support Project Management activities by allowing clear monitoring of progress towards the successful completion of a Safety Case.
  • The technique promotes consistency and improved comprehension of arguments, and allows analysis of complex system interdependencies.
  • Software Tools exist to support the GSN and Claim Tree techniques. These range from simple drawing packages to sophisticated products that can organise Safety Case documentation, link to Hazard Analysis tools and automatically generate documents and summary reports.
  • The technique can be particularly useful for the introduction of an untried concept into a well established system.

1.1.3.2.

Disadvantages and Warnings

  • The use of the GSN and Claim Tree technique might give an unrealistic impression of rigour if poorly applied. As with any top-down process, it is more difficult to identify omissions to the argument than to review the content of the presented argument. Stakeholders must still examine the Goals (Claims), together with supporting Arguments and Evidence, although the technique will facilitate this review process.
  • The Top Level Goal (Claim) must be stated clearly and contain the correct concepts to define it. The basis for Goals (Claims) should be unambiguous, and presented as positive statements of objectives to be achieved, not requirements or aspirations.
  • Oversimplification of Goals can reduce the scope and usefulness of the presented argument e.g. “System X is acceptably Safe” is less powerful than “System X is acceptably Safe to operate within Operating Concept Y”.
  • Goals often contain ‘context’ information e.g. “Operating Concept Y” in the previous paragraph. To prevent any misinterpretation all ‘context’ information must be supported by a ‘Context’ statement/reference to the associated information.
  • Care must be taken in construction of the GSN (Claim Tree) to avoid prematurely associating a Goal (Claim) with evidence without clearly showing the relationship. e.g. Goal of ‘Defence in Depth’ associated with claim of ‘System Design Validation’.
  • Evidence must be pertinent to the argument.
1.1.4. Sources of additional information. Standards, textbooks & web-sites.

1.1.4.1.

[1] Nuclear Reactor Engineering. S. Glastone and A Sesonke New York: Van Nostrand Reinhold 1981

[2] “Using Reversible Computing to Achieve Fail-safety,” presented at Eighth International Symposium on Software Reliability (ISSRE’97), P. Bishop, Albuquerque, New Mexico, 1997.

[3] “A six-step Method for the Development of Goal Structures” T. P. Kelly, York Software Engineering, Flixborough UK, 1997

[4] The future of goal-based assurance cases (Adelard paper)

[5] The HEAT/ACT Preliminary Safety Case: A case study in the use of Goal Structuring Notation, Paul Chinneck (Safety & Airworthiness Department, Westland Helicopters) David Pumfrey, John McDermid (Dept of Computer Science, University of York)

[6] Turning Up the HEAT on Safety Case Construction, Paul Chinneck (Safety & Airworthiness Department, Westland Helicopters) David Pumfrey, Tim Kelly (Dept of Computer Science, University of York)

[7] Building a Preliminary Safety Case: An Example from Aerospace, Tim Kelly, Iain Bate, John McDermid, Alan Burns Rolls-Royce Systems and Software Engineering, University Technology Centre, Department of Computer Science, University of York, York YO1 5DD, U.K.

Software to support development of graphical representation of the Safety Argument:

[8] Adelard ASCE Tool 

1.1.5. GSN Example

1.1.5.1.

The example below illustrates a part of a safety argument, which argues that System X is acceptable safe to operate within operating Concept Y because all identified hazards have been eliminated or sufficiently mitigated.

GSN

1.2. Version Control

1.2.1. Version 2.3 to 3.0 Uplift

1.2.1.1.

Major uplift from the Acquisition System Guidance (ASG) to online version.