The DOI matches its Crossref record.
Agile requirements engineering with prototyping: A case study
Abstract
The rise of agile software development methods has led to the abandonment of many traditional practices especially in requirements engineering (RE). Agile RE is still a relatively new research area and the growing use of agile methods in large projects is forcing companies to look for more formal practices for RE. This paper describes experiences gained from a case study of a large agile project. The goal of this case study was to explore how prototyping can solve the challenges of agile RE. Our findings indicate that while prototyping can help with some challenges of agile RE such as lack of documentation, motivation for RE work and poor quality communication, it also needs complementary practices to reach its full potential. These practices include reviewing the big picture regularly, keeping track of quality requirements, and using ATDD (Acceptance Test Driven Development).
Overview
Integrity signals
Registry
Cites
Statistics
Verification
Claims the paper makes
Claims other papers make about this one
Each is checked against this paper’s own text: does it say what the citing paper says it does?
Prototyping helped with challenges related to managing with very little requirements documentation, such as intangible and unaligned views and plans on what to develop.
“They observed that prototyping helped with challenges related to managing with very little requirements documentation, such as intangible and unaligned views and plans on what to develop.”
From An empirically based model of software prototyping: a mapping study and a multi-case study (2023) · cites this paper as Käpyaho and Kauppinen 2015
Prototyping also increased the motivation for requirements work since updating a prototype was considered more motivating than writing requirements documents.
“Prototyping also increased the motivation for requirements work since updating a prototype was considered more motivating than writing requirements documents (Käpyaho and Kauppinen 2015).”
From An empirically based model of software prototyping: a mapping study and a multi-case study (2023) · cites this paper as Käpyaho and Kauppinen 2015
The quality of stakeholder communication at the case company was increased through prototyping and mutual understanding between the development team and the customers was reached faster.
“Furthermore, the quality of stakeholder communication at the case company was increased through prototyping and mutual understanding between the development team and the customers was reached faster.”
From An empirically based model of software prototyping: a mapping study and a multi-case study (2023) · cites this paper as Käpyaho and Kauppinen 2015
Prototyping addresses several challenges within agile but also identify a need to complement prototyping with additional practices.
“Their findings indicate that prototyping addresses several challenges within agile but also identify a need to complement prototyping with additional practices.”
From An empirically based model of software prototyping: a mapping study and a multi-case study (2023) · cites this paper as Käpyaho and Kauppinen 2015
Citations
Cites
No references could be resolved yet.
Research works printed but not linked: 22
- fowler, 2001, The agile manifesto, Technical report Agile Alliance
- 10.1109/SocialInformatics.2012.11 · DOI
- 10.1109/ICSE.1996.493447 · DOI
- 10.1109/VLHCC.2010.36 · DOI
- heaton, 1992, what's wrong with the user interface: how rapid prototyping can help, Software Prototyping and Evolutionary Development IEE Colloquium on, 7/1
- windsor, 1992, prototyping user interfaces, Software Prototyping and Evolutionary Development IEE Colloquium on, 4/1
- 10.1109/52.268964 · DOI
- 10.1145/1473018.1473053 · DOI
- 10.1109/ICRE.1994.292401 · DOI
- 2011, Chaos manifesto - the laws of chaos and the chaos 100 best pm practices, Technical Report
- 10.1109/ICSMC.2009.5346888 · DOI
- 10.1109/MS.2008.1 · DOI
- 10.1145/2068783.2068786 · DOI
- 10.1109/RE.2011.6051626 · DOI
- 10.1109/ENABL.2003.1231428 · DOI
- savolainen, 2010, Transition to agile development - rediscovery of important requirements engineering practices, In 18th IEEE International Requirements Engineering Conference (RE), 289
- 10.1002/smr.528 · DOI
- schrage, 2004, Never go to a client meeting without a prototype [software prototyping], IEEE Software, 21, 42, 10.1109/MS.2004.1270760 · DOI
- 10.1177/1350507601321004 · DOI
- 10.1109/METRICS.2005.29 · DOI
- memmel, 2007, Agile human-centered software engineering, BCS-HCI '07, 1, 167
- 10.1109/HICSS.2012.127 · DOI
Cited by
Sorted by citations
An empirically based model of software prototyping: a mapping study and a multi-case study
Bjarnason, E., Lang, F., & Mjöberg, A. (2023) · Empirical Software Engineering · doi:10.1007/s10664-023-10331-w · Cited by 75
Metadata
- Authors
- Kapyaho, M., & Kauppinen, M.
- Affiliations
- Aalto University (FI)
- ORCID
- Kauppinen, Marjo
- Venue
- 2015 IEEE 23rd International Requirements Engineering Conference (RE)
- Publisher
- IEEE
- Published
- 2015-08
- Pages
- 334-343
- OpenAlex
- W1940716218
- Cited by
- 60
- References
- 0
- Citations by year
- 2026: 2 · 2025: 4 · 2024: 6 · 2023: 10 · 2022: 6 · 2021: 10 · 2020: 4 · 2019: 5 · 2018: 6 · 2017: 4 · 2016: 3
- FWCI
- 3.15
- Type
- conference paper
- Language
- en
- Open access
- closed
- Locations
- IEEE International Requirements Engineering Conference (RE) (publishedVersion)
- Topics
- Physical Sciences › Computer Science › Information Systems › Software Engineering Techniques and Practices
- Physical Sciences › Computer Science › Software › Advanced Software Engineering Methodologies
- Physical Sciences › Engineering › Control and Systems Engineering › Systems Engineering Methodologies and Applications
- Keywords
- agile requirements engineering, prototype development, acceptance test-driven development, requirements documentation, requirements communication, requirements quality
About these checks
Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.
Statistics and arithmetic are recomputed, not judged.
Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.
What counts as a claim ›How we measure confidence ›How we check this ›
Are you an author, or do you see a problem with this page? Request a review
