Philanthropic conference-based requirements engineering in time of pandemic and beyond

We live in an age where software is ubiquitous, crowdsourcing has become common practice, and the global sharing economies and online shopping are replacing traditional establishments—from taxicabs to hotels to brick and mortar stores. Digitization (e.g., AI, cloud computing) is making its way into every aspect of our lives, and society is moving into a different era as a result.

With software becoming such an integral part of society, we wondered if society should not become a more integral part of software engineering. As a concrete manifestation thereof, we wondered if it should become a larger part of our activities as scholars participating in conferences.

Software engineering for social good is an area receiving growing interest in recent years. Our approach of philanthropic projects in RE follows the vision of Software Engineering for “Social Good” presented in [1]: “Software is increasingly seen as a way to promote positive social change: this includes initiatives such as Code for America and events such as hackathons, which strive to build innovative software solutions with a social conscience” ([1], p. 1). Our focus is on small-scale software that is developed for meeting specific community needs where communities and requirements engineers work together. In our effort, we emphasize the RE aspect and our scope spans from requirements elicitation to prototype development.

The software engineering community has already realized the importance of addressing human values and promoting social good objectives in software development, for example, for mitigating user dissatisfaction and negative socioeconomic impact [2]. Engineering these values in software, however, requires technical and methodological support throughout the development lifecycle, starting with requirements engineering. However, we found no reports on how to create social contributions using the platform offered by SE conferences, except for our RE Cares experience which focuses on the RE phase of the SE lifecycle [3, 4].

The Requirements Engineering (RE) research community has an opportunity to apply its expertise and talents to addressing a need of a deserving, socially conscious organization in the locale of a given RE conference. The idea is simple. RE conferences gather the cream of the crop among RE researchers and practitioners. Our community—academics, students, industry researchers, and practitioners—jointly possess an enormous intellectual capacity: the knowledge of how to identify and specify software requirements and accordingly build software properly, and the ability to do so. RE conferences gather and concentrate this capacity at a single location. With this vision in mind, we organized a series of events called Requirements Engineering Cares (RE Cares) as part of the IEEE Requirements Engineering Conference in the years 2018–2021 [3, 4]. RE Cares is the way to direct this capacity toward helping local stakeholders who otherwise would never have had access to RE and software design experts of similar caliber.

This effort is aligned with the declared objectives of the United Nations (UN) to address issues that transcend national boundaries and promote economic and social progress,^{Footnote 1} bringing together stakeholders and RE experts from around the globe to cope with issues faced in specific locations but representing general challenges of humanity.

Our vision for using academic (RE) conferences to give back to the community hosting them, the RE Cares initiative, was inspired by experiences at our individual universities, such as capstone projects with societal impact, student organization projects assisting society (e.g., addressing homelessness, food waste), as well as “coding for good” endeavors and social software engineering [1]. Launched at RE 2018 by a group of requirements engineering (RE) researchers, the inaugural event resulted in the development of a communication application named Crier.^{Footnote 2} Crier was developed to support emergency field activity for Mutual Aid Alberta, a nonprofit organization coordinating natural disaster responses in the Canadian province [3]. The next RE Cares event in 2019 took place in Jeju Island in South Korea and resulted in a mobile public transportation application named Gochi-Gochi.^{Footnote 3} This application was designed to support people with mobility impairment, in seeking appropriate transport means while traveling in the Island [4].

In the RE Cares events, the stakeholders benefited from the elicited requirements, design, and other artifacts as well as the information gathered and knowledge gained from the conference work and from a small prototype of their desired product. In RE Cares 2018 and 2019, the activity before and after the conference was virtual, using virtual meeting tools, while the main effort was concentrated in the physical meeting at the conference, in which the stakeholders, RE experts, and students participated. Over the duration of the conference, the requirements specification was finalized, the system was designed, and a prototype was accordingly developed in a hackathon. In 2020, as the pandemic hit, the RE conference took place in a hybrid mode as did the RE Cares event. In 2021 the conference was fully virtual, however we decided, with the permission of the conference chair, to keep RE Cares in a hybrid mode.

In this paper, we extend our vision for philanthropic conference-based projects in requirements engineering—starting with overarching goals and continued with a detailed discussion and framework for conducting similar social contributions in any SE conference in general—going beyond our vision developed prior to the pandemic [3, 4].

