Search

The article discusses the IEEE International Requirements Engineering Conference (RE). This issue contains an introduction of the best papers presented during the conference on requirements activities in the fields of systems and software engineering. The conference was held at the University of Paris 1-Pantheon Sorbonne.

Requirements engineering (RE) has attracted a great deal of attention from researchers and practitioners in recent years. Requirements engineering education (REE) is therefore an important undertaking if the field is to have professionals who are capable of successfully accomplishing software projects. This increasing interest demands that academia should provide software engineering students with a solid foundation in the subject matter. This paper aims to identify and to present the current research on REE that is available at present, and to select useful approaches and needs for future research. A systematic mapping study was therefore performed to classify the selected studies into five classification criteria: research type, empirical type, contribution type, RE activity, and curricula. A total of 79 papers were selected and classified according to these criteria. The results of this systematic mapping study are discussed, and a list of advice obtained from the REE literature for instructors is provided. [ABSTRACT FROM AUTHOR]

Model transformation is one of the basic principles of Model Driven Architecture. To build a software system, a sequence of transformations is performed, starting from requirements and ending with implementation. However, requirements are mostly in the form of text, but not a model that can be easily understood by computers; therefore, automated transformations from requirements to analysis models are not easy to achieve. The overall objective of this systematic review is to examine existing literature works that transform textual requirements into analysis models, highlight open issues, and provide suggestions on potential directions of future research. The systematic review led to the analysis of 20 primary studies (16 approaches) obtained after a carefully designed procedure for selecting papers published in journals and conferences from 1996 to 2008 and Software Engineering textbooks. A conceptual framework is designed to provide common concepts and terminology and to define a unified transformation process. This facilitates the comparison and evaluation of the reviewed papers. [ABSTRACT FROM AUTHOR]

Model transformation is one of the basic principles of Model Driven Architecture. To build a software system, a sequence of transformations is performed, starting from requirements and ending with implementation. However, requirements are mostly in the form of text, but not a model that can be easily understood by computers; therefore, automated transformations from requirements to analysis models are not easy to achieve. The overall objective of this systematic review is to examine existing literature works that transform textual requirements into analysis models, highlight open issues, and provide suggestions on potential directions of future research. The systematic review led to the analysis of 20 primary studies (16 approaches) obtained after a carefully designed procedure for selecting papers published in journals and conferences from 1996 to 2008 and Software Engineering textbooks. A conceptual framework is designed to provide common concepts and terminology and to define a unified transformation process. This facilitates the comparison and evaluation of the reviewed papers. [ABSTRACT FROM AUTHOR]

The article focuses on Requirements Engineering (RE) conference in the year 2004. It is noted that RE '04 theme is a requirement for design and innovation in a changing world and reflects both the increasingly critical environment. Three papers presented in the RE '04 conference include purchasing and integrating COTS software products based on interoperability requirement, importance of goals and scenarios, and security requirement.

The human context within which a software system will operate is fundamental for its requirements. It may not appear to be very much related to the system, but it is very relevant in achieving its successful adoption. However, requirements engineers have usually a background in Software Engineering and are not trained to elicit this kind of information. This situation raises the need for analytical tools to deal with these features. These tools should enable collaborative work between requirements engineers, who use them in development, social practitioners, who provide the knowledge and processes underlying these tools, and the customers, who know the domain and intended application of the projects. The framework presented in this paper is based on the socio-psychological Activity Theory and its analysis of human contexts. It includes a repository of social properties and a process to perform this elicitation using it. The paper illustrates its application through a case study on the impact of a new system in the organization of a firm. [ABSTRACT FROM AUTHOR]

This paper proposes an explicit definition of green software requirements and a tool to support their evaluation . The proposed evaluation tool describes the green efficiency by considering the energy consumption as the main aspect to be studied during the development stage. This approach consists of building a multiple regression model, by using a supervised learning algorithm, in order to reproduce the energy consumption pattern of devices at different workload circumstances. The energy consumption model is then deployed to estimate the impact of software applications based on their resource usage. Our work has been validated on desktop and mobile devices. The experiments show the effectiveness of the proposed energy profiling tool that provided relevant information on the energy consumption of software applications. [ABSTRACT FROM AUTHOR]

Large-scale software applications are complex systems that involve a myriad of different concerns. Ideally, these concerns should be organized into separated and different modules, but often some of these concerns overlap and crosscut each other. Such a situation is problematic, as concerns are tangled and scattered into different modules; thus, design and source code become difficult to produce and maintain. The Modularity community has been addressing crosscutting concerns by developing techniques based on separation of concerns. This separation must be done as early as possible during software construction to obtain a more modular and consequently better maintainable software, where evolution is performed with less effort and the possibility of introducing unforeseen mistakes is minimal. In this paper, we propose a strategy to identify crosscutting concerns at requirements level, i.e., at early stages in the software development process, by using the Language Extended Lexicon. [ABSTRACT FROM AUTHOR]

The desired principle of separation of concerns in software development can be jeopardized by the so-called crosscutting concerns, which tend to be scattered over (and tangled with) the functionality of the modular units of a system. The correct identification of such concerns (and their encapsulation into separate artifacts) is thereby considered a way to improve software understanding and evolution. Pursuing a proper management of concerns from the requirements engineering stage can greatly benefit the entire software life-cycle. In this paper, we propose conceptual guidelines on how to perform the identification of crosscutting concerns in the process of building requirements specifications. We argue that the identification must be carried out in an incremental way, to encapsulate apart the crosscutting concerns even if they have not emerged completely yet. [ABSTRACT FROM AUTHOR]

