User story

About: User story is a research topic. Over the lifetime, 1078 publications have been published within this topic receiving 23717 citations.

Auto-tagging Emails with User Stories Using Project Context

Abstract: In distributed agile teams, people often use email as a knowledge sharing tool to clarify the project requirements (aka user stories). Knowledge about the project included in these emails is easily lost when recipients leave the project or delete emails for various reasons. However, the knowledge contained in the emails may be needed for useful purposes such as re-engineering software, changing vendor and so on. But, it is difficult to relate texts such as emails to certain topics because the relation is not explicit. In this paper, we present and evaluate a technique for automatically relating emails with user stories based on their text and context similarity. Agile project management tools can use this technique to automatically build a knowledge base that is otherwise costly to produce and maintain.

Clarifying Non-functional Requirements to Improve User Acceptance --- Experience at Siemens

Abstract: [Context and motivation] The starting point for software development is usually the system requirements The requirements, especially nonfunctional requirements specified in a document are often incomplete and inconsistent with the initial user needs and expectations [Question/problem] Experience at Siemens showed us that programmers working on software development often have trouble interpreting under-specified non-functional requirements, resulting in code that does not meet the users' quality expectations and contains "quality faults" that can only be detected later through expensive user acceptance testing activities [Principal ideas/results] In this problem statement paper, we investigate the need for clarifying non-functional requirements in software specifications to improve user acceptance In particular we focus on establishing the role of non-functional requirements on user acceptance [Contribution] Our contribution is that we emphasize the need for a systematic empirical study in this area We propose a possible set-up where a number of hypotheses have been developed that a systematic experiment will help to validate Our work is based on industrial experiments at Siemens, in the particular context of the installation of a Product Lifecycle Management (PLM) system

Communication Challenges in Requirements Definition: A Classroom Simulation

Abstract: 1. INTRODUCTION Systems analysis and design is a standard course offering within information systems programs and often an important lecture topic in Information Systems core courses. Given the persistent difficulty that organizations experience in implementing systems that meet their requirements, it is important to help students in these courses get a tangible sense of the challenges they will face, whether as Information Systems practitioners or business professionals, in the systems analysis and design process. This article presents a hands-on design game that focuses in particular on the structuring of opportunities for user participation in requirements definition. The game provides an opportunity to raise central questions about communication, knowledge transfer, and the level and timing of user involvement during systems projects. Students are organized into small groups that adopt multiple roles over the course of a simplified "system" development life cycle. Each group begins in the role of users with the initial articulation of a business need or opportunity, which they simulate by creating a model using Lego blocks. The Lego models are then put away, and pairs of teams exchange roles as users and analysts in conversations focused on preparing requirements documents that will give an account of each user team's model. During the subsequent construction phase, programmer teams attempt to use these requirements documents to recreate the original models. Acceptance testing follows, during which the entire class evaluates pairs of models--in each case, the original model representing the users' business requirements and the corresponding model created by the programmer team. The final step in the exercise is a post-project review, when the class discusses the challenges that arose during the game, and the instructor draws parallels to problems in system implementation practice. This exercise has been used and refined over a period of several years in core courses in information technology management at both the undergraduate and graduate levels and in classes in systems analysis and design. Students find the exercise highly engaging, and the divergent mismatches that always surface between "before" and "after" models are the cause of hilarity and good-natured finger-pointing. (See Figure 1a below with a "before" model on the left and the companion "after" model on the right; the requirements document is in Figure 1b.) [FIGURE 1A OMITTED] [FIGURE 1B OMITTED] The full payoff comes in the final phase, when students, with the instructor's guidance, draw out parallels between the difficulties encountered first-hand in the interpersonal communication of the game and the problems that commonly arise in translating business professionals' requirements via systems analysis for software builders. This also provides an opportunity to explore the implications of alternative project structures for user participation, and to make connections more broadly to issues of IT governance and business-side accountability. We begin our discussion here with some theoretical grounding in user participation issues, and we then explain how the Design Game helps to surface problems in this domain. After a summary overview of the game, step-by-step instructions are offered for conducting the exercise. Next, we provide detailed teaching notes to help guide instructors in preparing materials, integrating the exercise within a course plan, facilitating the related class discussion, and making the most of the game as a metaphor for real-world challenges in user participation. We conclude with some observations on learning outcomes, based on our experiences in using the game. 2. USER PARTICIPATION IN SOFTWARE DEVELOPMENT In the 1980s and 1990s system development methodologies relied upon the identification of known requirements (Valusek and Fryback, 1985) in a manner that didn't accurately model the real world as users experienced it (Land, 1982). …

QUESt: new practices to represent hypotheses in experiment-driven software development

Abstract: Recent studies have proposed the use of experiments to guide software development in order to build features that users really want. In this context, product assumptions should be taken as hypotheses to be tested through experiments. User stories (US) are broadly used in the agile context but current guidelines to write them, like INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable), are not suitable in a experiment-driven context. In this paper, we present the first cycle of a design science research to tackle this problem. We proposed QUESt, a quality guideline recommending US to have a Questioning sense, be Updatable, Evaluable and Straightforward, and a new template to write user stories. To evaluate these new artifacts, we performed a think-aloud evaluation with software development practitioners. Although the results do not confirm the artifacts effectiveness, they indicate that they have value and should be tested within a comprehensive framework complemented by other practices.

The impact of using a domain language for an agile requirements management

Abstract: Context: The development of software systems is a complex activity because of its nature and the management of its construction. It is challenging to create and follow a plan. Moreover, budget overrun is a common consequence of this situation. Agile methods, like Scrum, help to mitigate this problem using incremental and iterative development. Agile methods jump start new developments, but it is difficult to be agile after several months when the software has to deal with many requirements that are scattered and tangled across several User Stories written in different Sprints. Objective: In this paper, we propose a traceability approach anchored on an index structure to access specific User Stories from a large set. Our proposed strategy has the goal to consolidate the information dispersed in different User Stories into a particular lexicon: The Language Extended Lexicon (LEL). Method: The proposed approach consists of a set of rules which extract the information dispersed in the User Stories and organize it in symbols of the Lexicon. Thus, the Lexicon supplies a consolidated and organized structure to mitigate the problem of tangled information that generates lack of traceability among different sprints. Results: We assessed how the Lexicon built by our approach improves everyday activities related to requirement management. The assessment is based on a quantitative evaluation with 36 subjects. Conclusion: The approach presents benefits for requirement tracing in agile methodologies supported by the preliminary results of the evaluation. We have developed an application (a prototype) that automates the LEL derivation rules from a set of User Stories.