We share the experiences of running RE Cares events, in both physical and hybrid modes, with each event addressing a different social challenge. We discuss the successes we had, the challenges we faced, and the lessons we learned. We further analyze the different manners in which we ran these projects, before and during the pandemic and the social distance it demanded. While starting as a necessity, the pandemic has provided us with the opportunity to apply different practices and processes, some of which proved useful and contributed beyond their compensation for the social distance constraint.

We believe that while our experience is based on RE practices, such an initiative can be applicable to the entire cycle of SE, as discussed in [4]. In fact, the most recent RE Cares, held in 2021, continued to a full-scale development of the initiated project in an academic course led by one of RE Cares participants. Moreover, since RE is the initial activity of any SE development, other SE activities along the SE lifecycle can benefit from our experience.

The rest of the paper is structured as follows. Section 2 reviews past work promoting social good in software engineering. Section 3 presents brief descriptions of the RE approaches and methods used during the RE Cares events. Section 4 presents the generic process of the RE Cares series. Section 5 describes the previous RE Cares events—before and during the pandemic—discusses lessons learned and the future of this event following the accumulated experience. Section 6 concludes.

Specific methodologies were proposed for addressing social software engineering. One such example is Speedplay, a method combining elements of agile, iterative development, allowing quick development with limited resources, with principles drawn from action research and participatory design, promoting a proper understanding of the social context and vulnerable user populations [1].

A recent literature review, focusing on social innovation projects, found that research thus far lacks evidence on how social innovative processes occur and what are the methods and tools used throughout such projects, from ideation to implementation and scalability [5]. Moreover, while human values are crucial when designing software products, because these products are developed and used by humans [6, 7], there are only a few studies that address human values in SE [8]. There are even fewer studies that address human values continually throughout software development [9].

The RE Cares initiative operates for promoting social values via software engineering, with an emphasis on requirements engineering. Using the settings of an academic conference, RE Cares promotes a social objective in the locale of the conference each year, thereby raising awareness of different social needs and a sense of social responsibility within the RE community. RE Cares further serves as an educational opportunity, as it involves the participation of software engineering students in the RE and design processes and the hackathon [3, 4].

Given the focus on social values, which requires deep understanding of human values, needs, and barriers, RE Cares seeks to create an innovative solution leveraging human-centered and creative methods. To this end, the RE Cares team selected and applied the existing approaches and methods for this objective, including task-oriented requirements engineering [10], design thinking [11, 12], creativity [13], and multidisciplinary teams.

When planning RE Cares, we selected and adapted known RE methods and techniques that RE Cares organizers were familiar with and had experience in implementing them. The selected RE methods focus on problem and solution space and stakeholders, enable iterative work, and support creativity and multi-disciplinarity. Adapting RE methods for a specific project situation is a well-known practice: each project is different and therefore engineering methods need to be adapted, transformed, or enhanced to satisfy the specific context [14]. While the methods we selected worked well in RE Cares, other methods that support creativity and multi-disciplinarity can also be adapted.

Our main goals in selecting and combining methods for RE Cares were to promote interest, engagement, and creative thinking in order to motivate conference participants and students to volunteer and contribute to the RE Cares efforts and outcomes. We therefore selected three state-of-the-art techniques that are known to promote engagement and out of the box thinking: task-oriented RE, design thinking, creativity methods, and combined them with the multidisciplinary team approach, involving participants from art design and technology schools. These are all briefly described below. A detailed description of the applications of these methods in RE Cares 2018 and 2019 can be found in [3, 4], respectively.

3.1 Task-oriented requirements engineering

Task-oriented requirements engineering (TORE) is a framework to guide the elicitation process. Its initial version [10] was inspired by the task approach of Lauesen [15]. In contrast to use cases or user stories, it initially focuses on the user task and not on the support by the software. The requirements engineer elicits and describes the current work of the users as well as the problems which should be solved by the software. In the next step, ideas are generated and described for the support of the user tasks and their problems by the software and then are refined into detailed requirements. TORE extends this idea to a framework of 18 mutually dependent decisions that need to be made but does not prescribe specific documentation templates or the order of the decisions [16]. The decision points should address: supported stakeholders, stakeholder goals, and user tasks on the goal and task level through as-is- and to-be activities; domain data and system responsibilities on the domain level; system functions; interaction data, interactions, and user interface structure on the interaction level to dialogues; support and navigation functions; user interface data; screen design; architecture; internal actions; and data on the system level. This framework can be easily adapted to different kinds of projects and domains such as social network applications or ambient assisted living. In the context of the Fraunhofer IESE in Germany [16], it is continuously applied and evolved in industry projects.

