DTU ProjectLab - User contributions [en-gb]

Talk:Requirements engineering

2014-12-02T15:32:40Z

TigR:

== Review by MrP ==

==General remarks==
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)
** '''''Thanks for the complement'''''
*Good sample of references and links to other material
** '''''Thanks'''''
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''

==Specific remarks==
Below please find som specific remarks, adressing particular sections in your article

===Introductory paragraph===
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''
*See also general remark, consider rephrasing the paragraph to set the scene for your article better
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''

===Application context===
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?
** '''''Fixed - Reworked this section'''''
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article
** '''''Fixed - Reworked this section'''''
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing
** '''''Fixed - Reworked this section'''''
===Acceptance and use===
*In general, this section (and even the header itself) is a bit difficult to understand.
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition
** '''''Fixed'''''
*What is the point of your references to software development issues in the first half of the paragraph?
** '''''Fixed'''''
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp
** '''''Fixed'''''

===Creating requirements===
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''

===Major concepts===
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''

===Requirements elicitation===
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''

===Design and validation===
*It becomes a little unclear where we are now in the RE lifecycle?
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''
===Context===
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.
** '''''Fixed'''''
===Functional requirements===
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.
** '''''Fixed - I have made the picture bigger'''''
===Non-functional requirements===
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.
**'''''Fixed'''''

===Requirements management===
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?
** '''''Fixed'''''
===Discussion===
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''

* '''''Thank your for your review, it was very helpfull and gave new perspective! :-)'''''

== Review by TigR ==

==General remarks==

;Language
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.
;Layout
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])
* '''''This should be fixed now, thanks highlighting that. :-)''''''

==Specific remarks==

===Introduction===
;Grammatical things
:"among ''the'' involved parties"
*'''''Fixed'''''
:"from a client" => "''of'' a client"
*'''''Fixed'''''
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.
*'''''Fixed'''''
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''
:"to specific" => "to ''specify''"
*'''''Fixed'''''
:"is suppose" => "is ''supposed''"
*'''''Fixed'''''
:"the basis to get" => "the basis ''for getting''"
*'''''Fixed'''''
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an''
*'''''Fixed'''''
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.
*'''''Fixed'''''
The introduction is (besides the above stuff) very well written and explanatory.
*'''''Thanks :-)'''''

===Background===
due to the header it is difficult to see that the text is an introduction to the following sub-headers..
*'''''I have also removed it, thanks for noticing'''''
===Application context===
;Grammatical things
:"basis for" => "basis ''of''"
*'''''Fixed'''''
:"and that is where" => "and ''this'' is where"
*'''''Fixed'''''
:"to understand" => "''understanding''"
*'''''Fixed'''''
:"''the'' need", "''the'' problem"
*'''''Fixed'''''
:"is done" => "is ''reached''" or "''has been established''"
*'''''Fixed'''''
:"need of" => "need ''for''"
*'''''Fixed - Removed words while redoing section'''''
:"be clear defined" => "be ''clearly'' defined"
*'''''Fixed - Removed words while redoing section'''''
:"It is about" <= speech, and what is ''It'' in this sentence?
*'''''Fixed - Removed words while redoing section'''''
:"creating stable" => "creating ''a'' stable"
*'''''Fixed'''''
:"the destination" <= I think "where you might end" sounds a bit better?
*'''''Fixed'''''
:I'd scrap "though" and start at "The intention of ''the'' requirements"
*'''''Fixed'''''
:you mix times.. "is" and "would".. use "will"
*'''''Fixed - Removed words while redoing section'''''
:"management requirements" ? missing a komma? and then "form" without s
*'''''Fixed'''''
:"There exists multiple examples" => "''Multiple examples exist''"
*'''''Fixed'''''
:"because poorly" => "because ''of'' poorly"
*'''''Fixed'''''
:"shows the problems" => "shows ''that'' the problems"
*'''''Fixed'''''
:perhaps use ":" to list the three categories?

Perhaps elaborate bit more about the challenge you mention
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''

===Acceptance and use===
;layout
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.
*'''''Fixed'''''

;Grammatical things
:"requirement''s'' engineering"
*'''''Fixed - Removed words while redoing section'''''
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.
*'''''Fixed - Removed words while redoing section'''''
:"the could cause" => "''this'' could cause ''a''"
*'''''Fixed - Removed words while redoing section'''''
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".
*'''''Fixed - Removed words while redoing section'''''
:"for example" => "for example'';''"
*'''''Fixed'''''
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.
*'''''Fixed'''''
:"applies" => "''also'' applies"
*'''''Fixed - Removed words while redoing section'''''
:try to read the sentence without the insert.. "components which.." consider revision of the last part.
*'''''Fixed'''''
:"There exist several standards" => "''Several standards exist''"
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''
:"define''.''" and "where in" => "''In''"
*'''''Fixed'''''
:"likely the" => "likely ''that'' the"
*'''''Fixed'''''
Interesting and with substance
*'''''Thank you :-)'''''
===Creating requirements===
;Layout
: remember the header issue
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''
;Grammatical things
:"different ways" <= perhaps add an indicator of ammount? several, many, some.
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''
:"accordingly" => "according"
*'''''Fixed'''''
:"a system" => "''the'' system" ?
*'''''Fixed'''''
:"suppose''d''"
*'''''Fixed'''''
:"achieve ''the''"
*'''''Fixed - Removed words while redoing section'''''
:"best as possible." => "the best." ?
*'''''Fixed - Removed words while redoing section'''''
:ouch.. missing the ''s'' in your text for the picture as well.
*'''''Fixed'''''
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?
*'''''Fixed'''''

===Major concepts===
no intro?
*'''''Fixed - removed header, didn't really add anything :-)'''''

===Requirements elicitation===
;Layout
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.
:Beautiful table. well thought.
*'''''Thank you'''''

;Grammatical things
:req-''s'' again.. is the header or text incorrect?
*'''''Fixed - In this case it would be the text. '''''
:"to understanding" => "to understand"
*'''''Fixed'''''
:take out "Though"
*'''''Fixed'''''
:"use full" => "useful"
*'''''Fixed'''''
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''
:"called more like a" speech language => "called a"
*'''''Fixed'''''
:"where some like" => "where some''thing'' like"
*'''''Fixed'''''
:"in to" => "into" (best test.. make the space a deliberate pause when reading)
*'''''Fixed'''''
:"desire''s''"
*'''''Fixed'''''
:"t''h''rough"
*'''''Fixed'''''

impressive chapter, very few errors and very understandable.
*'''''Thanks :-)'''''

===Design and validation===
;Grammatical things
:"minded for" => "minded ''towards''"
*'''''Fixed'''''
:"intention" => "intent"
*'''''Fixed'''''
:"phase'',''"
*'''''Fixed'''''
:"useful to" => "useful ''for''"
*'''''Fixed'''''
:"fulfills ''the''"
*'''''Fixed'''''
good

===Context===
;Grammatical things
:"most reflect" => "most''ly'' reflect"
*'''''Fixed'''''
:"the project has" => "of the project"
*'''''Fixed'''''
:"establishing context"
*'''''Fixed'''''
:"identifying systems or process''es''"
*'''''Fixed'''''

only minor stuff

===Functional requirements===
;Grammatical things
:"on''e''"
*'''''Fixed'''''
:"meanwhile" => "while"
*'''''Fixed'''''
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."
*'''''Fixed'''''
:"exits" => "''exist''"
*'''''Fixed'''''
:"uses cases" => "use''r'' cases"?
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''
:"in the picture below" <= but I see it above or besides the text?

the picture is fairly small if you were to see the idea of it without clicking on it.
*'''''Fixed'''''

===Non-functional requirements===
;Grammatical things
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''
:"irrespective"? => "regardless"
*'''''Fixed'''''
:"specify a some" ?
*'''''Fixed'''''
:"There exits ISO standards" => "ISO standards exi''st''"
*'''''Fixed - Sentence has been reworked'''''
:"The idea is then" => "The procedure is"
*'''''Fixed'''''
:"system goal''s''"
*'''''Fixed'''''
:"argument ''of''"
*'''''Fixed'''''
:"example on list of" => "example ''of a'' list ''with''"
*'''''Fixed'''''

Perhaps (if possible) move the picture to the right of the text
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''

===Acceptance test===
;Grammatical things
:"engineering disciplines" => "engineering discipline"
*'''''Fixed'''''
:"various way''s''" & "testing ''a'' system"
*'''''Fixed'''''
:"should consists" => "should consist" or "consists"
*'''''Fixed'''''

===Requirements management===
;Grammatical things
:"activates" ? => "activities"?
*'''''Fixed'''''
:"in ''a'' more"
*'''''Fixed'''''
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present
*'''''Fixed'''''

===Discussion===
;Grammatical things
:"exi''st''"
*'''''Fixed'''''
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"
*'''''Fixed'''''
:"size''s''"
*'''''Fixed'''''
:"computers systems" => "computer systems"
*'''''Fixed'''''
:"systems ''have''" as in they have
*'''''Fixed'''''
:"affect" => "effect" verb vs. noun
*'''''Fixed'''''
:"for everyday" => "for every day"
*'''''Fixed'''''
:"consequence''s''"
*'''''Fixed'''''
:"why today the .... quality" => "why the .... quality today"
*'''''Fixed'''''
:"be emphasize the" => "be emphasize''d that''"
*'''''Fixed'''''
:"solution by" => "solution ''in''"
*'''''Fixed'''''
:"every persons" => "every person"
*'''''Fixed'''''

===Strength and weaknesses===
;Grammatical things
:"as wells" => "as well"
*'''''Fixed'''''
:"Though that the fact .... same" => "The fact .... same though"
*'''''Fixed'''''
:"benefit of ''using''"
*'''''Fixed'''''
:"and ''generate'' higher"
*'''''Fixed'''''
:"contribution''s''"
*'''''Fixed'''''
:"Though it is" => "It is"
*'''''Fixed'''''
:"but it is" => "but"
*'''''Fixed'''''

*'''''Thank you for your review, I can definitely see the language in the article has improved due to you catching my grammatical errors. :-) '''''

== Re-Review by TigR ==

===Layout===
two major things..

*Try to make your pictures stay in the right side, so it does not take up a lot of space where the text could be

*Consider what size is appropriate (you can re-size them, code is found in help)

*When using materials with the (c) in the picture, at least make a note about how it is permitted ;)

Talk:Requirements engineering

2014-12-02T15:30:04Z

TigR: /* Re-Review by TigR */ new section

== Review by MrP ==

==General remarks==
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)
** '''''Thanks for the complement'''''
*Good sample of references and links to other material
** '''''Thanks'''''
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''

==Specific remarks==
Below please find som specific remarks, adressing particular sections in your article

===Introductory paragraph===
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''
*See also general remark, consider rephrasing the paragraph to set the scene for your article better
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''

===Application context===
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?
** '''''Fixed - Reworked this section'''''
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article
** '''''Fixed - Reworked this section'''''
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing
** '''''Fixed - Reworked this section'''''
===Acceptance and use===
*In general, this section (and even the header itself) is a bit difficult to understand.
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition
** '''''Fixed'''''
*What is the point of your references to software development issues in the first half of the paragraph?
** '''''Fixed'''''
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp
** '''''Fixed'''''

===Creating requirements===
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''

===Major concepts===
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''

===Requirements elicitation===
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''

===Design and validation===
*It becomes a little unclear where we are now in the RE lifecycle?
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''
===Context===
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.
** '''''Fixed'''''
===Functional requirements===
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.
** '''''Fixed - I have made the picture bigger'''''
===Non-functional requirements===
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.
**'''''Fixed'''''

===Requirements management===
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?
** '''''Fixed'''''
===Discussion===
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''

* '''''Thank your for your review, it was very helpfull and gave new perspective! :-)'''''

== Review by TigR ==

==General remarks==

;Language
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.
;Layout
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])
* '''''This should be fixed now, thanks highlighting that. :-)''''''

