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 [1]. A core piece of RE are the requirements elicitation, specification and reuse processes.

Requirements elicitation is typically seen as the first step of RE [2]. It refers to the activities undertaken to surface the requirements of a system to be built or a problem to be solved [3]. Requirements specification involves describing adequately the elicited requirements. The main and most important specification task is to document the requirements for the system to be in a suitable manner [4]. Finally, requirements reuse refers to taking advantage of requirements knowledge obtained from previous projects and later on using this knowledge in a new one.

In order to understand better how requirements elicitation, specification and reuse practices are made in industry, we conducted an interview-based empirical study involving 12 Swedish companies and 24 senior experienced practitioners.

For more information on the study see also:

• Authors
• Resources

References

[1] The Project Management Institute (PMI), “Pulse of the Profession® In-Depth Report: Requirements Management — A Core Competency for Project and Program Success”, 2014.
[2] B. Nuseibeh and S. Easterbrook, “Requirements engineering: a roadmap”, in Procs. of the Conference on the Future of Software Eng. (ICSE’00) ACM, pp. 35–46, 2000.
[3] I. Sommerville and G. Kotonya, “Requirements engineering: processes and techniques”, John Wiley & Sons, Inc., 1998.
[4] K. Pohl and C. Rupp, Requirements Engineering Fundamentals, O'Reilly, 2011.

Finding 1.1. Group interaction techniques (meetings, workshops, …) are the most used in elicitation, more than individual participation techniques (interviews, questionnaires), reading documentation or conducting market research.

Finding 1.2. The main sources of requirements are the customer (often complemented with other external stakeholders, as external consultants) and technical roles as developers and system engineers. Analysts and market departments are also frequently involved.

Finding 1.3. Except in the case of having very well educated customers, elicitation has to face several challenges, being the most important ones related to the stakeholders (understanding their needs, prioritizing them and solving conflicts) and to stability (changing needs or priorities along the elicitation process). The elicitation process itself (e.g., time required) and the difficulties on communication (e.g., dealing with tacit knowledge) are also cited as challenges

Finding 1.4. Requirements elicitation does not rely on tool support, neither requirements management tools nor other type of tools (e.g., tools for collaborative work when conducting group interaction techniques).

Finding 2.1. Plain Natural Language (NL) is the usual language for specifying requirements. In some cases, it is used as the main language, and in other cases it is the starting language for the specification of requirements. Apart from plain NL, use cases and user stories are other textual artefacts used by about half of the respondents. Graphical representation and models were also mentioned by approximately half of the respondents, being mockups the most popular artefact among them. Remarkably, no type of model was dominant, although UML as modeling notation was mentioned by several respondents.

Finding 2.2. The use of templates for specifying requirements is quite common. The dominant provenance of the templates is the organization itself; in particular, standards are not much relevant in the definition of templates. Templates are used mainly for fixing the layout of the document (e.g., defining headings or section titles), and also for how-to-write guidelines and determining requirement attributes.

Finding 2.3. Requirements are always somehow classified. The most recurrent structuring concept is the functionality the requirements refer to. Concerning the structuring element, the use of headers and sections is largely preferred.

Finding 2.4. It is common to face challenges in the specification of requirements. Ambiguity is reported to be the most common specification challenge, followed by incompleteness and inconsistency. Incompleteness is the considered the toughest of such challenges.

Finding 2.5. MS Office tools are commonly used in specification practices. Other tools used in specification practices, sometimes used together with MS Office tools, are: modeling tools (e.g., IBM Rational Rose); project management tools (e.g., Jira); requirement management tools (e.g., IBM Doors) and large tool suites (e.g., IBM Rational ClearCase).

Finding 3.1. Some kind of requirements reuse was reported by the large majority of respondents, either in the project they chose for the interview or in other projects in their company. Focusing on the chosen projects, the situation was very diverse with the same share of respondents reporting high and low level of reuse.

Finding 3.2. Organizational factors were the most mentioned ones as influencing reuse, especially organization culture. Similarity among projects was also highly mentioned.

Finding 3.3. There was a significant majority of respondents who consider reuse as a beneficial practice in requirements engineering.

The most recurrent benefit was improving the effectiveness of the elicitation process, while also organization benefits (e.g., need to invest less effort in requirements-related practices) was often mentioned.

Finding 3.4. Among the reasons given for not reusing requirements, excels the diversity of projects and domains. An obstacle mentioned as impediment to reuse is the low consideration of requirements engineering in some companies.

Finding 3.5. Non-functional requirements are the most common type of requirement being object of reuse.

Finding 3.6. By far, the most popular reuse technique envisaged or followed by respondents is search for similar requirements in previous projects, and then copy, paste and modify. The use of tools or catalogues was only sparely mentioned.

Finding 3.7. Except one respondent, all considered requirement patterns useful. Success factors for their adoption are of different nature, with training being the most mentioned one, but also the existence of evidences like successful cases and measurable benefits.

Finding 3.8. The two main obstacles mentioned for patterns adoption are the integration in the current requirements engineering practices, and the resistance of requirements engineers to change. The impact on creativity and the need of a high-quality catalogue of patterns were also highlighted.

Finding 3.9. Main benefits on the use of patterns are similar to those mentioned for reuse in general (see Finding 3.3).