Requirements elicitation interviews are the most commonly used technique for requirements elicitation. Through interviewing subject matter experts, facilitating deep discussions, and documenting findings, requirement analysts can uncover the true needs of the system to satisfy stakeholders’ needs. However, during these interviews, the analysts often have to divide their attention to asking the right questions, react appropriately to the stakeholder’s responses, and keep track of the information flow throughout the interview. This is a complicated process, during which analysts could make mistakes and miss important information. For these reasons, it could be useful for them to review their interviews to understand what information has been elicited and what has been missed, what they would need to ask as follow up, and what mistakes they have done during the process. To support these processes, we propose AnnoteREI, a tool that allows analysts to upload the recording of their interviews and create an editable transcript with speaker diarization. The tool offers many functionalities for different purposes: (1) students and novices can use it to identify and tag their mistakes, thus improving their skills by learning from their experience; (2) analysts can annotate any part of the transcript and tag it for later review. For example, they can label a section as a requirement or as a topic that requires more investigation, or a name mentioned by the interviewee as another stakeholder; and (3) researchers can use the tagging system to analyze and collect new data.

Abstract Requirements are elicited from the customer and other stakeholders through an iterative process of interviews, prototyping, and other interactive sessions. Then, requirements can be further extended, based on the analysis of the features of competing products available on the market. Understanding how this process takes place can help to identify the contribution of the different elicitation phases, thereby allowing requirements analysts to better distribute their resources. In this work, we empirically study in which way requirements get transformed from initial ideas into documented needs, and then evolve based on the inspiration coming from similar products. To this end, we select 30 subjects that act as requirements analysts, and we perform interview-based elicitation sessions with a fictional customer. After the sessions, the analysts produce a first set of requirements for the system. Then, they are required to search similar products in the app stores and extend the requirements, inspired by the identified apps. The requirements documented at each step are evaluated, to assess to which extent and in which way the initial idea evolved throughout the process. Our results show that only between 30% and 38% of the requirements produced after the interviews include content that can be fully traced to initial customer’s ideas. The rest of the content is dedicated to new requirements, and up to 21% of it belongs to completely novel topics. Furthermore, up to 42% of the requirements inspired by the app stores cover additional features compared to the ones identified after the interviews. The results empirically show that requirements are not elicited in strict sense, but actually co-created through interviews, with analysts playing a crucial role in the process. In addition, we show evidence that app store-inspired elicitation can be particularly beneficial to complete the requirements.

Requirements are elicited from the customer and other stakeholders through an iterative process of interviews, prototyping, and other interactive sessions. Many communication phenomena may emerge in these early iterations, that lead initial ideas to be transformed, renegotiated, or reframed. Understanding how this process takes place can help in solving possible communication issues as well as their consequences. In this work, we perform an exploratory study of descriptive nature to understand in which way requirements get transformed from initial ideas into documented needs. To this end, we select 30 subjects that act as requirements analysts, and we perform a set of elicitation sessions with a fictional customer. The customer is required to study a sample requirements document for a system beforehand and to answer the questions of the analysts about the system. After the elicitation sessions, the analysts produce user stories for the system. These are compared with the original ones by two researchers to assess to which extent and in which way the initial requirements evolved throughout the interactive sessions. Our results show that between 30% and 38% of the produced user stories include content that can be fully traced to the initial ones, while the rest of the content is dedicated to new requirements. We also show what types of requirements are introduced through the elicitation process, and how they vary depending on the analyst. Our work contributes to theory in requirements engineering, with empirically grounded, quantitative data, concerning the impact of elicitation activities with respect to initial ideas.

Teaching students problem-solving skills is the biggest challenge for many computing programs. Students often do not consider what questions they need to ask while designing a solution. This paper introduces how technical writing techniques and problem-solving strategies can be combined to help students find those questions and develop programming code through writing instructions and documenting their design process. Preliminary results indicate that this approach helps developing problem-solving skills and improves the student success rate in the first programming course.