• Studies and Research

Requirements Engineering in German Job Advertisements


In order to answer these questions, job offers in a German online job portal have been analyzed for 2009, 2012 and 2015. In 2015, freelancer positions were also analyzed and compared. The results of 2009 and 2012 have been published at the REFSQ Conference 2013 [1]. Now, the study has been repeated with data from 2015 and enhanced by the freelancer data.

Definitions of terms used: person, position, role, task

In this study, we define a person to be a natural person with an individual name. When a person is employed in an organization, (s)he is integrated into the hierarchical system which is modeled by the organization´s organigram. The organigram´s leaves are positions which have hierarchical relations with each other. Each position is identified by a job title, and usually specific expectations in terms of responsibilities, tasks and authority (and salary) within the organization are linked to each job title. A position´s definition usually is organization-specific and is described in a job description. It can be used as the basis for a job offer and in the work contract. We have grouped position job titles into position categories which are similar, because a large variety of job titles can be found.

The concept of role describes a set of tasks and responsibilities within a project or business process and skills needed for them, but is usually not identical with the position. While the position is attributed to a person permanently until change of position (e.g. promotion), project roles are attributed to persons dynamically, according to the current need. Several roles can be assigned to one person at the same time, but one person has only one position at a time. Figure 1 describes the metamodel.

Figure 1: Meta model

Research approach

In the present study, we analyze job offers which are an official model of how practitioners integrate RE in their organizations and which qualifications they believe to be critical for this task. Ideally, these job advertisements also reflect previous experience, i.e. they demand such qualifications which in the past had been shown to be critical.

The questions listed in the abstract were answered based on such job offers in 2009, and again in 2012 and 2015.

These questions were:

  • Q1: What is the job title of the position doing RE?
  • Q2a: Which further tasks does this position include?
  • Q2b: How many further tasks does this position include?
  • Q3: Which qualifications are demanded?

A job advertisement typically has the following parts:

  • Job title (used here to answer Q1, classified into categories like “consultant” and “developer”)
  • Company presentation (used here to find out the company´s size and the application domain)
  • List of tasks (We coded them according the software engineering phases and then counted their number per position, see below at Q2)
  • Competencies demanded (also coded according to categories, see at Q3)
  • We offer (further information not analyzed here)
  • Application process and contact address (not analyzed, but sometimes necessary to find out the company name, size and domain)

The job offers to be analyzed were chosen like this: On the German job portal stepstone.de, within the categories of IT jobs, all offers were read, starting with the newest. The jobs were searched under category “IT”. The sub-categories which the portal offers were changed between the searches. In 2009, the four sub-categories considered were software engineering, application analysis, IT consulting and IT systems analyst. In 2012, the sub-category considered was “Consulting, Engineering”. It seemed that the four sub-categories from 2009 were merged into this one. In 2015, the category was “IT”, without selecting sub-categories.

The search included the countries Germany, Switzerland and Austria, all application domains, and all types of jobs (permanent job, temporary appointment, etc.; only internships were excluded). Those offers, which in the task description contained activities related to RE, were included in the further analysis. We defined RE to include the activities of “elicitation, documentation, validation/negotiation plus the management of requirements” [2]. However, RE is rarely called RE in all job offers, but can have many names.

The most frequent keywords that were found to be an indicator of RE tasks were: customer requirements, process modeling, problem analysis, functional specification, clarification of requirements with customers, analysis of business processes, communication of requirements to the development team. However, the following activities were considered not to be part of RE: making decisions about requirements, technical specification, solution design (e.g. security concepts, database designs), solution development, software customizing, consulting in the meaning of selling the company´s specific product, process improvement.

Table 1 lists how many job offers were analyzed in each year to find out those which contain RE tasks. In the second row, it describes how many of these contained RE tasks and in the third row which percentage of all job offers analyzed this is. Only those offers containing RE tasks have been included in the following analysis.

employees freelancers
2009 2012 2015 2015
Number of job offers analyzed 1378 589 800 500
Number of job offers related to RE 141 67 149 46
Job offers related to RE 10.2 % 11.4 % 19.6 % 9.2 %
Table 1: Number of job offers analyzed, number of job offers related to RE

Comments (4)

  • From: Maurice Spee
  • Date: 14. December 2016

Interesting article. Confirms my opinion about how many companies look at requirements engineering. That is: it is certainly not a job, it is some kind of role that can be performed by every teammember who has medium to good communications skills. It is about talking with some persons we call stakeholders, write down what they say, prioritize the list and we are ready to go.

So, if we want to professionalize RE our first step should be in convincing organizations and companies what the pitfalls are of the above mentioned approach and what the advantages are of RE done by a professional.
By neglecting this, RE as we see it will never be adopted.

I think we can learn a lot from our collegues in the field of testing: in former days, testing was also something every teammember could perform. But over the years, our testing collegues managed to stress out the importance of testing. This not only lead to widely adopted testing methods such as TMAP Next and ISTQB, but - more important - the adoptance of professional testing in all projects. Nowadays, there is no need in convincing organizations about the importance of testing. Let us make an effort in 2017 to achieve to same for RE.

Dear Maurice,

IREB is working on this. ISTQB just is some few years ahead. I will repeat this study regulary, so we can observe the development!

Best regards, Andrea

  • From: Frank Rabeler
  • Date: 18. October 2016

Thank you for this article.
To me this article proves that there is still a long way ahead for IREB.
IREB wants to professionalize Requirements Engineering. More than 27,000 certifications are a huge success so far but still companies are not explicitly searching for requirements engineers.
Why? I guess because many companies simply don’t know about the profession “Requirements Engineer”. I am convinced that in reality not 4.7% REs were searched in 2015 but at least 10%.
Job portals like stepstone.de should guide those who are about to place a job offer in a better way. Users should be guided in a way they say “Oh well, they are right. I’m not looking for a Consultant. Instead I’m looking for a Requirements Engineer”. This would be a win-win situation for users and portals.
My questions:
How can we achieve this guidance in job portals? Any ideas? Or do you think this is not the point?

  • From: Stefan Sturm
  • Date: 18. October 2016

Hi Frank,
you’re perfectly right – but it’s not an easy task. Recently IREB started to talk not to the RE community only, but to trade groups in order to inform their members about Requirements Engineering and the importance for project success. That way we try to reach out to a broader audience.

In fact, we have as well tried to reach out to job portals, but that was not very successful. They do not add roles/knowledge areas proactively. They watch what head hunters are looking for and what skills candidates do enter and if that reaches a critical mass they implement it. We were no yet successful – but we keep on trying!

Author's profile
Related Articles
Requirements Reuse

Requirements Reuse with the PABRE Framework

Read Article
Building the bridge

Building the bridge between experience and research: The future Research Section of the RE Magazine

Read Article
Gender Studies

What do we learn from Gender Studies for Requirements Engineering

Read Article