Renovating Requirements Engineering: First Thoughts to Shape Requirements Engineering as a Profession

TL;DR

This paper explores how Requirements Engineers can evolve into a vital profession by learning from roles like architects and product owners, emphasizing their importance in maintaining legacy systems.

Contribution

It compares Requirements Engineers with architects and product owners across key dimensions to propose a clearer professional identity for Requirements Engineering.

Findings

Identifies overlaps between Requirements Engineers, architects, and product owners.

Highlights the potential for Requirements Engineers to become a distinct profession.

Suggests learning from related roles to enhance Requirements Engineering practices.

Abstract

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.