Topic
User story
About: User story is a research topic. Over the lifetime, 1078 publications have been published within this topic receiving 23717 citations.
Papers published on a yearly basis
Papers
More filters
••
01 Aug 2018
TL;DR: The basic idea, several generally applicable development patterns (including patterns for the important and well-known class of CRUD functions), and various examples are presented, leading into the direction of Pattern-Driven Requirements Engineering (PaDRE).
Abstract: A recent paper answered the question how to come from initial user wishes up to a running system in a straightforward, transparent, modular, traceable, feasible, and agile way. That paper sketched a complete development path for functional requirements, starting from user stories via use cases and their system sequence diagrams to a socalled information machine and then to a realization, an information system. To support that promising approach and increase its effectiveness, we now introduce development patterns for such development paths (focusing on functional requirements). We present the basic idea, several generally applicable development patterns (including patterns for the important and well-known class of CRUD functions), and various examples. This leads us into the direction of Pattern-Driven Requirements Engineering (PaDRE). To reach our goal we had to cross the boundaries of several (sub) disciplines such as requirements engineering, machine theory, and (database) systems development. Although we used (variants of) many existing ingredients, the strength of our approach also lies in the combination of the ingredients chosen (and the ones ignored).
5 citations
••
01 Sep 2018TL;DR: The findings from this case study confirm the existence of what is called fuzzy artefacts, concepts which are not formally documented but are of such a pervasive nature that an agile team is well aware of their existence.
Abstract: Agile Software Development (ASD) is often thought of as to predominantly use face-to-face communication. Research over the last years already led to adjustment of this conception. ASD also uses formal communication where it blends both traditional and agile artefacts. A next step should then be to explore the entire spectrum from informal to formal communication. This raised our research question: Which artefacts do agile teams use in between formal communication with artefacts and informal face-to-face communication? In an exploratory multiple single-case study we found 38 agile teams in as many organizations willing to participate in answering our question. The findings from our case study confirm the existence of what we called fuzzy artefacts, concepts which are not formally documented but are of such a pervasive nature that an agile team is well aware of their existence. We found in total 73 individual fuzzy artefacts in 38 agile teams. Most of them are related to requirements. Populating a product or sprint backlog with user stories equipped with priorities and efforts is another area where they were found. In this way we extended the typology of formal communication (artefacts) and informal communication (face-to-face) in ASD with an intermediate concept: fuzzy artefacts.
5 citations
•
01 Jan 2007TL;DR: A new project management tool to measure and ensure common understanding of development artifacts is presented, based on Peirce's theory of semiotics and Mayer’s theory of learning.
Abstract: The success of information system development projects is critically dependent on arriving at a shared understanding of the desired outcome by all project stakeholders. To communicate such understanding among stakeholders, development artifacts such as design specifications, prototypes, and user stories are created. This paper presents a new project management tool to measure and ensure common understanding of such development artifacts. The method is based on Peirce’s theory of semiotics and Mayer’s theory of learning. The application of the method is demonstrated using a brief example.
5 citations
••
TL;DR: An attempt to structure this dialogue without disturbing the “Agile” approach is presented, and some considerations on the possibility of using semantic tools are made.
Abstract: Capturing the “user requirement” has always been the most critical phase in systems engineering. The problem becomes even more complicated in software engineering where uncertainty of the functions to implement and volatility of the user needs are the rule. In the past, this initial difficulty of the software production phase was tackled by the requirement engineers using formal methods to structure the dialogue with the user. The solutions offered by this discipline are controversial. Agile methods put once again the human factor at the center of the user needs capture phase, using the intrinsic nonlinearity of the human mind to translate the user stories into software development. Although this practice has a positive outcome, the built-in ambiguity of the natural language is a consistent limit. An attempt to structure this dialogue without disturbing the “Agile” approach is presented, and some considerations on the possibility of using semantic tools are made.
5 citations
••
09 Oct 2013TL;DR: Techniques from agile requirements engineering are put together to propose a methodology for identifying user stories and associated risks and priorities and via a collaborative, participatory, single day workshop, named inception workshop.
Abstract: We investigate how smart Information and Communication Technologies (ICT) solutions can be used for combating illegal logging and timber trade. We put together techniques from agile requirements engineering to propose a methodology for identifying user stories and associated risks and priorities and via a collaborative, participatory, single day workshop, named inception workshop. We present our findings from the first application of the method, with the active involvement of the relevant stakeholders, i.e technical and domain experts, which concluded in seven user stories.
5 citations