The DOI matches its Crossref record; 45 of the 45 references it cites were found in a registry or an index.
Impact of requirements volatility on software architecture: How do software teams keep up with ever‐changing requirements?
Open accessAbstract
Requirements volatility is a major issue in software development, causing problems such as higher defect density, project delays, and cost overruns. Software architecture that guides the overall vision of software product is one of the areas that is greatly affected by requirements volatility. Since critical architecture decisions are made based on the requirements at hand, changes in requirements can result significant changes in architecture. With the wide adoption of agile software development, software architectures are designed to accommodate possible future changes. However, the changes has to be carefully managed as unnecessary and excessive changes can bring negative consequences. An exploratory case study was conducted to study the impact of requirements volatility on software architecture. Fifteen semistructured, thematic interviews were conducted in a European software company. The research revealed poor communication, information distortion, and external dependencies as the main factors that cause requirement volatility and inadequate architecture documentation, inability to trace design rationale, and increased complexity as the main implications of requirements volatility on software architecture. Insights from software teams' awareness of the requirement volatility, factors contribute to it, and possible ways to mitigate its implications will be utilized to improve the management of requirement volatility during software architecting process.
Overview
The claims and statistics of this paper haven’t been checked yet.
Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.
Integrity signals
Registry
Cites
Statistics
Verification
Claims the paper makes
The claims and statistics of this paper haven’t been checked yet.
Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.
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?
The cited source says what the claim attributes to it.
In the citing paper
“Unpredictable evolution and changes of software requirements complicate architecture design ( group , calendar ).”
From Software Architecture in Practice: Challenges and Opportunities (2023) · cites this paper as [23]
Self-check
Percentages, sums and reported differences re-computed from the paper’s own numbers.
The self-check needs the paper’s full text.
Citations
Cites
Handbook of Interview Research
Gubrium, J. F., & Holstein, J. A. (2001) · Sage eBooks · doi:10.4135/9781412973588 · Cited by 3,317
Case Study Research in Software Engineering
Runeson, P., Höst, M., Rainer, A., & Regnell, B. (2012) · Wiley eBooks · doi:10.1002/9781118181034 · Cited by 913
Technical Debt: From Metaphor to Theory and Practice
Kruchten, P., Nord, R. L., & Ozkaya, I. (2012) · IEEE Software · doi:10.1109/ms.2012.167 · Cited by 735
The WyCash portfolio management system
Cunningham, W. (1992) · ACM SIGPLAN OOPS Messenger · doi:10.1145/157710.157715 · Cited by 606
Weaving together requirements and architectures
Nuseibeh, B. (2001) · Computer · doi:10.1109/2.910904 · Cited by 535
Shachaf, P. (2008) · Information & Management · doi:10.1016/j.im.2007.12.003 · Cited by 525
Software release planning: an evolutionary and iterative approach
Greer, D., & Ruhe, G. (2003) · Information and Software Technology · doi:10.1016/j.infsof.2003.07.002 · Cited by 434
An industrial survey of requirements interdependencies in software product release planning
Carlshamre, P., Sandahl, K., Lindvall, M., Regnell, B., & Dag, J. N. O. (2001) · IEEE International Requirements Engineering Conference (RE) · doi:10.1109/isre.2001.948547 · Cited by 281
A comparison of face‐to‐face and virtual software development teams
Andres, H. P. (2002) · Team Performance Management · doi:10.1108/13527590210425077 · Cited by 249
A survey of architecture design rationale
Tang, A., Babar, M. A., Gorton, I., & Han, J. (2006) · Journal of Systems and Software · doi:10.1016/j.jss.2006.04.029 · Cited by 207
Research works printed but not linked: 19
- ZowghiD NurmulianiN.A study of the impact of requirements volatility on software project performance. In: Proceedings ‐ Asia‐Pacific Software Engineering Conference APSEC Vol. 2002; January2002;Gold Cost Queensland Australia.3‐11.
- JansenA BoschJ.Software architecture as a set of architectural design decisions. In: 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05);2005;Washington DC USA.109‐120.
- JiangTm CoynerM.Software process disturbances. In: The 24th Annual International Computer Software and Applications Conference COMPSA 2000;2000;Taipei Taiwan.167‐168.
- MalaiyaYK DentonJ.Requirements volatility and defect density. In: Proceedings 10th International Symposium on Software Reliability Engineering (Cat. No.pr00443);1999;Boca Raton FL.285‐294.
- Wiegers K, 2013, Software Requirements
- Kotonya G, 1998, Requirements Engineering : Processes and Techniques
- NurmulianiN ZowghiD WilliamsSP.Requirements volatility and its impact on change effort: evidence‐based research in software development projects. In: Proceedings of the Eleventh Australian Workshop on Requirements Engineering;2006;Adelaide Australia. 7-7.
- SudhakarM.Managing the impact of requirements volatility.Master Thesis: Umeå University;2005.http://www8.cs.umu.se/education/examina/Rapporter/SudhakarMundlamuri.pdf
- ChristelMG KangKC.Issues in Requirements Elicitation. Pittsburgh(PA): Software Engineering Institute;1992:68. Report No.: CMU/SEI-92-TR-012.
- Loucopoulos P, 1995, System Requirements Engineering
- Fowler M, 2001, The agile manifesto, Software Dev, 9, 28
- ISO/IEC/IEEE.Systems and software engineering – Architecture description;2011.
- Clements P, 2001, Evaluating Software Architectures: Methods and Case Studies
- Bass L, 2012, Software Architecture in Practice
- Ford N, 2017, Building Evolutionary Architectures: Support Constant Change
- Yin RK, 2013, Case Study Research: Design and Methods
- KorkalaM AbrahamssonP KyllönenP.A case study on the impact of customer communication on defects in agile software development. In: AGILE 2006 Conference (AGILE 2006);2006;Minneapolis MN.76‐88.
- HintersteinerJ.Addressing changing customer needs by adapting design requirements. In: Proceedings of 1st International Conference on Axiomatic Design (ICAD 2000);2000;Cambridge MA.290‐299.
- HuoM VernerJ ZhuL BabarMa.Software quality and agile methods. In: Proceedings of the 28th Annual International on Computer Software and Applications Conference 2004. COMPSAC 2004 Vol. 1;2004;Hong Kong.520‐525.
Cited by
Mental Wellbeing at Work: Perspectives of Software Engineers
Wong, N., Jackson, V., van der Hoek, A., Ahmed, I., Schueller, S. M., & Reddy, M. C. (2023) · CHI Conference on Human Factors in Computing Systems · doi:10.1145/3544548.3581528 · Cited by 42
Software Architecture in Practice: Challenges and Opportunities
Wan, Z., Zhang, Y., Xia, X., Jiang, Y., & Lo, D. (2023) · Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering · doi:10.1145/3611643.3616367 · Cited by 30
“The unpredictable evolution and changes of requirements sometimes make it infeasible to deliver new features or meet the quality requirements with current architectures, as frequently mentioned in the literature [3, 8, 22, 24, 60, 90, 92].”
BackgroundReactive links across multi-domain engineering models
Raţiu, C. C., Assunção, W. K. G., Haas, R., & Egyed, A. F. (2022) · ACM/IEEE International Conference on Model Driven Engineering Languages and Systems (MODELS) · doi:10.1145/3550355.3552446 · Cited by 27
Integration of Software Architecture in Requirements Elicitation for Rapid Software Development
Gillani, M., Niaz, H. A., & Ullah, A. (2022) · IEEE Access · doi:10.1109/access.2022.3177659 · Cited by 17
When traceability goes awry: An industrial experience report
Fucci, D., Alégroth, E., & Axelsson, T. (2022) · Journal of Systems and Software · doi:10.1016/j.jss.2022.111389 · Cited by 16
Metadata
- Authors
- Dasanayake, S., Aaramaa, S., Markkula, J., & Oivo, M.
- Affiliations
- University of Oulu (FI)
- Corresponding author
- Dasanayake, Sandun
- ORCID
- Dasanayake, Sandun
- Venue
- Journal of Software: Evolution and Process
- Publisher
- Wiley
- Published
- 2019-03-25
- Volume
- 31
- Issue
- 6
- ISSN
- 2047-7473 (ISSN-L)
- 2047-7481
- OpenAlex
- W2936336847
- Cited by
- 32
- References
- 45
- Citations by year
- 2026: 1 · 2025: 7 · 2024: 7 · 2023: 6 · 2022: 7 · 2021: 1 · 2020: 3
- FWCI
- 3.42
- Type
- journal article
- Language
- en
- Open access
- green
- arxiv.org
- Locations
- Journal of Software Evolution and Process (publishedVersion)
- arXiv (Cornell University) (submittedVersion)
- arXiv (Cornell University)
- 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
- requirements change, software architecture, architecture decisions, agile software development, software development teams, architectural documentation, information distortion, external dependence, software complexity, requirements change management
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
