Background: The sensitivity of Requirements Engineering (RE) to the context makes it difficult to efficiently control problems therein, thus, hampering an effective risk management devoted to allow for early corrective or even preventive measures. Problem: There is still little empirical knowledge about context-specific RE phenomena which would be necessary for an effective context- sensitive risk management in RE. Goal: We propose and validate an evidence-based approach to assess risks in RE using cross-company data about problems, causes and effects. Research Method: We use survey data from 228 companies and build a probabilistic network that supports the forecast of context-specific RE phenomena. We implement this approach using spreadsheets to support a light-weight risk assessment. Results: Our results from an initial validation in 6 companies strengthen our confidence that the approach increases the awareness for individual risk factors in RE, and the feedback further allows for disseminating our approach into practice.
@cite_14: Risk analysis is traditionally considered a critical activity for the whole software system’s lifecycle. Risks are identified by considering technical aspects (e.g., failures of the system, unavailability of services, etc.) and handled by suitable countermeasures through a refined design. This, however, introduces the problem of reconsidering system requirements. In this paper, we propose a goal-oriented approach for analyzing risks during the requirements analysis phase. Risks are analyzed along with stakeholder interests, and then countermeasures are identified and introduced as part of the system’s requirements. This work extends the Tropos goal modeling formal framework proposing new concepts, qualitative reasoning techniques, and methodological procedures. The approach is based on a conceptual framework composed of three main layers: assets, events, and treatments. We use “loan origination process” case study to illustrate the proposal, and we present and discuss experimental results obtained from the case study.
@cite_25: Decision making in software engineering requires the consideration of risk information. The reliability of risk information is strongly influenced by the underlying risk estimation process which consists of the steps risk identification, risk analysis and risk prioritization. In this paper we present a novel risk estimation tool for software engineering pruposes called RisCal. RisCal is based on a generic risk model and supports the integration of manually and automatically determined metrics into the risk estimation. This makes the tool applicable for arbitrary software engineering activities like risk-based testing or release planning. We show how RisCal supports risk identification, analysis and prioritizations, provide an estimation example, and discuss its application to risk-based testing and release planning.
@cite_7: The worst thing that can happen in requirements engineering is that your set of requirements, however expressed, doesn't accurately represent your users' needs and consequently leads your team down the wrong development path. The whole point of requirements engineering is to steer your development toward producing the right software. If you don't get the requirements right, how well you execute the rest of the project doesn't matter because it will fail. The article looks at how we can be led astray.
In fact, most work on risk management in the context of requirements engineering focuses on identifying risks in a bottom-up approach and analysing risks during the requirements engineering process. For instance, @cite_14 provide a goal-driven approach for risk assessment in requirements engineering, and @cite_25 provide an estimation approach and respective tool support @cite_25 . For risk management within requirements engineering itself, @cite_7 provide a list of top risks in requirements engineering, which includes overlooking a crucial requirement, inadequate customer representation, modelling only functional requirements, not inspecting requirements, attempting to perfect requirements before beginning construction as well as representing requirements in the form of designs. However, evidence-based approaches to risk management in requirements engineering as proposed in this paper are so far not available. For such an approach, we need a proper empirical basis on requirements engineering which has been recently established by the NaPiRE (Naming the Pain in Requirements Engineering) initiative.