==Specific remarks==

===Introduction===
;Grammatical things
:"among ''the'' involved parties"
*'''''Fixed'''''
:"from a client" => "''of'' a client"
*'''''Fixed'''''
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.
*'''''Fixed'''''
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''
:"to specific" => "to ''specify''"
*'''''Fixed'''''
:"is suppose" => "is ''supposed''"
*'''''Fixed'''''
:"the basis to get" => "the basis ''for getting''"
*'''''Fixed'''''
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an''
*'''''Fixed'''''
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.
*'''''Fixed'''''
The introduction is (besides the above stuff) very well written and explanatory.
*'''''Thanks :-)'''''

===Background===
due to the header it is difficult to see that the text is an introduction to the following sub-headers..
*'''''I have also removed it, thanks for noticing'''''
===Application context===
;Grammatical things
:"basis for" => "basis ''of''"
*'''''Fixed'''''
:"and that is where" => "and ''this'' is where"
*'''''Fixed'''''
:"to understand" => "''understanding''"
*'''''Fixed'''''
:"''the'' need", "''the'' problem"
*'''''Fixed'''''
:"is done" => "is ''reached''" or "''has been established''"
*'''''Fixed'''''
:"need of" => "need ''for''"
*'''''Fixed - Removed words while redoing section'''''
:"be clear defined" => "be ''clearly'' defined"
*'''''Fixed - Removed words while redoing section'''''
:"It is about" <= speech, and what is ''It'' in this sentence?
*'''''Fixed - Removed words while redoing section'''''
:"creating stable" => "creating ''a'' stable"
*'''''Fixed'''''
:"the destination" <= I think "where you might end" sounds a bit better?
*'''''Fixed'''''
:I'd scrap "though" and start at "The intention of ''the'' requirements"
*'''''Fixed'''''
:you mix times.. "is" and "would".. use "will"
*'''''Fixed - Removed words while redoing section'''''
:"management requirements" ? missing a komma? and then "form" without s
*'''''Fixed'''''
:"There exists multiple examples" => "''Multiple examples exist''"
*'''''Fixed'''''
:"because poorly" => "because ''of'' poorly"
*'''''Fixed'''''
:"shows the problems" => "shows ''that'' the problems"
*'''''Fixed'''''
:perhaps use ":" to list the three categories?

Perhaps elaborate bit more about the challenge you mention
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''

===Acceptance and use===
;layout
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.
*'''''Fixed'''''

;Grammatical things
:"requirement''s'' engineering"
*'''''Fixed - Removed words while redoing section'''''
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.
*'''''Fixed - Removed words while redoing section'''''
:"the could cause" => "''this'' could cause ''a''"
*'''''Fixed - Removed words while redoing section'''''
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".
*'''''Fixed - Removed words while redoing section'''''
:"for example" => "for example'';''"
*'''''Fixed'''''
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.
*'''''Fixed'''''
:"applies" => "''also'' applies"
*'''''Fixed - Removed words while redoing section'''''
:try to read the sentence without the insert.. "components which.." consider revision of the last part.
*'''''Fixed'''''
:"There exist several standards" => "''Several standards exist''"
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''
:"define''.''" and "where in" => "''In''"
*'''''Fixed'''''
:"likely the" => "likely ''that'' the"
*'''''Fixed'''''
Interesting and with substance
*'''''Thank you :-)'''''
===Creating requirements===
;Layout
: remember the header issue
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''
;Grammatical things
:"different ways" <= perhaps add an indicator of ammount? several, many, some.
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''
:"accordingly" => "according"
*'''''Fixed'''''
:"a system" => "''the'' system" ?
*'''''Fixed'''''
:"suppose''d''"
*'''''Fixed'''''
:"achieve ''the''"
*'''''Fixed - Removed words while redoing section'''''
:"best as possible." => "the best." ?
*'''''Fixed - Removed words while redoing section'''''
:ouch.. missing the ''s'' in your text for the picture as well.
*'''''Fixed'''''
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?
*'''''Fixed'''''

===Major concepts===
no intro?
*'''''Fixed - removed header, didn't really add anything :-)'''''

===Requirements elicitation===
;Layout
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.
:Beautiful table. well thought.
*'''''Thank you'''''

;Grammatical things
:req-''s'' again.. is the header or text incorrect?
*'''''Fixed - In this case it would be the text. '''''
:"to understanding" => "to understand"
*'''''Fixed'''''
:take out "Though"
*'''''Fixed'''''
:"use full" => "useful"
*'''''Fixed'''''
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''
:"called more like a" speech language => "called a"
*'''''Fixed'''''
:"where some like" => "where some''thing'' like"
*'''''Fixed'''''
:"in to" => "into" (best test.. make the space a deliberate pause when reading)
*'''''Fixed'''''
:"desire''s''"
*'''''Fixed'''''
:"t''h''rough"
*'''''Fixed'''''

impressive chapter, very few errors and very understandable.
*'''''Thanks :-)'''''

===Design and validation===
;Grammatical things
:"minded for" => "minded ''towards''"
*'''''Fixed'''''
:"intention" => "intent"
*'''''Fixed'''''
:"phase'',''"
*'''''Fixed'''''
:"useful to" => "useful ''for''"
*'''''Fixed'''''
:"fulfills ''the''"
*'''''Fixed'''''
good

===Context===
;Grammatical things
:"most reflect" => "most''ly'' reflect"
*'''''Fixed'''''
:"the project has" => "of the project"
*'''''Fixed'''''
:"establishing context"
*'''''Fixed'''''
:"identifying systems or process''es''"
*'''''Fixed'''''

only minor stuff

===Functional requirements===
;Grammatical things
:"on''e''"
*'''''Fixed'''''
:"meanwhile" => "while"
*'''''Fixed'''''
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."
*'''''Fixed'''''
:"exits" => "''exist''"
*'''''Fixed'''''
:"uses cases" => "use''r'' cases"?
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''
:"in the picture below" <= but I see it above or besides the text?

the picture is fairly small if you were to see the idea of it without clicking on it.
*'''''Fixed'''''

===Non-functional requirements===
;Grammatical things
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''
:"irrespective"? => "regardless"
*'''''Fixed'''''
:"specify a some" ?
*'''''Fixed'''''
:"There exits ISO standards" => "ISO standards exi''st''"
*'''''Fixed - Sentence has been reworked'''''
:"The idea is then" => "The procedure is"
*'''''Fixed'''''
:"system goal''s''"
*'''''Fixed'''''
:"argument ''of''"
*'''''Fixed'''''
:"example on list of" => "example ''of a'' list ''with''"
*'''''Fixed'''''

Perhaps (if possible) move the picture to the right of the text
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''

===Acceptance test===
;Grammatical things
:"engineering disciplines" => "engineering discipline"
*'''''Fixed'''''
:"various way''s''" & "testing ''a'' system"
*'''''Fixed'''''
:"should consists" => "should consist" or "consists"
*'''''Fixed'''''

===Requirements management===
;Grammatical things
:"activates" ? => "activities"?
*'''''Fixed'''''
:"in ''a'' more"
*'''''Fixed'''''
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present
*'''''Fixed'''''

===Discussion===
;Grammatical things
:"exi''st''"
*'''''Fixed'''''
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"
*'''''Fixed'''''
:"size''s''"
*'''''Fixed'''''
:"computers systems" => "computer systems"
*'''''Fixed'''''
:"systems ''have''" as in they have
*'''''Fixed'''''
:"affect" => "effect" verb vs. noun
*'''''Fixed'''''
:"for everyday" => "for every day"
*'''''Fixed'''''
:"consequence''s''"
*'''''Fixed'''''
:"why today the .... quality" => "why the .... quality today"
*'''''Fixed'''''
:"be emphasize the" => "be emphasize''d that''"
*'''''Fixed'''''
:"solution by" => "solution ''in''"
*'''''Fixed'''''
:"every persons" => "every person"
*'''''Fixed'''''

===Strength and weaknesses===
;Grammatical things
:"as wells" => "as well"
*'''''Fixed'''''
:"Though that the fact .... same" => "The fact .... same though"
*'''''Fixed'''''
:"benefit of ''using''"
*'''''Fixed'''''
:"and ''generate'' higher"
*'''''Fixed'''''
:"contribution''s''"
*'''''Fixed'''''
:"Though it is" => "It is"
*'''''Fixed'''''
:"but it is" => "but"
*'''''Fixed'''''

*'''''Thank you for your review, I can definitely see the language in the article has improved due to you catching my grammatical errors. :-) '''''

== Re-Review by TigR ==

===Layout===
two major things..

*Try to make your pictures stay in the right side, so it does not take up a lot of space where the text could be

*Consider what size is appropriate (you can re-size them, code is found in help)

*'''''DO NOT USE COPYRIGHTED MATERIAL!!!!''''' It is not just a small blunder to put up a picture with the (c) in it..

Risk analysis

2014-12-01T17:29:00Z

TigR: /* Models used when analysing risk */

:''main article: [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]''
==Summary==

This article will describe the element of risk analysis within risk management, what it is used for and list several elements which can be used in the process of managing risk in projects, portfolios and programs..
Since risk analysis is a subpart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management], several correlations might be present between the two.

Several methods used for Risk Analysis will be mentioned and explained briefly, but (in order to allow the full use of the wiki) not be described in detail. Some of them might not seem directly applicable but can all be used during the possible iterations within the analysis.

