  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.
