This area of the SCSC website hosts Goal Structuring Notation (GSN) standardisation information and related guidance.
It can be reached through scsc.uk/gsn or goalstructuringnotation.info.
The GSN information is created and maintained by the GSN Standard Working Group (GSN_SWG), a sub-group of the SCSC's Assurance Case Working Group (ACWG).
The principal objective of this site is to disseminate information and resources related to GSN.
This page contains general FAQ about GSN. Further FAQ are also available for the following sub-topics:
What is GSN?
Please see the In a Nutshell section of the website.
How should I start?
You can start by reading the In a Nutshell section, and then the GSN standard and examples provided.
What is the difference between a goal and a claim?
None. Goals in GSN carry the claims of an argument.
How big should a GSN argument be?
As big as it needs to be. GSN arguments represent the reasoning behind the claims that we are prepared to make about a system. If a system is complex and requires complex reasoning, then the GSN argument will eventually be large. GSN does not add complexity to the system, it merely documents the reasoning of the stakeholders (making the implicit, explicit and thus amenable to challenge and consensus).
When in the lifecycle should I use GSN?
There is no specific part of the lifecycle for which GSN is best suited. GSN is used to capture the safety case, which ideally should go hand in hand with system development. With GSN, similarly to other notations (e.g. UML), details are added during each lifecycle stage until we have a established a convincing safety case. GSN semantics provide the necessary expressive richness to capture the information necessary at any lifecycle stage. Experience is useful to find the right balance of abstraction (for your needs) at any development stage.
Is GSN a safety case?
GSN provides better means to graphically capture the constituent elements of a safety case (i.e. argument and evidence). You can still have perfectly valid GSN structures, which however do not offer confidence with regard to the safety of the system (similarly to having a valid UML model for a not so good system).
How does GSN relate to OMG's SACM?
Both GSN and SACM have the same purpose, but GSN is at present more mature and more widely used. GSN is specified by the GSN Working Group whereas SACM by the OMG. SACM was influenced by GSN and there is an ongoing liaison between the GSN and SACM maintenance committees. There is a definition of equivalence of concepts between GSN and SACM available - see GSN Meta-Model.
Why do I need the six step method?
GSN is not merely a graphical notation. It is accompanied by a method that facilitates decomposition of goals in way that will result in a comprehensive and clear argument. The six step method is included in the GSN Standard.
What is a GSN pattern?
A pattern is a generic argument representing a specific strategy to address an issue (usually specified in the top level goal of the pattern). As with software patterns, GSN patterns should be used with care for the right type of problem and may always need some tuning to a specific case.
Do I need to use all GSN symbols when I create GSN?
No. GSN symbols provide you with expressive richness to capture anything that (many years of practice have shown) you may need.
What is modular GSN?
Modular GSN allows to create self contained interrelated argument modules. Modular GSN allows to group logical arguments in a module, that can be referenced from many sources. Modular GSN allows the logical separation of issues which can then be developed by the appropriate stakeholders, thus helping development as well as navigation of the argument (module view). Also, modular GSN allows to information hiding, which is particularly useful in the early stages of the lifecycle when the content of a part of the safety case may still be unclear.
Is GSN only used in the safety domain?
No, GSN could be used to capture any position supported by argument and evidence, even legal arguments.
Historically GSN has be used mainly in the safety domain to document safety cases. However, it has also been used to capture and support requirements (specified as goals). Examples include dependability, security and reliability & availability.