Creativity and creativity techniques are relevant for requirements elicitation. There are many different creativity techniques, but these techniques are not used as widely as expected. To investigate the reasons for this situation, we assumed the viewpoint of a requirements engineer looking for decision-making guidelines to facilitate the choice among the considerable number of available creativity techniques. The results of the search highlighted the gap between existing information and what is needed. To this end, we propose a logical framework based on two matrices for choosing creativity techniques and methods in view of their application in requirements elicitation.
Creativity plays an important role in requirements elicitation. This fact is confirmed by the large number
of papers, books – textbooks, handbooks, proceedings, scientific books – illustrating the need for
creativity to support requirements elicitation. The CreaRE workshop itself – dedicated to creativity in
requirements engineering – celebrates its 10th edition (https://creare.iese.de); in addition to this there
are many other conferences covering requirements elicitation topics (among them, Requirements
engineering https://requirements-engineering.org). Literature illustrates the large variety of creativity
techniques in general [
In such a context, one would expect that companies would adopt creativity techniques and tools for
requirements elicitation in their software and information system projects. However, that is not always
the case [
Subsequently the question arises as to: “Why companies do not apply creativity techniques in their requirements elicitation activities?” and also: “How can we promote creativity techniques in requirements elicitations”?
Answering these questions in full requires systematic investigations and surveys.
As a first contribution towards that goal, this paper aims to address the following sub-question: “If a requirements engineer (or analyst, or systems engineer or project manager), wants to adopt a creativity technique for requirements elicitation activities, are there recommendations or guidelines to support the choice among the different possibilities”.
The paper goes on to offer a preliminary answer to that sub-question. Then, to solve the paradox
between theory and practice of the use of creativity techniques in requirements elicitation, we propose
a logical framework for describing existing creativity techniques. The framework elaborates a
preliminary classification (technique vs. method) described in a technical report [
The classification proposed in this paper is grounded in two matrices – including information at different levels of detail – whose content is suggested by requirements elicitation and project management practices. The goal is to help a requirements engineer in identifying the most suitable technique for a given project.
Searching in the literature, a requirements engineer will find a considerable number of books focusing
on the origin and the factors of creativity (a well-known handbook is [
Focusing on requirement engineering activities, many papers illustrate a specific creativity
technique, but there are also papers describing general issues. For example, [
A schema to classify creativity techniques is proposed in [18] and some of the classification criteria
are included in this paper’s proposals. In [
One of the reasons that could explain why creativity techniques are not a common practice in requirements elicitation is that available information is not adequate for choosing between different techniques.
For a practical classification, we propose initially checking if a given creativity technique also suggests a creativity process. We then call such creativity techniques ‘methods’, to distinguish them from simpler ones. Examples of creativity methods are brainstorming [25], or the 6 Hats [26]. A classical process for a creativity method includes 4 steps: Preparation, Incubation, Illumination, Verification [27]. Most of the creativity enhancement techniques are focused on the illumination step only. Creativity methods cover, albeit in a different way, all the steps. Distinguishing creativity methods is relevant to understand if, and to what extent, the requirements elicitation process has to be adapted to adopt a given creativity technique.
A common criterion used to classify creativity techniques is the individual vs group techniques [28], [29], [30]. In fact, there are many techniques that have been designed for group session use (e.g., brainstorming [25]), while others have been introduced for individual application (e.g., creativity pause [31]). However, this classification has been challenged by practical applications, as individual techniques can be applied also in group-work and vice-versa (see for example the experiment for individual brainstorming [32]; or for variations of the more recent EPMcreate [33], [34]). It is subsequently important to know if a creativity technique is an individual or group technique or if it can be applied in both ways.
Furthermore, there are many different parameters and information that could be useful in selecting a creativity technique for requirements elicitation. Given the ample variety, the framework illustrates their main advantages and disadvantages as an effective and succinct description. Finally, references to scientific papers, documents and websites, useful for finding more information, have be added; other contacts could also be included, as for example for research groups that defined the technique, or consultants, or experts in its application.
The result is a matrix with the fields given in Table 1, partially filled-in to give an idea of its use. The names of the columns define a logical record to create a knowledge base documenting all the available creativity techniques. (...)
yes
The knowledge base supports the selection of a subset of candidate techniques to be compared in a candidate techniques matrix, as illustrated in Table 2. The matrix includes parameters based on requirements elicitation and project management practices [35]. In the example, the parameters are listed in alphabetical order. Costs comprise all costs included in running the requirements elicitation session when applying the creativity technique; these costs depend on the other parameters: for example, costs for an external expert to act as a facilitator for a group technique, for new equipment (e.g., an interactive whiteboard), software to support the activities included in the technique, training for the analysts, etc. Documentation is useful to know if there is adequate material for the creativity technique (content, languages). Domain is necessary to know if the technique is domain-independent and/or if it has to be adapted to be applied to a specific project domain. Equipment specifies if the candidate creativity technique requires furniture or spaces or instruments. Facilitator indicates the role that is foreseen by many group techniques to guide requirements elicitation sessions. Learning curve indicates the training effort required to be able to apply the creativity technique. Maturity is useful to evaluate the level of risk involved in the adoption of the candidate technique: some creativity techniques have been introduced more recently than others and could be more innovative, but also pose more risk; more importantly, a given technique may have never been applied to elicit requirements. Popularity helps to evaluate requirements engineering commitment in applying a creativity technique: renowned techniques should be more readily accepted, even though in some companies very new techniques could possibly challenge requirements engineering in a positive way. Steps allows specification of which activities may be supported by the candidate creativity techniques adding details relevant for its adoption. For example, a simple technique could be adopted in a pilot project in companies where creativity had never previously been considered; while a fully-fledged creativity method could be more suitable for challenging projects in which new requirements are a must (e.g., a software system for a highly competitive sector). Finally, tool indicates potential software systems supporting the creativity technique candidate’s application.
The candidate creativity techniques matrix can be used to attribute value of increasing precision to the listed parameters: Boolean (to specify if a candidate technique satisfy the attributes); using a Likert scale (giving a numerical score to each attribute in a defined range); giving a textual description of the specific characteristics for, e.g., a list of the equipment, the name of the tools available, number or types of projects where a candidate technique has been applied, etc.
The goal of this paper is to propose a framework based on two matrices to describe available – although often unknown – creativity techniques and methods in order to promote their adoption in requirements engineering. It is a first contribution towards a description of creativity techniques suitable to support a requirements engineer in choosing between the large number of available techniques.
The parameters in the matrices have been advocated by project management good practices and reflect a practical approach. Nevertheless, the two matrices have to be validated and refined. The first one should cover as many techniques as possible. Some of them are variants of the same technique, so that a hierarchical sub-classification could also be added [36]. Moreover, creativity techniques have to be described briefly to be of practical use. Subsequently, following an incremental process, the second matrix allows a requirements engineer to compare candidate techniques chosen from the first matrix, adding more information only for a limited sub-set of the existing techniques. More importantly, such information has to be ‘customized’ according to the project, the company, the sector, the process model, and any other aspect that could affect a successful application of creativity practices. Finally, as creativity techniques can be adopted to support many different activities in requirements engineering, the matrices could also be adapted to include criteria and parameters for those activities.
The two matrices framework constitutes the conceptual core of a creativity techniques knowledge base, which in turn can be used to design and implement a knowledge-based decision support system (a KBDSS, [37]). The architecture and the interface of the KMDSS have to be designed (a) to effectively exploit the information in the two matrices, (b) to allow a requirements analyst to adapt them to satisfy a company’s customization and selection process requirements. 4. References [17] S. K. Saha, M. Selvi, G. Büyükcan, M. Mohymen, A systematic review on creativity techniques for requirements engineering, in: Proceedings of International Conference on Informatics, Electronics & Vision (ICIEV), Dhaka, 2012, pp. 34-39. [18] P.P. Grube, K. Schmid, Selecting Creativity Techniques for Innovative Requirements Engineering, in: Proceedings 3rd International Workshop on Multimedia and Enjoyable Requirements Engineering - Beyond Mere Descriptions and with More Fun and Games, 2008, 32-36. [19] R. B. Svensson, M. Taghavianfar, Selecting creativity techniques for creative requirements: An evaluation of four techniques using creativity workshops, in: Proceeding IEEE 23rd International Requirements Engineering Conference (RE), Ottawa, ON, 2015, pp. 66-75. [20] A. J. Franco, G. U. Giraldo, Brainstorming versus a Scenario-based Approach: Results of an Empirical Study, in: Proceedings of the 8th International Conference on Software and Information Engineering, 2019, pp. 30-37. [21] K. Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques (1st ed.), Springer
Publishing Company, Incorporated, 2010. [22] E. Mcfadzean, “The Creativity Continuum Towards a Classification of Creative Problem
Solving_Techniques”, Creativity and Innovation Management, 2008, 7(3):131–139. [23] R. W. Weisberg, Problem solving and creativity, in Sternberg R. (Ed.) The nature of creativity,
Cambridge University Press, New York, 1988, pp. 148-176. [24] S. J. Parnes, Source book for creative problem solving, Creative Foundation Press, Buffalo, 1992. [25] A. F. Osborn, Applied Imagination, Scribner, New York, 1953. [26] E. De Bono, Six thinking hats, Key Porter Books, Toronto, Ont., 1985 (revised and updated edition 2019). [27] G. Wallas, Art of Thought, Harcourt, Brace & Company, New York, 1926. [28] R. P. Bostrom, M. Nagasundaram, Research in creativity and GSS, in: Proceedings of the 31st Hawaii International Conference on System Sciences, Kohala Coast, HI, USA, 1998, pp. 391-405 vol.6. [29] K. Wang, J. V. Nickerson, A literature review on individual creativity support systems. Computers in Human Behavior, 74 (2012) 139-151. [30] R. McAdam, J. McClelland, Individual and team‐based idea generation within innovation management: Organisational and research agendas, European Journal of Innovation Management, 2002 Jun 1. [31] L. Székely, “The creative pause.” International Journal of Psycho-Analysis 48 (1967): 353-367. [32] S. M. Ritter, N. M. Mostert, How to facilitate a brainstorming session: The effect of idea generation techniques and of group brainstorm after individual brainstorm, Creative Industries Journal, 2018. doi: 10.1080/17510694.2018.1523662. [33] A. Herrmann, L. Mich, D. M. Berry, “Creativity Techniques for Requirements Elicitation: Comparing Four-Step EPMcreate-Based Processes,” in: Proceedings 7th International Workshop on Empirical Requirements Engineering (EmpiRE), Banff, AB, 2018, pp. 1-7. [34] V. Sakhnini, L. Mich, D. M. Berry, The effectiveness of an optimized EPMcreate as a creativity enhancement technique for Web site requirements elicitation, Requirements Engineering 17, 171– 186, 2012. [35] D. I. Cleland, R. Gareis, Global Project Management Handbook, McGraw-Hill Professional, 2006. [36] K. Holt, Brainstorming - from classics to electronics, Journal of Engineering Design, 1996 Mar 1; 7(1): 77-82. [37] M. R. Klein, L. B. Methlie, Knowledge-based decision support systems with applications in business. Second edition. John Wiley & Sons, Chichester, 2000.