Answers are grounded in this paper and cite their sources.
Develops a taxonomy of change drivers in software, suggesting new avenues for empirical validation.
Software modularization principles — cohesion, coupling, separation of concerns, the SOLID principles — all presuppose an answer to a question almost no one asks: what is a change driver, where does it come from, and what is it never? This paper provides the first systematic classification by artifact type. It develops a nine-category taxonomy: six irreducible first-order categories (legislation/regulation, contractual obligations, industry/technical standards, business rules/policies, product vision/roadmap, quality/NFR commitments) and three derivative categories that trace to them (platform/infrastructure, organizational structure, user/market demand). The taxonomy is grounded by why-why analysis tracing change events to their first-principles root cause — the domain the system models refused to stay still — and corroborated by a cross-domain survey of six disciplines. A worked example applies the co-variation criterion to the EU VAT Directive. A negative ontology identifies six things a change driver is never (a person, a system-state property, a preference, a frequency, a pressure, a trend) and the boundary between change activity and change driver. The taxonomy is proposed for empirical validation through inter-rater agreement on a representative corpus of change requests.
No takes yet. Share an insight, caveat, or question.
Yannick Loth (2026) studied this question.
Synapse has enriched 8 closely related papers on similar clinical questions. Consider them for comparative context: