Requirements Engineering (RE) is a critical area in software development, as figuring out what to develop and include in a product is a cornerstone activity which all others depend upon. Countless studies of unsuccessful development projects report that lack in RE is often a core-contributing failure factor.13 Central in RE is the role that coordinates all its related activities, usually named requirements engineer. Still, empirical evidence on the way companies implement this role is scarce. In this article, we present the results of an interview-based descriptive study involving 24 IT professionals from 12 companies. As a main outcome, we can affirm that all companies assign IT professionals to the requirements engineer role in their projects, but in many different ways, which might impact efficiency of the function. Furthermore, we uncover that requirements engineers often perform other tasks ranging from project's go vs. no-go decisions to test suite design in addition to handling requirements. Last, the study highlights their need to communicate with many other roles inside the company, from domain experts to system architects.
According to the International Requirements Engineering Board (IREB), a requirements engineer is "a person who—in collaboration with stakeholders—elicits, documents, validates, and manages requirements."3 There are several synonyms in place, most of them using the term "analyst," like "requirements analyst," "business analyst," "system analyst," or even simply "analyst."16
While the complexity and criticality of RE activities call for such a role,13 there is not a vision shared in industry about its responsibilities and in fact, its existence as a separate role is not always clear. Ten years ago, Paech started her paper "What is a Requirements Engineer?"10 stating that "Rarely is there a role called requirements engineer." Afterward, Hermann seconded this view arguing that "in many organizations, the role of the requirements engineer is not defined clearly."5 Even recently, Wang et al. informed that in spite of practitioners framing requirements engineer as a profession, "there is a significant incongruity regarding the perceptions of the requirements engineering role, tasks, and responsibilities in the IT marketplace."15 Because of this incongruity, the way in which the requirements engineer is assigned and works in practice may vary largely depending on the organization.
To understand this phenomenon, we have performed a descriptive study investigating the requirements engineer role in the context of industry. Other studies focus on understanding the skills, the competences, and even the educational background of requirements engineers.1,2,5,15 Instead, we focus on the management of this role in companies. Questions we ask are among others: Who plays the requirements engineer role? How do companies assign IT professionals to this role? How does it relate to other roles? What activities do requirements engineers perform? The answers gathered in the study may help companies to know practices in place that they can eventually adopt to improve their current way of working.
The study. We conducted an interview-based descriptive study with 24 IT professionals in 12 Swedish companies from our local network of industry contacts. Descriptive studies allow investigating a given object, without the commitment of explaining the findings. Along this line, our study serves as an instrument to learn how things work in practice. (See the sidebar "Research Methods" for more details.)
The table here summarizes the most relevant information about the respondents and their companies. Half of the respondents hold a Computer Science or Information Systems degree (BSc or MSc). They occupy different positions, and we knew in advance that all of them are involved in RE activities, although in most cases we didn't know all details of their role.
In the rest of the article, we will refer to respondents using the notation Sx[Y], where Sx is the respondent's identifier and Y is the company's identifier.
Do organizations assign an IT professional to the role of requirements engineer? Most of the respondents explicitly confirmed the existence of the role of requirements engineer in their organizations, dedicated mainly to RE-related tasks. The role was concisely defined by S1[A] as: "A role played by some designated person which in that project is in charge of requirements."
There were a couple of respondents answering "no" to the direct question, but in the explanation that they provided, it became clear that they confused the concepts of "role" ("a function or part performed especially in a particular operation or process"8) and "position" ("an employment for which one has been hired"8). For example, S5[C] said: "No, the role didn't exist. It was a hat that a person wore when necessary, who did the tasks of a requirements engineer … The main responsibilities when this person was working as a requirements engineer were …" From the later description, it became clear that S5, as the rest of respondents, had a requirements engineer role in his project.
Only respondent S17[I] reported that sometimes nobody played this role in his organization: "The role only exists [in my organization] if the gathering of requirements is necessary." The justification of this response is that company I acts sometimes as subcontractor to perform development activities in external projects, therefore requirements are managed in the contracting company.
How is the requirements engineer role staffed? There exists a large variability in the way that practitioners are assigned to the requirements engineer role. In its simplest form, only one person acts as requirements engineer in a project. This situation was reported by 12 respondents. Three main variations were mentioned:
Eight respondents reported that more than one person has assigned the requirements engineer role. Again, we distinguish several situations:
Last, we observed how context factors may influence in the assignment and performance of the requirements engineering role. Four respondents informed that the concrete way in which the requirements engineer role is covered depends on some context factor. Respondents mentioned specifically project size and current workload:
In one respondent's company, the requirements engineer is entitled to "researching the possibility of developing a solution taking into account what the customer wanted," that is, a go vs. no-go decision.
What are the activities conducted by people playing the role of requirements engineer? Respondents in our study mentioned requirements engineers to be responsible of the usual RE-related activities: elicitation, negotiation, documentation/specification, validation and change management. However, except in the simplest cases as S1[A], the role "is a hat that a person wears at some moment, but then these people change to do other things" (S10[F]). Consequently, when a system architect or a developer is assigned as requirements engineer, she still needs to design the architecture or develop new software, while participating as requirements engineer when required. This can pose a real problem as it brings a solution focus very early on, especially when high-level requirements should be broken down to concrete needs. In fact, the elaboration of high-level requirements into more detailed ones (that is, "understanding what has to be done from this big first requirement," as said by S7[D]) is mentioned often by the interviewees as a challenge.
Furthermore, some respondents mentioned particular activities at different abstraction and granularity levels that we mention here:
Which other roles interact with the requirements engineer? When discussing the requirements engineer role, other functions and roles were also lifted by our respondents. A representative example comes from S1[A]. As already mentioned, in the case of this company, the requirements engineer only performs RE-related tasks, so she needs to communicate with other roles: the assignment lead ("it is kind of a project manager but inside the team, working hand to hand with them") and the business architect. The requirements engineer (called system analyst in this organization) is constantly interacting with both of them.
Another typical role reported as important for the requirements engineer is that of system architect. System architects collaborate typically in verification activities, as reported by S5[C]: "[Requirements engineers were in charge of] securing and verifying together with system engineering architects the technical accuracy of the requirements responses provided to the customer." With a similar function, S23[L] and S24[L] report the use of specialists and consultants in their organization, who "know a lot about technical aspects, so they help requirements engineers to understand the technical aspects when specifying requirements."
Some of these roles may be assigned depending on the context. Size is one of them, as reported by S3[B]: "If the project is quite big, the organization even has a project leader for each one of the different stages of the project: requirements, development, etc."
The information gathered from the 24 respondents has been very useful to gain insights in the requirements engineer role from the perspective of the organization (See the sidebar "Study Validity" for more details). The figure here summarizes the results as they have emerged from these answers. Here we report some observations:
Large diversity in the staffing of requirements engineers. This is an aspect not sufficiently addressed in the literature that deserves more attention. With so many options, an organization may be hesitant about the best way to proceed. For example, putting several people together to play the role of requirements engineer can be considered beneficial because they provide their own expertise, skills, and judgment and therefore improve the overall quality of the RE process. On the other hand, it may give rise to communication problems, which is one of the typical challenges reported by respondents in this study. For example, S5[C] declared that "there were requirements missing at the end (incompleteness) and some misunderstandings (ambiguity). Especially the problems were with the communication between the two roles related to requirements, as the interaction designers were using the requirements specified by the requirements analysts to create a new more detailed version of the requirements." This observation aligns with the study by Calzanas et al.,1 which reported good written and oral communications as two of the most frequently demanded requirements engineers' skills in the Brazilian market. Additional studies have also shown that written/oral comprehension and communication is one of the skills with more difficulties for requirements engineers;9 therefore, it may be argued that companies opting to share the role of requirements engineer among several people, should be ready to invest resources in training their soft skills.
It may be argued that companies opting to share the role of requirements engineer among several people should be ready to invest resources in training their soft skills.
Conversely, in the companies that reported a single person playing the requirements engineer role in the project, we found two possibilities reflecting two opposite views on considering RE. Having the same person across several projects is an indicator that RE is recognized as critical in the company. Instead, assigning a person opportunistically in a case-by-case basis may imply at the end that nobody in the company will have the competences required in performing RE activities. Unless it is well implemented and supported, this rotation on the role may turn into an impediment to have continuity in RE competences over projects and thus is an impediment to having a holistic view about the requirements of the company product portfolio. This is especially true considering emerging competences needed to develop complex systems in dynamic environments, such as contextual intelligence and ability to act in complex situations, like learning to learn, sensemaking, mindfulness, and facilitate leadership.7 These competences are not easy to acquire and require some training that companies may not provide to all their employees when they become assigned as requirements engineer in one project. If the company cannot provide such training to several people, having the same person across several projects seems the best option.
Large variability of non-specific RE activities performed by requirements engineers. Some of these activities are a consequence of the requirement engineers playing multiple roles. For example, making a go vs. no-go decision is aligned with REs assuming some product management responsibilities. This overload may have a negative impact on the RE phase. The fuzzy barrier with project management tasks may be the root cause of a challenge reported by respondents, namely the suboptimal quality of requirements documents: at the end, some requirements may be missing, or their quality may be inadequate (in terms of, say, ambiguity or incompleteness).
Other activities identified in the study connect well with concrete development strategies. Some respondents informed about the requirements engineer being involved in testing activities. This aligns well with the principles of test-driven development, where requirements are quickly turned into test cases. However, this is not always easy to get. S1[A] reported that "The level of specification [of the requirements] was good enough for developers, because they participated in the discussions around requirements, but not for testers. More information or details were missing so testers were not able to completely understand the requirements."
One observation which can be important is that the role assignment, and who gets the assignment in cases of being ad-hoc and/or opportunistic, can be a source of challenges. Due to the demands of the role, working with items from technical depth, to business aspects, the competence of the person needs to be fairly high. In addition, the coordination responsibility calls for demand of personal contacts in the development organization.
Development method not a determinant when it comes to the requirements engineer role. To start with, both companies following an agile approach and other companies more on the "waterfall-ish" side, reported the existence of the requirements engineer role in their projects. The appointment of requirements engineers in agile projects aligns with the observation by Heikkilä et al.4 who justified the introduction of this role to help with problems with client or customer representatives. We observe there is an influence of the method on the way of staffing the role: the majority of projects in which respondents reported more than one person assigned as requirements engineer were developed Agile, while for the rest of staffing situations, waterfall projects dominated. In the extreme case, the method is a determinant for the contextual appointment of requirements engineer: the four respondents who reported this situation (S2, S21, S23, and S24) used a waterfall method in their projects.
The development method did not appear to be determinant in the other parts of the study. The main challenges reported by our practitioners were instability of requirements (and especially changes in prioritization), the problem of hidden needs, and different issues related to the requirement process, like effort estimation or definition of project scope. All these challenges are reported by some existing studies in agile practices,4,6 together with others that our respondents do not experience (for example, inappropriate architecture6/growing technical debt4). However, in our study, these challenges are mentioned by respondents regardless of the development method. For instance, Inayat et al.6 mention requirements changes as a challenge in agile projects, but in our study, this is mentioned by respondents from companies that work under a waterfall approach, for example, respondents S12, S13, and S17. We may conclude that at the end, requirements engineers must be prepared to face similar challenges regardless the development approach.
Influence of the company size. In order to find determinants in some RE characteristics, we investigated the influence of several factors. We observed the size of the company influences several aspects. Particularly, the nine respondents working in four very large companies (that is, with more than 10,000 employees) reported that REs do not interact with other roles in their projects, the staffing of personnel to the role does not depend on contextual factors, and except in one case, the requirement engineers do not perform tasks unrelated to RE. Considering the three facts together, we can say that the role of requirements engineer is better delimitated in very large companies than in the rest.
This study shows how the role of the requirements engineer in IT companies is elusive (in the sense of "hard to comprehend or define"8): every company may understand it and implement it in a different way often dependent on context. However, understanding of the qualifications and level of seniority needed for the role, and to what extent this is a central factor in role assignment is unclear, but possibly critical. With this paper, we hope to shed some light on this critical problem.
Acknowledgments. This work gas been partially supported by the GENESIS project, TIN2016-79269-R. Tony Gorschek's work has been supported by KKS Funded Software Engineering ReThought (SERT) Research Profile @ SERL-SWEDEN, BTH.
6. Inayat, I., Salim, S.S., Marczak, S., Daneva, M., S. Shamshirband, S. A systematic literature review on agile requirements engineering practices and challenges. Computers in Human Behavior 51, B (2015).
8. The Merriam-Webster English Dictionary; https://www.merriam-webster.com/
11. Palomares, C., Franch, X., Quer, C., Chatzipetrou, P., Lopez, L. and Gorschek, T. The state-of-practice in requirements elicitation: An extended interview study of 12 companies. Requirements Engineering J.; DOI:10.1007/s00766-020-00345
Copyright held by authors/owners. Publications rights licensed to ACM.
Request permission to publish from email@example.com
The Digital Library is published by the Association for Computing Machinery. Copyright © 2021 ACM, Inc.
No entries found