Requirements reuse and requirement patterns: a state of the practice survey

Context. Requirements engineering is a discipline with numerous challenges to overcome. One of these challenges is the implementation of requirements reuse approaches. Although several theoretical proposals exist, little is known about the practices that are currently adopted in industry. Objective. Our goal is to contribute to the investigation of the state of the practice in the reuse of requirements, eliciting current practices from practitioners, and their opinions whenever appropriate. Besides reuse in general, we focus on requirement patterns as a particular strategy to reuse. Method. We conducted an exploratory survey based on an online questionnaire. We received 71 responses from requirements engineers with industrial experience in the field, which were analyzed in order to derive observations. Results. Although we found that a high majority of respondents declared some level of reuse in their projects (in particular, non-functional requirements were identified as the most similar and recurrent among projects), it is true that only a minority of them declared such reuse as a regular practice. Larger IT organizations and IT organizations with well-established software processes and methods present higher levels of reuse. Ignorance of reuse techniques and processes is the main reason preventing wider adoption. From the different existing reuse techniques, the simplest ones based on textual copy and subsequent tailoring of former requirements are the most adopted techniques. However, participants who apply reuse more often tend to use more elaborate techniques. Opinions of respondents about the use of requirement patterns show that they can be expected to mitigate problems related to the quality of the resulting requirements, such as lack of uniformity, inconsistency, or ambiguity. The main reasons behind the lack of adoption of requirement patterns by practitioners (in spite of the increasing research approaches proposed in the community) are related to the lack of a well-defined reuse method and involvement of requirement engineers.Peer ReviewedPostprint (author's final draft