Communications of the ACM
Contributed articles
On the Requirements Engineer Role
Credit: Getty Images
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.
Key Insights
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.
Table. Respondents, their projects, and their companies.
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:
- The organization assigns a person as requirements engineer due to some other role or position s/he currently plays in the project or organization. For instance, S3[B] (and similarly S4[B]) reported that "it is always the same person, the system analyst," while S9[E] informs that "it is a hat worn by the business analyst" and S14[H] and S15[H], "the system engineer." S20[J] mentions two other candidates, namely the system developer and the designer.
- The organization assigns a person as requirements engineer in a case-by-case basis, as stated by S1[A], S10[F], S17[I] and S19[J]. S1 informs about a specific name for the role, namely "requirements lead."
- It is the client organization that assigns the requirements engineer. Respondents S12[G] and S13[G] reported such situation because "my organization works as a provider of systems or solutions, and the client is the one in charge of providing the requirements." Also as reported here, S17[I] identified this situation for some projects in her organization.
Eight respondents reported that more than one person has assigned the requirements engineer role. Again, we distinguish several situations:
- The requirements engineer role is split into different roles that act at different moments. We found two similar situations:
- Respondents S6[D] and S7[D] reported one department and one role for managing requirements: the global service department and the system manager. The global service department "manages the business requirements for all the systems in the organization" while the system manager "knows the requirements of a specific product" and acts as a "spoke person for the main requirements from a technical point of view," playing a role similar to that of a project owner in agile development projects. The main reason behind sharing requirements at these two levels is their need to manage all the main products of the organization in a holistic way.
- Respondent S18[J] informed about a system constructor role "who is responsible of translating from function owner requirements (high-level goals) to system requirements … distributed to different modules of the platform" and a requirements manager "who is the person who has a general view of the requirements at the module level." Similarly, S5[C] reported a system analyst closer to the customer, and an interaction designer for elaborating the initial requirements. In both cases, the assignment of particular people to these roles is made case-by-case.
- The requirements engineer role is exerted by several people that collaborate during the project. In all the cases, one of the people had a clear lead:
- S16[I] reported the product manager did most of the RE work but had the support of a person taking care of a repository of safety requirements, given the importance of this particular type of requirements in company I.
- S8[E] reported three roles involved in RE: "The system analyst, the project manager, and the system architect, and these people are also doing other tasks, so it is a hat that a person wears at some moment."
- Also, three roles were mentioned by S11[F]: system architect, who is the "person that has more responsibility over requirements;" interaction designer, in charge of requirements related to user interface; and developers, who mainly "add ideas related to technical requirements in the project meetings."
- S22[K] informed about a non-complete list of people acting as requirements engineers as needed: product owner, project leader, architects, interaction designers, and so on. However, even if "all the responsibilities are dispersed between these roles," still "the project leader is the main responsible for the requirements."
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.
- S23[L] and S24[L] reported that a dedicated person is assigned or not depending on the size of the project: "For large projects, it is a designated person. For small projects, it is a person that later will do further tasks."
- S2[A] reported a similar situation with the addition that "for huge projects there could be more than one requirements analyst in the project."
- In the same pace, S21[K] informed that usually the product owner or product manager acts as requirements engineer, but "If that person has too much work, they can pass that responsibility to other persons, like consultants or testers." Furthermore, for some big projects or own development projects they appoint a specific business analyst.
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:
- Probably the most critical action was mentioned by S5[C]. In his 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.
- Whenever necessary, the requirements engineer may be requested to provide a business view. S21[K] mentions as responsibilities "defining a business model, defining how the return on investment is achieved by the specified requirements."
- Some activities arise due to the nature of the organization. For example, respondent S7[D] works in a market-driven company. Therefore, one of the two roles managing requirements, the system manager, needs to do "quick studies or pre-studies and based on that they select what to put in their requirements and how to scope the solution."
- Requirements engineers may sometimes be assigned to perform project management tasks. As reported by S3[B], the reason may be that "there is no clear barrier of who should do these tasks."
- Interaction inside the organization may be necessary for the requirements engineers. S19[J] reports among the main responsibilities "talking to other groups to get input or data necessary from other systems."
- Some of the respondents include test-related activities as part of the requirements engineer responsibilities. S2[A] and S3[B] mention the design of tests, while S6[D] reports the specification of tests in general. S5 also run the tests for some requirements.
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."
Discussion
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:
Figure. Summary of responses in the study.
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.
Conclusion
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.
References
1. Calzanas, A. et al. Software requirements analyst profile: A descriptive study of Brazil and Mexico. RE, 2017.
2. Chang, C.K., Christiansen, M. Blueprint for the ideal requirements engineer. IEEE Software 13, 2 (1998).
3. Glinz, M. A glossary of requirements engineering terminology, Ver. 1.7. IREB (May 2017).
4. Heikkilä, V.T., Damian, D., Lassenius, C., Paasivaara, M. A mapping study on requirements engineering in Agile software development. SEAA, 2015.
5. Herrmann, A. Requirements engineering in practice: There is no requirements engineer position. REFSQ, 2013.
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).
7. Jantunen, S., Dumdum, R., Gause, D.C. Towards new requirements engineering competencies. CHASE, 2019.
8. The Merriam-Webster English Dictionary; https://www.merriam-webster.com/
9. Morales-Ramírez, I., Alva-Martínez, L.H. Requirements analysis skills: How to train practitioners? REET@RE, 2018.
10. Paech, B. What is a requirements engineer? IEEE Software 25, 4 (2008).
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
12. Palomares, C., Quer, C. and Franch, X. Requirements reuse and requirement patterns: A state of the practice survey. Empirical Software Engineering 22, 6 (2017).
13. The Project Management Institute. Pulse of the Profession® In-Depth Report: Requirements Management—A Core Competency for Project and Program Success. 2014.
14. Patton, M.Q. Qualitative Research & Evaluation Methods. Sage Publications, 2002.
15. Wang, C., Cui, P., Daneva, M., Kassab, M. Understanding what industry wants from requirements engineers: An exploration of RE jobs in Canada. ESEM 2018.
16. Wiegers, K.E., Beatty, J. Software Requirements, 3rd Ed. Microsoft Press, 2013.
Copyright held by authors/owners. Publications rights licensed to ACM.
Request permission to publish from [email protected]
The Digital Library is published by the Association for Computing Machinery. Copyright © 2021 ACM, Inc.
No entries found