Collection of End User Requirements and Use Cases during a Pandemic—Towards a Framework for Applied Research Projects

Abstract

Research projects in the security domain often aim to develop innovative technology-based solutions for end users (e.g., situational awareness tools, crisis management tools). The pandemic crisis hit hard and without warning, not only influencing our everyday life but also the scientific community. To continue applied research projects during a pandemic, work structures needed to be adapted (e.g., user requirements collection, use case development), as face-to-face events were impossible but crucial to collect high quality requirements with a variety of different stakeholders. To ensure continued multi-stakeholder engagement we developed an overarching framework for collecting user requirements and use cases in an online setting and applied the framework within two research projects. The framework consists of four steps with the aim to assure high quality user requirements and use case collection (first analysis, stakeholder consultation, evaluation and prioritization, technical evaluation). The two projects presented in this paper provide insight on the potential of the framework. The framework offers a structured approach that fits for many different security research projects in terms of the easy application and its transferability. The main advantages (e.g., easily adaptable, reduced workshop time, no need to travel, suitability for different contexts and project types, etc.) and drawbacks (e.g., organization of online events, feedback collection time, etc.) of the framework are presented and discussed in this paper to offer increased stakeholder engagement. Empirical testing of the framework is proposed.

1. Introduction

Developing innovations in the field of crisis and disaster management is strongly needed, as disasters strike humankind all over the world and in rising numbers. The COVID-19 pandemic is one of the latest disasters that affects humankind globally and impacts us in various ways. New technology innovations form an important part in aiding against the negative consequences of disasters. These innovations, in our case software innovations, can increase effectiveness in preparedness, prevention or response as well as reducing the danger for first responders in the field and enhancing safety and security. At the starting point of these developments, project teams must collect and analyze relevant user needs and translate them into user requirements. Corresponding use cases are required to understand the context in which a solution should be applied. Many factors are influencing these processes of collection and consolidation of user requirements and use cases.

If user requirements are incorrect, misinterpreted or changed during a project, it can jeopardize successful completion of a solution in its development or foster additional costs for its development [1,2]. Therefore, success or failure of the whole project heavily relies on the user requirements collection [3,4,5,6]. The collection not only depends on choosing the right method, but it is also influenced by how the method is carried out and it is influenced by the attitude of the respective end users [4,5]. Thus, the main aim is to best reflect the needs and expectations of the stakeholders beforehand. The success measure then is the degree to which a requirement meets the purpose for which it was intended [6].

Without involvement of stakeholders, the solution is likely to have lower acceptance/application in practice or lower purchasing rates. Especially in the fast-paced field of crisis and disaster management, end users tend to have little time resources available to help developing suitable solutions for their own domain. [1]. Selecting the most fitting format for the collection is thus very important. Re-doing work at a later stage comes with the need for an increased time budget, in case requirements are inadequate. Various methods exist for this process (e.g., interviews [7] and surveys [8] field studies, including the use of online tools [9,10]). However, the most appropriate approach depends on the context of the project [5]. Additionally, unexpected restrictions such as the COVID-19 pandemic have to be factored in during the planning stage.

The coronavirus SARS-CoV-2 was declared a Public Health Emergency of International Concern on 30 January 2020 and was officially announced to be a pandemic on 11 March [11]. Spreading of the virus mainly happens via small droplets emitted by talking, sneezing and coughing, which leads to preventive measures such as reducing social contacts or even lockdowns [12]. Such measures not only affect the population in general but also the scientific community in particular. Social science research, specifically stakeholder engagement research, is one area which is potentially impacted, given its need for person-to-person interaction [13]. The measures against spreading the disease made it necessary to temporarily stop nearly all on-site research activities including workshops, seminars, conferences or other dissemination events. For all these activities, new formats had to be explored, to keep project time plans in order. This is also true for the user requirements and use case collection with end users.

We were left with the major challenge to follow-up with plans of research projects that—due to the pandemic—now had to be conducted under completely different circumstances. The original set-up of the projects did not foresee researchers and end users suddenly being stuck at home without any option to meet and exchange ideas face-to-face. The new situation also has some advantages for the people involved in the projects (e.g., reduction in everyday travel time, possibility to attend events that would otherwise have been too time and cost intensive, ability to disconnect from a meeting if deemed irrelevant [14]). Major drawbacks were also faced (e.g., increasing offer for interesting online events, already increased workload due to the crisis, missing networking options and discussions with colleagues during the work time or at face-to-face events [13,15,16]). All of this led to the need for a new way of collaborating within projects in order to produce the desired outcomes for user requirements and use case collection, without relying on in-person-meetings. Thus, we developed an easily adaptable framework for the collection and analysis of end user requirements and use cases, which we applied in two different projects at different stages of the development process.

