Software Requirements: Styles and Techniques
Software Requirements: Styles and Techniques
Mastering the Requirements Process (2nd Edition)
Mastering the Requirements Process (2nd Edition)
The requirements engineer as a liaison officer in agile software development
Proceedings of the 1st Workshop on Agile Requirements Engineering
| Hi-index | 0.00 |
[Context and motivation] Our company's software development process describes seven roles, one of which is the requirements engineer. We want the work of the requirements engineer to give more benefit in our development projects than is currently the case. [Question/problem] The requirements engineer works in an interdisciplinary setting closely together with the other roles, in particular with the user experience specialist, the software architect, and the project manager. We have found that these three roles are performing most of the actual RE work in our projects. As a consequence, the requirements engineer often only plays a minor role, which is also explained by the fact that the requirements engineer role is not given high organisational attention. With a few exceptions, the requirements engineer is appointed ad hoc, at project level. This poses a potential risk of neglecting important RE activities. The problem that we address is how to best distribute responsibilities between the requirements engineer role and the other roles in our organization. [Principal ideas/results] We have surveyed a number of recent projects and have analysed to which extent RE has been carried out, by which roles, and with which techniques and tools. [Contribution] Our contribution is to discuss our survey results and on this basis propose a redefinition of the requirements engineer role that respects that user experience, software architecture, and project management have a higher organisational priority.