Abstract
There are a number of concerns in agile software development, including requirements engineering. There are different types of agile requirement, of which currently the most common forms are use cases and user stories. The use cases and user stories have different origins, both in space and in time, but, by being among the practices of scenario-oriented requirements engineering (SORE), they are not entirely unrelated. The purpose of this article is to situate use cases and user stories in context of each other. This is done by means of a conceptual framework for systematically comparing use cases and user stories. The understanding of similarities and differences between use cases and user stories have pedagogical as well as practical implications.
TopBackground
In this section, a brief background on agile methodologies and requirements engineering is presented, and previous work on comparing use cases and user stories is analyzed.
Agile Methodologies
In the 1990s, a number of limitations of rigidity in approaches for development of certain types of software systems were realized. These limitations made it difficult for organizations that aimed for relatively short release cycles of their products to remain competitive in the market, had relatively small budgets to allocate for their projects, and required richer communication between technical and non-technical stakeholders (including customers and users) to address their needs better. The drive to cope with these limitations led to the inception of agility.
The Agile Manifesto constitutes the basis for a number of agile methodologies, including Agile Experience Design (AXD), Crystal Clear, Extreme Programming (XP), OpenUP, Scrum, and User-Centered Agile Process (UCAP). The agile methodologies have evolved over time and in certain cases, such as the Discipline Agile Delivery (DAD) process framework (Ambler & Lines, 2012), elements of multiple agile methodologies have been included.
Requirements Engineering
In software engineering, significant emphasis is placed on the requirements engineering, in general, and practices of requirements engineering, in particular, in the light of their impact on the later phases of software development and eventually their influence on the success of the software project (Wiegers, 2003). This causality is depicted in Figure 1. In requirements engineering, the attention is on the problem so as to devise a desirable and viable solution, namely the software system, which can satisfy the stakeholders.
Figure 1. A causal relationship between the success of a software project and the practices of software requirements engineering
The agile methodology underlying an agile project determines the type of agile requirement to be adopted. For example, in Crystal Clear and OpenUP, an agile requirement can take the form of a use case (Jacobson et al., 1992) and in AXD, XP, Scrum, and UCAP, an agile requirement can take the form of a user story (Cohn, 2004).
Key Terms in this Chapter
Agile Methodology: A software development methodology based on the Agile Manifesto. Artifact: A document or a model produced during software development.
User: An individual who interacts with the software system usually, but not always, with a specific goal.
Acceptance Criteria: The criteria that a system must satisfy in order to be accepted by a user, customer, or other authorized entity.
User Story: A high-level requirement statement that contains minimally sufficient information to produce a reasonable estimate of the effort to implement it.
Requirement: A statement which translates or expresses a need and its associated constraints and conditions.
Stakeholder: An individual, team, organization, or classes thereof, having an interest in a system.
Use Case: A sequence of actions performed by a system, which yields an observable result of value to an actor of the system.
Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
Process: A set of interrelated or interacting activities that transforms inputs into outputs for some purpose.