Integrating risk management activities into requirements engineering

Islam, Shareeful; Houmb, Siv Hilde

doi:10.1109/rcis.2010.5507389

Cited by 41 publications

(28 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Our studies results also agreed with this conclusion [IHMFJ09,IH10]. Therefore, the plan risk management task enforces the development team to consider a complete risk management process during requirements engineering so that risk assessment and management are formally integrated during the development.…”

Section: Plan Risk Managementsupporting

confidence: 86%

“…We define the activities, tasks, steps and underlying roles for a detailed goal-driven risk management process model [IH10,IH11]. We follow an artifact oriented view by considering the content and associated concept of the individual artifact as work product of the risk management activities.…”

Section: Systematic Risk Assessment and Management During Requirementmentioning

confidence: 99%

“…We have observed through the case studies [Isl09,IHMFJ09], that a requirement engineer is capable to contribute in risk management activities. In real project situation, for small or medium size project, there may not be any risk manager due to budget constraints [Isl09,IHMFJ09,IH10]. Project manager is concerned with the overall project execution and takes the additional role as risk manager.…”

Section: Integration Of Gsrm Into Requirements Engineeringmentioning

confidence: 99%

See 2 more Smart Citations

Software development risk management model

Islam

2009

Proceedings of the Doctoral Symposium for ESEC/FSE on Doctoral Symposium

Self Cite

View full text Add to dashboard Cite

Every software project by its inherent nature is unique and contains significant numbers of uncertainties from various perspectives such as time-to-market, budget and schedule estimation, product deployment or maintenance. If failing to control these uncertainties, it imposes potential risks not only during the development phases but also throughout the life cycle of the product. Software risk management is an effective tool to control these risks and contributes to increase the likelihood of project success. Risk management needs to be integrated as early as possible from a holistic perspective into the development. However a comprehensive risk management practice is not always possible due to resource problems, more emphasize on budget and schedule constraints and difficulties to concretely estimate the benefit of risk management.This thesis proposes a Goal-driven Software Development Risk Management Model (GSRM) that explicitly integrates into the requirements engineering phase. The integration provides an early warning of potential problems so that both preventive and corrective actions can be undertaken to avoid the causes of project failure. The framework is comprised of four layers, i.e., goal, obstacle, assessment and treatment, that support the identification, assessment, treatment and documentation of risks in relation to project-specific goals. GSRM is implemented in active on-going software development projects to empirically evaluate its usefulness, particular advantages and limitations in an industrial context. The results show that goaldriven approach is suitable for risk management and risk management is well integrated into requirements engineering phase. It is not always necessary to rank budget and schedule related goals and risk factors at the highest priority for risk management. At the early stage of the project risk factors related to estimation, project management, project scope, requirements, change management and human (i.e. customer/user and practitioner) and at the later stage risk factors related to user satisfaction and product usage are more frequent and severely affect meeting the project goals. If project risk factors are beyond the control of a project manager and project development environment, it is difficult to control the risks. The results conclude that early risk management practice is necessary and GSRM contributes to this direction for a successful project outcome. ZusammenfassungJedes Software-Entwicklungsprojekt ist einzigartig und geprägt von schwer planbaren Einflussfaktoren, wie time-to-market oder Budget, aber auch von Einflüssen resultierend aus der Integration und der Wartung. Die Beherrschung dieser Einflussgrößen ist unabdingbar für die Minimierung der Risiken während der Entwicklung als auch während des gesamtem Software-Lebenszyklus.

show abstract

Section: Plan Risk Managementsupporting

confidence: 86%

Section: Systematic Risk Assessment and Management During Requirementmentioning

confidence: 99%

Section: Integration Of Gsrm Into Requirements Engineeringmentioning

confidence: 99%

See 1 more Smart Citation

Software development risk management model

Islam

2009

Proceedings of the Doctoral Symposium for ESEC/FSE on Doctoral Symposium

Self Cite

View full text Add to dashboard Cite

show abstract

“…For example, the approach in [11] advocates the early and explicit consideration of risks as part of RE goal modeling. Although certain risk factors (e.g., an unknown budget) may motivate the presence of model uncertainty, our framework is not explicitly intended to capture these risks.…”

Section: Related Workmentioning

confidence: 99%

Managing requirements uncertainty with partial models

et al. 2013

View full text Add to dashboard Cite

Abstract-Models are good at expressing information that is known but do not typically have support for representing what information a modeler does not know at a particular phase in the software development process. Partial models address this by being able to precisely represent uncertainty about model content. In previous work, we developed a general approach for defining partial models and applied it to capturing uncertainty, including reasoning over design models containing uncertainty. In this paper, we show how to apply our approach to managing requirements uncertainty. In particular, we address the problem of specifying uncertainty within a requirements model, refining a model as uncertainty reduces and reasoning with traceability relations between models containing uncertainty. We illustrate our approach using the meeting scheduler example.

show abstract

“…[25,39,64,71], model not only intentional uses but also [67] Attack Graphs [54] CORAS [14] Goal-Risk Model [10] GSRM [39] Requirements misuses of system components. However, eliciting information on intentional uses and misuses requires expertise of stakeholders with different backgrounds.…”

Section: Related Workmentioning

confidence: 99%

IT architecture-based confidentiality risk assessment in networks of organizations

Morali¹

View full text Add to dashboard Cite

Integrating risk management activities into requirements engineering

Cited by 41 publications

References 15 publications

Software development risk management model

Software development risk management model

Managing requirements uncertainty with partial models

IT architecture-based confidentiality risk assessment in networks of organizations

Contact Info

Product

Resources

About