In Requirements Engineering, requirements elicitation aims the acquisition of information from the stakeholders of a system-to-be. An important task during elicitation is to identify and render explicit the stakeholders' implicit assumptions about the system-to-be and its environment. Purpose of doing so is to identify omissions in, and conflicts between requirements. This paper o?ers a conceptual framework for the identi?cation and documentation of default requirements that stakeholders may be using. The framework is relevant for practice, as it forms a check-list for types of questions to use during elicitation. An empirical validation is described, and guidelines for elicitation are drawn.
In their seminal paper on the four dark corners of RE, Zave and Jackson established a core ontology for RE, which describes the important concepts to be accounted for in RE @cite_16 . Doing so, they suggest that information about domain assumptions, requirements and specifications of the system-to-be must be collected, documented and analysed in order for RE to be successful. broaden this ontology by suggesting that any communicated information is relevant to consider as part of requirements problem @cite_14 . In other words, any information that is explicitely adressed to the engineer is relevant to consider . The present paper argues that both explicit implicit information are relevant to consider.
@cite_14 @cite_16
2148347120 2518473846 2113435553 1982139199
In their seminal paper ACM T. Softw. Eng. Methodol., 61 1997, 1--30, Zave and Jackson established a core ontology for Requirements Engineering RE and used it to formulate the “requirements problem”, thereby defining what it means to successfully complete RE. Starting from the premise that the stakeholders of the system-to-be communicate to the software engineer the information needed to perform RE, Zave and Jackson's ontology is shown to be incomplete, in that it does not cover all classes of basic concerns --namely, the beliefs, desires, intentions, and evaluations --that the stakeholders communicate. In response, we provide a new core ontology for requirements that covers these classes of basic stakeholder concerns. The proposed new core ontology leads to a new formulation of the requirements problem. We thereby establish a new framework for the information that needs to be elicited over the course of RE and new criteria for determining whether an RE problem has been successfully addressed. 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. 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. 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.