The user of risk analysis essentially choose the most appropriate method(s) for calculating the given information and delivers a collective overview of the situation, as an artisan chooses the right tool for the job and produces the individual parts for the product. Using “known knowns” and “known unknowns” '' (from [http://apppm.man.dtu.dk/index.php/The_Cynefin_Framework the Cynefin framework]) '' along with estimates made by either extrapolation based on prior knowledge or by experts, the analysis generates a better understanding enabling the user to conduct a valid risk evaluation.

==Definition==
[[File:Risk Analysis from ISO31000.JPG|500px|thumb|right|Risk Analysis]]
Risk analysis lies at the heart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] and functions very much like the Central Processing Unit (CPU) of a computer.

The term "Risk" is most often defined as a probability of losing something of a specific value.
Mathematically speaking; the probability of an event occurring multiplied by the potential value-loss = the risk.

In order to compute this risk the person(s) doing the analysis must as a minimum receive information on the probability of an event occurring and the value of the potential loss.
The definition of risk analysis, as defined by the International Organisation for Standardization is as follows:

In their [http://www.iso.org/iso/catalogue_detail?csnumber=44651 ISO Guide 73-2009], it is stated as the ''“Process to comprehend the nature of risk and to determine the level of risk”''
In the [http://www.iso.org/iso/catalogue_detail?csnumber=43170 ISO 31000] standard it is described as the process which ''“provides an input to risk evaluation and to decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods” ''.

Both are correct since the process mentioned is the computational part of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] where different aspects, variables and factors are used to estimate the risk involved with a specific feature, action, decision, condition etc. The outcome of this computation is a quantified number or percentage which can then be used as an evaluation criterion, determining either which option to select or if it is safe to proceed down the investigated path.

==Main features of risk analysis==
There are three different analysis method groupings within risk analysis; Qualitative, Semi-Quantitative and Quantitative.

;Qualitative:
:Qualitative analysis methods are based on opinions and estimates. They compute the risk scenario based on few numbers and many interpretations. Outcome of these methods are usually given in levels of significance like “high”, “medium” and “low” or other "word scales" which are not specifically determining any actual number. An example of a qualitative result is the risk of terror when travelling abroad, made by the ministry of foreign affairs.

;Semi-quantitative:
:The outcomes of the semi-quantitative analysis methods are based on numeric ratings using evaluation scales for probability and consequence and usually combining them using a formula, resulting in a comparable value for the risk level.

;Quantitative:
:The quantitative analysis uses estimates of probability and consequence values to generate an approximation of the risk involved, represented by one specific value. The specific values, depending on the method of gathering, from different analysis can then be combined into one overall risk factor.

Because risk analysis works much like the processor in a computer it needs to receive a minimum of information as input before it can calculate an output which allows the user to gain a better overview and basis for making changes or taking decisions. A risk analysis is often generated for the sake of factual argumentation and credibility of decisions.
Normally input are generated in the step before the analysis; "Risk identification" but some can also be derivatives generated during the analysis. Many of the models described later can be used to generate input during the identification stage.
Output of the analysis step is usually used within the "Risk evaluation" in order to understand the risk in question.

{| class="wikitable"
|+Risk Analysis
|-
|'''Input:'''
|'''Output:'''
|-
|;Purpose
:The purpose is the reason for analysing the risk; it assists in determining the boundaries of the analysis.
|rowspan="4"|;Assessment of the risk with the following aspects
:Description of methods used and known control features impact on the risk
:Combined Likelihood / probability depending on the description of original risk
:Consequences of different scenarios
|-
|;Type of risk
:Choice of models depends on the type of risk in question.
|-
|;Information available
:Determines whether it is possible to conduct the analysis right away or information has to be gathered.
|-
|;Existing control features
:The features that are already in place to influence the risk and outcome of the analysis.
|-
|;Effectivity of existing control features
:How effective the control features are. This information can also reveal if there is room for improvements.
|rowspan="4"|;Description of the confidence in:
:The assessment of the risk (the result of the analysis)
:The sensitivity of the result to preconditions and assumptions
:Information Uncertainty
:Information Availability
:Information Quality
:Information Quantity
:Ongoing relevance of information (how relevant will the analysis be in the future)
|-
|;Consequences
:The consequences can be both positive and negative, and reflect the impact of events defined in the analysis.
|-
|;Likelihood / Probabilities
:Estimates, guesstimates, statistics and assumptions on the probability of an event happening.
|-
|;Risk criteria
:Terms against which the risk significance is evaluated, often based on context (internal/external) and objectives of the organisation.
|-
|;Causes of risk
:The reasons why an event takes place.
|rowspan="4"|;Limitations
:Demarcation description.
|-
|;Sources of risk
:The objects which affects the risk.
|-
|;Factors influencing any of the above
:Weights which scale the severity of the quantities are part of this input, as well as uncertainties and sensitivities.
|-
|;Interrelations / Interdependence
:The network of relational aspects between different risks
|}

----

==Benefits of analysing risk==
Analysing risk has become an integrated part of working with forecasts as well as decisions in projects, programs and portfolios, simply because it generates the big picture needed to make an informed decision.
The drivers of analysing risk are the focus on lowering costs and expenses, avoiding loss of anything valuable and reducing variability in outcomes.
The reason why risk is analysed with so many different methods to choose from, is because several different categories of risk exist, and yet there is a universal consensus that risk is best avoided, mitigated, minimised or negated.

==Models used in order to analyse risk==
All but one of the following models are described in Annex B of the ISO 31010 standard.

*'''[http://en.wikipedia.org/wiki/Brainstorming Brainstorming]:'''
::Brainstorming is a very intuitive method which uses associations and connections made by possibly several people around a central subject to uncover problematic and opportunistic aspects affecting the subject. This qualitative information is then used to gather as much quantitative information as possible in order to complete the further analysis. It can e.g. be used to imagine future risks or possible control features to known risks.

*'''[http://en.wikipedia.org/wiki/Structured_interview Structured] or [http://en.wikipedia.org/wiki/Semi-structured_interview semi-structured] interviews:'''
::The structured or semi-structured interview can be used for gathering information from numerous sources. These interviews do not have to be done face to face since questionnaires are also considered within this model. Applicable in the phases before and after Risk Analysis.

*'''[http://en.wikipedia.org/wiki/Delphi_method Delphi technique]:'''
::The Delphi technique is essentially a brainstorming process where the participants are kept anonymous but are able to see the collected work of all participating in the process. It is used to reach some kind of consensus around the subject in question. Applicable in the phases before and after Risk Analysis.

*'''Check-lists:'''
::Check-lists are built from previous experiences and often list known risks, control features and/or hazards gathered through prior assessments or lessons learned.

*'''[http://en.wikipedia.org/wiki/Hazard_analysis Preliminary hazard analysis (PHA)]:'''
::PHA is used when there is little information available and as the name states normally in the beginning of e.g. a project, in order to uncover potential hazards influencing the further development.

*'''[http://en.wikipedia.org/wiki/Hazard_and_operability_study Hazard and operability study (HAZOP)]:'''
::HAZOP is a qualitative method which studies the current activities in order to access the risk involved. It usually examines existing operations like procedures and products as well as processes and the system around them.

*'''[http://en.wikipedia.org/wiki/Hazard_analysis_and_critical_control_points Hazard analysis and critical control points (HACCP)]:'''
::HACCP is mainly used in the industry which produces items for consumption where infections are of vital importance. The critical control points are then indicating areas within the production where errors can lead to loss of quality or worse.

*'''Toxicity assessment:'''
::Toxicity assessment is used when looking at risk related to the environment and how the introduction of a source of harm affects it.

*'''[http://en.wikipedia.org/wiki/Structured_What_If_Technique Structured “What-If” Technique (SWIFT)]:'''
::SWIFT is normally used at workshops by the facilitator to make the participants introduce risk into their chain of thought by using a set of specific questioning words along with the catchphrase “what if?” .

*'''[http://en.wikipedia.org/wiki/Scenario_analysis Scenario analysis]:'''
::When conducting a scenario analysis, one or several future scenarios are developed based on the participants’ thoughts and ideas on where the future might bring us. Then doing back-casting in order to determine the events needed to reach the scenario and evaluating the risks of these events.

*'''Business impact analysis (BIA):'''
::The BIA investigates the risks capable of disrupting the organisation’s operations as well as the current controls in place and how well they will handle the disruption.

*'''[http://en.wikipedia.org/wiki/Root_cause_analysis Root cause analysis (RCA)]:'''
::RCA is often used after an event has taken place with the aim of preventing it from happening again.
::By constantly questioning for the reason why an event occurred, turning the reason into an event and repeating the question the RCA attempts to discover the fatal event which set several chains of actions into motion.

*'''[http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis Failure modes and effects analysis (FMEA)] / [http://en.wikipedia.org/wiki/Failure_mode,_effects,_and_criticality_analysis failure modes and effects and criticality analysis (FMECA)]:'''
::FMEA is essentially an error tool attempting to map out the different possible ways for processes, systems or components are able to fail and thus not fulfil the designed purpose.
::FMECA expands FMEA by ranking the outcomes against each other and thereby identifying the most critical failures.

*'''[http://en.wikipedia.org/wiki/Fault_tree_analysis Fault tree analysis (FTA)]:'''
::FTA is a method used to develop your typical trouble shooting guide where it is possible to locate the cause of an undesired event by deductive reasoning.

*'''[http://en.wikipedia.org/wiki/Event_tree_analysis Event tree analysis (ETA)]:'''
::ETA can be used to generate the probability of the control features working or not working with regards to a specific event happening. Contrary to the FTA, the ETA can be used before the event has actually happened as a hypothetical reasoning method. It can be used both quantitative and qualitative.

*'''Cause-consequence analysis:'''
::Cause-consequence analysis is combining FTA and ETA in order to analyse the various paths possible within a system following a critical event. It is used within critical safety systems as a reliability tool.

*'''[http://en.wikipedia.org/wiki/Ishikawa_diagram Cause-and-effect analysis]:'''
::Cause-and-effect analysis identifies potential causes of an event or problem by looking at the possible contributing factors and organising them in either a fishbone or tree diagram in order to consider all possible hypotheses.

*'''Layers of protection analysis (LOPA):'''
::LOPA analyses if the required control features are present to mitigate an undesired event or scenario. It is a semi-qualitative method used to provide a baseline when specifying independent protection layers.

*'''[http://en.wikipedia.org/wiki/Decision_tree Decision tree analysis]:'''
::Decision tree analysis can be used as a forecast tool, assisting the decision makers with understanding the consequences and follow-up decisions to an initial event. It resembles a tool usable for career path decisions where you start with a lot of options and by deciding on one path, still having several options open.

*'''[http://en.wikipedia.org/wiki/Human_reliability Human reliability assessment (HRA)]:'''
::HRA is mainly used to evaluate the human influence on performance of systems or the human error factor.
::It is usable both quantitatively and qualitatively.

*'''[http://en.wikipedia.org/wiki/Bowtie_(sequence_analysis) Bow tie analysis]:'''
::The bow tie analysis generates a graphical representation which assists in generating the full picture of what has to happen prior to an event (causes) and what can happen afterwards (consequences). It is mostly generated in a brainstorming session.

*'''[http://en.wikipedia.org/wiki/Reliability_centered_maintenance Reliability centered maintainance (RCM)]:'''
::RCM identifies policies which need to be implemented in order to achieve the required safety by managing failures effectively and efficiently.

*'''Sneak analysis (SA) / [http://en.wikipedia.org/wiki/Sneak_circuit_analysis sneak circuit analysis (SCI)]:'''
::SA and SCI are used for identifying design errors which may cause harm to production or personnel or just generate an undesired outcome.

*'''[http://en.wikipedia.org/wiki/Markov_chain Markov analysis]:'''
::The Markov analysis is used when the future state depends only on present state of a system. It is a quantitative method which can be described with discrete or continuous states.

*'''[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]:'''
::Simulating complex systems can be the only way to grasp how uncertainties affect them. The Monte Carlo simulation is used for this.

*'''[http://en.wikipedia.org/wiki/Bayesian_inference Bayesian statistics] and[http://en.wikipedia.org/wiki/Bayesian_network Bayes Nets]:'''
::This is a probability theory using Bayes Theorem to sum up several probabilities in to one.

*'''FN curves:'''
::These curves are used in relation with casualties in a specified population affected by an event.

*'''Risk indices:'''
::This semi-quantitative measure generates a risk index derived from scorings of normal scales, and is used as a classification system.

*'''Consequence/probability matrix:'''
::As the name suggests it is a matrix combining qualitative or semi-qualitative consequences with probabilities in order to generate a risk rating. This matrix can then be used to rank different risks treatments or risk sources.

*'''[http://en.wikipedia.org/wiki/Cost%E2%80%93benefit_analysis Cost/benefit analysis (CBA)]:'''
::The CBA is often used to see if it is worth it to go ahead with changes to status quo, and mainly on a financial level.

*'''[http://en.wikipedia.org/wiki/Multiple-criteria_decision_analysis Multi-criteria decision analysis (MCDA)]:'''
::By using several different criteria the MCDA assesses the overall positive value of a set of options, transparently and objectively. It aims to sort the options in order of preference.

*'''Fuzzy synthetic evaluation (FSE) approach: '''
::Described in the International journal of Project Management 31 (2013) it is an intuitive method which starts out identifying the risk factors, evaluating a specific risk using both quantitative and qualitative values and by combining them generating a matrix of numeric risk values. After determining the evaluation criteria each criteria is given a weight which is combined with the risk matrix into a fuzzy evaluation matrix. The risk index is then calculated and the overall risk evaluated after each risk is given a weight of it’s own.

==Reference==
[http://www.iso.org/iso/catalogue_detail?csnumber=44651 ISO Guide 73-2009 – Risk Management Vocabulary (2009)]

[http://www.iso.org/iso/catalogue_detail?csnumber=43170 ISO 31000 - Risk management - Principles and guidelines (2009)]

[http://www.iso.org/iso/catalogue_detail?csnumber=51073 ISO 31010 - Risk management (2009)]

International Journal of Project Management 32 (2014) - Vahid Khodakarami , Abdollah Abdi - Project cost risk analysis: A Bayesian networks approach for modelling dependencies between cost items

International Journal of Project Management 31 (2013) - Jialin Liu, Quanxi Li, Yuhan Wang - Risk analysis in ultra deep scientific drilling project – a fuzzy synthetic evaluation approach

Project Management Journal (April 2013) - Juliane Teller - Portfolio Risk Management and Its Contribution to Project Portfolio Success: An Investigation of Organization, Process, and Culture

==Links==
'''Only the following links are internal in the APPPM-wiki, All others are to Wikipedia.org and may be replaced when the APPPM-pages has been written, and added to this list.

Once all links are internal, this section can be deleted.'''

[http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]

[http://apppm.man.dtu.dk/index.php/The_Cynefin_Framework the Cynefin framework]

[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]

Risk analysis

2014-12-01T17:27:56Z

TigR:

:''main article: [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]''
==Summary==

This article will describe the element of risk analysis within risk management, what it is used for and list several elements which can be used in the process of managing risk in projects, portfolios and programs..
Since risk analysis is a subpart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management], several correlations might be present between the two.

Several methods used for Risk Analysis will be mentioned and explained briefly, but (in order to allow the full use of the wiki) not be described in detail. Some of them might not seem directly applicable but can all be used during the possible iterations within the analysis.

The user of risk analysis essentially choose the most appropriate method(s) for calculating the given information and delivers a collective overview of the situation, as an artisan chooses the right tool for the job and produces the individual parts for the product. Using “known knowns” and “known unknowns” '' (from [http://apppm.man.dtu.dk/index.php/The_Cynefin_Framework the Cynefin framework]) '' along with estimates made by either extrapolation based on prior knowledge or by experts, the analysis generates a better understanding enabling the user to conduct a valid risk evaluation.

==Definition==
[[File:Risk Analysis from ISO31000.JPG|500px|thumb|right|Risk Analysis]]
Risk analysis lies at the heart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] and functions very much like the Central Processing Unit (CPU) of a computer.

The term "Risk" is most often defined as a probability of losing something of a specific value.
Mathematically speaking; the probability of an event occurring multiplied by the potential value-loss = the risk.

In order to compute this risk the person(s) doing the analysis must as a minimum receive information on the probability of an event occurring and the value of the potential loss.
The definition of risk analysis, as defined by the International Organisation for Standardization is as follows:

In their [http://www.iso.org/iso/catalogue_detail?csnumber=44651 ISO Guide 73-2009], it is stated as the ''“Process to comprehend the nature of risk and to determine the level of risk”''
In the [http://www.iso.org/iso/catalogue_detail?csnumber=43170 ISO 31000] standard it is described as the process which ''“provides an input to risk evaluation and to decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods” ''.

Both are correct since the process mentioned is the computational part of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] where different aspects, variables and factors are used to estimate the risk involved with a specific feature, action, decision, condition etc. The outcome of this computation is a quantified number or percentage which can then be used as an evaluation criterion, determining either which option to select or if it is safe to proceed down the investigated path.

==Main features of risk analysis==
There are three different analysis method groupings within risk analysis; Qualitative, Semi-Quantitative and Quantitative.

;Qualitative:
:Qualitative analysis methods are based on opinions and estimates. They compute the risk scenario based on few numbers and many interpretations. Outcome of these methods are usually given in levels of significance like “high”, “medium” and “low” or other "word scales" which are not specifically determining any actual number. An example of a qualitative result is the risk of terror when travelling abroad, made by the ministry of foreign affairs.

;Semi-quantitative:
:The outcomes of the semi-quantitative analysis methods are based on numeric ratings using evaluation scales for probability and consequence and usually combining them using a formula, resulting in a comparable value for the risk level.

;Quantitative:
:The quantitative analysis uses estimates of probability and consequence values to generate an approximation of the risk involved, represented by one specific value. The specific values, depending on the method of gathering, from different analysis can then be combined into one overall risk factor.

Because risk analysis works much like the processor in a computer it needs to receive a minimum of information as input before it can calculate an output which allows the user to gain a better overview and basis for making changes or taking decisions. A risk analysis is often generated for the sake of factual argumentation and credibility of decisions.
Normally input are generated in the step before the analysis; "Risk identification" but some can also be derivatives generated during the analysis. Many of the models described later can be used to generate input during the identification stage.
Output of the analysis step is usually used within the "Risk evaluation" in order to understand the risk in question.

{| class="wikitable"
|+Risk Analysis
|-
|'''Input:'''
|'''Output:'''
|-
|;Purpose
:The purpose is the reason for analysing the risk; it assists in determining the boundaries of the analysis.
|rowspan="4"|;Assessment of the risk with the following aspects
:Description of methods used and known control features impact on the risk
:Combined Likelihood / probability depending on the description of original risk
:Consequences of different scenarios
|-
|;Type of risk
:Choice of models depends on the type of risk in question.
|-
|;Information available
:Determines whether it is possible to conduct the analysis right away or information has to be gathered.
|-
|;Existing control features
:The features that are already in place to influence the risk and outcome of the analysis.
|-
|;Effectivity of existing control features
:How effective the control features are. This information can also reveal if there is room for improvements.
|rowspan="4"|;Description of the confidence in:
:The assessment of the risk (the result of the analysis)
:The sensitivity of the result to preconditions and assumptions
:Information Uncertainty
:Information Availability
:Information Quality
:Information Quantity
:Ongoing relevance of information (how relevant will the analysis be in the future)
|-
|;Consequences
:The consequences can be both positive and negative, and reflect the impact of events defined in the analysis.
|-
|;Likelihood / Probabilities
:Estimates, guesstimates, statistics and assumptions on the probability of an event happening.
|-
|;Risk criteria
:Terms against which the risk significance is evaluated, often based on context (internal/external) and objectives of the organisation.
|-
|;Causes of risk
:The reasons why an event takes place.
|rowspan="4"|;Limitations
:Demarcation description.
|-
|;Sources of risk
:The objects which affects the risk.
|-
|;Factors influencing any of the above
:Weights which scale the severity of the quantities are part of this input, as well as uncertainties and sensitivities.
|-
|;Interrelations / Interdependence
:The network of relational aspects between different risks
|}

----

==Benefits of analysing risk==
Analysing risk has become an integrated part of working with forecasts as well as decisions in projects, programs and portfolios, simply because it generates the big picture needed to make an informed decision.
The drivers of analysing risk are the focus on lowering costs and expenses, avoiding loss of anything valuable and reducing variability in outcomes.
The reason why risk is analysed with so many different methods to choose from, is because several different categories of risk exist, and yet there is a universal consensus that risk is best avoided, mitigated, minimised or negated.

==Models used when analysing risk==
All but one of the following models are described in Annex B of the ISO 31010 standard.

*'''[http://en.wikipedia.org/wiki/Brainstorming Brainstorming]:'''
::Brainstorming is a very intuitive method which uses associations and connections made by possibly several people around a central subject to uncover problematic and opportunistic aspects affecting the subject. This qualitative information is then used to gather as much quantitative information as possible in order to complete the further analysis. It can e.g. be used to imagine future risks or possible control features to known risks.

*'''[http://en.wikipedia.org/wiki/Structured_interview Structured] or [http://en.wikipedia.org/wiki/Semi-structured_interview semi-structured] interviews:'''
::The structured or semi-structured interview can be used for gathering information from numerous sources. These interviews do not have to be done face to face since questionnaires are also considered within this model. Applicable in the phases before and after Risk Analysis.

*'''[http://en.wikipedia.org/wiki/Delphi_method Delphi technique]:'''
::The Delphi technique is essentially a brainstorming process where the participants are kept anonymous but are able to see the collected work of all participating in the process. It is used to reach some kind of consensus around the subject in question. Applicable in the phases before and after Risk Analysis.

*'''Check-lists:'''
::Check-lists are built from previous experiences and often list known risks, control features and/or hazards gathered through prior assessments or lessons learned.

*'''[http://en.wikipedia.org/wiki/Hazard_analysis Preliminary hazard analysis (PHA)]:'''
::PHA is used when there is little information available and as the name states normally in the beginning of e.g. a project, in order to uncover potential hazards influencing the further development.

*'''[http://en.wikipedia.org/wiki/Hazard_and_operability_study Hazard and operability study (HAZOP)]:'''
::HAZOP is a qualitative method which studies the current activities in order to access the risk involved. It usually examines existing operations like procedures and products as well as processes and the system around them.

*'''[http://en.wikipedia.org/wiki/Hazard_analysis_and_critical_control_points Hazard analysis and critical control points (HACCP)]:'''
::HACCP is mainly used in the industry which produces items for consumption where infections are of vital importance. The critical control points are then indicating areas within the production where errors can lead to loss of quality or worse.

*'''Toxicity assessment:'''
::Toxicity assessment is used when looking at risk related to the environment and how the introduction of a source of harm affects it.

*'''[http://en.wikipedia.org/wiki/Structured_What_If_Technique Structured “What-If” Technique (SWIFT)]:'''
::SWIFT is normally used at workshops by the facilitator to make the participants introduce risk into their chain of thought by using a set of specific questioning words along with the catchphrase “what if?” .

*'''[http://en.wikipedia.org/wiki/Scenario_analysis Scenario analysis]:'''
::When conducting a scenario analysis, one or several future scenarios are developed based on the participants’ thoughts and ideas on where the future might bring us. Then doing back-casting in order to determine the events needed to reach the scenario and evaluating the risks of these events.

*'''Business impact analysis (BIA):'''
::The BIA investigates the risks capable of disrupting the organisation’s operations as well as the current controls in place and how well they will handle the disruption.

*'''[http://en.wikipedia.org/wiki/Root_cause_analysis Root cause analysis (RCA)]:'''
::RCA is often used after an event has taken place with the aim of preventing it from happening again.
::By constantly questioning for the reason why an event occurred, turning the reason into an event and repeating the question the RCA attempts to discover the fatal event which set several chains of actions into motion.

*'''[http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis Failure modes and effects analysis (FMEA)] / [http://en.wikipedia.org/wiki/Failure_mode,_effects,_and_criticality_analysis failure modes and effects and criticality analysis (FMECA)]:'''
::FMEA is essentially an error tool attempting to map out the different possible ways for processes, systems or components are able to fail and thus not fulfil the designed purpose.
::FMECA expands FMEA by ranking the outcomes against each other and thereby identifying the most critical failures.

*'''[http://en.wikipedia.org/wiki/Fault_tree_analysis Fault tree analysis (FTA)]:'''
::FTA is a method used to develop your typical trouble shooting guide where it is possible to locate the cause of an undesired event by deductive reasoning.

*'''[http://en.wikipedia.org/wiki/Event_tree_analysis Event tree analysis (ETA)]:'''
::ETA can be used to generate the probability of the control features working or not working with regards to a specific event happening. Contrary to the FTA, the ETA can be used before the event has actually happened as a hypothetical reasoning method. It can be used both quantitative and qualitative.

*'''Cause-consequence analysis:'''
::Cause-consequence analysis is combining FTA and ETA in order to analyse the various paths possible within a system following a critical event. It is used within critical safety systems as a reliability tool.

*'''[http://en.wikipedia.org/wiki/Ishikawa_diagram Cause-and-effect analysis]:'''
::Cause-and-effect analysis identifies potential causes of an event or problem by looking at the possible contributing factors and organising them in either a fishbone or tree diagram in order to consider all possible hypotheses.

*'''Layers of protection analysis (LOPA):'''
::LOPA analyses if the required control features are present to mitigate an undesired event or scenario. It is a semi-qualitative method used to provide a baseline when specifying independent protection layers.

*'''[http://en.wikipedia.org/wiki/Decision_tree Decision tree analysis]:'''
::Decision tree analysis can be used as a forecast tool, assisting the decision makers with understanding the consequences and follow-up decisions to an initial event. It resembles a tool usable for career path decisions where you start with a lot of options and by deciding on one path, still having several options open.

*'''[http://en.wikipedia.org/wiki/Human_reliability Human reliability assessment (HRA)]:'''
::HRA is mainly used to evaluate the human influence on performance of systems or the human error factor.
::It is usable both quantitatively and qualitatively.

*'''[http://en.wikipedia.org/wiki/Bowtie_(sequence_analysis) Bow tie analysis]:'''
::The bow tie analysis generates a graphical representation which assists in generating the full picture of what has to happen prior to an event (causes) and what can happen afterwards (consequences). It is mostly generated in a brainstorming session.

*'''[http://en.wikipedia.org/wiki/Reliability_centered_maintenance Reliability centered maintainance (RCM)]:'''
::RCM identifies policies which need to be implemented in order to achieve the required safety by managing failures effectively and efficiently.

*'''Sneak analysis (SA) / [http://en.wikipedia.org/wiki/Sneak_circuit_analysis sneak circuit analysis (SCI)]:'''
::SA and SCI are used for identifying design errors which may cause harm to production or personnel or just generate an undesired outcome.

*'''[http://en.wikipedia.org/wiki/Markov_chain Markov analysis]:'''
::The Markov analysis is used when the future state depends only on present state of a system. It is a quantitative method which can be described with discrete or continuous states.

*'''[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]:'''
::Simulating complex systems can be the only way to grasp how uncertainties affect them. The Monte Carlo simulation is used for this.

*'''[http://en.wikipedia.org/wiki/Bayesian_inference Bayesian statistics] and[http://en.wikipedia.org/wiki/Bayesian_network Bayes Nets]:'''
::This is a probability theory using Bayes Theorem to sum up several probabilities in to one.

*'''FN curves:'''
::These curves are used in relation with casualties in a specified population affected by an event.

*'''Risk indices:'''
::This semi-quantitative measure generates a risk index derived from scorings of normal scales, and is used as a classification system.

*'''Consequence/probability matrix:'''
::As the name suggests it is a matrix combining qualitative or semi-qualitative consequences with probabilities in order to generate a risk rating. This matrix can then be used to rank different risks treatments or risk sources.

*'''[http://en.wikipedia.org/wiki/Cost%E2%80%93benefit_analysis Cost/benefit analysis (CBA)]:'''
::The CBA is often used to see if it is worth it to go ahead with changes to status quo, and mainly on a financial level.

*'''[http://en.wikipedia.org/wiki/Multiple-criteria_decision_analysis Multi-criteria decision analysis (MCDA)]:'''
::By using several different criteria the MCDA assesses the overall positive value of a set of options, transparently and objectively. It aims to sort the options in order of preference.

*'''Fuzzy synthetic evaluation (FSE) approach: '''
::Described in the International journal of Project Management 31 (2013) it is an intuitive method which starts out identifying the risk factors, evaluating a specific risk using both quantitative and qualitative values and by combining them generating a matrix of numeric risk values. After determining the evaluation criteria each criteria is given a weight which is combined with the risk matrix into a fuzzy evaluation matrix. The risk index is then calculated and the overall risk evaluated after each risk is given a weight of it’s own.

==Reference==
[http://www.iso.org/iso/catalogue_detail?csnumber=44651 ISO Guide 73-2009 – Risk Management Vocabulary (2009)]

[http://www.iso.org/iso/catalogue_detail?csnumber=43170 ISO 31000 - Risk management - Principles and guidelines (2009)]

[http://www.iso.org/iso/catalogue_detail?csnumber=51073 ISO 31010 - Risk management (2009)]

International Journal of Project Management 32 (2014) - Vahid Khodakarami , Abdollah Abdi - Project cost risk analysis: A Bayesian networks approach for modelling dependencies between cost items

International Journal of Project Management 31 (2013) - Jialin Liu, Quanxi Li, Yuhan Wang - Risk analysis in ultra deep scientific drilling project – a fuzzy synthetic evaluation approach

Project Management Journal (April 2013) - Juliane Teller - Portfolio Risk Management and Its Contribution to Project Portfolio Success: An Investigation of Organization, Process, and Culture

==Links==
'''Only the following links are internal in the APPPM-wiki, All others are to Wikipedia.org and may be replaced when the APPPM-pages has been written, and added to this list.

Once all links are internal, this section can be deleted.'''

[http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]

[http://apppm.man.dtu.dk/index.php/The_Cynefin_Framework the Cynefin framework]

[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]

Risk analysis

2014-11-29T20:30:01Z

TigR:

:''main article: [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]''
==Summary==

This article will describe the element of risk analysis within risk management, what it is used for and list several elements which can be used in the process of managing risk in projects, portfolios and programs..
Since risk analysis is a subpart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management], several correlations might be present between the two.

Several methods used for Risk Analysis will be mentioned and explained briefly, but (in order to allow the full use of the wiki) not be described in detail. Some of them might not seem directly applicable but can all be used during the possible iterations within the analysis.

The user of risk analysis essentially choose the most appropriate method(s) for calculating the given information and delivers a collective overview of the situation, as an artisan chooses the right tool for the job and produces the individual parts for the product. Using “known knowns” and “known unknowns” '' (from [http://apppm.man.dtu.dk/index.php/The_Cynefin_Framework the Cynefin framework]) '' along with estimates made by either extrapolation based on prior knowledge or by experts, the analysis generates a better understanding enabling the user to conduct a valid risk evaluation.

==Definition==
[[File:Risk Analysis from ISO31000.JPG|500px|thumb|right|Risk Analysis]]
Risk analysis lies at the heart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] and functions very much like the Central Processing Unit (CPU) of a computer.

The term "Risk" is most often defined as a probability of losing something of a specific value.
Mathematically speaking; the probability of an event occurring multiplied by the potential value-loss = the risk.

In order to compute this risk the person(s) doing the analysis must as a minimum receive information on the probability of an event occurring and the value of the potential loss.
The definition of risk analysis, as defined by the International Organisation for Standardization is as follows:

In their [http://www.iso.org/iso/catalogue_detail?csnumber=44651 ISO Guide 73-2009], it is stated as the ''“Process to comprehend the nature of risk and to determine the level of risk”''
In the [http://www.iso.org/iso/catalogue_detail?csnumber=43170 ISO 31000] standard it is described as the process which ''“provides an input to risk evaluation and to decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods” ''.

Both are correct since the process mentioned is the computational part of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] where different aspects, variables and factors are used to estimate the risk involved with a specific feature, action, decision, condition etc. The outcome of this computation is a quantified number or percentage which can then be used as an evaluation criterion, determining either which option to select or if it is safe to proceed down the investigated path.

==Main features of risk analysis==
There are three different analysis method groupings within risk analysis; Qualitative, Semi-Quantitative and Quantitative.

;Qualitative:
:Qualitative analysis methods are based on opinions and estimates. They compute the risk scenario based on few numbers and many interpretations. Outcome of these methods are usually given in levels of significance like “high”, “medium” and “low” or other "word scales" which are not specifically determining any actual number. An example of a qualitative result is the risk of terror when travelling abroad, made by the ministry of foreign affairs.

;Semi-quantitative:
:The outcomes of the semi-quantitative analysis methods are based on numeric ratings using evaluation scales for probability and consequence and usually combining them using a formula, resulting in a comparable value for the risk level.

;Quantitative:
:The quantitative analysis uses estimates of probability and consequence values to generate an approximation of the risk involved, represented by one specific value. The specific values, depending on the method of gathering, from different analysis can then be combined into one overall risk factor.

Because risk analysis works much like the processor in a computer it needs to receive a minimum of information as input before it can calculate an output which allows the user to gain a better overview and basis for making changes or taking decisions. Risk analysis is often generated for the sake of factual argumentation and credibility of decisions.

{| class="wikitable"
|+Risk Analysis
|-
|'''Input:'''
|'''Output:'''
|-
|;Purpose
:The purpose is the reason for analysing the risk; it assists in determining the boundaries of the analysis.
|rowspan="4"|;Assessment of the risk with the following aspects
:Description of methods used and known control features impact on the risk
:Combined Likelihood / probability depending on the description of original risk
:Consequences of different scenarios
|-
|;Type of risk
:Choice of models depends on the type of risk in question.
|-
|;Information available
:Determines whether it is possible to conduct the analysis right away or information has to be gathered.
|-
|;Existing control features
:The features that are already in place to influence the risk and outcome of the analysis.
|-
|;Effectivity of existing control features
:How effective the control features are. This information can also reveal if there is room for improvements.
|rowspan="4"|;Description of the confidence in:
:The assessment of the risk (the result of the analysis)
:The sensitivity of the result to preconditions and assumptions
:Information Uncertainty
:Information Availability
:Information Quality
:Information Quantity
:Ongoing relevance of information (how relevant will the analysis be in the future)
|-
|;Consequences
:The consequences can be both positive and negative, and reflect the impact of events defined in the analysis.
|-
|;Likelihood / Probabilities
:Estimates, guesstimates, statistics and assumptions on the probability of an event happening.
|-
|;Risk criteria
:Terms against which the risk significance is evaluated, often based on context (internal/external) and objectives of the organisation.
|-
|;Causes of risk
:The reasons why an event takes place.
|rowspan="4"|;Limitations
:Demarcation description.
|-
|;Sources of risk
:The objects which affects the risk.
|-
|;Factors influencing any of the above
:Weights which scale the severity of the quantities are part of this input, as well as uncertainties and sensitivities.
|-
|;Interrelations / Interdependence
:The network of relational aspects between different risks
|}

----

==Benefits of analysing risk==
Analysing risk has become an integrated part of working with forecasts as well as decisions in projects, programs and portfolios, simply because it generates the big picture needed to make an informed decision.
The drivers of analysing risk are the focus on lowering costs and expenses, avoiding loss of anything valuable and reducing variability in outcomes.
The reason why risk is analysed with so many different methods to choose from, is because several different categories of risk exist, and yet there is a universal consensus that risk is best avoided, mitigated, minimised or negated.

==Models used when analysing risk==
All but one of the following models are described in Annex B of the ISO 31010 standard.

*'''[http://en.wikipedia.org/wiki/Brainstorming Brainstorming]:'''
::Brainstorming is a very intuitive method which uses associations and connections made by possibly several people around a central subject to uncover problematic and opportunistic aspects affecting the subject. This qualitative information is then used to gather as much quantitative information as possible in order to complete the further analysis. It can e.g. be used to imagine future risks or possible control features to known risks.

*'''[http://en.wikipedia.org/wiki/Structured_interview Structured] or [http://en.wikipedia.org/wiki/Semi-structured_interview semi-structured] interviews:'''
::The structured or semi-structured interview can be used for gathering information from numerous sources. These interviews do not have to be done face to face since questionnaires are also considered within this model. Applicable in the phases before and after Risk Analysis.

*'''[http://en.wikipedia.org/wiki/Delphi_method Delphi technique]:'''
::The Delphi technique is essentially a brainstorming process where the participants are kept anonymous but are able to see the collected work of all participating in the process. It is used to reach some kind of consensus around the subject in question. Applicable in the phases before and after Risk Analysis.

*'''Check-lists:'''
::Check-lists are built from previous experiences and often list known risks, control features and/or hazards gathered through prior assessments or lessons learned.

*'''[http://en.wikipedia.org/wiki/Hazard_analysis Preliminary hazard analysis (PHA)]:'''
::PHA is used when there is little information available and as the name states normally in the beginning of e.g. a project, in order to uncover potential hazards influencing the further development.

*'''[http://en.wikipedia.org/wiki/Hazard_and_operability_study Hazard and operability study (HAZOP)]:'''
::HAZOP is a qualitative method which studies the current activities in order to access the risk involved. It usually examines existing operations like procedures and products as well as processes and the system around them.

*'''[http://en.wikipedia.org/wiki/Hazard_analysis_and_critical_control_points Hazard analysis and critical control points (HACCP)]:'''
::HACCP is mainly used in the industry which produces items for consumption where infections are of vital importance. The critical control points are then indicating areas within the production where errors can lead to loss of quality or worse.

*'''Toxicity assessment:'''
::Toxicity assessment is used when looking at risk related to the environment and how the introduction of a source of harm affects it.

*'''[http://en.wikipedia.org/wiki/Structured_What_If_Technique Structured “What-If” Technique (SWIFT)]:'''
::SWIFT is normally used at workshops by the facilitator to make the participants introduce risk into their chain of thought by using a set of specific questioning words along with the catchphrase “what if?” .

*'''[http://en.wikipedia.org/wiki/Scenario_analysis Scenario analysis]:'''
::When conducting a scenario analysis, one or several future scenarios are developed based on the participants’ thoughts and ideas on where the future might bring us. Then doing back-casting in order to determine the events needed to reach the scenario and evaluating the risks of these events.

*'''Business impact analysis (BIA):'''
::The BIA investigates the risks capable of disrupting the organisation’s operations as well as the current controls in place and how well they will handle the disruption.

*'''[http://en.wikipedia.org/wiki/Root_cause_analysis Root cause analysis (RCA)]:'''
::RCA is often used after an event has taken place with the aim of preventing it from happening again.
::By constantly questioning for the reason why an event occurred, turning the reason into an event and repeating the question the RCA attempts to discover the fatal event which set several chains of actions into motion.

*'''[http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis Failure modes and effects analysis (FMEA)] / [http://en.wikipedia.org/wiki/Failure_mode,_effects,_and_criticality_analysis failure modes and effects and criticality analysis (FMECA)]:'''
::FMEA is essentially an error tool attempting to map out the different possible ways for processes, systems or components are able to fail and thus not fulfil the designed purpose.
::FMECA expands FMEA by ranking the outcomes against each other and thereby identifying the most critical failures.

*'''[http://en.wikipedia.org/wiki/Fault_tree_analysis Fault tree analysis (FTA)]:'''
::FTA is a method used to develop your typical trouble shooting guide where it is possible to locate the cause of an undesired event by deductive reasoning.

*'''[http://en.wikipedia.org/wiki/Event_tree_analysis Event tree analysis (ETA)]:'''
::ETA can be used to generate the probability of the control features working or not working with regards to a specific event happening. Contrary to the FTA, the ETA can be used before the event has actually happened as a hypothetical reasoning method. It can be used both quantitative and qualitative.

*'''Cause-consequence analysis:'''
::Cause-consequence analysis is combining FTA and ETA in order to analyse the various paths possible within a system following a critical event. It is used within critical safety systems as a reliability tool.

*'''[http://en.wikipedia.org/wiki/Ishikawa_diagram Cause-and-effect analysis]:'''
::Cause-and-effect analysis identifies potential causes of an event or problem by looking at the possible contributing factors and organising them in either a fishbone or tree diagram in order to consider all possible hypotheses.

*'''Layers of protection analysis (LOPA):'''
::LOPA analyses if the required control features are present to mitigate an undesired event or scenario. It is a semi-qualitative method used to provide a baseline when specifying independent protection layers.

*'''[http://en.wikipedia.org/wiki/Decision_tree Decision tree analysis]:'''
::Decision tree analysis can be used as a forecast tool, assisting the decision makers with understanding the consequences and follow-up decisions to an initial event. It resembles a tool usable for career path decisions where you start with a lot of options and by deciding on one path, still having several options open.

*'''[http://en.wikipedia.org/wiki/Human_reliability Human reliability assessment (HRA)]:'''
::HRA is mainly used to evaluate the human influence on performance of systems or the human error factor.
::It is usable both quantitatively and qualitatively.

*'''[http://en.wikipedia.org/wiki/Bowtie_(sequence_analysis) Bow tie analysis]:'''
::The bow tie analysis generates a graphical representation which assists in generating the full picture of what has to happen prior to an event (causes) and what can happen afterwards (consequences). It is mostly generated in a brainstorming session.

*'''[http://en.wikipedia.org/wiki/Reliability_centered_maintenance Reliability centered maintainance (RCM)]:'''
::RCM identifies policies which need to be implemented in order to achieve the required safety by managing failures effectively and efficiently.

*'''Sneak analysis (SA) / [http://en.wikipedia.org/wiki/Sneak_circuit_analysis sneak circuit analysis (SCI)]:'''
::SA and SCI are used for identifying design errors which may cause harm to production or personnel or just generate an undesired outcome.

*'''[http://en.wikipedia.org/wiki/Markov_chain Markov analysis]:'''
::The Markov analysis is used when the future state depends only on present state of a system. It is a quantitative method which can be described with discrete or continuous states.

*'''[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]:'''
::Simulating complex systems can be the only way to grasp how uncertainties affect them. The Monte Carlo simulation is used for this.

*'''[http://en.wikipedia.org/wiki/Bayesian_inference Bayesian statistics] and[http://en.wikipedia.org/wiki/Bayesian_network Bayes Nets]:'''
::This is a probability theory using Bayes Theorem to sum up several probabilities in to one.

*'''FN curves:'''
::These curves are used in relation with casualties in a specified population affected by an event.

*'''Risk indices:'''
::This semi-quantitative measure generates a risk index derived from scorings of normal scales, and is used as a classification system.

*'''Consequence/probability matrix:'''
::As the name suggests it is a matrix combining qualitative or semi-qualitative consequences with probabilities in order to generate a risk rating. This matrix can then be used to rank different risks treatments or risk sources.

*'''[http://en.wikipedia.org/wiki/Cost%E2%80%93benefit_analysis Cost/benefit analysis (CBA)]:'''
::The CBA is often used to see if it is worth it to go ahead with changes to status quo, and mainly on a financial level.

*'''[http://en.wikipedia.org/wiki/Multiple-criteria_decision_analysis Multi-criteria decision analysis (MCDA)]:'''
::By using several different criteria the MCDA assesses the overall positive value of a set of options, transparently and objectively. It aims to sort the options in order of preference.

*'''Fuzzy synthetic evaluation (FSE) approach: '''
::Described in the International journal of Project Management 31 (2013) it is an intuitive method which starts out identifying the risk factors, evaluating a specific risk using both quantitative and qualitative values and by combining them generating a matrix of numeric risk values. After determining the evaluation criteria each criteria is given a weight which is combined with the risk matrix into a fuzzy evaluation matrix. The risk index is then calculated and the overall risk evaluated after each risk is given a weight of it’s own.

==Reference==
[http://www.iso.org/iso/catalogue_detail?csnumber=44651 ISO Guide 73-2009 – Risk Management Vocabulary (2009)]

[http://www.iso.org/iso/catalogue_detail?csnumber=43170 ISO 31000 - Risk management - Principles and guidelines (2009)]

[http://www.iso.org/iso/catalogue_detail?csnumber=51073 ISO 31010 - Risk management (2009)]

International Journal of Project Management 32 (2014) - Vahid Khodakarami , Abdollah Abdi - Project cost risk analysis: A Bayesian networks approach for modelling dependencies between cost items

International Journal of Project Management 31 (2013) - Jialin Liu, Quanxi Li, Yuhan Wang - Risk analysis in ultra deep scientific drilling project – a fuzzy synthetic evaluation approach

Project Management Journal (April 2013) - Juliane Teller - Portfolio Risk Management and Its Contribution to Project Portfolio Success: An Investigation of Organization, Process, and Culture

==Links==
'''Only the following links are internal in the APPPM-wiki, All others are to Wikipedia.org and may be replaced when the APPPM-pages has been written, and added to this list.

Once all links are internal, this section can be deleted.'''

[http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]

[http://apppm.man.dtu.dk/index.php/The_Cynefin_Framework the Cynefin framework]

[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]

Talk:Risk management strategy

2014-11-29T19:28:26Z

TigR: /* Picture */ new section

== Review from Username111 ==

First of all, it doesn't look like the article is complete yet. Therefore, I will only give a review based on the abstract, structure and the risk processing chapter (doesn't seem complete either but I'll use what is produced so far) which is currently produced (November 25th 15:00). However, the topic seems interesting and very relevant for any project manager (or student within project management). It seems clear that the article is under in-depth method description category, due to each of the proposed chapters will have method descriptions.

I like the proposed structure of the article. I believe that it will create a good flow with a clear red thread.

These are my specific questions and suggestions:

* Maybe you could add a general example to each of the chapters. This could further strengthen the arguments of using the methods. E.g. you could give an example of an identified risk in "risk identification", analyze this specific risk in "risk analysis", assess the risk in "risk assessment", and finally propose mitigation action for the risk in "risk processing". This would give the reader a clear understanding of how to use the proposed methods in each of the chapters.
* There seems to be a lack of proper referencing.
'''(MartinKruck reply)''' Should be fixed now.
** In the first sentence you reference to (Machiavelli, 1514), but there is no bibliography were I can find the actual article/journal/book.
'''(MartinKruck reply)''' Added
** In the second paragraph in the abstract there is a lot of interesting statements of risk management. I guess most of them are not something you have created out of your own thoughts, and therefore they need referencing to the correct sources. E.g. the definition of risk: "''A risk can be defined as the product of the probability of the risk and the impact of the risk''" needs referencing. Maybe some of the statements are common sense for a project manager, but I would still suggest using some references to academic resources in order to improve the quality of the article.
'''(MartinKruck reply)''' Saying a risk is a product of probability and impact is just the short(and more accurate) way of saying: "A risk is when something might go wrong". However finding were this was first used is too time consuming and of little consequence for the credibility of the article. I will therefor not try to find a reference, but thank you for the tip.
** Your dice example needs need a reference as well, unless you came up with it yourself of course.
'''(MartinKruck reply)''' I am actually a habitual wargamer (warhammer 40000) where determining probability related to dice rolls is a major advantage. This is of my own creation.
* In the second paragraph you give two examples; when a problem is likely to happen but no impact, and when a problem is unlikely to happen and high impact. Maybe you could add a few more examples, in order to introduce scenarios were risk mitigation action is required.
'''(MartinKruck reply)''' Example added.
* You talk about "injuries" in relation to the impact of a given risk. I consider an injury something that can occur to an person. E.g. Bendtner sustained an injury after scoring his 6th goal. I would propose to use: consequence, damage, etc., since it often will be the impact in the project/company, not the person.
'''(MartinKruck reply)''' injuries replaced with impacts
* This sentence is very hard to read: "''If there is no certain way to determine a risk’s impact or probability or multiple risks are compared without having similar impact type (e.g. comparing human casualties against monetary loss) a qualitative approach can be used, where the risk is rated from e.g. 1-5.''". Please consider revising, in order to make it more understandable.
'''(MartinKruck reply)''' Sentence removed.
* Since you already mention there are several other apppm wikis about risk management, you could use these as potential references, instead of just saying they might be similar.
'''(MartinKruck reply)''' Sentence removed.
* The risk processing chapter: It seems like the chapter is not completely done. I would suggest to begin this chapter with describing the different methods/strategies (accept, mitigate, transfer, avoid, improve), and then follow by when you would use these different methods/strategies. Ideally you could give an example in the end of a risk that has been mitigated using one of the methods/strategies. Remember proper referencing for this chapter as well.
'''(MartinKruck reply)''' The current layout was kept, but your idea was considered and actually implemented at first. However due to the flow of the article, I reverted back to the first layout, since I felt it gave a better flow.

Other than these few comments, good job. Just fill in the chapters and make sure to use proper referencing, and the article will be great :)

Good luck!

== Review from Xyz ==

You have chosen a very exiting topic and is a very good first outcast, but obviously it's not complete.
* The spelling, grammar and punctuation looks fine to me.
'''(MartinKruck reply)''' Thank you ;)
* The article is generally easy to understand, but some of the sentences are bit long and hard to follow.
'''(MartinKruck reply)''' Sorry about that. I'll try to cut down on my sentences.
* There are so fare no figures. It would be easier to understand the main points, if there were a few figures.
'''(MartinKruck reply)''' Figures added.
* I find the topic very interesting and relevant, and i think any person within project management would to.
* To me it seams like article belongs to the method description category.
* I think there will be a nice flow through out the article, when it is finished.
* It would be nice to finish the article with a short summery/conclusion.
'''(MartinKruck reply)''' Added.
* It might be a good idea to have some more solid references.
'''(MartinKruck reply)''' Added.

-Good luck.

== Picture ==

The picture you use seems to be taken as snapshot from the ISO 31000.. that is copyrighted.. you can use the one which I have uploaded.. check files.

Talk:Risk management

2014-11-27T22:48:43Z

TigR: /* TigR helping */

== Sube - Review ==

Greetings Risk management writer

First of all, congratulation you wrote you first wiki style article!

Second, NOTE that the text flows to the right... I do not know how to fix this...

* Your english is pretty good and understandable:)

* General speaking. Be more concrete about what you are writing, remember the reader do not know what you have in mind when writing it...
Ex. First line "abstract" ''...in each area.''
- which areas... This issue is present around the article. And improved, would make it much more reader freindly.

* Try to make the text more compressed and concrete. Words and add-on words that dont add value to the sentence should more or less not be there.

* Take note of long sentences try to rewrite or divide them... They are present:)

* Maybe use some example of best practice cases to further inhance the truthness of your writing.

* A suggestion; Have you heart about Monte Carlo Method regarding Risk Management/Analysis. This perspective could be interesting.

----
'''Abstract'''
- To start with I would place the abstract in the beginning of the document, followed by a table of content...

- Moreover, I would add a general introduction, maybe without heading, to explain why risk management is important, this way make the reader more intreaked.

- I think the Abstract could be rewritten, if you catch the reader here they will read the entire thing:)

----
'''Defination'''
- Titles... Definition is spelled like this, you do spell it right in the text though:) then definition of what? I would call it "Risk Management"

----
'''What is risk'''

- What is risk is a question and whould be ended with ?. Maybe Definition of risk instead...
When talking about the word risk,I would put the topic before Defination, as is explain some aspects of this topic.

----
'''Benefit of risk management and why risk management'''
- Titles... Revisit; "Benefit of risk management and why risk management", title cuold be more focused. You dont really answer why risk management?.

First line isnt that a SWOT. Maybe: risk managment do the same as a SWOT analysis, by evaluating both S, W, T and O ... And why does is avaluate this?

- Reference .16. "There are many reasons to manage risk" - is it where the benefits come from`?
Then I would move the reference. Otherwise I think it is a wierd reference:)

- Small Note: . after the first 7 bullet points none after...

----
'''Three levels of operational risk management'''
- Honestly I think this part is vaid. Maybe rearrange to focus on projects, programs and portfolio? What are the risks here

- Another thing i notest, isnt it called; Strategic, Tactical and Operational level?

----
'''How to develop a risk analysis'''
- First line... Again be specific ex. Risk can develop in two different ways... Risk Management can be developed in ....
I think the second way (second bulletpoing) is nonsence, dont get me wrong:)

- What is M_O_R? or what does it stand for?
- Good with ISO standarts:) Maybe make a list: ISO blabla - does this/provides this ect.
I suggest in bulletpoints. This would make it more illustrative and as a reader it provides a nice overview...

----
'''An example on how to identify your projects risks'''
- Title:) Risk Management in Practice - just a suggestion from my side.
- It would be more appropriate in bulletpoints suplemented by text. Step by step what do you have to do?

I would add a wrapup to end the article, somehow answering what you tried to figure out...

Hope you can use atleast some of my review... Good Luck Have Fun:)

== s132463 Review ==
I like that you aim at defining risk and risk management before going into concrete examples. Also the use of many sources is good, as it gives the reader opportunity to read more on the topic. Maybe use more journal article style as references, rather than e-newspaper articles. Empirical evidence and good research is preferable.

However, I see the article as a whole having the following general flaws:
*The is no distinct red-thread through the article. I can see what you are trying to do, and I think the general layout/chapters are a good idea. The chapters just do not link in any way. Make sure to finish each chapter with some sort of conclusion, to clearly state what is learned.
*Many of the first chapters pretty much say the same thing, with minor changes. Be sure to write about the specific topic within the headline of the chapter. No information should be stated twice, unless it is in relation/discussion with something new.
*References should be done in wiki style references and with appropriate annotation of source (author(s), year, journal name, etc.).
**<nowiki><ref name=RefName>Information here. This is what can be found in the bottom.</ref></nowiki>
**You can reference to the same by using the "RefName" like this: <nowiki><ref name=RefName></ref></nowiki>. Be aware that Ref-names are case sensitive.
**Include </references> at the bottom of your page to get all reference information shown
*Include categories to your article (see front page here on the apppm.wiki). fx <nowiki>[[Category:Uncertainty]]</nowiki>. This should just be added somewhere in the wiki-code. Maybe as the very last.

=== "Introduction" ===
* You write "...this article focuses on for example...". I think the focus of the article should be clearly stated, not mentioned as an example
* The NOTE at the end should link to the actual wiki pages (link by typing <nowiki>[["Category Name"]] fx. [[Risk management]]</nowiki> , beware that page names are case sensitive). Link to this page: [[Risk management]]

=== Definition of risk management ===
I like the general idea of starting with description of risk, then risk management and how risk assesment is used.

*I find the start of this chapter to be fine, but when you spend a lot of different sources to define risk in different ways, you should briefly discuss what the differences on the definitions actually mean. What definition do you assume?
*The second part where you talk about how risk management is used, you can be a bit more direct in your description. I'm not quite sure what direction you try to direct my attention/understanding. Try to clearly answer: How is risk used? Why is risk used? What implications when using? What implications when not using? etc. - I can see what you try to do, but the red thread is a bit hard to find when reading it.

=== What is risk ===
*Again I am not 100% sure what you are trying to tell me as the reader. Defining the risk (again again)? Talking about what risk can actually be? I suggest you describe more different actual examples of risk (like the example of 6/12 months) and then call the chapter "Examples of Risk"

=== Benefit of risk management and why risk management ===
*Nice with a bullet list of benefits, but I miss some sort of conclusion or specific declaration of "why risk management".
*Reference on bullets?

=== Three levels of operational risk management ===
*Strategic level:
**What is risk demand? why does strategic operational relate to this? I think this should be stated more clearly
**I find it somewhat unclear what risk management at the strategic level actually is. Try to be clear in your definitions.
*Tactical level:
**I find the information to be okay. However, this specific chapter is not very well-written. Consider rewriting to make sure the reader understand what you try to convey.
*Dynamic level:
**What is the dynamic level? Normally I would think strategic, tactical, and operational are the three organisational levels.

=== How to develop a risk analysis ===
*I suppose first line should be: Risk analysis can develop in two different ways
*The comparison of ISO 31010 and M_O_R is a bit hard to follow. Be clear about what the differences are. Maybe set up a table, similar points of explanation or similar, and then do the comparison and discussion of differences.

=== An example of how to identify your project's risk ===
*What source(s) is/(are) used here?
*I like the idea of describing an example of how to identify risk. However, the example is very short and provides very little information. Consider what you want to say with this chapter.
*The "second part" where you describe how risk should be assigned; Is that really a general way of doing risk analysis?
*Try to combine the knowledge gained through previous chapters in this example. Since this ends the article, it should act as a conclusion/sum-up of important knowledge gained through the entire article
*Pictures should contain a text description. Also, are the pictures covered by copyright?

== TigR helping ==

I thought you might want to use this picture: http://apppm.man.dtu.dk/index.php/File:Risk_Management_from_ISO31000.JPG
I use a version of it in my article on Risk Analysis.. (also consider linking to my article where it is applicable. :)
Also.. you might not want to be too detailed on the "Risk Analysis" part.. instead let me know if I have missed out on some points which you mention.

2014-11-24T11:20:12Z

TigR:

Risk analysis

2014-11-24T01:47:36Z

TigR:

==Abstract==

This article is a subpart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] but will attempt to describe different approaches to analysing the risk when managing projects, portfolios and programs

Several tools will be mentioned and explained briefly, but (in order to allow the full use of the wiki) not be described in detail
==Definition==
According to the ISO Guide 73-2009, risk analysis is the “Process to comprehend the nature of risk and to determine the level of risk”

ISO 31000 describes risk analysis as the process which “provides an input to risk evaluation and to decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods”.

This process mentioned is the computational part of risk management where different aspects, variables and factors are used to estimate the risk involved with a specific feature, action, decision, condition ect. The outcome of this computation is a quantified number or percentage which can then be used as an evaluation criterion, determining either which option to select or if it is safe to proceed down the investigated path.

==Main features of risk analysis==
Input:
:Purpose
The purpose is the reason for analysing the risk; it assists with determining the boundaries of the analysis.

:Consequences

:Likelihood / Probabilities

:Existing control features

:Effectiveness of existing control features

:Causes of risk

:Sources of risk

:Factors influencing any of the above

:Interrelations / Interdependence

:Type of risk

:Information available

:Risk criteria

Output:
:Combined Likelihood / probability

:Consequences

:Confidence in:
::Risk level

::Sensitivity of result to preconditions and assumptions

::Information Uncertainty

::Information Availability

::Information Quality

::Information Quantity

::Ongoing relevance of information

:Limitations

==Benefits of analysing risk==

==Different models used when analysing risk==
:'''[http://en.wikipedia.org/wiki/Brainstorming Brainstorming]:'''

----
:'''[http://en.wikipedia.org/wiki/Structured_interview Structured] or [http://en.wikipedia.org/wiki/Semi-structured_interview semi-structured] interviews:'''

----
:'''[http://en.wikipedia.org/wiki/Delphi_method Delphi technique]:'''

----
:'''Check-lists:'''

----
:'''[http://en.wikipedia.org/wiki/Hazard_analysis Preliminary hazard analysis (PHA)]:'''

----
:'''[http://en.wikipedia.org/wiki/Hazard_and_operability_study Hazard and operability study (HAZOP)]:'''

----
:'''[http://en.wikipedia.org/wiki/Hazard_analysis_and_critical_control_points Hazard analysis and critical control points (HACCP)]:'''

----
:'''Toxicity assessment:'''

----
:'''[http://en.wikipedia.org/wiki/Structured_What_If_Technique Structured “What-If” Technique (SWIFT)]:'''

----
:'''[http://en.wikipedia.org/wiki/Scenario_analysis Scenario analysis]:'''

----
:'''Business impact analysis (BIA):'''

----
:'''[http://en.wikipedia.org/wiki/Root_cause_analysis Root cause analysis (RCA)]:'''

----
:'''[http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis Failure modes and effects analysis (FMEA)] / [http://en.wikipedia.org/wiki/Failure_mode,_effects,_and_criticality_analysis failure modes and effects and criticality analysis (FMECA)]:'''

----
:'''[http://en.wikipedia.org/wiki/Fault_tree_analysis Fault tree analysis (FTA)]:'''

----
:'''[http://en.wikipedia.org/wiki/Event_tree_analysis Event tree analysis (ETA)]:'''

----
:'''Cause-consequence analysis:'''

----
:'''[http://en.wikipedia.org/wiki/Ishikawa_diagram Cause-and-effect analysis]:'''

----
:'''Layers of protection analysis (LOPA):'''

----
:'''[http://en.wikipedia.org/wiki/Decision_tree Decision tree analysis]:'''

----
:'''[http://en.wikipedia.org/wiki/Human_reliability Human reliability assessment (HRA)]:'''

----
:'''[http://en.wikipedia.org/wiki/Bowtie_(sequence_analysis) Bow tie analysis]:'''

----
:'''[http://en.wikipedia.org/wiki/Reliability_centered_maintenance Reliability centered maintainance]:'''

----
:'''Sneak analysis (SA) / [http://en.wikipedia.org/wiki/Sneak_circuit_analysis sneak circuit analysis (SCI)]:'''

----
:'''[http://en.wikipedia.org/wiki/Markov_chain Markov analysis]:'''

----
:'''[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]:'''

----
:'''[http://en.wikipedia.org/wiki/Bayesian_inference Bayesian statistics] and[http://en.wikipedia.org/wiki/Bayesian_network Bayes Nets]:'''

----
:'''FN curves:'''

----
:'''Risk indices:'''

----
:'''Consequence/probability matrix:'''

----
:'''[http://en.wikipedia.org/wiki/Cost%E2%80%93benefit_analysis Cost/benefit analysis (CBA)]:'''

----
:'''[http://en.wikipedia.org/wiki/Multiple-criteria_decision_analysis Multi-criteria decision analysis (MCDA)]:'''

==Reference==
ISO Guide 73-2009 – Risk Management Vocabulary

ISO 31000 - Risk management - Principles and guidelines

ISO 31010 - Risk management

International Journal of Project Management 32 (2014) - Vahid Khodakarami , Abdollah Abdi - Project cost risk analysis: A Bayesian networks approach for modelling dependencies between cost items

==Links==
'''Only the following links are internal in the APPPM-wiki, All others are to Wikipedia.org and may be replaced when the APPPM-pages has been written, and added to this list:'''

[http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]

[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]

Risk analysis

2014-11-24T01:23:57Z

TigR:

==Abstract==

This article is a subpart of [http://apppm.man.dtu.dk/index.php/Risk_management Risk Management] but will attempt to describe different approaches to analysing the risk when managing projects, portfolios and programs

Several tools will be mentioned and explained briefly, but (in order to allow the full use of the wiki) not be described in detail
==Definition==
According to the ISO Guide 73-2009, risk analysis is the “Process to comprehend the nature of risk and to determine the level of risk”

ISO 31000 describes risk analysis as the process which “provides an input to risk evaluation and to decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods”.

This process mentioned is the computational part of risk management where different aspects, variables and factors are used to estimate the risk involved with a specific feature, action, decision, condition ect. The outcome of this computation is a quantified number or percentage which can then be used as an evaluation criterion, determining either which option to select or if it is safe to proceed down the investigated path.

==Main features of risk analysis==
Input:
:Purpose
The purpose is the reason for analysing the risk; it assists with determining the boundaries of the analysis.

:Consequences

:Likelihood / Probabilities

:Existing control features

:Effectiveness of existing control features

:Causes of risk

:Sources of risk

:Factors influencing any of the above

:Interrelations / Interdependence

:Type of risk

:Information available

:Risk criteria

Output:
:Combined Likelihood / probability

:Consequences

:Confidence in:
::Risk level

::Sensitivity of result to preconditions and assumptions

::Information Uncertainty

::Information Availability

::Information Quality

::Information Quantity

::Ongoing relevance of information

:Limitations

==Benefits of analysing risk==

==Different models used when analysing risk==
:'''[http://en.wikipedia.org/wiki/Brainstorming Brainstorming]:'''

----
:'''Structured or semi-structured interviews:'''

----
:'''Delphi technique:'''

----
:'''Check-lists:'''

----
:'''Preliminary hazard analysis (PHA):'''

----
:'''Hazard and operability study (HAZOP):'''

----
:'''Hazard analysis and critical control points (HACCP):'''

----
:'''Toxicity assessment:'''

----
:'''Structured “What-If” Technique (SWIFT):'''

----
:'''Scenario analysis:'''

----
:'''Business impact analysis (BIA):'''

----
:'''Root cause analysis (RCA):'''

----
:'''Failure modes and effects analysis (FMEA) / failure modes and effects and criticality analysis (FMECA):'''

----
:'''Fault tree analysis (FTA):'''

----
:'''Event tree analysis (ETA):'''

----
:'''Cause-consequence analysis:'''

----
:'''Cause-and-effect analysis:'''

----
:'''Layers of protection analysis (LOPA):'''

----
:'''Decision tree analysis:'''

----
:'''Human reliability assessment (HRA):'''

----
:'''Bow tie analysis:'''

----
:'''Reliability centered maintainance:'''

----
:'''Sneak analysis (SA) / sneak circuit analysis (SCI):'''

----
:'''Markov analysis:'''

----
:'''[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]:'''

----
:'''Bayesian statistics and Bayes Nets:'''

----
:'''FN curves:'''

----
:'''Risk indices:'''

----
:'''Consequence/probability matrix:'''

----
:'''Cost/benefit analysis (CBA):'''

----
:'''Multi-criteria decision analysis (MCDA):'''

==Reference==
ISO Guide 73-2009 – Risk Management Vocabulary

ISO 31000 - Risk management - Principles and guidelines

ISO 31010 - Risk management

International Journal of Project Management 32 (2014) - Vahid Khodakarami , Abdollah Abdi - Project cost risk analysis: A Bayesian networks approach for modelling dependencies between cost items

==Links==
'''Only the following links are internal in the APPPM-wiki, All others are to Wikipedia.org and may be replaced when the APPPM-pages has been written, and added to this list:'''

[http://apppm.man.dtu.dk/index.php/Risk_management Risk Management]

[http://apppm.man.dtu.dk/index.php/Monte_Carlo_Simulation_of_Risk Monte Carlo simulation]

2014-11-24T00:03:03Z

TigR:

Risk analysis

2014-11-23T23:56:51Z

TigR:

=Abstract=
This article may overlap with Risk Management but will attempt to discuss different approaches to analysing the risk when managing projects/portfolios/programs.

Several tools will be mentioned and explained briefly, but (in order to allow the full use of the wiki) not be described in detail
=Definition=
According to the ISO Guide 73-2009, Risk analysis is the “Process to comprehend the nature of risk and to determine the level of risk”

ISO 31000 describes Risk analysis as the process which “provides an input to risk evaluation and to decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods”.

This process mentioned is the computational part of risk management where different aspects, variables and factors are used to estimate the risk involved with a specific feature, action, decision, condition ect. The outcome of this computation is a quantified number or percentage which can then be used as an evaluation criterion, determining either which option to select or if it is safe to proceed down the investigated path.

=Main features of risk analyses=
:Input:
Purpose
Consequences
Likelihood / Probabilities
Existing control features
Effectiveness of existing control features
Causes of risk
Sources of risk
Factors influencing any of the above
Interrelations / Interdependence
Type of risk
Information available
Risk criteria
:Output:
Combined Likelihood / probability
Consequences
Confidence in:
Information Uncertainty
Information Availability
Information Quality
Information Quantity
Ongoing relevance of information
Limitations
=Different models used when analysing risk=

=Benefits of analysing risk=
=How to develop a risk analysis=
=Reference=
ISO Guide 73-2009 – Risk Management Vocabulary
ISO 31000 - Risk management - Principles and guidelines
ISO 31010 - Risk management
International Journal of Project Management 32 (2014) - Vahid Khodakarami , Abdollah Abdi - Project cost risk analysis: A Bayesian networks approach for modelling dependencies between cost items

Risk analysis

2014-11-23T19:34:35Z

TigR: