The Next Generation of Human-Drone Partnerships: Co-Designing an Emergency Response System

The use of semi-autonomous Unmanned Aerial Vehicles (UAV) to support emergency response scenarios, such as fire surveillance and search and rescue, offers the potential for huge societal benefits. However, designing an effective solution in this complex domain represents a "wicked design" problem, requiring a careful balance between trade-offs associated with drone autonomy versus human control, mission functionality versus safety, and the diverse needs of different stakeholders. This paper focuses on designing for situational awareness (SA) using a scenario-driven, participatory design process. We developed SA cards describing six common design-problems, known as SA demons, and three new demons of importance to our domain. We then used these SA cards to equip domain experts with SA knowledge so that they could more fully engage in the design process. We designed a potentially reusable solution for achieving SA in multi-stakeholder, multi-UAV, emergency response applications.Comment: 10 Pages, 5 Figures, 2 Tables. This article is publishing in CHI202

Supporting Multiple Stakeholders in Agile Development

Agile software development practices require several stakeholders with different kinds of expertise to collaborate while specifying requirements, designing and modeling software, and verifying whether developers have implemented requirements correctly. We studied 112 requirements engineering (RE) tools from academia and the features of 13 actively maintained behavior-driven development (BDD) tools, which support various stakeholders in specifying and verifying the application behavior. Overall, we found that there is a growing tool specialization targeted towards a specific type of stakeholders. Particularly with BDD tools, we found no adequate support for non-technical stakeholders —- they are required to use an integrated development environment (IDE) —- which is not adapted to suit their expertise. We argue that employing separate tools for requirements specification, modeling, implementation, and verification is counter-productive for agile development. Such an approach makes it difficult to manage associated artifacts and support rapid implementation and feedback loops. To avoid dispersion of requirements and other software-related artifacts among separate tools, establish traceability between requirements and the application source code, and streamline a collaborative software development workflow, we propose to adapt an IDE as an agile development platform. With our approach, we provide in-IDE graphical interfaces to support non-technical stakeholders in creating and maintaining requirements concurrently with the implementation. With such graphical interfaces, we also guide non-technical stakeholders through the object-oriented design process and support them in verifying the modeled behavior. This approach has two advantages: (i) compared with employing separate tools, creating and maintaining requirements directly within a development platform eliminates the necessity to recover trace links, and (ii) various natively created artifacts can be composed into stakeholder-specific interactive live in-IDE documentation. These advantages have a direct impact on how various stakeholders collaborate with each other, and allow for rapid feedback, which is much desired in agile practices. We exemplify our approach using the Glamorous Toolkit IDE. Moreover, the discussed building blocks can be implemented in any IDE with a rich-enough graphical engine and reflective capabilities

Supporting multiple stakeholders in agile development

Agile software development practices require several stakeholders with different kinds of expertise to collaborate while specifying requirements, designing, and modelling software, and verifying whether developers have implemented requirements correctly. We studied 112 requirements engineering (RE) tools from academia and the features of 13 actively maintained behavior-driven development (BDD) tools, which support various stakeholders in specifying and verifying the application behavior. Overall, we found that there is a growing tool specialization targeted towards a specific type of stakeholders. Particularly with BDD tools, we found no adequate support for non-technical stakeholders-- they are required to use an integrated development environment (IDE)-- which is not adapted to suit their expertise. We argue that employing separate tools for requirements specification, modelling, implementation, and verification is counterproductive for agile development. Such an approach makes it difficult to manage associated artifacts and support rapid implementation and feedback loops. To avoid dispersion of requirements and other software-related artifacts among separate tools, establish traceability between requirements and the application source code, and streamline a collaborative software development workflow, we propose to adapt an IDE as an agile development platform. With our approach, we provide in-IDE graphical interfaces to support non-technical stakeholders in creating and maintaining requirements concurrently with the implementation. With such graphical interfaces, we also guide non-technical stakeholders through the object-oriented design process and support them in verifying the modelled behavior. This approach has two advantages: (i) compared with employing separate tools, creating, and maintaining requirements directly within a development platform eliminates the necessity to recover trace links, and (ii) various natively created artifacts can be composed into stakeholder-specific interactive live in-IDE documentation. These advantages have a direct impact on how various stakeholders collaborate with each other, and allow for rapid feedback, which is much desired in agile practices. We exemplify our approach using the Glamorous Toolkit IDE. Moreover, the discussed building blocks can be implemented in any IDE with a rich-enough graphical engine and reflective capabilities

A Qualitative Study on Using GuideGen to Keep Requirements and Acceptance Tests Aligned

Software requirements constantly change, thus impacting all other artifacts of an evolving system. In order to keep the system in a consistent state, changes in requirements should be documented and applied accordingly to all affected artifacts, including acceptance tests. In practice, however, changes in requirements are not always documented nor applied to the affected acceptance tests. This is mostly due to poor communication, lack of time or work overload, and eventually leads to project delays, unintended costs and unsatisfied customers. GuideGen is a tool-supported approach for keeping requirements and acceptance tests aligned. When a requirement is changed, GuideGen automatically generates guidance in natural language on how to modify impacted acceptance tests and communicates this information to the concerned parties. In this paper, we evaluate GuideGen in terms of its perceived usefulness for practitioners and its applicability to real software projects. The evaluation was conducted via interviews with 23 industrial practitioners from ten companies based in Europe. The results indicate that GuideGen is a useful approach that facilitates requirements change management and the communication of changes between requirements and test engineers. The participants also identified potential for improvement, in particular for using GuideGen in large projects