1,721,001 research outputs found
REFSQ 2019: Joint proceedings of workshops, industrial track, doctoral symposium, live studies, and posters and tools track
No full textREFSQ 2018: Joint proceedings of workshops, doctoral symposium, live studies, and posters and tools track
No full textBias-aware guidelines and fairness-preserving Taxonomy in software engineering education
No full textThis innovative practice work in progress paper tackles the problem of unfairness and bias in software, that recently has emerged in countless cases. This unfairness can be present in the way software makes its decision or can limit the software functionalities to work only with certain populations. Well-known examples of this problem are the Microsoft Kinect facial recognition algorithm, which does not work properly with darker skin players, and the software used in 2016 by Amazon.com to determine the parts of the United States to which offer free same-day delivery that made decisions that prevented minority neighborhoods from participating in the program. The reasons behind these phenomena have often roots in the fact that software is created by humans who are biased and live in biased and non-inclusive environments. Recent research from the software engineering community is starting to tackle this problem at many levels from requirements analysis to the new automatic fairness testing technique (proposed first at FSE 2017 conference). However, research in bias of software is still a very undervalued and rarely discussed problem as software is often seen as a product immune to bias and non-inclusivity. This problem will be not addressed unless software engineering educators start to include this notion as a first-class problem in their foundation courses to future generation of scholars. In this work, we propose a set of bias-aware guidelines and taxonomy on how to flesh out this problem and possible solutions to it in software engineering curricula
On including the institutional review board process in undergraduate information technology curricula
No full textThis lightning talk discusses the institutional review board (IRB) and the Information Technology (IT) education community aiming to a) illuminate the benefits that our IT students and community can gain from the IRB process and b) have a general discussion of the role the IRB process should have in IT curricula and specific IT courses
Are requirements engineering courses covering what industry needs? a preliminary analysis of the United States situation
No full textIn the United States, only few undergraduate curricula for computing-related field majors have an entire course dedicated to requirements engineering (RE). Usually, these are the bachelors of science in software engineering (BS SWE), while bachelors of science in computer science (BS CS) cover the topic during an overview course on software engineering, and dedicate only a couple of weeks to RE. Recent studies have shown that companies have specific demands for the competences that requirements engineers should have, and often such competences, such as analytical thinking and communication skills, are not sufficiently covered by RE textbooks and courses. However, no systematic analysis has been performed on the actual content of RE-related courses. In this paper, we survey what is taught in academia in RE-related courses. Our analysis is based on the data collected from more than 40 universities in the United States that offer a BS SWE. We show potential misalignments between what is offered by courses and industry needs, and we propose a research plan to further investigate this situation and to develop possible remedies for it
COVER: Change-based goal verifier and reasoner
No full textCOVER is a unified framework that supports the interplay between requirements analysts and software developers. It contracts a bridge between the requirements analyst's and the software developer's artifacts by enabling goal model analysis during software design. The goal model produced by the requirements analyst is kept alive and updated while the system is designed. Whenever the design of the system changes, COVER verifies the new design against the requirements of interest. The verification results are used to trigger a goal model analysis procedure. The results of this analysis can be used by the requirements analyst and the software developer to update the goal model or the design of the system. In this paper, we present the tool support developed for COVER
Empowering requirements elicitation for populations with special needs by using virtual reality
No full textRequirements elicitation is the process of discovering requirements for a system by accessing available knowledge sources and communicating with stakeholders who have a direct or indirect influence on such requirements. Although requirements elicitation is by no means a new concept and many techniques are available for this activity (e.g., interviews, observations, focus groups, questionnaires), there is no silver bullet which guarantees collecting a set of complete and correct requirements. When software is being developed for a special needs population, individuals with mental or physical impairments, the task becomes even tougher. In this scenario, techniques other than the traditional ones must be used to support the elicitation process. To ease the task of collecting requirements from special needs populations, we propose the use of Virtual Reality (VR) environments as elicitation technique. Our research is not to propose that VR is the silver bullet for collection of requirements; however, VR can definitely complement other elicitation techniques to develop a complete set of requirements specification. The following proposal explains the benefits of VR, why it can be useful with elicitation activities, how it can benefit special needs population, and what it can contribute towards the requirements process
Measuring Team Members' Contributions in Software Engineering Projects using Git-driven Technology
No full textSoftware engineering is inherently a human-centric and collaborative process and this reflects in its teaching programs, as most of the courses comprise projects and team efforts. In order to fairly evaluate students, there is the problem of quantifying the amount of work contributed to the team development project by each of its members. Most commonly, in order to estimates student contributions, instructors use arbitrary and subjective judgment derived from observations and evaluations. The currently used process is not a complete picture and is time consuming since it requires numerous observations and extensive paperwork's review. Emerging decentralized systems (such as git) and their widespread applications in all realms of development which capitalize on team-aware metrics, are worthwhile and can provide a solution to the problem. In this work we support a solution that utilizes git-driven technology, and its related features, to measure a team member's contributions objectively, based not only upon the completion of the project, but also at any time during progression development. Such performance assessment could generate more productive team-based learning with higher-quality graduates for better meeting software industry's expectations
Requirements Elicitation: A Look at the Future Through the Lenses of the Past
No full textRequirements elicitation is the initial step of the requirements engineering process and aims at gathering all the relevant requirements through the direct or indirect interactions between requirements analysts and stakeholders. Even if the requirements elicitation problem is not new and has been approached many times over the years, it is still considered one of the most challenging of the requirements engineering process. In the proposed presentation, we aim at analyzing the journey of the research on requirements elicitation through the 25 years of the Requirements Engineering conference not only by considering the different proposed approaches and their evolution, but also by evaluating the role of requirements elicitation in the conference. Moreover, we will present the lessons learnt during this analysis and will use them as a starting point to present the current trends and outline possible future directions
Learning from mistakes: An empirical study of elicitation interviews performed by novices
Full text link© 2018 IEEE. [Context] Interviews are the most widely used elicitation technique in requirements engineering. However, conducting effective requirements elicitation interviews is challenging, due to the combination of technical and soft skills that requirements analysts often acquire after a long period of professional practice. Empirical evidence about training the novices on conducting effective requirements elicitation interviews is scarce. [Objectives] We present a list of most common mistakes that novices make in requirements elicitation interviews. The objective is to assist the educators in teaching interviewing skills to student analysts. [Re-search Method] We conducted an empirical study involving role-playing and authentic assessment with 110 students, teamed up in 28 groups, to conduct interviews with a customer. One re-searcher made observation notes during the interview while two researchers reviewed the recordings. We qualitatively analyzed the data to identify the themes and classify the mistakes. [Results and conclusion] We identified 34 unique mistakes classified into 7 high level themes. We also give examples of the mistakes made by the novices in each theme, to assist the educationists and trainers. Our research design is a novel combination of well-known pedagogical approaches described in sufficient details to make it re-peatable for future requirements engineering education and training research
- …
