Goal structuring notation

Last updated

Goal structuring notation (GSN) is a graphical diagram notation used to show the elements of an argument and the relationships between those elements in a clearer format than plain text. [1] Often used in safety engineering, GSN was developed at the University of York during the 1990s to present safety cases. [2] The notation gained popularity as a method of presenting safety assurances but can be applied to any type of argument and was standardized in 2011. [1] GSN has been used to track safety assurances in industries such as clinical care [3] aviation, [4] automotive, rail, [5] traffic management, and nuclear power [6] and has been used in other contexts such as security cases, patent claims, debate strategy, and legal arguments. [5]

Contents

History

The goal structuring notation was first developed at the University of York during the ASAM-II (A Safety Argument Manager II) project in the early 1990s, to overcome perceived issues in expressing safety arguments using the Toulmin method. The notation was further developed and expanded by Tim Kelly, whose PhD thesis contributed systematic methods for constructing and maintaining GSN diagrams, and the concept of ′safety case patterns′ to promote the re-use of argument fragments. [2] During the late 1990s and early 2000s, the GSN methodology was taught in the Safety Critical Systems Engineering course at York, and various extensions to the GSN methodology were proposed by Kelly and other members of the university's High Integrity Systems Engineering group. [7]

By 2007, goal structuring notation was sufficiently popular that a group of industry and academic users came together to standardise the notation and its surrounding methodology, resulting in the publication of the GSN Community Standard in 2011. From 2014, maintenance of the GSN standard moved under the auspices of the SCSC's Assurance Case Working Group. [8] As at 2022, the standard has reached Version 3. [1]

Criticism

Charles Haddon-Cave in his review of the Nimrod accident commented that the top goal of a GSN argument can drive a conclusion that is already assumed, such as that a platform is deemed acceptably safe. This could lead to the safety case becoming a "self-fulfilling prophesy", giving a "warm sense of over-confidence" rather than highlighting uncertainties, gaps in knowledge or areas where the mitigation argument was not straightforward. [4] This had already been recognised by Habli and Kelly, who warned that a GSN diagram was just a depiction, not the safety case itself, and likened it to Magritte's painting The Treachery of Images. [9] Haddon-Cave also criticised the practice of consultants producing "outsize GSN charts" that could be yards long and became an end in themselves rather than an aid to structured thinking.

See also

Related Research Articles

<span class="mw-page-title-main">Object-modeling language</span> Component in software development

An object-modeling language is a standardized set of symbols used to model a software system using an object-oriented framework. The symbols can be either informal or formal ranging from predefined graphical templates to formal object models defined by grammars and specifications.

<span class="mw-page-title-main">Unified Modeling Language</span> Software system design modeling tool

The unified modeling language (UML) is a general-purpose visual modeling language that is intended to provide a standard way to visualize the design of a system.

A modeling language is any artificial language that can be used to express data, information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure Programing language.

<span class="mw-page-title-main">Computer-aided software engineering</span> Software Quality Engineering Practices

Computer-aided software engineering (CASE) was a domain of software tools used to design and implement applications. CASE tools were similar to and were partly inspired by Computer-Aided Design (CAD) tools used for designing hardware products. CASE tools were intended to help develop high-quality, defect-free, and maintainable software. CASE software was often associated with methods for the development of information systems together with automated tools that could be used in the software development process.

<span class="mw-page-title-main">Data modeling</span> Creating a model of the data in a system

Data modeling in software engineering is the process of creating a data model for an information system by applying certain formal techniques. It may be applied as part of broader Model-driven engineering (MDD) concept.

GSN may refer to:

<span class="mw-page-title-main">Business process modeling</span> Activity of representing processes of an enterprise