There is a broad state of the art for the process of user requirements collection and use case definition. The basic parts of the process typically consist of two steps: (a) the identification step and (b) the evaluation step [17]. The identification step often includes a review of the state of the art in terms of relevant tools, projects and technologies [18]. This is mostly followed by a method to collect explicit requirements from the relevant end user group. In the security research domain, the targeted end user group is usually represented by an organization with security tasks. Methods for the collection are always strongly dependent on the end user group, the product that should be developed and the time and money available for the dedicated task. Courage and Bexter [19] provide an overview on the different methods for the collection and what should be considered when applying them. Within their work they also focus mainly on face-to-face events for the collection of user requirements [19]. Projects often decide to opt for a combination of methods to obtain a broader picture from their different end users. This can then include stakeholder meetings, observations, questionnaires and interviews [20]. Lately, the collection is also performed by using online tools, e.g., an online platform where partners can insert their requirements and use cases by using the provided templates [18]. Alternatively, online questionnaires are more and more commonly used to collect user requirements without the need for a direct interaction with the users [21]. An explicit framework for the requirements collection and use case development in the security research domain is not yet available, and thus we aim to provide a first concept for such a framework that can be further developed and empirically tested within other security research projects.

The next section (Section 2) will elaborate more on the state of the art of user requirements collection, general project management and other existing concepts and frameworks. This is followed by Section 3, which explains how the framework for user requirements collection and use case development was established. Then, two application examples, one within the project AIFER (Section 4.1) and one within the project METICOS (Section 4.2), will show a first insight on how the framework was already applied. In Section 5, the two applications as well as the opportunities and drawbacks will be discussed in further detail. The last section (Section 6) presents the conclusions and potential of the framework for applied research projects.

2. Background

Developing a new software innovation inherently requires a set-up and defined process through which it can be realized. Focused and organized project management is necessary to develop a new product within the given time and resources. If basic project management is missing, the development will most likely drift into the wrong direction or end up with a huge time delay. In the following, some basic PM concepts are presented to provide an understanding of the underlying processes in which this framework is embedded.

Projects can vary in size (from small units to various companies working together) in duration (from several days to several years) but also in complexity (ranging from simple to complex). The common theme is that it is important to choose the methodology and follow along to have control over it [22]. It is possible to choose one of the already available methodologies (e.g., PMBOK, PRINCE2, LEAN management) or to create a new one [23]. To select the most suitable approach, it is necessary to understand the most common methodologies, which are briefly presented below.

PMBOK was developed by the PMI (Project Management Institute) [24] with the purpose to guide a project manager successfully through its nine knowledge areas that are broken down into activities across five stages of the project life cycle [25]. PRINCE2, another state-of-the-art project management method, was developed by CCTA (Central Computer and Telecommunications Agency) [26]. It is a flexible and widely recognized methodology oriented towards the final product and also divides the project into phases, but it is driven by the projects business case [27]. While PMBOK is a process-based methodology, PRINCE2 is product-based [28]; in addition, the number of processes defined are different (PMBOK has 5 groups, PRINCE2 has 8 groups) [25]. Both methodologies have differences and similarities and often cover the features which are not covered by the other methodology [29]. Lean Project Delivery System (LPDS) differs from traditional project management in its goals, structure but also relationships between the phases and participants [30]. The main goal of this approach is to satisfy the customer with the service or product by performing only those activities that add value to the service or product, comply with the customer requirements and meeting the high-quality standards by minimizing waste and redundancy [31]. According to Nikiforova and Bicevska (2018), based on Dobbs and Ambler [32], IT companies that have adopted the LEAN approach have accomplished more projects successfully than companies which follow other approaches [31]. The LEAN approach is similar to the AGILE methodology, which is widely used in IT industry and is a subset of LEAN, and both are based on systemic thinking [33,34]. In comparison to agile and lean management methods, traditional project management methodologies (e.g., PMBOK) rely more on processes, linear development cycles and waterfall-like software development including stable requirements, analysis and design [35]. There are several other methods that fall under the LEAN philosophy (e.g., the Scrum-based approach, Extreme Programming, Disciplined agile delivery, Scaled, Agile Framework). The latest methods that emerged are placed somewhere between the two types of methodologies in the spectrum, called hybrid methods, encompassing characteristics of both types [36].

