Showing papers on "User story published in 2021"

Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review

Abstract: Following the highly pervasive and effective use of agile methods at the team level, many software organisations now wish to replicate this success at the organisational level, adopting large-scale agile methods such as SAFe, Scrum-at-Scale, and others However, this has proven significantly challenging An analysis of the extant literature reveals a disparate set of studies across each individual method, with no cross-method comparison based on empirical evidence This systematic literature review compares the main large-scale agile methods, namely SAFe, LeSS, Scrum-at-Scale, DAD, and the Spotify model It is the first study to analyse and compare each of the method's principles, practices, tools, and metrics in a standardised manner For each method, it presents not just the original method specifications but also all extensions and modifications to each method proposed by subsequent empirical research It includes in this comparison not just commercial large-scale methods but also those that have been custom-built in organisations such as Nokia, Ericsson, and others Based on the findings reported in this study, practitioners can make a more informed decision as to which commercial method or method component or, indeed, custom-built method is better suited to their needs Our study reveals a number of theoretical and practical issues in the current literature, such as an emphasis on the practices of commercial frameworks at the expense of their underlying principles, or indeed any of the custom method A set of challenges and success factors associated with the use of large-scale agile methods are identified The study also identifies a number of research gaps to be addressed across methods

User Stories and Natural Language Processing: A Systematic Literature Review

Abstract: Context: User stories have been widely accepted as artifacts to capture the user requirements in agile software development. They are short pieces of texts in a semi-structured format that express requirements. Natural language processing (NLP) techniques offer a potential advantage in user story applications. Objective: Conduct a systematic literature review to capture the current state-of-the-art of NLP research on user stories. Method: The search strategy is used to obtain relevant papers from SCOPUS, ScienceDirect, IEEE Xplore, ACM Digital Library, SpringerLink, and Google Scholar. Inclusion and exclusion criteria are applied to filter the search results. We also use the forward and backward snowballing techniques to obtain more comprehensive results. Results: The search results identified 718 papers published between January 2009 to December 2020. After applying the inclusion/exclusion criteria and the snowballing technique, we identified 38 primary studies that discuss NLP techniques in user stories. Most studies used NLP techniques to extract aspects of who, what, and why from user stories. The purpose of NLP studies in user stories is broad, ranging from discovering defects, generating software artifacts, identifying the key abstraction of user stories, and tracing links between model and user stories. Conclusion: NLP can help system analysts manage user stories. Implementing NLP in user stories has many opportunities and challenges. Considering the exploration of NLP techniques and rigorous evaluation methods is required to obtain quality research. As with NLP research in general, the ability to understand a sentence’s context continues to be a challenge.

How to Write Ethical User Stories? : Impacts of the ECCOLA Method

Abstract: Artificial Intelligence (AI) systems are increasing in significance within software services. Unfortunately, these systems are not flawless. Their faults, failures and other systemic issues have emphasized the urgency for consideration of ethical standards and practices in AI engineering. Despite the growing number of studies in AI ethics, comparatively little attention has been placed on how ethical issues can be mitigated in software engineering (SE) practice. Currently understanding is lacking regarding the provision of useful tools that can help companies transform high-level ethical guidelines for AI ethics into the actual workflow of developers. In this paper, we explore the idea of using user stories to transform abstract ethical requirements into tangible outcomes in Agile software development. We tested this idea by studying master’s level student projects (15 teams) developing web applications for a real industrial client over the course of five iterations. These projects resulted in 250+ user stories that were analyzed for the purposes of this paper. The teams were divided into two groups: half of the teams worked using the ECCOLA method for AI ethics in SE, while the other half, a control group, was used to compare the effectiveness of ECCOLA. Both teams were tasked with writing user stories to formulate customer needs into system requirements. Based on the data, we discuss the effectiveness of ECCOLA, and Primary Empirical Contributions (PECs) from formulating ethical user stories in Agile development.

Linguistic Patterns and Linguistic Styles for Requirements Specification: Focus on Data Entities

Abstract: Requirements specification includes technical concerns of an information system and is used throughout its life cycle. It allows for sharing the vision of the system among stakeholders and facilitates its development and operation processes. Natural languages are the most common form of requirements representation, however, they also exhibit characteristics that often introduce quality problems, such as inconsistency, incompleteness, and ambiguousness. This paper adopts the notions of linguistic pattern and linguistic style and discusses their relevance to produce better technical documentation. It focuses on the textual specification of data entities, which are elements commonly referred to throughout different types of requirements, like use cases, user stories, or functional requirements. This paper discusses how to textually represent the following elements: data entity, attribute, data type, data entity constraint, attribute constraint, and even cluster of data entities. This paper shows concrete examples and supports the discussion with three linguistic styles, represented by a rigorous requirements specification language and two informal controlled natural languages, one with a more compact and another with a more verbose, expressive, and complete representation. We analyzed how other languages cope with the representation of these data entity elements and complemented that analysis and comparison based on the PENS classification scheme. We conducted a pilot evaluation session with nineteen professional subjects who participated and provided encouraging feedback, with positive scores in all the analyzed dimensions. From this feedback, we preliminarily conclude that the adoption of these linguistic patterns would help to produce better requirements specifications written more systematically and consistently.

Implementation Science Meets Software Development to Create eHealth Components for an Integrated Care Model for Allogeneic Stem Cell Transplantation Facilitated by eHealth: The SMILe Study as an Example.

Abstract: Purpose To describe a process of creating eHealth components for an integrated care model using an agile software development approach, user-centered design and, via the Behavior Change Wheel, behavior theory-guided content development. Following the principles of implementation science and using the SMILe project (integrated care model for allogeneic stem cell transplantation facilitated by eHealth) as an example, this study demonstrates how to narrow the research-to-practice gap often encountered in eHealth projects. Methods We followed a four-step process: (a) formation of an interdisciplinary team; (b) a contextual analysis to drive the development process via behavioral theory; (c) transfer of content to software following agile software development principles; and (d) frequent stakeholder and end user involvement following user-centered design principles. Findings Our newly developed comprehensive development approach allowed us to create a running eHealth component and embed it in an integrated care model. An interdisciplinary team's collaboration at specified interaction points supported clear, timely communication and interactions between the specialists. Because behavioral theory drove the content development process, we formulated user stories to define the software features, which were prioritized and iteratively developed using agile software development principles. A prototype intervention module has now been developed and received high ratings on the System Usability Scale after two rounds of usability testing. Conclusions Following an agile software development process, structured collaboration between nursing scientists and software specialists allowed our interdisciplinary team to develop meaningful, theory-based eHealth components adapted to context-specific needs. Clinical relevance The creation of high-quality, accurately fitting eHealth components specifically to be embedded in integrated care models should increase the chances of uptake, adoption, and sustainable implementation in clinical practice.

On deriving conceptual models from user requirements: An empirical study

Abstract: Context: There are numerous textual notations and techniques that can be used in requirements engineering. Currently, practitioners make a choice without having scientific evidence regarding their suitability for given tasks. This uninformed choice may affect task performance. Objective: In this research, we investigate the adequacy of two well-known notations: use cases and user stories, as a starting point for the manual derivation of a structural conceptual model that represents the domain of the system. We also examine other factors that may affect the performance of this task. Methods: This work relies on two experiments. The first is a controlled classroom experiment. The second one is a quasi-experiment, conducted over multiple weeks, that aims at evaluating the quality of the derived conceptual model in light of the notation used, the adopted derivation process, and the complexity of the system to be. We measure quality in terms of validity and completeness of the conceptual model. Results: The results of the controlled experiment indicate that, for deriving conceptual models, user stories fit better than use cases. Yet, the second experiment indicates that the quality of the derived conceptual models is affected mainly by the derivation process and by the complexity of the case rather than the notation used. Contribution: We present evidence that the task of deriving a conceptual model is affected significantly by additional factors other than requirements notations. Furthermore, we propose implications and hypotheses that pave the way for further studies that compare alternative notations for the same task as well as for other tasks. Practitioners may use our findings to analyze the factors that affect the quality of the conceptual model when choosing a requirements notation and an elicitation technique that best fit their needs.

