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 and delivers sound environmental performance. 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.3.

GSN and Claim Trees provide graphical methods to present Safety and Environmental 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 arguments have been constructed to meet the top-level Goal (Claim).

1.1.1.5.

A safety or environmental argument provides the link between documented evidence and the Goal (claim) it is intended to satisfy. The arguments comprise 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, Arguments provide the rationale for progression through the levels of the diagram, and ultimately to the Top Level Goal (Claim).

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.10.

Claim Trees and GSN diagrams are often constructed for complex systems composed of several distinct systems each with their own discrete Safety and Environmental Requirements and Safety and Environmental Cases. 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 and/or environmental argument by looking at the safe and/or environmentally sound operation of System A, given that System B is in a certain configuration.

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 and Environmental Assurance activities such as testing and analysis should be used to replace Assumptions with evidence.

1.1.2.4.

An example of a GSN is shown below:

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.1.

A list of additional information (e.g., Standards, textbooks, and websites) includes but is not limited to:

• Nuclear Reactor Engineering. S. Glastone and A Sesonke New York: Van Nostrand Reinhold 1981
• “Using Reversible Computing to Achieve Fail-safety,” presented at Eighth International Symposium on Software Reliability (ISSRE’97), P. Bishop, Albuquerque, New Mexico, 1997.
• “A six-step Method for the Development of Goal Structures” T. P. Kelly, York Software Engineering, Flixborough UK, 1997
• The future of goal-based assurance cases (Adelard paper)
• 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)
• 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)
• 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.
• Adelard ASCE Tool  (A software to support development of graphical representation of the Safety Argument)

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.