Within the project management, the selected methodology has a great impact on how the development process is conducted. The collection of user requirements and use cases is influenced by the project management method as well. Traditional approaches are more focused on a linear development and thus on identifying user requirements at one stage of the project without iterations. Lean and agile approaches are more open to work with ongoing changes in requirements. The success or failure of a software innovation heavily depends on the quality of the requirements [37]. Emerging problems can be mostly traced back to the technique used to gather these requirements [38,39]. For requirements gathering or requirements collection, as part of the project management, there are many processes or models available [5,37,40,41,42]. An important part in the process is the technique selection (e.g., surveys, prototyping or interviews).

Jukic and Nicholas [43] defined a requirements collection framework for data warehousing projects, including four steps that should be followed iteratively. It involves two separate processes, the requirements collection and the consideration of the implications as an evaluation and feedback loop. The first step is to identify the end user business analytical needs, providing a first high-level set of requirements. It also includes a prioritization into categories (i.e., from “must have”, to “want”, and “wish to have”). The next step features a consideration of the implications of the first set of requirements for the data warehouse details. This includes adding further requirements. In the next step the set of requirements is being modified based on the data warehouse details. In a final step, the requirements form the end user business analytical needs perspective. The authors [43] suggest several techniques to collect the requirements (e.g., review of available records, review of past interviews, focus groups, surveys, comments about existing data warehouses, observation of end users at work).

As requirements collection and engineering is a very collaborative approach, Konaté et al. [44] developed a process-centered approach for the collaborative requirements elicitation. The approach consists of four different processes that follow a waterfall method: (1) identification of needs and its collection and the verification of needs consistency and completeness, (2) transformation of needs into technical requirements, verification of requirements consistency and classification, (3) verification of requirement completeness and validation of requirements, (4) requirements recording including a specification book as output. The authors [45] suggest different techniques for the approach selected, depending on the time and resources available. Among them are the dialogue [45], group storytelling [46], brainstorming [47] as well as a combination of the aforementioned methods.

Looking more into the selection of the most suitable techniques for the elicitation of user requirements, Tsumaki and Tamai [38] have developed a framework for matching requirements elicitation techniques with project characteristics. It is focused on four different requirements elicitation methods that clearly differ from each other: (1) domain decomposition (a target domain is decomposed into subdomains step by step), (2) goal oriented (goals are decomposed into subgoals by asking “how” and “why” questions), (3) scenario based (scenarios are defined based on use cases) and (4) brainstorming (collecting ideas often in areas where experience is scant or a new kind of software is expected). Then, they are characterized by two dimensions, namely operation types (static and dynamic) and object types (closed and open). The various techniques are then mapped based on these two dimensions. The characteristics of projects are extracted based on five factors, (1) application domain, (2) requirements engineer types, (3) information resources, (4) user involvement and (5) requirements properties. Each factor is defined by a one-dimensional line that indicated the direction of the method.

Considering the already existing approaches and the according techniques, there is a vast amount of material available to select a suitable approach for the user requirements collection. Nevertheless, research is a dynamic process, situations change, and a lot of the before-mentioned approaches cannot be easily implemented during a pandemic with its according restrictions. This increased the need for digital transformation of human interaction [48]. Scientific research project managers as well as other project managers in various other fields were forced to change their planned project activities [49]. Re-planning and rescheduling of many activities were the result, and decisions had to be made under unpredictable circumstances [50]. Studies showed that the pandemic and national lockdowns had a significant detrimental impact on research output [51,52]. Project delays often emerged in experimental and laboratory settings, where work could not be continued during the pandemic, whereas other activities such as meetings or conferences were organized as online events instead [50]. Online events also seemed to be a good alternative for the user requirements and elicitation part within security research projects. As end users in this domain are strongly involved in pandemic management, workshops or face-to-face meetings were simply impossible due to the pandemic restrictions, but also due to the limited time of the relevant end users. Therefore, we developed an easily adaptable framework for the collection and analysis of end user requirements and use cases which we applied in two different security research projects.