Learnings from the design and acceptance of the German COVID-19 tracing app for IS-driven crisis management: a design science research.

Abstract: BACKGROUND: This article investigates the research problem of digital solutions to overcome the pandemic, more closely examining the limited effectiveness and scope of the governmental COVID-19 tracing apps, using the German COVID-19 tracing app (Corona-Warn-App) as an example. A well-designed and effective instrument in the technological toolbox is of utmost importance to overcome the pandemic. METHOD: A multi-methodological design science research approach was applied. In three development and evaluation cycles, we presented, prototyped, and tested user-centered ideas of functional and design improvement. The applied procedure contains (1) a survey featuring 1993 participants from Germany for evaluating the current app, (2) a gathering of recommendations from epidemiologists and from a focus group discussion with IT and health experts identifying relevant functional requirements, and (3) an online survey combined with testing our prototype with 53 participants to evaluate the enhanced tracing app. RESULTS: This contribution presents 14 identified issues of the German COVID-19 tracing app, six meta-requirements, and three design principles for COVID-19 tracing apps and future pandemic apps (e.g., more user involvement and transparency). Using an interactive prototype, this study presents an extended pandemic app, containing 13 potential front-end (i.e., information on the regional infection situation, education and health literacy, crowd and event notification) and six potential back-end functional requirements (i.e., ongoing modification of risk score calculation, indoor versus outdoor). In addition, a user story approach for the COVID-19 tracing app was derived from the findings, supporting a holistic development approach. CONCLUSION: Throughout this study, practical relevant findings can be directly transferred to the German and other international COVID-19 tracing applications. Moreover, we apply our findings to crisis management theory-particularly pandemic-related apps-and derive interdisciplinary learnings. It might be recommendable for the involved decision-makers and stakeholders to forego classic application management and switch to using an agile setup, which allows for a more flexible reaction to upcoming changes. It is even more important for governments to have a well-established, flexible, design-oriented process for creating and adapting technology to handle a crisis, as this pandemic will not be the last one.

Prototype of Web System for Organizations Dedicated to e-Commerce under the SCRUM Methodology

Abstract: This research work is based on making a prototype e-commerce system applying the scrum methodology, because currently the systems of many organizations are still developed following traditional methodologies, i.e. the system does not meet the requirements that should provide value to the organization in addition to its poor information security, leading to the organization's data to the vulnerability of loss or theft. That is why this article aims to design a web system for organizations dedicated to e-commerce under the agile SCRUM methodology. The methodology allowed to design the prototype meeting the needs of the organization with frequent retrospectives and continuous communication between stakeholders, in addition to proposing the information security of the company's data. In the results of this research the user stories were analyzed, which allowed the division into 4 Sprint deliverables of the general modules proposed in the article, for which a maximum score of 21 story points per Sprint was placed; in which 16 story points were placed to the first sprint, the second Sprint with 20 story points, the third Sprint with 21 story points and the fourth Sprint with 16 story points. The e-commerce system proposal will be beneficial for the organization and its customers, since it will allow them to have a system according to their requirements and needs in a secure manner.

A Named Entity Recognition Based Approach for Privacy Requirements Engineering

Abstract: The presence of experts, such as a data protection officer (DPO) and a privacy engineer is essential in Privacy Requirements Engineering. This task is carried out in various forms including threat modeling and privacy impact assessment. The knowledge required for performing privacy threat modeling can be a serious challenge for a novice privacy engineer. We aim to bridge this gap by developing an automated approach via machine learning that is able to detect privacy-related entities in the user stories. The relevant entities include (1) the Data Subject, (2) the Processing, and (3) the Personal Data entities. We use a state-of-the-art Named Entity Recognition (NER) model along with contextual embedding techniques. We argue that an automated approach can assist agile teams in performing privacy requirements engineering techniques such as threat modeling, which requires a holistic understanding of how personally identifiable information is used in a system. In comparison to other domain-specific NER models, our approach achieves a reasonably good performance in terms of precision and recall.

