Renovating Requirements Engineering: First Thoughts to Shape Requirements Engineering as a Profession
This addresses the issue of ad-hoc maintenance in legacy systems for software organizations, but it is incremental as it builds on existing role comparisons without new empirical results.
This position paper tackles the problem of organizations neglecting Requirements Engineers in legacy software maintenance by comparing their role with Building Architects and Product Owners across liability, self-portrayal, core activities, and artifacts to propose shaping Requirements Engineering as a distinguished profession.
Legacy software systems typically include vital data for organizations that use them and should thus to be regularly maintained. Ideally, organizations should rely on Requirements Engineers to understand and manage changes of stakeholder needs and system constraints. However, due to time and cost pressure, and with a heavy focus on implementation, organizations often choose to forgo Requirements Engineers and rather focus on ad-hoc bug fixing and maintenance. This position paper discusses what Requirements Engineers could possibly learn from other similar roles to become crucial for the evolution of legacy systems. Particularly, we compare the roles of Requirements Engineers (according to IREB), Building Architects (according to the German regulations), and Product Owners (according to "The Scrum-Guide"). We discuss overlaps along four dimensions: liability, self-portrayal, core activities, and artifacts. Finally we draw insights from these related fields to foster the concept of a Requirements Engineer as a distinguished profession.