3. Establishment of a Framework—A Step-by-Step Approach

Taking into account the pandemic and its effects on face-to-face events, a framework needed to be developed and applied to current research projects, merging together different elements and processes of technology developers and first responders that can be broadly applied, be it use case development or user requirements collection. This was necessary as the typical method for the collection of user requirements and use cases in most security research projects are relying on face-to-face events. For the development of the framework, we considered how the user requirements collection and use case development was conducted before the pandemic [11] within the research projects we were part of as end users. As the framework’s main aim is to provide an alternative to the missing face-to-face events, which usually take place at an early stage of an applied research project, the basic principles of the framework do not differ much from the usual structures of in person meetings [21]. The major difference is that it implements several (smaller) interactive online workshops and online tools at different process stages, instead of one or two big face-to-face events with various participants. This approach accommodates an iterative process allowing for gradual adjustments throughout the project.

We propose to apply the developed framework within a LEAN project management system to cope with complexity and improve project performance [53]. In general, the framework is a combination of several requirement elicitation techniques that are embedded in a digital environment. It includes elements such as focus group discussions, surveys and brainstorming that are useful for dynamic requirements identification [38]. Like already existing methods or frameworks [38,43,44], the framework we developed consists of a collection and analysis of the needs, transforming them into technical requirements, the evaluation of the requirements and a technical validation. Typical for the requirements and use case collection within our former security research projects was a stakeholder workshop with a moderator who explained the general idea of the innovative solution and then collected relevant requirements or use cases from the End users. They were guided within this session by the overall goal and predefined scenario of the project and the moderator led them through the various planned modules of the software. This step is usually preceded by a detailed literature review and internal preparation meeting of the moderator’s team or organization. Both steps were reflected within the framework by transforming it into a virtual setting. Additional steps regarding the evaluation and prioritization are also common to identify the user requirements or use cases which are most important and the ones that just offer additional comfort if implemented. Both parts are integrated into the framework as well. As the collected requirements and use cases should be added by end users without a software development background, the framework needs an additional step to evaluate the requirements or use cases from a technical point of view. The step was added as the last part of the framework; nevertheless, it foresees to also redo steps later, if it is deemed necessary. The detailed description of the framework is presented below.

The framework consists of four individual process steps with (at least) two separate events or tasks (see Figure 1). The starting point is the consolidation of the overall project aims and scenarios. The scenario is especially important to understand in which context the project is developed and how the results are planned to be applied. Once the relevant context is clear, the first step of the process is started. Initial analysis consists of a literature review and a team co-creation workshop. The literature review is focused on publications about similar or related developments as it was also studied in Božić et al. [18]. The results can then be used as a first basis for the team co-creation workshops. These workshops (one or more) can be organized within the organization responsible for the requirements collection or use case definition. It can also be conducted with the project’s internal end users.

The next process step is the stakeholder consultation. Two distinct methods are part of the framework to receive crucial input from relevant stakeholder groups. To collect requirements or use cases from external stakeholders and interest groups, an online survey is recommended [54]. Easy-to-use online-tools (e.g., LimeSurvey) allow the design of surveys including options to evaluate the results with the help of the tool or export the data in SPSS or Excel. The aim of this step is to collect data from a bigger audience. Finding a suitable strategy to distribute the survey via the online-tool is important as it directly impacts the quality of the results. The workshops can be organized as one single event or, if several different stakeholder groups are of interest, they can be split into several workshops. It is important that they are held in a short, comprehensive and compact way, to keep the end users interested in the project. Ideally, they should range from one hour to one and a half hours to present the current status of the project and to highlight what is requested from the end users. The detailed feedback should be requested after and not during the workshop itself. Complemented with the online survey, the needed inputs for the evaluation are collected.