Conceptual Modeling Versus User Story Mapping: Which is the Best Approach to Agile Requirements Engineering?

Abstract: User stories are primary requirements artifacts within agile methods. They are comprised of short sentences written in natural language expressing units of functionality for the to-be system. Despite their simple format, when modelers are faced with a set of user stories they might be having difficulty in sorting them, evaluating their redundancy, and assessing their relevancy in the effort to prioritize them. The present paper tests the ability of modelers to understand the requirements problem through a visual representation (named the Rationale Tree) which is a conceptual model and is built out of a user stories’ set. The paper is built upon and extends previous work relating to the feasibility of generating such a representation out of a user stories’ set by comparing the performance of the Rationale Tree with the User Story Mapping approach. This is achieved by performing a two-group quantitative comparative study. The identified comparative variables for each method were understandability, recognition of missing requirements/epics/themes, and adaptability. The Rational Tree was not easy to understand and did not perform as anticipated in assisting with the recognition of missing requirements/epics/themes. However, its employment allowed modelers to offer qualitative representations of a specific software problem. Overall, the present experiment evaluates whether a conceptual model could be a consistent solution towards the holistic comprehension of a software development problem within an agile setting, compared to more ‘conventional’ techniques used so far.

How to do it with sticky notes: a method for exploring expert knowledge to prepare guidelines for practice in railway vehicle maintenance

Abstract: The process of describing human activities in procedures has been used since the beginning of the 20th century. However, it...

From Ideas to Expressed Needs: an Empirical Study on the Evolution of Requirements during Elicitation

Abstract: Requirements are elicited from the customer and other stakeholders through an iterative process of interviews, prototyping, and other interactive sessions. Many communication phenomena may emerge in these early iterations, that lead initial ideas to be transformed, renegotiated, or reframed. Understanding how this process takes place can help in solving possible communication issues as well as their consequences. In this work, we perform an exploratory study of descriptive nature to understand in which way requirements get transformed from initial ideas into documented needs. To this end, we select 30 subjects that act as requirements analysts, and we perform a set of elicitation sessions with a fictional customer. The customer is required to study a sample requirements document for a system beforehand and to answer the questions of the analysts about the system. After the elicitation sessions, the analysts produce user stories for the system. These are compared with the original ones by two researchers to assess to which extent and in which way the initial requirements evolved throughout the interactive sessions. Our results show that between 30% and 38% of the produced user stories include content that can be fully traced to the initial ones, while the rest of the content is dedicated to new requirements. We also show what types of requirements are introduced through the elicitation process, and how they vary depending on the analyst. Our work contributes to theory in requirements engineering, with empirically grounded, quantitative data, concerning the impact of elicitation activities with respect to initial ideas.

A Cost Estimating Method for Agile Software Development

Abstract: In every software development project, the software effort estimating procedure is an important process in software engineering and always critical. The consistency of effort and timeline estimation, along with several factors, determines whether a project succeeds or fails. Both academics and professionals worked on the estimation approaches in software engineering. But, all these approaches have many problems that need to be addressed. One of the most difficult aspects of software engineering is estimating effort in agile development. This study aims to provide an effort estimation method for agile software development projects. Because in software engineering, the agile method is widely used for the development of software applications. The development and usage of the agile method are described in depth in this study. The framework is configured with empirical data gathered by projects from the software industry. The test findings reveal that the estimation method has great estimation accuracy in respect of mean magnitude of relative error (MMRE) and Prediction of Error PRED (n). The suggested approach achieves more accuracy for effort estimation as compare to others.

A human-centric approach to building a smarter and better parking application

Abstract: Finding a parking space can be very stressful and time consuming. A variety of different vehicle parking applications have been developed but many fail to support diverse end-users. We captured diverse human-centric issues from user reviews and literature, and then created personas that encompass a wide representative range of parking app user groups. Using these personas, user stories were created, categorized and parking app tasks prioritized. We used these to develop a prototype new "smart parking app". A cognitive walk-through was employed using each of the personas and user stories to evaluate the app. With more human-centric factors taken into account in the design and development of the app, we found that majority of the human-centric frustrations identified were resolved, when compared with a commonly used parking app.

Empirical Findings on BDD Story Parsing to Support Consistency Assurance between Requirements and Artifacts

Abstract: Behaviour-Driven Development (BDD) stories have gained considerable attention in recent years as an effective way to specify and test user requirements in agile software development projects. External testing frameworks also allow developers to automate the execution of BDD stories and check whether a fully functional software system behaves as expected. However, other software artifacts may quite often lose synchronization with the stories, and many inconsistencies can arise with respect to requirements representation. This paper reports on preliminary empirical findings regarding the performance of two existing approaches in the literature intended to support consistency assurance between BDD stories and software artifacts. The first approach involves the parsing of BDD stories in order to identify conceptual elements to automatically generate consistent class diagrams, while the second approach seeks to identify interaction elements to automatically assess the consistency of task models and GUI prototypes. We report on the precision of these approaches when applied to a study with BDD stories previously written by Product Owners (POs). Based on the results, we also identify a set of challenges and opportunities for BDD stories in the consistency assurance of such artifacts.

iMER: Iterative process of entity relationship and business process model extraction from the requirements

Abstract: Context Extracting conceptual models, e.g., entity relationship model or Business Process model, from software requirement document is an essential task in the software development life cycle. Business process model presents a clear picture of required system's functionality. Operations in business process model together with the data entity consumed, help the software developers to understand the database design and operations to be implemented. Researchers have been aiming at automatic extraction of these artefacts from the requirement document. Objective In this paper, we present an automated approach to extract the entity relationship and business process models from requirements, which are possibly in different formats such as general requirements, use case specification and user stories. Our approach is based on the efficient natural language processing techniques. Method It is an iterative approach of Models Extraction from the Requirements (iMER). iMER has multiple iterations where each iteration is to address a sub-problem. In the first iteration, iMER extracts the data entities and attributes. Second iteration is to find the relationships between data entities, while extracting cardinalities is in the third step. Business process model is generated in the fourth iteration, containing the external (actors’) and internal (system's) operations. Evaluation To evaluate the performance and accuracy of iMER, experiments are conducted on various formats of the requirement documents. Additionally, we have also evaluated our approaches using the requirement documents which been modified by shuffling the sentences and by merging with other requirements. Comparative study is also performed. The preliminary results show a noticeable improvement. Conclusion The iMER is an efficient automated iterative approach that is able to extract the conceptual models from the various formats of requirements.

Extending the Participant’s Voice to Guide Artificial Intelligence Transformation Using Futures Methodology and Layered User Story Analysis:

Abstract: Artificial intelligence (AI) is a vital driver of the next wave of automatisation of Industry 4.0. It impacts product-based and service-based organisations and is becoming an investment stream in o...

Alignment and granularity of requirements and architecture in agile development: A functional perspective

Abstract: Context: Requirements engineering and software architecture are tightly linked disciplines The Twin Peaks model suggests that requirements and architectural components should stay aligned while the system is designed and as the level of detail increases Unfortunately, this is hardly the case in practical settings Objective: We surmise that a reason for the absence of conjoint evolution is that existing models, such as the Twin Peaks, do not provide concrete guidance for practitioners We propose the Requirements Engineering for Software Architecture (RE4SA) model to assist in analyzing the alignment and the granularity of functional requirements and architectural components Methods: After detailing the RE4SA model in notation-independent terms, we propose a concrete instance, called RE4SA-Agile, that connects common artifacts in agile development, such as user stories and features We introduce metrics that measure the alignment between the requirements and architecture, and we define granularity smells to pinpoint situation in which the granularity of one high-level requirement or high-level component is not uniform with the norm We show two applications of RE4SA-Agile, including the use of the metrics, to real-world case studies Results: Our applications of RE4SA-Agile, which were discussed with representatives from the development teams, prove to be able to pinpoint problematic situations regarding the relationship between functional requirements and architecture Conclusion: RE4SA and its metrics can be seen as a first attempt to provide a concrete approach for supporting the application of the Twin Peaks model We expect future research to apply our metrics to additional cases and to provide variants for RE4SA that support different concrete notations, and extend the perspective beyond the functional perspective of this research, similar to what we did with RE4SA-Agile in this paper