Requirements engineering is one of the most important areas of software engineering because it enables practitioners to determine the characteristics and constraints of the software to be developed. Therefore, the requirements elicitation process aims to obtain a preliminary version of the requirements before their specification, but it is difficult to know if the elicited requirements have the desired attributes (i.e., these requirements are complete, correct, consistent, etc.) due to the nature of this process. There are some measures that allow requirements engineers to quantify certain aspects of the requirements elicitation process and its final product (i.e., the preliminary version of the requirements, also known as preliminary requirements), but there is no way of measuring and controlling the quality of the elicited preliminary requirements. With the aim of understanding, evaluating, and improving the activities of the requirements elicitation process, some of the existing measures for this process were analyzed and, consequently, a case study was conducted to define and implement a measurement program with a set of eight measures that are proposed in this study. This program is based on the ISO/IEC/IEEE 15939:2017—systems and software engineering—measurement process, an international standard that establishes a common process and framework for the measurement of systems and software. The measurement program corresponds to a lightweight implementation of the standard in the context of a small-sized software organization (where the size of the software staff is 11–50 people, the size of projects is 50,000–100,000 LOC, and the time spent on the projects is six to twelve months) and the obtained results showed a preliminary positive influence when obtaining high-quality preliminary requirements. [ABSTRACT FROM AUTHOR]

The importance of prioritizing requirements stems from the fact that not all requirements can usually be met with available time and resource constraints. Efficient and trustworthy methods for prioritizing requirements are therefore in high demand. In this article, we present results of a systematic mapping study in order to appreciate the different considerations that have influenced prioritization of software requirements, identify the various types of artifacts proposed toward prioritizing software requirements, and examine certain characterizations of these artifacts. The results emphasize the heightened attention the domain of requirement prioritization has received in recent years. On the basis of this study, we are able to provide the following inferences regarding possible future research trajectories in software requirement prioritization artifacts: (1) focus on frameworks and tools; (2) emphasis on specialization; and (3) proposition of theory-based artifacts. Additional research possibilities are also pointed out at the end and are expected to stimulate further research on the topic. [ABSTRACT FROM AUTHOR]

Improving the quality of software demands quality controls since the very beginning of the development process, i.e., requirements capture and writing. Automating quality metrics may entail considerable savings, as opposed to tedious, manually performed evaluations. We present some indicators for measuring quality in textual requirements, as well as a tool that computes quality measures in a fully automated way. We want to emphasize that the final goal must be measure to improve. Reducing quality management to the acquisition of a numerical evaluation would crash against the strong opposition of requirements engineers themselves, who would not see in the measurement process the aid of a counselor, but a policeman mechanism of penalties. To avoid this, quality indicators must first of all point out concrete defects and provide suggestions for improvement. The final result will not only be an improvement in the quality of requirements, but also an improvement in the writing skills of requirements engineers. [ABSTRACT FROM AUTHOR]

Software products are usually developed for either a specific customer (bespoke) or a broader market (market-driven). Due to their characteristic, bespoke and market-driven development face different challenges, especially concerning requirements engineering. Many challenges are caused by an inadequate requirements engineering process, and hence there is a need for process improvement frameworks based on empirical research and industry needs. In a previous article we introduced Uni-REPM, a lightweight requirements engineering process assessment framework based on a review of empirically motivated practices in market-driven and bespoke requirements engineering literature. In this article, we validate this framework in academia as well as industry, in order to prepare Uni-REPM for widespread industry use. We conduct two validations; a static validation based on interviews with seven academic experts and a dynamic validation where Uni-REPM is applied in four industrial organisations. Uni-REPM is refined according to the feedback obtained in the validations. The study shows that Uni-REPM is a quick, simple, and cost-effective solution to assess the maturity level of the requirements engineering process of projects. Moreover, the assessment method using checklists is highly usable and applicable in various international development environments. [ABSTRACT FROM AUTHOR]

Software systems are becoming an integral part of everyday life influencing organizational and social activities. This aggravates the need for a socio-technical perspective for requirements engineering, which allows for modelling and analyzing the composition and interaction of hardware and software components with human and organizational actors. In this setting, alternative requirements models have to be evaluated and selected finding a right trade-off between the technical and social dimensions. To address this problem, we propose a tool-supported process of requirements analysis for socio-technical systems, which adopts planning techniques for exploring the space of requirements alternatives and a number of social criteria for their evaluation. We illustrate the proposed approach with the help of a case study, conducted within the context of an EU project. [ABSTRACT FROM AUTHOR]

A technique is presented for obtaining a specification from a requirement through a series of incremental steps. The starting point is a Problem Frame description, involving a decomposition of the environment into interconnected domains and a formal requirement on phenomena of those domains. In each step, the requirement is moved towards the machine, leaving behind a trail of “breadcrumbs”—partial domain descriptions representing assumptions about the behaviors of those domains. Eventually, the transformed requirement references only phenomena at the interface of the machine and can therefore serve as a specification. Each step is justified by a mechanically checkable implication, ensuring that, if the machine obeys the derived specification and the domain assumptions are valid, the requirement will hold. The technique is formalized in Alloy and demonstrated on two examples. [ABSTRACT FROM AUTHOR]