Without an evaluation and prioritization of the collected requirements or use cases, the outcomes of the project in which it is planned to be applied will not be sufficient to start developing the technology [55]. The third step of the framework is dedicated to this stage, linked to two distinct tasks. First, the various results collected need to be consolidated to phrase clear and concise requirements or use cases. As the collection is performed with several different groups, some of the outcomes will be similar or doubled. Therefore, collected user requirements may need to be rephrased or merged to a concise list of requirements which can further be weighted (depending on the number of times requirements are referenced). Following this task, we developed templates to be used for the analysis. One template refers to the user requirements and another one to the use cases, both easy to use as Excel files. The user requirements template offers several blank fields that allow us to structure the requirements based on the specific scenario at hand, the timeline of the scenario, the technological components needed and the command level it applies to. The requirement can be selected according to “must”, “could” or “should” criteria for the evaluation. This evaluation can be conducted by the project team or by the participants of the stakeholder workshop. There is one single selection per user requirement. The template offers the possibility to collect all relevant information about the use case steps, the relevant inputs and outputs per step as well as the responsible persons for the step. All use cases can be compared to see where they are overlapping.

The last step in the process is the evaluation from the technical point of view. As proposed in the presented framework, this should be performed in an online workshop with technical partners. Participants need to define for each component if it can be implemented within the project and how many resources (e.g., time, personnel, money) are potentially needed. All relevant questions can be answered within the analysis template of the user requirements. The technical partners need to evaluate the potential application of their technology within the use case and the importance of the use case itself. Additionally, the needed resources to provide the necessary functionalities should be estimated by the technical partners. The user requirements and use cases can be ranked based on the end user evaluation as well as the technical evaluation. It is possible to insert the user requirements in an attached matrix within the template. The matrix shows the different user requirements based on the importance for the end users and the potential for the technical implementation within the project and serves as useful guidance in the (technology) development phase. The outcome for the user requirements and the use cases is the results catalogue which can serve the developers as a starting point for the implementation phase of the project.

4. Results: Applying the Framework in Two Research Projects

4.1. Application of the Framework—Requirements Collection

The development of the framework and its first application was embedded within the AIFER project. AIFER stands for “artificial intelligence for the analysis and fusion of earth observation and internet data for decision support in disaster control” (funded by FFG, Nr. 879732). The aim is to develop an AI-based algorithm for the fusion of information based on the analysis of earth observation and internet data to enrich the common operational picture with additional information. It will be complemented with a common operational picture user interface and demonstrated in a field- and usability test.

The project started at a time when Austria was moving from one lockdown phase to the next. Travel restrictions as well as restrictions concerning meetings within the partner organizations made it obvious that during the first phase of the project, no face-to-face meetings or events will take place. Adjustments to the methodology needed to be made. Especially for the collection of end user requirements, several workshops were planned that now needed to be transformed to virtual events. Therefore, we developed our framework for the collection of user requirements and use cases to be applied in projects facing similar problems.

Following the framework, the project team started the user requirements work by conducting a literature research (1) regarding three relevant scenarios (floods, wildfires, and heatwaves). This was followed by an internal co-creation workshop to identify additional application scenarios and first user requirements for the tool. It was then extended by an additional risk analysis to understand the importance of different scenarios for the country and the first responders. Then, all the collected scenarios were consolidated. Floods were already fixed as the main scenario, followed by five selected side scenarios (wildfires, heat waves, storms, heavy snow, and blackout).

During the stakeholder consultation (2), several events took place. An online survey was prepared to collect feedback on the scenarios (i.e., tools that are available and user requirements for each of the scenarios). The answers were collected and summarized in a first list of requirements. These served as the basis for two end user workshops. As the project had two different end user groups, two separate workshops were organized. One was conducted with a command center team and one with a state task force of the Red Cross. During the workshops, the initial set of user requirements from the online survey were partly discussed and additional requirements were identified. In total, we were able to collect 75 different user requirements for the three individual technical components of the project.

After the workshops, the list of user requirements was sent to the workshop participants again to collect the evaluation for each requirement (3). Both groups decided for every single requirement, if it is a must, could or should requirement for them. All collected user requirements were then analyzed with the help of the provided template. It included the number of requirements, descriptions, evaluations from the command center, evaluations from the task force, the corresponding technology part, the timing within the scenario, the scenario for which it applies, the source it was identified for and the command level where it is relevant. The workshop participants were invited to send feedback regarding the classifications.

The last columns of the template were filled in during the final workshop as part of the technical evaluation (4). The workshop aimed to identify the potential of each requirement for being fulfilled within the project as well as the time spent on the development. Additionally, it was also deemed as important to understand which of the requirements could potentially be fulfilled in the future. The technical evaluation and end user evaluation of the user requirements were prioritized along several groups depending on their importance for the end users and on the realization potential on the other hand. The templates also allowed us to generate a matrix to display both sides of the evaluation.