Agile Islands in a Waterfall Environment: Requirements Engineering Challenges and Strategies in Automotive.

Abstract: [Context & motivation] Driven by the need for faster time-to-market and reduced development lead-time, large-scale systems engineering companies are adopting agile methods in their organizations. This agile transformation is challenging and it is common that adoption starts bottom-up with agile software teams within the context of traditional company structures. [Question/Problem] This creates the challenge of agile teams working within a document-centric and plan-driven (or waterfall) environment. While it may be desirable to take the best of both worlds, it is not clear how that can be achieved especially with respect to managing requirements in large-scale systems. [Principal ideas/Results] This paper presents an exploratory case study at an automotive company, focusing on two departments of a large-scale systems company that is in the process of company-wide agile adoption. [Contribution] We present challenges related to requirements engineering that agile teams face while working within a larger plan-driven context and propose potential strategies to mitigate the challenges. Challenges relate to, e.g., development teams not being aware of the high-level requirement and dealing with flexibility of writing user stories. We found that strategies for overcoming most of these challenges are still lacking and thus call for more research.

Towards Just-Enough Documentation for Agile Effort Estimation: What Information Should Be Documented?

Abstract: Effort estimation is an integral part of activities planning in Agile iterative development. An Agile team estimates the effort of a task based on the available information which is usually conveyed through documentation. However, as documentation has a lower priority in Agile, little is known about how documentation effort can be optimized while achieving accurate estimation. Hence, to help practitioners achieve just-enough documentation for effort estimation, we investigated the different types of documented information that practitioners considered useful for effort estimation. We conducted a survey study with 121 Agile practitioners across 25 countries. Our survey results showed that (1) despite the lower priority of documentation in Agile practices, 98% of the respondents considered documented information moderately to extremely important when estimating effort, (2) 73% of them reported that they would re-estimate a task when the documented information was changed, and (3) functional requirements, user stories, definition of done, UI wireframes, acceptance criteria, and task dependencies were ranked as the most useful types of documented information for effort estimation. Nevertheless, many respondents reported that these useful types of documented information were occasionally changing or missing. Based on our study results, we provide recommendations for agile practitioners on how effort estimation can be improved by focusing on just-enough documentation.

Access Control Policy Generation from User Stories Using Machine Learning

Abstract: Agile software development methodology involves developing code incrementally and iteratively from a set of evolving user stories. Since software developers use user stories to write code, these user stories are better representations of the actual code than that of the high-level product documentation. In this paper, we develop an automated approach using machine learning to generate access control information from a set of user stories that describe the behavior of the software product in question. This is an initial step to automatically produce access control specifications and perform automated security review of a system with minimal human involvement. Our approach takes a set of user stories as input to a transformers-based deep learning model, which classifies if each user story contains access control information. It then identifies the actors, data objects, and operations the user story contains in a named entity recognition task. Finally, it determines the type of access between the identified actors, data objects, and operations through a classification prediction. This information can then be used to construct access control documentation and information useful to stakeholders for assistance during access control engineering, development, and review.

Bluejay: A Cross-Tooling Audit Framework For Agile Software Teams

Abstract: Agile software teams are expected to follow a number of specific Team Practices (TPs) during each iteration, such as estimating the effort ("points") required to complete user stories and coordinating the management of the codebase with the delivery of features. For software engineering instructors trying to teach such TPs to student teams, manually auditing teams if teams are following the TPs and improving over time is tedious, time-consuming and error-prone. It is even more difficult when those TPs involve two or more tools. For example, starting work on a feature in a project-management tool such as Pivotal Tracker should usually be followed relatively quickly by the creation of a feature branch on GitHub. Merging a feature branch on GitHub should usually be followed relatively quickly by deploying the new feature to a staging server for customer feedback. Few systems are designed specifically to audit such TPs, and existing ones, as far as we know, are limited to a single specific tool. We present Bluejay, an open-source extensible platform that uses the APIs of multiple tools to collect raw data, synthesize it into TP measurements, and present dashboards to audit the TPs. A key insight in Bluejay's design is that TPs can be expressed in terminology similar to that used for modeling and auditing Service Level Agreement (SLA) compliance. Bluejay therefore builds on mature tools used in that ecosystem and adapts them for describing, auditing, and reporting on TPs. Bluejay currently consumes data from five different widely-used development tools, and can be customized by connecting it to any service with a REST API. Video showcase available at governify.io/showcase/bluejay

