Background: A previously proposed Design Thinking-based Requirements Elicitation Process distinguishes between internal and external empathy as distinct sub-activities. To corroborate the effectiveness of this distinction, empirical validation is required. Objective: The main goal of this paper is to present a quasi-experiment carried out with the aim of comparing the use of the Vision Canvas technique for internal empathy and the Empathy Map technique for external empathy in requirements elicitation, assessing whether and how these techniques enhance stakeholder and requirements identification during Brainstorming sessions. Method: The quasi-experiment involved 138 undergraduate Computer Engineering students at University of Sevilla. Three treatments were considered: a combination of both techniques (Vision Canvas followed by Empathy Maps), Empathy Maps alone, and a control group relying solely on Brainstorming. Results: The results revealed an improvement in stakeholder identification using empathy-based techniques, with statistically significant differences observed when these techniques were applied in combination. Additionally, the analysis showed an increase in the number of requirements ideas generated with either technique, compared to the control group. Conclusions: While these findings support the distinction between internal and external empathy in requirements elicitation, further research is necessary to determine the optimal application of these techniques across different contexts.

This article presents a proposal for validating a requirements elicitation process based on Design Thinking (PRO-RE-DT) using action research. The action research method was selected based on evidence of similar uses in software engineering, its iterative nature, and primarily for the active role of the researcher, which we consider.

Abstract Background: Agile Software Development is widely used nowadays and to measure its real usage we need to analyze how its practices are used. These practices have been categorized by several authors and some practitioners have suggested that technical practices have a lower usage level than organizational practices. Objective: In this study we aim to understand the actual usage of technical and organizational agile practices in the Latin-American Agile community. Method: We conducted a three-stage survey in conferences of the Latin-American Agile Community. Results: Organizational practices are much more used than technical ones. The number of practices used is a direct function of organization experience using agile. The difference between technical and organizational practices reduces with the experience of the organization using agile. Team size and project duration seem to have no effect in the number of practices used.

Estimating the size of a software system is a critical task due to the implications the estimation has in the management of the development project. There are some widely accepted estimation techniques: Function Points, Use Case Points and Cosmic Points, but these techniques can only be applied after the availability of a requirements specification. In this paper, we propose an approach to estimate the size of an application previous to its requirements specification by using the application language itself, captured by the Language Extended Lexicon (LEL). Our approach is based on Use Case Points and on a technique which derives Use Cases from the LEL. The proposed approach provides a measure of the application's size earlier than the usual techniques, thus reducing the effort needed to apply them. An initial experiment was conducted to evaluate the proposal.

Context-Aware Software Systems adapt their response to the execution context. Therefore, context information processing is fundamental, since it determines the behavior of the application. Thus, a mechanism for the collection, representation and validation of context information should be provided. In this paper, an extension of Loucopoulos' requirements engineering process incorporating context information processing is presented. Two real-world study cases from the home and building automation fields of application are presented.

Scenarios are well recognized as an important strategy towards understanding the interface between the environment and the system, as well as a means to elicit and specify software behavior. We have a broader understanding of scenarios: for us, a scenario is an evolving description of situations in the environment. Our proposal is framed by Leite's (1995) work on a client-oriented requirements baseline, which aims at modeling the external requirements of a software system and its evolution. Scenarios start by describing the environmental situation, according to the main actions performed outside the software system. Scenarios also help the clarification of the interrelation between functional and non-functional requirements. We have validated our strategy and related representations based on case studies of a real situation.