The emphasis on the users and their tasks is essential in TORE as this provides the context for the whole requirements engineering. Requirements engineers and developers are guided to focus on the user, not the software system. Therefore, TORE can be well integrated with approaches such as user-centered design or design thinking. As a complement to these approaches, TORE provides guidance on which decisions to document for later use in the development, operation, and maintenance of the software system and how to relate software-related decisions to the users and their tasks.

3.2 Design thinking (DT)

Design thinking (DT) is a development methodology for learning the problem space, in a way that emphasizes building empathy with users by understanding their functional as well as emotional needs [11]. The DT methodology involves three perspectives: (1) mindset, (2) process, and (3) toolbox [12]. From the mindset perspective, DT exhibits a combination of divergent and convergent thinking, a strong orientation toward both explicit and implicit needs of customers and users, and prototyping. Multiple prototyping iteration cycles are needed to test, refine, and further elaborate on the idea to reduce uncertainty [11]. From the process perspective, DT combines both a micro-process and a macro-process. The micro-process consists of defining the problem, finding and synthesizing needs, generating ideas, prototyping, testing, and targeting for innovation. The macro-process consists of managing milestones while developing prototypes that fulfill the defined requirements. From the toolbox perspective, DT refers to the application of numerous methods and techniques taken from the design, engineering, informatics, and psychology disciplines [11].

Empathy is essential when practicing DT. Indeed, empathy-driven design differs from other user-centered design techniques in that all stakeholders are genuinely engaged and involved in the development of solutions that best fit their needs [12]. To determine user needs, the persona description tool (see Fig. 1) is often used to analyze conversations with stakeholders, especially end-users [11]. The real or imagined user persona is then further described using the four categories of the empathy map (see Fig. 2): Says (quotes and main terms), does/hears/sees (observed behaviors), thinks (assumed thoughts), and feels (assumed feelings). The sheet allows also to detail the persona's goals and opportunities, pain points, and barriers as well as the needed value. Additional DT methods include defining the identified gap or problem before conducting ideation. These DT tools were used as a basis for creating the user stories and scenarios.

The persona sheet

Full size image

The empathy-map sheet

Full size image

The ideation process includes divergent and convergent thinking, motivating team members to suggest multiple ideas, first without considering their feasibility to reduce criticism, and encouraging associative thinking that may lead to innovation, and later discussing and further elaborating on emergent ideas deemed promising and feasible [11]. The final DT step consists of creating prototypes, customer journey maps, and storyboards for illustrating possible solutions to be examined by various relevant stakeholders [11].

3.3 Creativity

Previous work in requirements engineering has applied theories and methods associated with creativity to the elicitation of requirements [17]. Traditional requirements elicitation focuses on determining what the users want and need. In creative requirements elicitation, the idea is to elicit novel and useful requirements that the stakeholders did not know they wanted or needed. To support this, creative requirements elicitation makes use of a number of standard creativity techniques from design and other areas [18]. For example, the most basic creativity technique is brainstorming, where people work to come up with ideas, often “bouncing” ideas of each other and building on each other's thoughts. After the obvious ideas have been elicited, one could use techniques like role playing, hall of fame (what if a famous person used your software?) [19], assumption busting (what if certain assumptions were not true?), creativity triggers (think of green, light, simple, etc.) [17], or pairwise comparison (what if idea x and y were combined?).

According to existing creativity theories, creativity can be exploratory (exploring the solution space), combinatorial (combining ideas), or transformational (removing boundaries and transforming the solution space) [20]. Different techniques favor each of these creativity types. We can also focus on divergent and convergent creativity, coming up with a wide space of ideas, then converging, combining, and narrowing the space to the best few ideas [21]. A further theory describes four stages of the creative process: (1) preparation, understanding and collecting information; (2) incubation, reflection; (3) illumination, EUREKA! moments; and (4) verification, evaluating against criteria [22].