Agile Requirements Engineering: From User Stories to Software Architectures

Abstract: Most agile practitioners employ user stories for capturing requirements, also thanks to the embedding of this notation within development and project management tools. Among user story users, circa 70% follow a simple template: As a role, I want to action, so that benefit. User stories’ popularity among practitioners and their template-based structure make them ideal candidates for the application of natural language processing techniques. In our research, we have found that circa 50% of real-world user stories contain easily preventable linguistic defects. To mitigate this problem, we have created tool-supported methods that facilitate the creation of better user stories. This tutorial combines previous work of the RE-Lab@UU into a pipeline for working with user stories: (1) The basics of creating user stories and their use in requirements engineering; (2) How to improve user story quality with the Quality User Story Framework and the AQUSA tool; (3) How to generate conceptual models from user stories using the Visual Narrator tool and analyze them for possible ambiguity and inconsistency; and (4) How to link requirements to architectures via the RE4SA model. Our approach is demonstrated with results obtained from 20+ software companies employing user stories.

On the impact of using different templates on creating and understanding user stories

Abstract: Context: User stories are often used for elicitation and prioritisation of requirements. However, the lack of a widely adopted user story template, covering benefit and the usage (or not) of a persona, can affect user stories’ quality, leading to ambiguity, lack of completeness, or accidental complexity. Objectives: Our goal was to analyse the differences between 4 alternative user story templates when creating and understanding user stories. Methods: We conducted a quasi-experiment. We asked 41 participants to perform creation and understanding tasks with the user story templates. We measured their accuracy, using metrics of task success; their speed, with task duration; visual effort, collected with an eye-tracker; and participants’ perceived effort, evaluated with NASA-TLX. Results: Regarding the impact of the different templates in creating user stories, we observed statistically significant differences in some of the metrics for accuracy, speed and visual effort. For understanding user stories, we observed small differences in terms of visual effort. Conclusions: Although some templates outperformed others in a few metrics, no template obtained the best overall result. As such, we found no compelling evidence that one template is "better" than the others.

The Quality Triage Method: Quickly Identifying User Stories with Quality Risks

Abstract: Quality requirements often receive insufficient attention, both in agile and in traditional software development. This paper describes the quality triage, a quick, agile method in which user stories or features with quality risks are identified. This paper shows how the four qualities scalability, security, safety, and availability are scored at short expert meetings ― triages. In this way, quality risks are made explicit and can be immediately addressed. We illustrate the method with a scenario involving semi-autonomous cars.

Understanding Users Through Three Types of Personas

Abstract: Personas is a suggested method to extend IT professionals' understanding of users and users’ needs. A common advantage expressed is that personas extend the IT professionals’ empathy for the users, but a disadvantage is that personas are typically defined at the start of a software project and gradually are forgotten, since there is little reference to the personas through the software development project. In this paper we report experiences of coaching IT professionals in defining agile user stories based on personas, called: Persona User Stories (PUS). The aim of these workshops, was to extend the usage of personas and thereby extend the IT professionals’ understanding of their users. In a research project with three companies, we coached teams of IT professionals in three-hour workshops with 76 participants in total. The workshops were conducted at each company using personas already defined by the IT professionals. The persona descriptions were based on three types of information: (a) assumptions, (b) secondary research, and (c) data specific to a project. Our findings show that personas based on assumptions result in the participants questioning the description of the personas and having difficulties in understanding the personas. For making the persona user stories (PUS), the participants used themselves more often as a reference when working with the assumption based personas, than the participants using the other two types of personas.