Business process modeling (BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current business processes may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.

<span class="mw-page-title-main">Stephen Toulmin</span> English philosopher (1922–2009)

Stephen Edelston Toulmin was a British philosopher, author, and educator. Influenced by Ludwig Wittgenstein, Toulmin devoted his works to the analysis of moral reasoning. Throughout his writings, he sought to develop practical arguments which can be used effectively in evaluating the ethics behind moral issues. His works were later found useful in the field of rhetoric for analyzing rhetorical arguments. The Toulmin model of argumentation, a diagram containing six interrelated components used for analyzing arguments, and published in his 1958 book The Uses of Argument, was considered his most influential work, particularly in the field of rhetoric and communication, and in computer science.

The Shlaer–Mellor method, also known as object-oriented systems analysis (OOSA) or object-oriented analysis (OOA) is an object-oriented software development methodology introduced by Sally Shlaer and Stephen Mellor in 1988. The method makes the documented analysis so precise that it is possible to implement the analysis model directly by translation to the target architecture, rather than by elaborating model changes through a series of more platform-specific models. In the new millennium the Shlaer–Mellor method has migrated to the UML notation, becoming Executable UML.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

<span class="mw-page-title-main">Argument map</span> Visual representation of the structure of an argument

An argument map or argument diagram is a visual representation of the structure of an argument. An argument map typically includes all the key components of the argument, traditionally called the conclusion and the premises, also called contention and reasons. Argument maps can also show co-premises, objections, counterarguments, rebuttals, and lemmas. There are different styles of argument map but they are often functionally equivalent and represent an argument's individual claims and the relationships between them.

Eight Disciplines Methodology (8D) is a method or model developed at Ford Motor Company used to approach and to resolve problems, typically employed by quality engineers or other professionals. Focused on product and process improvement, its purpose is to identify, correct, and eliminate recurring problems. It establishes a permanent corrective action based on statistical analysis of the problem and on the origin of the problem by determining the root causes. Although it originally comprised eight stages, or 'disciplines', it was later augmented by an initial planning stage. 8D follows the logic of the PDCA cycle. The disciplines are:

<span class="mw-page-title-main">Issue-based information system</span> Argumentation scheme

The issue-based information system (IBIS) is an argumentation-based approach to clarifying wicked problems—complex, ill-defined problems that involve multiple stakeholders. Diagrammatic visualization using IBIS notation is often called issue mapping.

<span class="mw-page-title-main">Function model</span>

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions within the modeled system or subject area.

Process map is a global-system process model that is used to outline the processes that make up the business system and how they interact with each other. Process map shows the processes as objects, which means it is a static and non-algorithmic view of the processes. It should be differentiated from a detailed process model, which shows a dynamic and algorithmic view of the processes, usually known as a process flow diagram. There are different notation standards that can be used for modelling process maps, but the most notable ones are TOGAF Event Diagram, Eriksson-Penker notation, and ARIS Value Added Chain.

A goal model is an element of requirements engineering that may also be used more widely in business analysis. Related elements include stakeholder analysis, context analysis, and scenarios, among other business and technical areas.

A metaCASE tool is a type of application software that provides the possibility to create one or more modeling methods, languages or notations for use within the process of software development. Often the result is a modeling tool for that language. MetaCASE tools are thus a kind of language workbench, generally considered as being focused on graphical modeling languages.

<span class="mw-page-title-main">Systems modeling</span>

Systems modeling or system modeling is the interdisciplinary study of the use of models to conceptualize and construct systems in business and IT development.

The Safety-Critical Systems Club (SCSC) is a professional association in the United Kingdom. It aims to share knowledge about safety-critical systems, including current and emerging practices in safety engineering, software engineering, and product and process safety standards.

One definition of a Safety Case is that it is a structured argument, supported by evidence, intended to justify that a system is acceptably safe for a specific application in a specific operating environment. Safety cases are often required as part of a regulatory process, a certificate of safety being granted only when the regulator is satisfied by the argument presented in a safety case. Industries regulated in this way include transportation and medical devices. As such there are strong parallels with the formal evaluation of risk used to prepare a Risk Assessment, although the result will be case specific. A vehicle safety case may show it to be acceptably safe to be driven on a road, but conclude that it may be unsuited to driving on rough ground, or with an off-center load for example, if there would then be a greater risk of danger e.g. a loss of control or an injury to the occupant. The information used to compile the safety case may then formally guarantee further specifications, such as maximum safe speeds, permitted safe loads, or any other operational parameter. A safety case should be revisited when an existing product is to be re-purposed in a new way, if this extends beyond the scope of the original assessment.

References

  1. 1 2 3 The Assurance Case Working Group (May 2021). Goal Structuring Notation Community Standard Version 3. ISBN   979-8451294949.
  2. 1 2 Kelly, Timothy Patrick (September 1998). Arguing Safety – A Systematic Approach to Managing Safety Cases (PDF) (PhD thesis). University of York.
  3. ↑ Ge, Xiaocheng; Rijo, Rui; Paige, Richard F.; Kelly, Tim P.; McDermid, John A. (2012). "Introducing Goal Structuring Notation to Explain Decisions in Clinical Practice". Procedia Technology. 5: 686–695. doi: 10.1016/j.protcy.2012.09.076 . ISSN   2212-0173.
  4. 1 2 Haddon-Cave QC, Charles (28 October 2009), The Nimrod Review, London: The Stationery Office
  5. 1 2 Cabot, Jordi (12 February 2014). "Goal Structuring Notation – a short introduction". Modeling Languages. Retrieved 21 June 2018.
  6. ↑ Spriggs, John (2012). GSN - The Goal Structuring Notation. Springer London. doi:10.1007/978-1-4471-2312-5. ISBN   978-1-4471-2311-8.
  7. ↑ Hawkins, R.D.; Kelly, T.P. (July 2010). "A Systematic Approach for Developing Software Safety Arguments". Journal of System Safety. 46 (4): 25–33. ISSN   0743-8826.
  8. ↑ The Assurance Case Working Group (Jan 2018). Goal Structuring Notation Community Standard Version 2.
  9. ↑ Habli, Ibrahim; Kelly, Tim (August 2007). Safety Case Depictions vs. Safety Cases – Would the Real Safety Case Please Stand Up? (PDF). 23rd International System Safety Conference.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.