Resources

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).