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.
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.
@cite_14 @cite_25 @cite_7
2518473846 1972276999 1982139199 2113435553
Requirements Engineering (RE) has received much attention in research and practice due to its importance to software project success. Its interdisciplinary nature, the dependency to the customer, and its inherent uncertainty still render the discipline difficult to investigate. This results in a lack of empirical data. These are necessary, however, to demonstrate which practically relevant RE problems exist and to what extent they matter. Motivated by this situation, we initiated the Naming the Pain in Requirements Engineering (NaPiRE) initiative which constitutes a globally distributed, bi-yearly replicated family of surveys on the status quo and problems in practical RE. In this article, we report on the qualitative analysis of data obtained from 228 companies working in 10 countries in various domains and we reveal which contemporary problems practitioners encounter. To this end, we analyse 21 problems derived from the literature with respect to their relevance and criticality in dependency to their context, and we complement this picture with a cause-effect analysis showing the causes and effects surrounding the most critical problems. Our results give us a better understanding of which problems exist and how they manifest themselves in practical environments. Thus, we provide a first step to ground contributions to RE on empirical observations which, until now, were dominated by conventional wisdom only. 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. Practices in seven key areas from requirements engineering (RE) good practice guide are examined via in-depth interviews with ten Australian software development organisations. Our objective is to provide a better understanding of the relative perceived value of the RE practices investigated and to provide an initial assessment of the appropriateness of Sommerville and Sawyer's three classification levels. We used in-depth interviews as our main approach to collecting data. We assessed practices as either standardised use, normal use, used at the discretion of project manager or never used. We found that the single most standardised, or valuable, practice for 1) documentation, was making a business case of a project, for 2) elicitation, it was assessing system feasibility, 3) for analysis and negotiation, it was defining system boundaries, 4) for requirements description, it was to specify requirements quantitatively and to define standard templates for requirements, 5) for system modelling, it was to use a data dictionary, 6) for validation, it was to propose test cases, and 7) for management, it was to define a change management process. We suggest Sommerville and Sawyer's classification of basic, intermediate and advanced practices needs some reconsideration to bring his list into alignment with current industry practices. Research in requirements engineering has produced an extensive body of knowledge, but there are four areas in which the foundation of the discipline seems weak or obscure. This article shines some light in the “four dark corners,” exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements and engineering to be successfully completed.