Software Requirement-Related Information Extraction from Online News using Domain Specificity for Requirements Elicitation: How the system analyst can get software requirements without constrained by time and stakeholder availability

Abstract: Stakeholder involvement is vital in the requirements elicitation process. However, a lack of stakeholder involvement in the project often occurs. Various data sources, such as business processes and software documentation, will help determine what stakeholders need. The limitation of these documents is that they are technical and do not contain numerous stakeholder's needs. This paper aims to extract information related to software requirements from online news using domain specificity. The online news comprises elements that compose the user story, namely: the aspect of who (stakeholder), the aspect of what (functional), and the aspect of why (reason). User stories are standard practices used to capture and write functional software requirements in agile software development. This paper proposes to use domain specificity to extract aspects of what from online news to increase understanding of domain knowledge, especially software functionality. We use SRS documents and online news as data sources. Based on these datasets, domain specificity is calculated to produce software specific vocabulary. POS tags are being used to extract software requirements-related information from online news. When examining two datasets, our approach improved precision and recall with average values of 0.56 and 0.579.

Cultivating Urban Big Data

Abstract: Urban big data often contain spatial and temporal elements that have increasingly become an integral part of various applications and projects such as smart mobility, smart city, and other digitally enhanced urban infrastructure. It is critical to develop an open and collaborative environment so that these data can be used by a wide range of users. This chapter first discusses some characteristics and sources of urban big data. Three hypothetical user stories are described to highlight the potential of these data. After describing the internal data structure of these data and techniques that can be used to retrieve the data, we discuss the difficulty in making the data useful for the general public and elaborate on a self-organizing agile approach to developing an urban big data infrastructure.

From Service-Orientation to Agile Development by Conceptually Linking Business IT Services and User Stories: A Meta-Model and a Process Fragment

Abstract: IT services are being built by IT departments and other service providers to address the core technological requirements of organizations. Even if these services solve operational issues, their adoption – because of their internal behavior – has a sustaining or non-sustaining impact on the (long term) strategy of the organization. This impact is called the Business and IT alignment (BITA); as such, it is problematic to estimate before the development of the service without a view on its design. To be properly done, BITA evaluation indeed needs details about the service run-time behavior. Conversely, the agile wave refrains from a detailed upfront software design; functions providing high operational value to users are indeed selected and built for one sprint at a time. The mismatch between a traditional service approach and an agile way of development is therefore quite obvious. The present paper proposes a method (called Agile-MoDrIGo) to reconcile these two approaches. For this purpose, it (i) decomposes services into epic user stories under the scope of which (user-level built) user stories can be mapped (i.e. functional alignment) and (ii) links services as (coarse-grained) conceptual elements along with the strategic objectives they sustain to fine-grained user story functional elements for value-driven prioritization (i.e. strategic alignment). The proposal is presented in the form of a meta-model and supported by a process fragment; it is validated on a case study in healthcare.

An Empirical Study of User Story Quality and Its Impact on Open Source Project Performance

Abstract: When software development teams apply Agile Software Development practices, they commonly express their requirements as User Stories. We aim to study the quality of User Stories and its evolution over time. Firstly, we develop a method to automatically monitor the quality of User Stories. Secondly, we investigate the relationship between User Story quality and project performance measures such as the number of reported bugs and the occurrence of rework and delays. We measure User Story quality with the help of a recently published quality framework and tool, Automatic Quality User Story Artisan (AQUSA). For our empirical work, we use six agile open source software projects. We apply time series analysis and use the Windowed Time Lagged Cross Correlation (WTLCC) method. Our results indicate that automatic User Story quality monitoring is feasible and may result in various distinct dynamic evolution patterns. In addition, we found the following relationship patterns between User Story quality and the software development aspects. A decrease/increase in User Story quality scores is associated with (i) a decrease/increase of the number of bugs after 1–13 weeks in short-medium projects, and 12 weeks in longer ones, (ii) an increase in rework frequency after 18–28, 8–15, and 1–3 weeks for long, medium, and short projects, respectively, and (iii) an increase in delayed issues after 7–20, 8–11, and 1–3 weeks for long, medium, and short duration projects.