4.2. Application of the Framework—Use Case Generation

The H2020-funded European project “METICOS” (grant number: 883075) is dedicated to the development of “a platform for monitoring and prediction of social impact and technology acceptability of modern border control technology”. In the domain of smart border technologies, the project aims to introduce big data analysis of cross border control validation technologies, develop a tool for efficient border management, and create a platform in support of technology acceptance targeted at no gate crossing point solutions and users.

The focus was set on sufficient online stakeholder engagement applying our specific framework for the purpose of generating various use cases from which scenarios were then derived to test project components. Basis for the use case generation process was a set of predefined user requirements. These were collected in a previous step by a partner organization through technologies and capabilities templates, questionnaires and end user meetings including user requirement workshops, applying a cooperative design with the 15 consortium partner organizations.

In the case of the METICOS project, the initial literature review for the use case generation consisted of an internal document review (i.e., project deliverables), zooming in on the previously collected user requirements which formed a starting point for the joint definition of use cases (1). This was followed by a first co-creation workshop with end user organizations within the project consortium. To ease the definition process, a questionnaire set up in Excel was created to structure partner input and enable comparison.

For the phase of the stakeholder consultation, we chose to offer a “how to” guide for end users to describe different use cases based on their working realities and collect input in a structured format, using Excel sheets (2). These questionnaires were introduced to the team members in internal stakeholder workshops. Due to the sensitivity of the research topic, it was decided to work exclusively with internal partners of the project.

Partner input received, it was then consolidated, and the different steps in the process descriptions of use cases were compared. At this stage, another feedback loop with stakeholders was built in, to update the collected use case material (3). This comparison and adaptation round was followed by further processing and analyzing and complemented by feedback from technical partners. After implementation of feedback received from technology developers, and merging multiple use cases in the analysis, specific scenarios emerged from the collected use cases, by breaking down the various use cases in different phases or areas (grouping commonalities). For the analysis, no separate analysis template was developed as partner input was already collected in a structured manner.

The evaluation by technology partners was set up as a stakeholder workshop (4). For the definition of use cases, it was important to define at which step in the process soft- or hardware components can be applied to support overall end user processes and test the system during development accordingly. Here, the focus did not lie on how the component was to be designed (hence the user requirements) but on how it will be applied in the work context that it is developed for.

5. Discussion

By applying the framework in the two application cases, we were able to overcome some of the typical problems of the user requirements identification and use case development, identified by Leffingwell and Widrig [56] and as follows: (a) lack of user input, (b) incomplete requirements and specifications, (c) changing requirements and specifications. The lack of user input was overcome in the AIFER project, by motivating the end users to provide input as well as work with us on the overall understanding of their needs and by keeping the online sessions short. Within the METICOS project this was an issue as the communication with end users often took a lot of time. Incomplete requirements and specifications could be avoided in both cases by applying the framework. With the evaluation and prioritization step within the framework the incomplete requirements and use cases could be improved and finalized. This step also improved the quality of the requirements that changed during the collection and evaluation of the requirements as end users had time to adapt them within the last two steps of the framework. In comparison to other methods, we were not only using online tools without direct user interaction [18,21], but we also tried to transform the common approaches with direct user interaction [19,20] into the online environment, also applying an iterative process.

The presented framework for the collection of user requirements and use cases can be used as a guidance to work under restrictions such as the current pandemic. However, it is not limited to these circumstances. In the future, it can be a useful way to collect input also in projects with involvement of many different end users scattered all around the world. Applying the framework, working online, allows us to bring in more diversified views, as geographic distance can easily be overcome (albeit language differences have to be taken into consideration). The framework can easily be adapted to the different needs of the project and its project members, and each step can be reduced or expanded depending on the results collected. Our framework, presented in this paper, provides a structured and holistic approach utilizing existing tools (e.g., LimeSurvey, Risk analysis) and newly established templates for projects in crisis management.

During the two different application cases (i.e., a national project as well as an EU project), we were able to identify several challenges for the framework as well as opportunities for improvement.