Past work in RE has combined these ideas together to run creativity workshops, supporting industry in coming up with novel and useful ideas for new or existing products [23, 24]. These workshops often involve a number of techniques, focusing on divergent and then convergent creativity, preparation, incubation, illumination, and verification.

3.4 Multidisciplinary teams

In the new global economy era, multidisciplinary knowledge and capabilities are required for gaining competitive advantages and fostering innovation [25, 26]. Previous research addressed the need to enable effective collaboration among people from different disciplines, finding that successful multidisciplinary encounters depend on tailoring the selection of a theme, participants, and location to the encounters’ particular objectives [27].

In the context of RE, multidisciplinary approaches have also been promoted in recent years. For example, the five editions so far of the workshop series “D4RE: International Workshop on Learning from Other Disciplines for Requirements Engineering” is focused on the question: “What can requirements engineering learn from other disciplines?”^{Footnote 4} During the workshop series, different disciplines and their potential benefit to RE were discussed, including finance, law, psychology, criminology, art, games, fiction, and more.

One example is found in work by Levy and Hadar [28] using an approach from art design applied to RE. This work was based on previous studies, which illustrated the potential of multidisciplinary teams in addressing social issues [29]. In particular, when facing wicked problems, which are unstructured and ill defined, and where human, cultural, and technical aspects should be considered, leveraging (art) design skills within team members may better address such trials [25, 26]. This example [28] demonstrates how such skills benefit the specification of the often under-performed privacy requirements.

Indeed, design skills have a central role in driving innovation processes and bridging different disciplines, such as engineering, humanities, social sciences, economics, and production [30]. These design skills, applied to engineering, foster innovation, encompassing creative, proactive, and empathic approaches to connect different bodies of knowledge in order to shape innovative solutions [31, 32].

In the following, we present the main activities (pre-conference, during, and post-conference) that took place for organizing and executing the RE Cares events (see Fig. 3). This serves the twofold objective of discussing the actual process the organizing team used for the events, and at the same time providing a blueprint for the organization of future events of this nature.

The RE cares process

Full size image

4.1 Pre-conference activities

4.1.1 Initiation and stakeholder selection

The RE Cares organizers initiate the process by requesting the help of the conference General Chairs and the organizing committee for finding local stakeholders with whom a project promoting social good can benefit from RE Cares activities (Fig. 4).

A pre-conference meeting with stakeholders

Full size image

4.1.2 Project definition and initial requirements elicitation

During the months leading up to the conference, the RE Cares organizers and the local stakeholders hold a series of video-conference meetings and exchange documentation. The aim of these meetings is to make the purpose and plans of the event clear and to understand the domain in which our stakeholders operate and the obstacles they face and define the problem of focus and the scope of the project. There were at least two stakeholders at each of these meetings, and at least three researchers, but sometimes more of each. During the meetings, we appointed a note-taking person (one of the RE Cares organizers) who summarized the main issues we discussed during the meetings. In each meeting, we decided on the schedule of the next one. At the beginning, we had meetings once a month, which evolved to meeting every two weeks and then a month before the event once a week. The final meetings prior to the conference are dedicated to eliciting the prominent user stories and personas leading to initial requirements specification and a first draft of the database structure.

4.1.3 Event logistics coordination

It is important to determine event logistics, including resources and schedule and to secure space (physical, virtual, or both—as per the conference instructions) during the conference. RE Cares’ organizing committee (OC) selects people responsible for different aspects of the event and plans the individual RE Cares sessions. The organizing committee members recruit students from their respective institutions, who have the capabilities required for the project (including tools used) to participate in the different RE Cares activities, most notably the hackathon. We further make sure that the development environment is set up and ensure access as required to the IT infrastructure of the stakeholders if there is an identified need to access information or tools residing at the stakeholder’s site.

4.2 Conference activities

4.2.1 Day 1: Requirements elicitation and specifications

This activity takes place in parallel to the conference workshops, ideally on the first day of the workshops to allow for more time to document the outcomes. The activity, which is devoted to detailed requirements elicitation and their specification, uses the approaches and methods is described in Section 3 (Fig. 5).

