Please log in using either your email address or your membership number.
Please register with your name, email address, password and email preferences. You will be sent an email to verify the address.
Please enter the email address used for your account. A temporary password will be emailed to you.
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.
Please see the In a Nutshell section of the website.
You can start by reading the In a Nutshell section, and then the GSN standard and examples provided.
None. Goals in GSN carry the claims of an argument.
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).
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.
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).
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.
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.
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.
No. GSN symbols provide you with expressive richness to capture anything that (many years of practice have shown) you may need.
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.
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.