Risk Analysis for Collaborative Systems during Requirements Engineering (S)

Kolluri, Kirthy

doi:10.18293/seke2021-192

Cited by 2 publications

(8 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Hence, we use the term Collaborative system for all the systems to which the Reference model is applicable. We adopt work involving the Reference Model [6,7] and transform it into Augmented Reference Model [19].…”

Section: Related Workmentioning

confidence: 99%

“…3, by the systematic generation of risks. For this, we use the Augmented Reference Model from our previous work [19] and extend it by adding multiple rules for extensive risk generation and devising risk mitigation strategies for the risks identified. As a part of the risk analysis process, we follow these steps to generate the RAG:…”

Section: Generation Of Risk Analysis Graphmentioning

confidence: 99%

“…Step 1 and 2: For this work, we assume that the requirement, specification, and domain are of the form i → t. We use the antecedent (i) part and the consequent (t) part to identify risks by applying rules for systematic risk generation. We use a part of the initial process (Steps 1 and 2) discussed in our previous work [19] for generation of RAG.…”

Section: ) Acquiring the Requirement Specification And Domain 2) Deco...mentioning

confidence: 99%

“…Step 3: We have discussed some rules in our previous work [19], and we extend them by adding more rules for systematic risk generation. Rules are applied to the decomposed require-ment, specification and domain that are obtained using the augmentation process explained in our previous work [19]. the reversal and negation of both i and t in i → t. It is read as if not t then not i.…”

Section: ) Acquiring the Requirement Specification And Domain 2) Deco...mentioning

confidence: 99%

“…This paper proposes Murphy, a framework for performing risk identification and analysis using an activity-oriented and ontology-based approach for collaborative systems. Our previous work [19], which extends the Reference Model [6,7] with risks to obtain the Augmented Reference Model, is extended by adding more rules for systematic risk identification. We also introduce a highly activity-oriented ontology, a domain-specific ontology, and constraints on agent's actions which can be used to come up with risks when violated.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Identifying Risks for Collaborative Systems during Requirements Engineering: An Ontology-Based Approach

Kolluri¹,

Ahn²,

Hill³

et al. 2022

Proceedings of the 34th International Conference on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

A risk is an undesirable event that can result in mishaps if not identified early on during requirements engineering adequately. However, identifying risks can be challenging, and requirements engineers may not always be aware if risks are ignored. In this paper, we present Murphy -a framework for performing risk analysis. Murphy adopts the Reference Model, in which requirements are supposed to be met not by the projected software system behavior alone but through collaboration between the system and events occurring in its environment, hence the term Collaborative System. Murphy provides risk analysis facilities that include an activity-oriented ontology for carrying out risk analysis by systematically identifying risky activities in the system and in the environment, thereby obtaining a Risk Analysis Graph (RAG) and towards devising risk mitigation strategies later. In order to see both the strengths and weaknesses of Murphy, we experimented on developing a smartphone app involving a group of Ph.D. and senior-level graduate students -one group using Murphy and the other not using Murphy. Our observation, we feel, shows that the risks identified by the group using Murphy were able to identify more critical risks and those risks were comprehensive and relevant as. well. The results also showed that incorporating risk mitigation strategies for the risks identified can indeed help avoid them to some extent.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Generation Of Risk Analysis Graphmentioning

confidence: 99%

Section: ) Acquiring the Requirement Specification And Domain 2) Deco...mentioning

confidence: 99%

Section: ) Acquiring the Requirement Specification And Domain 2) Deco...mentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Identifying Risks for Collaborative Systems during Requirements Engineering: An Ontology-Based Approach

Kolluri¹,

Ahn²,

Hill³

et al. 2022

Proceedings of the 34th International Conference on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

show abstract

Identifying Risks and Risk Mitigation Strategies for Collaborative Systems during Requirements Engineering: A Goal-Oriented Approach (S)

Kolluri,

Hill,

Chung

2023

International Conferences on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

If risks are not identified, they are unlikely to be addressed, possibly resulting in undesirable consequences, such as fatal accidents or even loss of human lives. Furthermore, risks should be considered not only in terms of system behavior but also events occurring in the system environment -i.e., in a collaborative setting in which the system and its environment work together towards certain goals the system is intended to help achieve. In this paper, we present a goal-oriented risk analysis framework, Murphy+G, in which non-functional requirements (hereafter, NFRs) are treated as softgoals to be achieved and systematically addressed in terms of both the system and its environment during requirements engineering, by adopting what is called the Reference Model. A study of a smartphone app, Theia, which is intended to help blind people navigate indoors, is used for the purpose of both illustration and experimentation. In this study, NFRs (e.g., safety, reliability, timeliness, etc.) are treated as softgoals, and risks (e.g., fall down, injury, etc.) are identified, along with risk-mitigation strategies for both the system and its environment, with the help of an activity-oriented ontology. To see both the strengths and weaknesses of Murphy+G, a systematic methodology for risk analysis for collaborative systems, a controlled experiment has been carried out, in terms of three different versions of Theia implementations. Feedback from students show improvements on the accuracy of the risk analysis and the risk mitigation strategies devised, as well as enhanced users' experience with respect to increased confidence in navigating indoors, in a safe, timely, and reliable manner.

show abstract

Risk Analysis for Collaborative Systems during Requirements Engineering (S)

Cited by 2 publications

References 10 publications

Identifying Risks for Collaborative Systems during Requirements Engineering: An Ontology-Based Approach

Identifying Risks for Collaborative Systems during Requirements Engineering: An Ontology-Based Approach

Identifying Risks and Risk Mitigation Strategies for Collaborative Systems during Requirements Engineering: A Goal-Oriented Approach (S)

Contact Info

Product

Resources

About