Requirements elicitation activity during the conference

Full size image

4.2.2 Day 2: Requirements reporting and review & software design

This takes place on the first day of the main conference. In the opening session, a representative of RE Cares’ organizing committee introduces this year’s RE Cares project and invites the conference participants to contribute in the upcoming RE Cares’ sessions. This day is devoted to finalizing the requirements and software design, allowing additional participants recruited from the conference to contribute. The design activities include finalizing the database design, sketching a high-level design of the application for addressing the functional requirements, and discussing architectural concerns addressing also non-functional requirements (Fig. 6).

Introducing the projects at the conference

Full size image

4.2.3 Day 3: Hackathon and prototype development

This is an all-day hackathon, for building a small prototype of the app, including development of the database and a mock-up of the app.

4.2.4 Day 4: Showcase and conclusion

This is the concluding day of the main conference. A representative of the RE Cares OC presents the outcomes of this year’s event at the conference closing session (Fig. 7).

Presenting the RE Cares outcomes at the conference closing session

Full size image

4.3 Post-conference activities

4.3.1 Continuous development

We continue the development of the app so that a minimum viable product (MVP) can be turned over to the stakeholders and released to the open-source community for further development.

4.3.2 Outcome evaluation

The RE Cares’ OC evaluates this year’s event and outcomes for documenting best practices and lessons learned for continuous learning and improvement of the RE Cares series.

4.3.3 Preparing for next year

The RE Cares organizers commence a “teaser” message to the organizers of next year’s RE conference, alerting them ahead of time to the need for assistance in identifying appropriate local stakeholder/s for the next event.

We started the RE Cares events in physical mode and had two runs before the pandemic. The detailed descriptions of these two RE Cares events executed in this form can be found in the work by Anonymous [3, 4]. As the pandemic changed the modalities of organizing and holding conferences in general, and the RE Cares event in particular, we had to adapt the way in which the event took place (physical vs hybrid) and the selected projects. While the former papers focused on experiences in organizing RE Cares as an in-person event, here we focus on how organization of such events changed in the face of hybrid and virtual conferences, the challenges arising from organizing philanthropic events in a pandemic, and discuss lessons learned and benefits that can be gained from these experiences. Our emphasis here is on the activities held during the event, as this was the part that changed because of the pandemic.

5.1 Physical pre-pandemic events

We held two RE Cares events before the pandemic, in 2018 [3] and 2019 [4]. In these events, the pre- and post-conference activities were held remotely, via teleconferences. Two teams worked in parallel, each with expertise in a different discipline, forming the multidisciplinary effort. The first team, at the conference site, focused on the technical aspects of the solution, and the second one, from distance at Shenkar, College of Engineering, Design, Art in Israel, focused on the designed video prototyping of the solution.

In 2018 the application targeted emergency field activity for Mutual Aid Alberta, a nonprofit organization coordinating natural disaster responses in the Canadian province. We applied, in sequence, Task-Oriented RE and Design Thinking to elicit the stakeholders’ requirements, involving all participants in the effort of designing an innovative solution.

In 2019, the application objective was to help mobility-impaired people to travel in Jeju Island, which is a popular tourist destination with a far-reaching system of public transportation; however, not all buses are wheel-chair friendly. This event started under restrictions due to a typhoon hitting the Island the day before the start of the event. As a result, on the first day there were only very few participants beyond the local stakeholders. Given the late arrival of the Design Thinking mediators and the limited time, we decided to run only the Creativity Workshop, combining the elicitation of requirements and the initial design of the solution.

In both RE Cares occasions, our experience showed that most development was done by organizers, or pre-arranged dedicated students as opposed to conference attendees. However, several researchers helped students with design tools, such as how to draw UML diagrams, helping them express their design ideas more formally. In both 2018 and 2019, we received great contributions from the student volunteers assigned to the RE Cares room. That said, we had some useful contributions (in the form of questions, observations, as well as requirements, design, code) from all kinds of participants.

