Requirement elicitation is the process of acquiring the system requirements from the system stakeholders. This process is critical in all software projects: if not all the requirements are elicited, or if some elicited requirements do not describe real stakeholder needs, or if the quality of the requirements is poor (e.g., they suffer from ambiguities), the chance of project failure increases. Techniques supporting requirements elicitation (interviews, meetings, storyboards...) are mostly oriented to obtain requirements from scratch and they may hardly take advantage of a fundamental observation: When specifying a system, it is quite usual that a significant proportion of requirements is recurrent and belongs to a relatively small number of categories, especially in the case of non-functional requirements. Our motivation is to consider this observation for improving the effectiveness of the requirement elicitation process. We are using the concept of software requirement
pattern [1] (SRP). An SRP basically consists of a template that generates one or more requirements, and some information to identify its need in a particular project, and how it may be tailored to this project. The main benefits of using SRPs may be summarized as: 1) more effective requirement elicitation (requirements are not built from scratch; a process guides the engineer by giving advices, suggesting information, ...); 2) improved quality and consistency of requirements documents (by using a uniform style); 3) improved requirements management (e.g., clear traceability from requirements to goals).Postprint (author’s final draft
