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

Interactive Behavior-driven Development: a Low-code Perspective

Within behavior-driven development (BDD), different types of stakeholders collaborate in creating scenarios that specify application behavior. The current workflow for BDD expects non-technical stakeholders to use an integrated development environment (IDE) to write textual scenarios in the Gherkin language and verify application behavior using test passed/failed reports. Research to date shows that this approach leads non-technical stakeholders to perceive BDD as an overhead in addition to the testing. In this vision paper, we propose an alternative approach to specify and verify application behavior visually, interactively, and collaboratively within an IDE. Instead of writing textual scenarios, non-technical stakeholders compose, edit, and save scenarios by using tailored graphical interfaces that allow them to manipulate involved domain objects. Upon executing such interactively composed scenarios, all stakeholders verify the application behavior by inspecting domain-specific representations of run-time domain objects instead of a test run report. Such a low code approach to BDD has the potential to enable nontechnical stakeholders to engage more harmoniously in behavior specification and validation together with technical stakeholders within an IDE. There are two main contributions of this work: (i) we present an analysis of the features of 13 BDD tools, (ii) we describe a prototype implementation of our approach, and (iii) we outline our plan to conduct a large-scale developer survey to evaluate our approach to highlight the perceived benefits over the existing approach

Moldable requirements

Separate tools are employed to carry out individual requirements engineering (RE) activities. The lack of integration among these tools scatters the domain knowledge, making collaboration between technical and non-technical stakeholders difficult, and management of requirements a tedious task. In this Ph.D. research proposal, we argue that an integrated development environment (IDE) should support various RE activities. For that, distinct stakeholders must be able to effortlessly create and manage requirements as first-class citizens within an IDE. With "moldable requirements," developers create custom hierarchies of requirements and build tailored interfaces that enable other stakeholders to create requirements and navigate between them. Similarly, they create custom representations of requirements and involved domain objects to reflect various levels of detail. Such custom and domain-specific representations assist non-technical stakeholders in accomplishing their distinguished RE related tasks. The custom interfaces make the IDE usable for non-technical stakeholders and help to preserve requirements in one place, closer to the implementation

Towards Executable Domain Models

Lack of stakeholder commitment to project activities is an important cause of project failure. It leads to poor understanding of the problem domain and ultimately to incorrect domain modeling. We believe that combining Goal Directed Design methodology with Domain Driven Design using the Naked Objects Pattern would help stakeholders to become actively involved in important project activities such as requirements elicitation and rapid prototyping. This paper suggests how these approaches can gracefully be combined to facilitate active stakeholder involvement right from requirements elicitation until rapid prototyping to build a clear product vision, and realize it through an executable domain model

Towards a Catalogue of Mobile Elicitation Techniques

Mobile apps are crucial for many businesses. Their reach and impact on the end users and on the business in return demands that requirements are elicited carefully and properly. Traditional requirements elicitation techniques may not be adequate in the mobile apps domain. Researchers have proposed numerous requirements elicitation techniques for the mobile app domain, but unfortunately, the community still lacks a comprehensive overview of available techniques. This paper presents a literature survey of about 60 relevant publications, in which we identify 24 techniques that target mobile apps. We found that only every second strategy was evaluated empirically, and even worse, non-functional requirements were rarely considered. We provide an evaluation scheme that is intended to support readers in efficiently finding opportune elicitation techniques for mobile apps. The found literature characteristics may guide future research and help the community to create more efficient, yet better, apps

First-class artifacts as building blocks for live in-IDE documentation

A traditional round-trip engineering approach based on model transformations does not scale well to modern agile development environments where numerous artifacts are produced using a range of heterogeneous tools and technologies. To boost artifact connectivity and maintain their consistency, we propose to create and manage software-related artifacts as first-class entities directly in an integrated development environment (IDE). This approach has two advantages: (i) compared to employing separate tools, creating various artifacts directly within a development platform eliminates the necessity to recover trace links, and (ii) first-class artifacts can be composed into stakeholder-specific live document-artifacts. We detail and exemplify our approach in the Glamorous Toolkit IDE (henceforth, Glamorous toolkit), and discuss the results of a semi-structured pilot survey we conducted with practitioners and researchers to evaluate its usefulness in practice

An Exploratory Study on the Usage of Gherkin Features in Open-Source Projects

With behavior-driven development (BDD), domain experts describe system behavior and desired outcomes through natural language-like sentences, e.g., using the Gherkin language. BDD frameworks partially convert the content of Gherkin specifications into executable test code. Previous studies have reported several issues with the current BDD practice, for example long repetitive Gherkin specifications and slow-running test suites. Data tables and additional features were added to the Gherkin syntax to express compactly test inputs (e.g., provide different combinations of input values and desired outputs to run tests multiple times) and also to improve the readability of Gherkin files (henceforth called spec files). However, there is no empirical evidence about the actual usage of these Gherkin features. To fill this gap, we analyzed the content of 1,572 spec files extracted from 23 open-source projects. For each spec file, we collected a set of metrics modeling the structure and the usage of the different Gherkin features. We found that only a minority of the considered spec files (i.e., 590) used data tables that contain two rows, on average. We also used statistical tests to compare the contents of spec files with and without data tables and found significant differences between the two populations, especially for what concerns the number of lines of code (LoC). On the one hand, our results shed some light on the discrepancies between the recommendations for defining Gherkin specifications and their actual adoption in practice. On the other hand, our findings demonstrate that the adoption of additional features, such as data tables, might only partially help to reduce the length of Gherkin specifications