The most important lessons learned from the first two years’ experience include the benefits earned by all the involved participants and the topics requiring special care and effort. The stakeholders achieve a good understanding of their needs by the RE Cares participants that develop open-source software solutions, resulting with a viable prototype; students and faculty experience real-life opportunities to learn and implement multidisciplinary practices while giving back to society; and, faculty further have the opportunity to collect data that can benefit their teaching and research activities. The efforts required include careful planning of the exact structure of the event ahead of time and proper allocation of resources to the event throughout the duration of the conference. The event planning starts with finding appropriate stakeholders and early buy-in from the host conference. As resources, we recruit student developers (and possibly their advisor) or stakeholders’ commitments of their developers beforehand. We learned that spending more time in the initial stages of elicitation before the conference, allowing to spend less time for this during the event and getting to the design stages earlier, provides better outcomes during the conference, leaving less development work required after the event toward delivery to the stakeholders.

To sum up, the first two years showed that RE Cares received support, buy-in, and appreciation from stakeholders, conference organizers, and, most importantly, conference participants. Some additional benefits had also arisen in the form of conference participants, who could use RE Cares artifacts in their courses and as datasets for research.

5.2 Hybrid during-pandemic events

The software engineering community at large, like many others, faced a major challenge during the pandemic, hindering in particular the RE professionals who could not meet their stakeholders and negotiate on the system requirements [33, 34]. RE professionals had to adjust their RE practices, modify the way they coach, mentor, and navigate new paths for engagement with their research and industry peers [33]. They had to get used to distributed ethnography, collaborate in real time, document requirements—use cases, natural language requirements, models, and any representation that can be a single source of truth for their work [34]. A recent study, focused on the challenge of RE remote negotiation, even suggested considering blockchain technology for requirements negotiation [34].

The hybrid mode of both RE Cares events, in 2020 and 2021, raised difficulties to the requirements elicitation process on-site, as only few conference participants physically attended. The requirements elicitation process therefore continued as mostly online sessions, during the event itself as well. This limited our ability to perform the aforementioned RE methods, leading to a more traditional interaction with the stakeholders, and less engaging one compared to the previous events. In the following, we present in more detail each hybrid event.

5.2.1 RE cares 2020

In RE Cares 2020, due to the pandemic, the conference transformed to hybrid mode. This had several effects. First, the team structure changed: because of the hybrid nature of the event, the Shenkar students worked together with the organizers and student developers for the entire duration of the project, thus forming a single team. Second, the work mode during the conference was hybrid, with part of the team and stakeholders joining on-site, and the rest participating virtually.

The challenge of the 2020 event was helping small business owners understand today’s cyber security risks and protection. We had no direct access to users until the conference itself; in the pre-conference sessions we communicated with proxies. This raised some difficulty in defining the exact requirements of the system. Before the conference, we had online meetings with a stakeholder, an activist from a consulting firm, who tried to find SME customers with whom we can learn about real needs. In the online meetings, first with the activist only and then with the recruited customers, notes were taken in an online shared document. We prepared guiding principles for interviewing potential customers and eliciting data about the company, their daily activities, the business information they share and whether they use any tool that assesses the security situation, the way they use technology/computers in the business, and whether they are concerned about IT security. We further asked them to name applications or websites which they perceived as trustworthy.

After meeting with several potential customers, we realized that their limited background about security did not enable defining their actual goals and potential solutions. Recognizing this knowledge barrier, we moved from discussing security issues to business processes in digital tools, allowing our security experts to identify possible threats. As a result of this process, no requirements document was provided toward the conference but instead we came up with the product vision: “An easy and actionable tool to support individuals and small companies to raise their systems’ cyber security level,” and a task: “A modular web application that starts a conversation about different cybersecurity topics and speaks the language of its users.” In addition, an initial prototype, focusing on weak passwords and phishing attacks was created in order to propose a conceptual solution to the (abstractly defined, at this point) problem.

On Day 1 of the RE Cares event in parallel to the conference workshops, RE Cares organizers introduced the proposed conceptual solution to the users, followed by a discussion and usability test.

