A 2019 industrial case study (Dasanayake, Aaramaa, Markkula and Oivo) identified factors of requirements volatility — poor communication, distorted information, and external dependencies — and their implications for software architecture — degraded documentation, loss of design-rationale traceability, and increased architectural complexity — but explicitly stated that its single-company, qualitative evidence could establish only correlations, not causal relationships. The open problem is to move beyond that correlational, single-case account: to establish empirically, across organizational contexts, the causal relationships between specific requirements-volatility factors and software-architecture outcomes; to characterize whether and when volatility positively affects architecture; to validate the factor-to-implication mappings beyond the original case company; and to evaluate the efficacy of the proposed mitigation measures. Later work on requirements volatility has remained qualitative, single-case, or project-success-focused, leaving this causal and positive-effects core open.

Background

Requirements volatility (RV) denotes uncertainty and change in software requirements during development — added, modified, or removed requirements. It is a long-recognized source of project risk, and the question of how it interacts with software architecture — the high-level structure of a system, which constrains and is constrained by the requirements it must satisfy — sits at the so-called "twin peaks" of development, the intertwined exploration of requirements and architectural design. The empirical anchor of this problem is a study by Dasanayake, Aaramaa, Markkula and Oivo (2019), a qualitative single-case study of a European software company (roughly 900 employees, five business units, distributed development), based on semi-structured interviews with fifteen software experts involved in architecture design. The study identified visible RV factors in each team (notably poor communication, distorted information, and external dependencies), the implications these had for architecture (among them degradation of architecture documentation, loss of traceability of design rationale — the recorded reasoning behind architectural decisions — and increased architectural complexity), each team's readiness to handle those implications, and means to mitigate the implications and eliminate the factors. A companion exploratory case study of the same company (Aaramaa, Dasanayake, Oivo, Markkula and Saukkonen, 2017) had earlier surfaced the seven recurring architectural implications. The authors were explicit about the epistemic limits of this account: the evidence was insufficient to suggest causal relationships between factors and implications (only correlations could be identified), all data came from a single case company, the positive side of volatility — the possibility, emphasized in agile principles, that changing requirements can be harnessed to improve the product and its architecture — was an unexplored gap, and the proposed mitigations (better documentation and design-rationale practices, suitable elicitation techniques, release buffers, communication improvements, twin-peaks-style integration of requirements and architecture work) had not been evaluated for effectiveness, cost, or side effects. Subsequent literature has not closed this gap: later studies of requirements volatility remain qualitative interview studies (Mohammad and Kollamana, 2024, on causes and agile mitigation practices), single-case mixed-method studies (Silva et al., 2024, on stakeholder centralization in a government software project), project-success-level quantitative surveys (Osama, Khedr and Abdelsalam, 2020, on requirements quality and volatility versus project success), or conceptual treatments of agile–architecture reconciliation (Rocha, Misra and Soares, 2023). None establishes causal relationships between specific volatility factors and architecture-level outcomes, and none characterizes positive architectural effects of volatility.

Problem Statement

Establish empirically, beyond a single case company, the relationship between requirements volatility and software architecture — specifically: (1) which of the identified requirements-volatility factors (e.g., poor communication, distorted information, external dependencies) causally produce which architecture-level outcomes (e.g., degraded architecture documentation, loss of design-rationale traceability, increased architectural complexity), with effect sizes and confound control sufficient to support causal rather than correlational claims; (2) whether and under which conditions requirements volatility can have positive effects on software architecture — that is, when and how changing requirements drive architecturally beneficial change — in industrial contexts; (3) which of the identified factor-to-implication mappings and team-readiness patterns generalize across organizational contexts, validated by replication in companies and domains other than the original European case company; and (4) how effective the proposed mitigation and prevention measures (improved documentation and design-rationale practices, elicitation-technique selection, release buffers, communication improvements, twin-peaks-style integration of requirements and architecture work) are in industrial deployments, including their costs and side effects. These four strands serve one objective: converting the 2019 study's single-case correlational account of how requirements volatility acts on software architecture into validated causal, cross-context knowledge. Each strand may be answered independently.

References

  1. Dasanayake, S., Aaramaa, S., Markkula, J., Oivo, M. (2019). Impact of requirements volatility on software architecture: How do software teams keep up with ever-changing requirements? Journal of Software: Evolution and Process, 31(6), e2160. DOI: 10.1002/smr.2160. https://doi.org/10.1002/smr.2160 (preprint: arXiv:1904.08164, https://arxiv.org/abs/1904.08164)
  2. Aaramaa, S., Dasanayake, S., Oivo, M., Markkula, J., Saukkonen, N. (2017). Requirements volatility in software architecture design: an exploratory case study. Proceedings of the 2017 International Conference on Software and Systems Process (ICSSP '17), pp. 40–49. DOI: 10.1145/3084100.3084105. https://doi.org/10.1145/3084100.3084105
  3. Mohammad, A., Kollamana, J. M. (2024). Causes and Mitigation Practices of Requirement Volatility in Agile Software Development. Informatics 11(1), 12. DOI: 10.3390/informatics11010012. https://doi.org/10.3390/informatics11010012
  4. Silva, A. S., Araújo, A., Palomino, P., Araújo, R., Dermeval, D. (2024). Mastering Requirements Volatility: Strategies for Dynamic Environments and Multiple Stakeholders in Government Software Projects. IEEE Access, 12, 183060–183077. DOI: 10.1109/ACCESS.2024.3510056. https://doi.org/10.1109/ACCESS.2024.3510056
  5. Osama, E., Khedr, A., Abdelsalam, M. (2020). The Effect of Requirements Quality and Requirements Volatility on the Success of Information Systems Projects. International Journal of Advanced Computer Science and Applications 11(9). DOI: 10.14569/ijacsa.2020.0110950. https://doi.org/10.14569/ijacsa.2020.0110950
  6. Rocha, F. G., Misra, S., Soares, M. S. (2023). Guidelines for Future Agile Methodologies and Architecture Reconciliation for Software-Intensive Systems. Electronics 12(7), 1582. DOI: 10.3390/electronics12071582. https://doi.org/10.3390/electronics12071582