Applying the framework in the AIFER project for the user requirements collection, was helpful for obtaining an overview of the direction in which the requirements would serve as an orientation for the development of technologies. In comparison to other projects, we collected very specific user-oriented requirements that were not simply reflections of what the technical partners were already planning, but took into account the end user perspective. This aspect remains a big challenge in projects [4,5]. Too often, user requirements are not thoroughly collected but simply display what technology providers set out to do, or on the contrary, requirements are too unspecific, making it very difficult to translate them into system specifications. Consolidating the vast number of requirements from various sources turned out to be a challenge (i.e., some were very similar, and some were not similar at all).

During the workshops with end users, we learned that the best way to organize these events was to provide information about the planned technology (and components), briefly discuss the collection template and let participants brainstorm on their own about new requirements (i.e., without too much steering by a facilitator). This process could best be assisted with an online whiteboard solution. There, the host can organize the requirements based on different scenarios or technological components. Afterwards, all requirements can be summarized in the analysis template. End users should take their time—outside of the workshop—to discuss the prioritization. Regarding the planning of the workshops, our end users allowed us to use some dedicated time within their monthly team meeting, which turned out to be very fruitful for all of us, as they did not need to attend additional events.

The iterative approach has been proven to offer ample opportunities for stakeholders to engage in and help shape the process. While the sensitivity of the research topic within METICOS did not allow for broader stakeholder engagement, the iterative process on use case identification offered increased opportunities for active engagement and transparency among all stakeholders. The process also helped stakeholders of different professional backgrounds to find common ground concerning their different expertise. At times, workshops did not immediately generate the expected output, but the continuing discussions triggered due to the workshops among project partners helped to identify and understand challenges in the development process concerning the whole consortium. Missing motivation of partners to provide input is a common problem [18,22]. Even if results are not achieved in a direct manner, our proposed process can contribute to an overall improved collaborative approach. While the implementation of the presented framework does require dedication and an open-minded approach of all stakeholders involved, it can significantly increase the quality and depth of the collection of user requirements or use case definitions.

The developed overarching framework was created to face the emerging pandemic situation addressing its major issues for projects (e.g., travel restrictions, high workload of end users) and offer an approach that allows researchers to continue project work for all research projects which are currently in the initial project phase (user requirements collection or use case generation). Although the presented applications within the research projects are just first examples of the use of the framework and do not constitute a representative sample, they demonstrate that the framework can be of help for national as well as international projects. Nevertheless, it is not only applicable during an ongoing pandemic. All the listed advantages (e.g., no need to travel, suitability for different contexts and project types) are valid anytime. It can be applied whenever it is not suitable or too expensive to gather a lot of end users in one room. The framework also helps to overcome problems that arise in projects if end user requirements or use cases are mainly developed by technical partners. It allows project members to agree on a common denominator concerning the aims of a project. Therefore, we regard our framework as highly relevant to allow research projects to develop new end user oriented innovative solutions in the security domain. Nevertheless, it is important to test the usability of the framework in several case studies of different projects.

6. Conclusions

The overarching framework for the collection of user requirements and generation of use cases presented here contributes to the user requirements and use case collection under restricted situations (e.g., pandemic) by offering a structured approach that fits various kinds of security research projects which aim to develop new innovative solutions for end users. It provides a basic structure focusing on the identification and prioritization of user requirements and use cases without the need for face-to-face meetings. The framework can easily be adapted to rapidly changing circumstances within the project process (e.g., varying inputs from end users, additional end user groups) and can be reduced or expanded as needed. The two applications in applied research projects presented in this paper highlight the versatile application of the framework (low-to-high number of partner organizations and countries involved, short-to-long project lifetime), although an empirical evaluation of the framework is still needed. The main advantages (e.g., no face-to-face meetings needed, easily adaptable, reduced workshop time, requirements and use cases directly collected by the end users, user requirements are more concrete and can be better transformed to system specifications, reduced lack of input and reduced, incomplete requirements) and drawbacks (e.g., organization of online events and tools to be used, feedback collection time, time needed to understand the overall project idea and aim) of the framework were presented. The established framework contributes to the complicated task of user requirements collection and use case definition from end users by reducing the potential for typical problems occurring within this process identified in the literature [55]. It provides a transformed way of already existing techniques for the user requirements elicitation [38] into an online environment by following the rules of LEAN project management [30]. This allows a practical application of the requirements process within research projects by providing hands-on guidance and templates for the users. Future work is dedicated to the collection of more feedback through the application in other projects and the continuous improvement of this overarching framework.