The lessons learned are spread over two aspects—the selected projects and the mode of the event. The RE Cares project as defined in 2020 posed difficulties that we did not encounter in previous years. One difficulty stemmed from the multiplicity of stakeholders who were not part of the same organization. The stakeholders were from small businesses such as a local baker and hairdresser as well as startups and consultants. The various stakeholders had very different perspectives, security awareness, and needs. Another difficulty we faced was a limited direct access to the actual users; we were able to interview only two users, owners of two very different small businesses. Finally, the very specific and technical domain of cyber security, for which we had partial expertise posed another difficulty, which we tried to address by inviting several cyber security experts to join the team. Unfortunately, this did not fully solve the problem of understanding the needs of the users. This was mainly caused by the complexity and technical nature of the topic of data security. This, in fact, is not surprising: data security, especially in the context of small and medium enterprises (SMEs) is still an open problem in many businesses, with several governments making efforts to help SMEs deal with security by building security guides and awareness campaigns based on the identification of different segments of such businesses [35]. Planning future RE Cares events, we should consider these risks and ensure a more homogenic stakeholder population, direct communication with users from the very beginning, and selecting a project (given a choice) that better fits this event’s frame of limited time and communication with the users, especially considering the designated users’ availability and knowledge. All these hopefully should prevent the situation of not being able to define a (preliminary, at least) requirements specification document. Indeed, these risks were considered and addressed later when we planned the event of 2021 (described below).

The hybrid mode of the event raised additional difficulties, including the different time zones in which the remote participants were located, making it very hard to synchronize the development activities, the management of these activities in a way that would provide the remote participants similar opportunity of engagement and influence, and fewer opportunities to recruit conference participants from the conference venue rooms and hallways. Planning future events should consider additional management and recruitment strategies. For example, we plan to use more aggressive marketing of the event to the RE community in general, and registered participants in particular. In addition, in the weeks before the conference, allocating specific responsibilities and tasks to participants, especially those participating remotely, to improve their ability and motivation to engage in the activities during the conference.

5.2.2 RE cares 2021

As the pandemic continued, the RE conference transformed to the mode of a fully virtual event in 2021. Despite this, the organizers of RE Cares 2021, with the permission of the conference general chairs, decided to keep the hybrid mode of last year rather than going fully virtual. Accordingly, part of the RE Cares organizing team and development students were on-site, meeting physically with the stakeholders and participating in the development process.

The 2021 event focused on Goodwill Industry's Stand Against Violence Everyday (SAVE) division of the Gun Violence Intervention (GVI) organization in the location of the conference: Notre Dame, South Bend, USA. The stakeholder’s challenge was taking notes at an incident site, as well as preparing supporting data analytics for assessing the outcomes of the efforts of the SAVE team and visualizing the analytics results in a usable manner.

Goodwill actually needed two main services: data collection and data analytics, two applications were thus planned to be developed. This resulted in restoring the two-team structure: Most of the RE Cares organizers and their development students worked on the first application (note-taking app.) and the Shenkar RE Cares organizer and development students worked on the other application (analytics and visualization app.). As in 2020, the pre- and post-conference events were fully virtual, and the during-conference event of RE Cares was hybrid, with part of the team and stakeholders joining on-site, and the rest participating virtually.

At an early phase of the pre-conference discussion, as we agreed on the scope of the project, based on our understanding of the priorities of the stakeholders it was decided to dedicate most of our pre-conference efforts to the note-taking app.

We used a shared document for creating together the DT tools of Persona, Empathy Map, and Customer Journey. Based on the virtual meetings and discussions, in which DT tools represented the actual real-life conduct and events, we developed several user stories and scenarios, noting their respective priorities (see Fig. 8).

An example of a user story

Full size image

This enabled us to create a very detailed requirements document, including user stories, and detailed requirements specifications. Moreover, because of the high commitment of the stakeholders, enabling high frequency of meetings, and the focus on a single-service app, we had enough time left to allow for a first hackathon taking place before the conference (this was a first). As a result, we started the during-conference event with the following artifacts: a mature requirement document and a first version of both the database and the user interface design. During the conference, the meetings with the stakeholders mainly focused on the analytics and visualization app.

Shenkar students were more engaged during the conference (and less so in the pre-conference activities), as they were part of the visualization app team. After the design sessions were performed during the conference, a requirements document for this app was created and they worked on the application mock-up screens during the hackathon day. These screens were enhanced by the other team (which started to work after Shenkar’s student workday ended, due to the time zone differences). The mock-up was further enhanced by the other student team at Cal Poly in the hackathon that took place after the conference ended.

Overall, the lessons learned in 2020 contributed greatly to the success of 2021’s event. We selected a single division of an organization with whom we defined the RE Cares challenge; we made sure to collaborate intensively with the direct users of the planned solution; upon understanding the need for two applications, we prioritized and focused on a single app before the conference to ensure a detailed understanding of its requirements and a start to the design, so that we provided a minimal-viable product at the end of RE Cares. Fortunately, we were also able to progress with the second application, thanks to the high commitment of the stakeholders and the teams of organizers and students, and the allocation of responsibility to each team and their members. However, it was evident that the second app, for which we had not elicited detailed requirements prior to the conference, ended up being less mature than the first app. It is also important to note that the rest of the difficulties stemming from the hybrid mode of the event were mostly not overcome.

5.3 The future of RE cares—beyond pandemic

Moving forward, as we hope that physical-presence conferences will be restored, we aim to learn which of the practices emerging from the constraints of the pandemic can lead us to additional recommendations we would have otherwise not considered.

First, the use of teleconferences prior to the conference was more extensive in the two recent events than those preceding them, due to the concern that we would be less productive during the conference—compared to the previous events—because of the difficulties stemming from its hybrid nature. This, however, would be highly beneficial to physical conferences as well: arriving at the main event with a mature understanding of requirements and design provides a good basis and high motivation for achieving a viable product during the hackathon.

Second, the hybrid nature of the event increased substantially the communication and collaboration between the on-site and remote teams. While teleconference technologies were available to us in the previous events as well, and used before and after the conference, we had not considered using them during the physical events. The culture of remote collaboration beyond short conversations had emerged during the pandemic, making this a common practice. This practice would continue to be useful, including teams that are not present in the conference location. This mode of collaboration not only improves communication and outcomes but may also motivate remote teams to commit to this project, as they feel more involved in the process.

5.4 Philanthropic projects and their role in academic settings

Philanthropic projects often are not of the highest priority on the agenda of anyone involved, including the product owners themselves. Everyone must carve out time from their schedules to work on the projects. Having such a time constraint for developing requirements specifications and an MVP requires recruiting researchers and students ahead of time and providing adequate academic recognition for their effort. Such recognition can be in the form of academic credentials or extending the developed MVP to a more mature project that can lead to validation and research. We believe that recruiting researchers and students that have specific interests in the challenge can foster engagement and commitment, helping overcome the special conditions of RE Cares, including limited time, language barriers, different time zones, and more.

5.5 Lessons learned summary

In the following, we summarize our lessons learned in order to provide a take-away for future researchers or practitioners who plan to organize philanthropic events at conferences, both in person and in hybrid mode. The organizers were participatory action researchers [36]. The process of identifying the lessons learned was based on the group of organizers from all editions (the full authors’ list) in which we all contributed to the reflection about the experience we had in these events, defined lessons learned, and finally discussed and refined them until achieving stability and consensus (Table 1).

The categories of lessons learned are:

• Conference-related: addressing issues that concern the way RE conference organizers were involved in RE Cares

• Process-related: addressing issues that concern the way RE Cares was handled and communicated with different stakeholders (except RE conference organizers)

• RE-related: addressing issues that concern the way RE Cares executed RE processes and methods

In this paper, we presented our vision for philanthropic projects in requirements engineering, which has been materialized in the series of events of RE Cares. Based on the experiences of running these events, in both physical and hybrid modes, with each event addressing a different social challenge, we provide a generic process for running such an event, including pre, during, and post-conference activities. We elaborate on the lessons we learned over the four events we ran in the two modes: physical and hybrid, the latter dictated by the pandemic and the social distance it demanded. While starting as a necessity, the pandemic has provided us with the opportunity to apply different practices, some of which proved useful and contributed beyond their compensation for the social distance constraint.

We believe that our experience and lessons learned can extend beyond RE and conference-based events to other SE initiatives, such as helping specific industries to develop solutions based on advanced artificial intelligence or virtual reality technologies. In such cases, the activities will focus more on the development process than on the RE one, but the lessons learned discussed above do not relate to RE alone, and include many aspects related to the project as a whole, and as such are general enough to be relevant and beneficial to additional SE activities.

Future events can further teach us about these and additional practices and methods for promoting engagement and contribution of stakeholders and participants, facilitating collaborative efforts for the achievement of social good via technological solution development.