Requirements-level change propagation analysis depends on knowing which requirements depend on which, yet the dependency-type catalogues used for this purpose were long untested in real projects. Zhang, Li, Zhu, Jeffery, Liu, Wang and Li (2014) evaluated 25 dependency types from two established catalogues — an 18-type model attributed to Pohl and the 7-type model of Dahlstedt and Persson — in a single industrial case study (a property valuation system with 144 requirements, analyzed by three practitioners), found only a few types applicable and several ambiguous or overlapping, and proposed a refined dependency model of nine types (Constrain, Precede, Be_similar_to, Refine, Be_exception_of, Conflict, Evolve_into, Increase/Decrease_cost_of, Increase/Decrease_value_of). Whether this model generalizes has never been established: later research automated dependency extraction and change impact analysis using simplified or alternative type inventories (most recently approaches based on large language models, LLMs), while no study validates the nine-type model on further projects, compares it against the earlier catalogues, or builds a dedicated representation and tool support around it. The open problem is to establish the model's understandability, usability, and completeness at realistic empirical scale; evaluating its comparative effectiveness against the earlier catalogues and making it operational for automated traceability and change propagation analysis are reported from the source's future directions as additional, optional extensions.

Background

Software requirements — statements of what a system must do or must constrain — are rarely independent. When one requirement changes (a new input format, an added user role, a tightened security rule), other requirements that depend on it usually must change too; the process by which a change spreads through a requirements specification is called change propagation, and requirements-level change impact analysis is the activity of determining in advance which requirements are affected by a given change. This analysis rests on requirement dependencies (also called interdependencies): explicit, typed relationships between requirements, such as 'requirement A must hold before requirement B can be fulfilled' or 'A and B constrain the same data'. Missed dependencies let changes propagate undetected into design, code, and tests — a classical source of rework and project failure — and dependency relations also underpin automated traceability, the machine-supported recovery and maintenance of links between requirements and other development artifacts.

Because 'depends on' can express many different relations — temporal precedence, shared data, refinement, similarity, conflict, replacement — several catalogues of dependency types were proposed. Two influential ones predate the study: an 18-type model attributed to Pohl (the 'P-model'; the source cites Pohl's 1996 book Process-Centered Requirements Engineering) and the 7-type model of Dahlstedt and Persson (the 'D-model'), whose 2005 chapter also set the research agenda for requirements interdependencies. Until 2014, however, no such catalogue had been empirically evaluated in a real project, so practitioners had no evidence about which dependency types actually occur, which are usable, or which propagate changes.

Zhang et al. (2014), extending the same group's EASE 2012 precursor, narrowed that gap. In an industrial case study of a property valuation system (PVS; 144 requirements in 19 modules, plus 33 new or upgraded requirements in a later release), three practitioners (a project manager, a requirements engineer, and a developer) recorded dependencies in a dependency matrix — a table relating requirement pairs by dependency type — and analyzed which existing requirements were impacted by each new one. The study found that only a minority of the 25 catalogued types were applicable (e.g., precondition, similar_to, constraint); some definitions were ambiguous (practitioners interpreted Conflicts and Compares differently) or overlapping (Similar vs. Similar_to; Precondition vs. Requires); dependency discovery varied strongly with analyst experience, professional perspective, analysis process, and natural-language documentation; and the three roles identified different, largely complementary sets of impacted requirements, implying that impact analysis should involve multiple stakeholders.

Based on this single case, the authors proposed a refined requirement dependency model of nine types — Constrain, Precede, Be_similar_to, Refine, Be_exception_of, Conflict, Evolve_into, Increase/Decrease_cost_of, and Increase/Decrease_value_of — each with a precise definition, explicit directionality (which requirement depends on which), and typical engineering uses, grouped into intrinsic categories (business, implementation, structure, evolution) and additional categories (value, cost). The model's entire evidence base, however, is one project and three participants, and the nine types are presented as an initial set whose generalization cannot yet be claimed. The validation dimensions reported for the model are whether practitioners can interpret the type definitions consistently (understandability), apply them to identify dependencies with reasonable effort and agreement (usability), and find that the nine types cover the dependencies they need, in particular those that propagate changes (completeness). Also reported from the source's future directions are a dedicated representation for the types, their integration into tools for automated traceability and change propagation analysis, richer definitional examples, and a comparison of the new model's effectiveness against the earlier catalogues; these are separate optional directions rather than conditions for answering the validation question.

Problem Statement

Determine whether the refined nine-type requirement dependency model of Zhang et al. (2014) is a valid and usable basis for requirements-level change propagation analysis beyond the single case study from which it was derived. The question is whether empirical research at realistic scale — a substantially larger and more diverse set of projects and participants than the original three practitioners on one system — shows that (1) practitioners interpret the nine type definitions (Constrain, Precede, Be_similar_to, Refine, Be_exception_of, Conflict, Evolve_into, Increase/Decrease_cost_of, Increase/Decrease_value_of) consistently (understandability); (2) the types can be applied to identify dependencies with reasonable effort and agreement (usability); and (3) the nine types cover the dependencies practitioners need, in particular those that propagate changes (completeness). The original evidence base — one project and three participants — does not support generalization; evidence at scale that confirms, refines, or refutes the model's validity and utility all count as answers to the question. Resolution is a determination, grounded in the strongest available evidence — including indirect and adjacent empirical studies and the original case — of which of the nine types are supported, refined, or refuted on each dimension, with the residual uncertainty stated; producing new multi-project studies is not required.

Two further directions are reported from the source's future work and remain optional extensions, not required to resolve the question: (4) evaluating the model's comparative effectiveness against the earlier catalogues it refined — the 18-type P-model and the 7-type D-model — for dependency identification and change propagation analysis; and (5) the model's operationalization through a representation for the nine types (e.g., a dedicated dependency modeling language or metamodel, with the richer definitional examples called for) and its integration into tools for automated traceability and change propagation analysis.

References

  1. Zhang, H., Li, J., Zhu, L., Jeffery, R., Liu, Y., Wang, Q., & Li, M. (2014). Investigating dependencies in software requirements for change propagation analysis. Information and Software Technology, 56(1), 40–53. DOI: 10.1016/j.infsof.2013.07.001. https://doi.org/10.1016/j.infsof.2013.07.001
  2. Li, J., Zhu, L., Jeffery, R., Liu, Y., Zhang, H., Wang, Q., & Li, M. (2012). An initial evaluation of requirements dependency types in change propagation analysis. In: 16th International Conference on Evaluation & Assessment in Software Engineering (EASE 2012), pp. 62–71. DOI: 10.1049/ic.2012.0009. https://doi.org/10.1049/ic.2012.0009
  3. Dahlstedt, Å., & Persson, A. (2005). Requirements Interdependencies: State of the Art and Future Challenges. In: Aurum, A., & Wohlin, C. (eds.), Engineering and Managing Software Requirements. Springer, pp. 95–116. DOI: 10.1007/3-540-28244-0_5. https://doi.org/10.1007/3-540-28244-0_5
  4. Goknil, A., Kurtev, I., van den Berg, K., & Spijkerman, W. (2014). Change impact analysis for requirements: A metamodeling approach. Information and Software Technology, 56(8), 950–972. DOI: 10.1016/j.infsof.2014.03.002. https://doi.org/10.1016/j.infsof.2014.03.002
  5. Wang, J., & Wang, Q. (2016). Analyzing and predicting software integration bugs using network analysis on requirements dependency network. Requirements Engineering, 21(2), 161–184. DOI: 10.1007/s00766-014-0215-x. https://doi.org/10.1007/s00766-014-0215-x
  6. Jayatilleke, S., Lai, R., & Reed, K. (2018). A method of requirements change analysis. Requirements Engineering, 23(4), 493–508. DOI: 10.1007/s00766-017-0277-7. https://doi.org/10.1007/s00766-017-0277-7
  7. Atas, M., Samer, R., & Felfernig, A. (2018). Automated Identification of Type-Specific Dependencies between Requirements. In: IEEE/WIC/ACM International Conference on Web Intelligence (WI 2018), pp. 688–695. DOI: 10.1109/WI.2018.00-10. https://doi.org/10.1109/WI.2018.00-10
  8. Deshpande, G., Motger, Q., Palomares, C., Kamra, I., Biesialska, K., Franch, X., Ruhe, G., & Ho, J. (2020). Requirements Dependency Extraction by Integrating Active Learning with Ontology-Based Retrieval. In: 2020 IEEE 28th International Requirements Engineering Conference (RE), pp. 78–89. DOI: 10.1109/RE48521.2020.00020. https://doi.org/10.1109/RE48521.2020.00020
  9. Deshpande, G., Ruhe, G., & Saunders, C. (2021). How Much Data Analytics is Enough? The ROI of Machine Learning Classification and its Application to Requirements Dependency Classification. arXiv:2109.14097. https://arxiv.org/abs/2109.14097
  10. Gräßler, I., Oleff, C., Hieb, M., & Preuß, D. (2022). Automated Requirement Dependency Analysis for Complex Technical Systems. Proceedings of the Design Society, 2, 1865–1874. DOI: 10.1017/pds.2022.189. https://doi.org/10.1017/pds.2022.189
  11. Rajbhoj, A., Nistala, P., Kulkarni, V., Soni, S., & Pathan, A. (2022). DizSpec: Digitalization of Requirements Specification Documents to Automate Traceability and Impact Analysis. In: 2022 IEEE 30th International Requirements Engineering Conference (RE), pp. 243–254. DOI: 10.1109/RE54965.2022.00030. https://doi.org/10.1109/RE54965.2022.00030
  12. Dede, G., Mitropoulou, P., Nikolaidou, M., Kamalakis, T., & Michalakelis, C. (2021). Safety requirements for symbiotic human–robot collaboration systems in smart factories: a pairwise comparison approach to explore requirements dependencies. Requirements Engineering, 26(1), 115–141. DOI: 10.1007/s00766-020-00337-x. https://doi.org/10.1007/s00766-020-00337-x
  13. Guan, H., Xu, H., & Cai, L. (2024). Requirement Dependency Extraction Based on Improved Stacking Ensemble Machine Learning. Mathematics, 12(9), 1272. DOI: 10.3390/math12091272. https://doi.org/10.3390/math12091272
  14. Chen, W., Chen, H., Chen, T., & Cai, F. (2017). FACIA: A Fully Automatic Change Impact Analysis Method for Large Scale Requirements. DEStech Transactions on Engineering and Technology Research (AMMA 2017). DOI: 10.12783/dtetr/amma2017/13398. https://doi.org/10.12783/dtetr/amma2017/13398
  15. Etezadi, R., Abualhaija, S., Arora, C., & Briand, L. (2025). LLM-Driven Cost-Effective Requirements Change Impact Analysis. arXiv:2511.00262. https://arxiv.org/abs/2511.00262