A Software Process Line for Combinational Creativity-based

Requirements Elicitation

Rafael Pinto

, Lyrene Silva

, Marcia Lucena

and Fellipe A. Aleixo

Instituto Federal de Educação, Ciência e Tecnologia do RN, Rua Dr. Nilo Bezerra Ramalho, Natal/RN, Brazil

Universidade Federal do Rio Grande do Norte, DIMAP, BR 101 - Lagoa Nova, Natal/RN, Brazil

Keywords: Requirements Elicitation, Combinational Creativity, Software Process Line.

Abstract: The need for innovation and appreciation of creative solutions has driven requirements engineering

researchers to investigate creativity techniques to elicit useful and unique requirements. Some techniques

are based on the combination of ideas (requirements, words or problems) that generally come from different

sources and are carried out in a process that involves different roles. However, how can we identify the

common core and which variations can be adapted to the organizational context where the technique will be

used? This article presents a Software Process Line (SPrL) to elicit requirements based on combinational

creativity. This SPrL represents commonalities and variabilities found in some combinational creativity

techniques thereby it helps teams to define the combinational technique according their organizational

context. We validate this approach by discussing how the SPrL is aligned with three techniques that have

already been used in experimental studies and produced satisfactory results.

1 INTRODUCTION

Requirements engineering is the process of finding

out the purpose of a system by identifying its

stakeholders and their needs, as well as registering

this information in a way that enables its analysis,

communication and subsequent implementation

(Nuseibeh and Easterbrook, 2000). However, in

some situations it is hard to identify how to improve

the systems or how to make them competitive. This

identification process is even more difficult when it

comes to a new product or an unknown market

(Saha et al., 2012).

Thus, creativity can be considered a success

factor for organizations and industries. Sternberg

(Sternberg, 1999) defines creativity as "the ability to

produce work that is both novel (i.e., original and

unexpected) and appropriate (i.e., useful and

adaptable to task constraints)". In the requirements

engineering context, the definition of creative

requirements as innovative and appropriate (Maiden

et al., 2010) is also used and the strategic importance

of creativity and innovation for software

development is highlighted.

Among the creative requirements elicitation

techniques, we have focused on those based on

combinational creativity, such as the framework

defined in (Bhowmik et al., 2014). This framework

proposes the creation of new requirements from

word pairs (verb, noun) combined in an unfamiliar

way. These pairs are extracted using a flow that

involves social network analysis, natural language

processing (NLP) and similarity analysis. They

carried out an experiment showing that the proposed

framework is able to generate creative requirements.

Later works (Pinto et al., 2015; Pinto, 2016)

modify the process proposed by (Bhowmik et al.,

2014) defining the following changes: these works

did not use social networks and similarity analysis;

they diversified the source of the texts that

originated the words; they varied the way they

choose the words with NLP; they allowed the

requirements engineers (REng) to add, modify or

delete, manually, the set of words; and they

diversified the number of stakeholders, as well as

their location and profiles. Even with these

variations, the experiments that they carried out

showed that it was also possible to create new and

useful requirements.

Therefore, there are several ways to extract and

combine the elements that make up the elicitation

strategy. Moreover, the organizational context

influences directly the variations that will be applied

360

Pinto, R., Silva, L., Lucena, M. and Aleixo, F.

A Software Process Line for Combinational Creativity-based Requirements Elicitation.

DOI: 10.5220/0006315803600369

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 360-369

ISBN: 978-989-758-248-6

when using this type of technique. Thus, using

combinational creativity to carry out requirements

elicitation may require great effort from

requirements engineers (REng) since they have to

identify what should be considered and what can be

varied.

This work proposes a Software Process Line

(SPrL) for requirements elicitation using

combinational creativity. We mapped tasks and

variabilities that were defined in previous works to

facilitate the use and adaptation of this kind of

technique to the organizational context in which the

software will be developed. These variabilities

provide greater flexibility for the REng to instantiate

the model to a specific situation. Our SPrL enlarges

the possible combinations, however it does not try to

exhaust all possibilities.

The remainder of this paper is organized as

follows. Section 2 cites some creativity techniques

and the software process line concept. Section 3

defines a software process line for combinational

creativity-based requirements elicitation and how to

instantiate it. Section 4 presents the similarities

between this SPrL and experiments previously

carried out and presented in the literature. Finally, in

section 5, we present general conclusions and future

works.

2 BACKGROUND

The software industry has been encouraged to

develop innovative products to stand out from their

competitors and attract new customers (Lemos et al.,

2012). This way, the industry tries to identify

unexpected satisfaction factors (Kano et al., 1984),

which are those system properties that stakeholders

do not know of or do not expect to find and that are

usually discovered when using the system.

Creativity techniques are most suitable to come up

with these factors (Pohl and Rupp, 2011).

Creativity can be defined as a mental process

involving the generation of original and innovative

ideas (Nguyen and Shanks, 2009) and can be

classified as exploratory, combinational or

transformational (Boden, 2004). In requirements

engineering, this classification varies with the

techniques and heuristics used (Maiden, 2013). In

the exploratory creativity, creative requirements are

obtained by exploring the possibilities in a search

space delimited by rules and tasks constraints

specific to the software. The combinational

creativity is achieved by making unknown

connections between known requirements in a

familiar environment. That is, it is characterized by

using known solutions in an unlikely combination.

Transformational creativity, in its turn, is performed

by challenging the search space restrictions,

exceeding this restricted space.

2.1 Creativity-based Elicitation

Techniques

There are different approaches to stimulate creative

thinking during the requirements elicitation process,

such as: conducting requirements workshops

(Maiden et al., 2004); performing the EPMCreate

(Elementary Pragmatic Model Creative

Requirements Engineering Technique) (Mich et al.,

2005); conducting the elicitation process based on

the integrated collaboration between technologists

and users (Yang-Turner and Lau, 2011); using

Design Thinking (Vetterli et al., 2013); and using

approaches that combine words to create new

requirements (Bhowmik et al., 2014; Pinto et al.,

2015; Pinto, 2016).

These later works use natural language

processing (NLP) algorithms to find relevant words

in information sources, which are then used as input

for participants to elaborate ideas.

These techniques can promote the understanding

of the client's implied expectations (Lemos et al.,

2012). They have a common goal, but they are very

different when considering the way that they are

carried out. Therefore, they require hard effort from

the REng who needs to understand the existing

possibilities and how the organizational context

influences them.

Given the diversity of creativity-oriented

elicitation techniques, we realized the importance of

having an abstract model to organize and cover the

common points and the existing variabilities. Thus,

we modeled the combinational creativity-oriented

elicitation as a software process line, i.e. a process

that has different characteristics that will be selected

(instantiated) according to the existing context and

REng´s goals.

2.2 Software Process Line

A software process can be defined as the set of

activities required to design, develop, implement and

maintain a software product (Fuggetta, 2000). These

activities may require resources, as well as consume

and/or produce artefacts and adopt procedures while

they are being carried out. Artefacts are software

products that are consumed or produced during an

activity (Falbo et al., 1998).

A Software Process Line for Combinational Creativity-based Requirements Elicitation

361

Software Process Line (SPrL) is the integration

of concepts that comes from software process and

software product lines (Rombach, 2005). Depending

on the organizational context, software processes

must be distinguished presenting variabilities and

commonalities (such as software product lines). The

goal of a software process line is, therefore, to guide

software engineers in their development tasks

(Aleixo, 2013), by defining these commonalities and

variabilities, i.e., what is mandatory and what is

alternative or optional. The organizational context is

characterized by its goals, available people,

processes and artefacts, as well as by the features of

the project that is being developed.

The feature model represents variabilities and

commonalities of a process family. It is a tree

structure that represents associations between

features as follows: (i) Mandatory – features that

must be in all instances of the process; (ii) Optional

– features that may or may not be in each instance;

(iii) Inclusive – at least one of the associated features

must be in the process; and (iv) Alternatives – only

one of the associated features (Ataide et al., 2012)

must be in the process.

3 A PROCESS LINE FOR

ELICITATION

Our SPrL defines an elicitation process based on

combinational creativity. It models the fundamental

characteristics of this type of process and points out

those that can be adapted according to the context or

experiment being carried out. Thus, the contribution

of the SPrL is to make clear and organized

variabilities and commonalities of this type of

technique, making it easy to develop new techniques

or adjust the existing ones to a specific context.

This modeling approach consists of two models:

(i) a process model in BPMN notation, which

(abstractly) defines a sequence of activities, their

inputs and outputs and the roles played, shown in

Figure 1; and (ii) a feature model, which

hierarchically organizes process features, indicating

the possible combinations, as illustrated in Figure 2.

In addition, a third document defines how features

and process elements are associated, as well as

which are the implications and constraints between

features.

3.1 Process Model

As shown in Figure 1, the elicitation process begins

with a planning phase in which the REng should: (i)

define the element sources – the element sources are

artefacts or repositories chosen by the REng to serve

as source of information from which elements (e.g.

words, ideas, requirements, figures) will be

extracted. These elements will be used by the

stakeholders as input for the creation of

requirements; (ii) select elements – i.e. pick a set of

elements that inspire stakeholders. Usually, this set

is not very large and its elements should be

organized into categories; and (iii) define criteria for

requirements elaboration – in which the REng

decides which combinations the stakeholders can

make with the available elements.

After that, in the execution phase, stakeholders

play a key role that includes: (i) creating new

requirements – in which they will analyze the

available elements and propose ideas (or sentences)

that represent new requirements, according to the

Figure 1: A combinatorial creativity-oriented elicitation process.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

362

specified criteria; (ii) validating requirements – in

which stakeholders must evaluate if the

requirements are in accordance with the creativity

criteria defined by the REng; and (iii) improving

requirements – this is an optional activity, its goal is

to consider the possibility of carrying out another

elicitation process based on the requirements that

have already been found. The process ends with a

list of requirements for the system.

This process is abstract to generalize common

activities of any elicitation process, particularly

those that are related with the planning phase and are

based on combinational creativity. The activities of

this process are characterized by the feature model,

in Figure 2. Therefore, the process alone does not

represent a process line, the feature model is an

essential part that complement it.

3.2 Feature Model

The feature model shown in Figure 2 begins with an

abstract item that represents the entire elicitation

process. This item is decomposed in an optional

feature, the "Improvement of requirements", and five

mandatory features, which are: "definition of

element sources", "selection of elements",

"definition of criteria for requirements elaboration",

"elaboration of requirements" and "validation of

requirements". These features are directly related to

the activities that have the same denomination,

shown in the elicitation process (Figure 1) and

explained below.

Definition of element sources – This feature refers

to the choice of information sources from which

elements (e.g. words, ideas) will be extracted. These

sources are tangible artifacts that mandatorily

consist of: (i) kind of media that represents it,

whether it is represented by texts, images, video or

audio; (ii) what is their relation with the system,

whether they are directly related (named internal

source) such as the system documentation (e.g.

vision document, use cases) or are foreign (named

external source) to the software's purpose, extracted

from a general and open source (e.g. news website

and social networks, podcasts, music, advertisement

lectures); or a combination of both. In these cases,

all concrete features (the leaves) are alternative

because more than one of them can be selected.

Some organizational questions that influence this

choice are: software documentation is enough rich?

Is it necessary complement the documentation with

some external source? Which kind of media do the

sources use? How distinct from those coded should

be the new ideas? Which subjects should the new

ideas deal with?

Selection of elements – This feature refers to how

the elements are selected and which types of

elements should be made available to stakeholders to

create requirements. Thus, the following sub-

features are mandatory:

(i) elements classification, which depends on the

previously chosen media: if are texts, they can be

classified according to grammatical categories (i.e.

verbs, nouns, adjectives); if they are images, video

or audio, they can be classified according to their

content or style (e.g. for images: abstract, real,

objects, graphics; for video: advertising, news,

Figure 2: Feature model for our elicitation process.

A Software Process Line for Combinational Creativity-based Requirements Elicitation

363

lectures; for audio: news, advertising, music). This

classification influences the definition of the criteria

(possible combinations) for the creation of

requirements. For example, in (Bhowmik et al.,

2014), given textual elements, the participants had to

use predetermined pairs of verb and noun;

(ii) kind of processing of element sources, if

searching for the most (or least) common elements,

for the most (or least) relevant elements or for

unfamiliar combinations (for textual elements). This

processing form depends on the media used in the

sources. For example, if the REng has chosen an

image or video social network as element source, it

could select images and videos that are better (or

worst) evaluated or that are most (or least) viewed.

Choosing the most common elements results in those

most relevant, but that can have already been

exhaustively approached. On the other hand,

selecting the least common elements can result in

those that were not dealt with, but whose relevance

for the scope is small.

(iii) element selection form, which can be

manual or automated. The manual selection can be

used in situations when the number of element

sources is not big or when they are not digital (that

is, they are, for example, printed text or printed

photos); and

(iv) the number of elements to be extracted (and

later made available), considering that the greater

the number of elements, the easier it will be for the

stakeholder to generate a requirement that he or she

was already predisposed to request (taking into

consideration a need empirically identified). Thus,

there will be no effort to create something that was

not yet thought of. On the other hand, setting a very

small number may excessively limit the possibilities,

making it hard to come up with new requirements or

even making the creation task an arduous and

tedious job.

Definition of criteria for requirements

elaboration – This feature indicates the need to

define criteria to drive the creation of requirements.

These criteria should take into account the

classification of the elements, how they should be

combined and what is waited to be produced by the

stakeholders. For example, in (Pinto et al., 2015): i)

each participant must create simple sentences

representing a new feature for the system; ii) each

sentence must contain at least one word from the list

of verbs and one word from the list of nouns; iii) the

requirements should be created in a time span of 30

minutes. These criteria can also include a template

for the requirements sentences, for instance: "The

<system> must/should/will + <verb> + <noun>".

Requirements templates provide a simple and

understandable approach that helps to reduce the

language variation in requirements documents,

decreasing the ambiguity and so increasing their

quality (Pohl and Rupp, 2011).

Elaboration of new requirements – This feature

refers to the elicitation itself, which should be

guided by the elements and criteria provided

previously and should also consider: (i) stakeholders

location - whether they will be present in a face-to-

face or remote meeting or if questionnaires will be

used; (ii) stakeholders profile - whether they are end

users, domain experts or developers; (iii)

organization and interaction between stakeholders -

if they will perform the task individually, in pairs or

in larger groups; and (iv) the number of

stakeholders, since it can interfere directly in the

amount of generated requirements or in the time it

will take to create the desired amount of

requirements.

These factors are essential for any elicitation

technique. The success (or failure) of an elicitation

process is substantially influenced for the

availability of resources and characteristics of the

project, organization, and environment (Zowghi and

Coulin, 2005). It is not always possible to group all

the best characteristics due to context and

organizational constraints, such as, relevant people

are not available, people are geographically spread,

people do not work well in groups or not understand

each other.

Validation of requirements – This feature includes:

(i) the criteria to be used in the evaluation – whether

utility, innovation, viability or simply the fact that it

was not thought of previously. It is important to

make the meaning of each criterion clear since they

can vary in accordance with the context or people

that are validating; (ii) the score scale to be assign to

each criterion, for example, the Likert scale (Matell

and Jacoby, 1971), VAS (Visual Analogue Scales),

numerical scale or the Guttman scale; (iii) who will

perform the evaluation – whether the same group

that elaborated the requirements (assuming that they

will not evaluate their own requirements), an

external team that had no part in the previous task, a

team of developers or the REng; (iv) the number of

requirements that will be evaluated by each

participant and the number of evaluations waited for

each requirement. It is necessary to balance these

numbers because a large number of requirements for

each stakeholder may make the evaluation process

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

364

boring and thus compromise its quality. At the same

time, a little number of evaluations by requirement

will make the biased evaluation.

Improvement of requirements – This feature is

optional, but once it is selected, the following items

should be defined: (i) which requirements will be

discussed, for instance, all of them, the most creative

or those considered not creative; (ii) which

elicitation technique should be used, e.g. interview,

workshops or even creativity techniques; and (iii)

who are the participants - stakeholders that took part

in previous tasks, other stakeholders or only

software engineers.

3.3 How to Use this Process Line

In order to use this SPrL, it is necessary to generate

a process configuration. Each configuration includes

all mandatory features and those optional, or-

inclusive or or-exclusive that have been selected by

REng. During the selection, dependencies between

features must be respected, for instance, when the

chosen media is image, it is not possible select a

kind of classification associated to text (e.g. verb

and object). Configurations may be manually

generated by regarding the options and constraints of

feature model. When the features are chosen, they

must be applied to the activity flow. We illustrate

with an example to follow.

Table 1 summarizes a set of possible choices for

all mandatory features, in which the last column

represents a configuration. In this example, the

elements sources are internal and external pictures;

the ten most viewed images will be automatically

selected and classified according to two people´s

feeling (sadness or happiness); being five pictures of

each category. The requirements definition rules

impose that the ideas have to mention characteristics

from at least one picture of each category.

Elaboration will be performed by five pairs of users,

geographically distributed. The validation will be

performed by an external team with three experts in

innovation; each person will evaluate all

requirements in accordance to Linkert scale with 5

points. Ideas that have the maximum score will be

improved and prototyped in a design thinking

meeting.

Table 1: An instance of our SPrL - features.

Feature from SPrL Instance

Def. of element sources

Internal or external source Internal and external

source: pictures from a

social network about the

system and a related

system

Media Image

Selec. of

elements

Image classification Happiness and sadness

Selection type: automatic or manual Automatic by using an

app for classification

Processing type The most viewed pictures

Quantity of elements Five of each

classification

Def. of criteria for req. elab.

Criteria Each requirement should

be based on a picture of

each classification. The

participants should cite

which pictures he or she

has used.

Requirements definition A non-structured text

explaining a user story

Elab. of req.

Location of the participants Remote

Participants organization and interaction Each pair works using

collaborative tools

Kind of participants Users who are experts on

the domain

Number of participants 5 pairs

Validation of req.

Validation criteria New for that system and

useful

Score scale Likert scale with 5 points

Kind of participants Experts on innovation

Number of participants 3

Number of requirements each

participant validates

All ideas

Improv..of req.

Which requirements The ideas that have been

evaluated with score 5 in

all criteria

Elicitation technique Design thinking

Kind of participants Users and experts that

have had part on the

elaboration and

validation

Figure 3 illustrates how the selected features

impact on the activities flow. Basically, inputs,

outputs and activities are renamed to directly

represent the choices that have been made.

We emphasize that using feature models to map

variabilities and commonalities presupposes the

possibility of expanding the model in the future,

since new features and constraints can come up due

to the organizational context of the project that is

being developed.

We are developing a tool to support this

approach, by assisting the REng in generating

configurations, planning the elicitation, managing

the requirements elaboration, validation, and

improvement.

A Software Process Line for Combinational Creativity-based Requirements Elicitation

365

Figure 3: An instance of our SPrL – process.

4 COMPARATIVE ANALYSIS

We validated the SPrL by showing that it is aligned

to three combinational creativity-oriented elicitation

approaches that were created before this SPrL. Table

2 summarizes this alignment and we highlight the

features that were used in each approach.

Firefox and Mylyn Cases (Bhowmik et al., 2014) -

In this work, the authors propose a framework for

requirements elicitation based on data taken from

stakeholders' social interaction. From this data, pairs

of words (verbs and nouns), which are not similar

among themselves, are extracted. These pairs are

then used on generation of new requirements. This

framework's validation was performed using an

experiment involving two software: Firefox – a web

browser; and Mylyn – an Eclipse plug-in to manage

software developers' tasks. The sources of

information were requirements description and

developers' comments, texts that were available in

Bugzilla (definition of elements source – textual and

internal sources). Social network analysis algorithms

were used to extract non-familiar connections

between words and stakeholders' comments.

The result obtained was a set of unfamiliar

(selection of elements) word pairs (verbs and

nouns). After that, a software engineer created new

requirements for the two systems. Besides having to

use word pairs, he had to follow the subject + verb +

noun template, the verb had to act on the noun, and

he or she could search the Internet for software

features (definition of criteria for requirements

elaboration). When the two-hour period was over,

the engineer came up with eight requirements for

Table 2: Alignment between SPrL features and related works.

Feature from SPrL Firefox and Mylin (Bhowmik et

al., 2014)

SIGAA (Pinto et al., 2015) Suap (Pinto, 2016)

Def. of

element

sources

Internal or external source Internal source: Requirements and

comments from a social net

Internal source: Vision document

and use case specifications

Internal source: vision document

and use case specifications

External source: comments from

GooglePlay

Media Text

Selec. of

elements

Text classification Grammatical classification, considering only verbs and nouns

Selection type: automatic or

manual

Using NLP algorithms A tool, that also uses NLP

Processing type Pairs of words with low similarity

among themselves

Less and most frequent words Most relevant words and adding

manual inclusion and exclusion

Quantity of elements Uninformed 30 nouns and 24 verbs 15 nouns and 15 verbs

Def. of

criteria

for req.

elab.

Criteria To use the pre-defined pairs; the

verb must influence the noun

To create one to 3 sentences; to use at least one verb and one noun

from each group

Template Subject + verb + noun

Elab. of req.

Location of the participants Presential Remote Presential

Participants organization and

interaction

Individual

Kind of participants Developers who are experts on the

domain

Users Developers who are experts on

the domain

Number of participants 1 11 3

Validation of req.

Validation criteria Original and new, relevant and

useful

New Useful and original

Score scale Likert scale with 5 points Valid, invalid, new and common Likert scale with 5 points

Kind of participants Developers who are experts on the

software

A SIGAA system analyst The participants of requirements

elaboration

Number of participants 29 1 3

Number of requirements each

participant validates

All of the requirements

Imp. of

req.

Which requirements This feature has not been selected All of the requirements

Elicitation technique Interview

Kind of participants The participants of requirements

elaboration and validation

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

366

Firefox and five for the Mylyn (elaboration of

requirements). Twenty-nine developers were

recruited to validate these requirements, all of them

experienced in Java and C (validation of

requirements). These participants evaluated the

originality and usefulness of each requirement by

using a 5-point Likert scale: 1=least innovative,

2=not innovative, 3=neutral, 4=innovative, 5=most

innovative.. Six of the eight Firefox requirements

and four of the five Mylyn requirements were

considered innovative. According to the authors, this

result suggests that the framework helps to generate

innovative requirements. In this case, activities

related to improving requirements were not

performed.

SIGAA Case (Pinto et al., 2015) - In this work, the

authors propose to simplify the framework above by

using a different information source (vision

document and use case specifications) and extracting

words in a different manner. This technique was

validated with an academic management system

named SIGAA. From the vision document and use

case specifications (definition of element sources -

textual and internal sources), 30 nouns and 24 verbs

were extracted considering those that showed up the

most and the least frequent in the text (selection of

elements). After that, 11 users answered a

questionnaire that asked them to create one to three

requirements using at least one verb and one noun

per requirement (definition of criteria for

requirements elaboration). This resulted in 25

requirements (elaboration of requirements). A

system analyst expert on academic systems

evaluated the requirements considering them as:

valid requirements - the sentence followed the

experiment's rules; invalid - it did not meet the rules;

new - valid requirement that had not been

implemented; and existing - valid requirement that

was already available in the SIGAA (validation of

requirements). Therefore, from 20 valid

requirements, 11 were considered new. The authors

also found that the technique is able to produce

creative requirements. The requirements

improvement was not included in this experiment.

Suap Case (Pinto, 2016) - This study aimed to use

another form of extracting words, as well as consider

sources that were not directly related to the software.

The validation was carried out through a case study

also involving an academic management system

named Suap. The element sources used were internal

(use case specifications) and external (user

comments on two education applications that were

available in the GooglePlay Store). These

applications were chosen taking into account their

scope, the number of downloads and the number of

comments made by users (definition of element

sources). A support tool called Ideasy was used to

process the element sources. In this case, 8 nouns

and 8 verbs were extracted from internal sources,

while 7 nouns and 7 verbs were extracted from

external sources. After analyzing the selected words,

the REng replaced 3 verbs and 3 nouns with words

that he or she considered important to direct the

experiment (selection of elements). Three

stakeholders, who were SUAP developers, were

present in a face-to-face meeting. After 15 minutes,

each of the participants had already created three

requirements (elaboration of requirements). The

rules for the creation were identical to the rules

defined in the previous work (Pinto et al, 2015), with

the only difference that the participants could talk

about the system's current features but should not

share information on what they were writing or what

words they were using (definition of criteria for

requirements elaboration). These same participants

evaluated the requirements created by their

colleagues, assigning a score of 1 to 5 considering

usefulness and originality criteria (validation of

requirements). After that, in an interview conducted

by the REng, they discussed each of the

requirements and their scores, when they were

allowed to detail and expand the ideas that they had

defined initially (improvement of requirements),

resulting in 5 (out of 9) requirements being

considered useful and original.

Discussion

As can be seen in Table 2, all the mandatory

characteristics raised by our SPrL are contemplated

in the related works. Therefore, these works can be

seen as instances or configurations that could have

been generated from the SPrL. There are many

variations in these three approaches, but they all use

exclusively textual element sources and process

these sources searching for words classified

according to their grammatical function (verbs and

nouns). On the other hand, the processing methods

used in the approaches are rather different. This is

perhaps the feature that most distinguishes them

from each other, despite the fact that all of the

results were considered satisfactory, generating new

requirements for the software.

Our SPrL documents the main variabilities

available when using combinational creativity in

requirements elicitation. Variabilities that were not

used in the reported experiments were also identified

A Software Process Line for Combinational Creativity-based Requirements Elicitation

367

to document and suggest possible works using other

forms of combination, according to the

organizational context. Images, videos and audios

elements are examples of these variabilities.

5 CONCLUSIONS

This article proposes a Software Process Line for

requirements elicitation based on combinational

creativity. The SPrL tasks were defined and

documented to help REng to adapt this type of

elicitation technique to the organizational context in

which the software is being developed. In addition to

the activities in the process, we also documented, by

using a feature diagram, the common and variable

features used when performing each activity.

To evaluate this SPrL, we compared the

proposed model to the characteristics of creativity

techniques used in experiments found in the

literature. This comparison validates the tasks and

features modeled in the SPrL since they are also

found in the chosen works. Furthermore, this SPrL

also specifies features (or the possibility to combine

them) that have not yet been used. New variabilities

can come up when preparing requirements

elicitation techniques that use combinational

creativity, however this adaptation could be easier

since a set of features was already identified.

Accordingly, we can mention the following

contributions of this work: (i) mapping relevant

features to be selected by REng, thus making it easy

to use this type of technique; (ii) classification and

comparison of three combinational creativity

approaches that even though seemed different, only

vary when it comes to a few specific characteristics.

Furthermore, by observing the experimental studies

performed, we noticed that the technique's success

depends on a set of combined factors that include,

for instance, the arrangement of the participants.

Future works include experimental studies to

compare the effectiveness of different variations in

combinational creativity techniques and

comparisons between these and other elicitation

techniques. Thus, it is interesting to analyze average

(or bordering) values as a suggestion for the number

of elements used, the number of stakeholders, the

number of evaluators and the number of

requirements to be created and analyzed by each

evaluator, as well as better score scales. We also

suggest an evaluation of the scalability of the use of

such techniques with a large number of participants,

as well as an analysis if we can define the profile of

those participants that were responsible for

generating the best ideas. It is also necessary to

create or adapt a tool to allow the combination of

elements such as images, music and videos, as well

as categorization forms according to the type of

element used. In addition, we plan to automate the

selection of process models via transformation

techniques to generate a custom process SPrL

through models transformation technique.

REFERENCES

Ataide, W. A., Brito, P. H., Silva, A. P., Costa, E.,

Bittencourt, I. I., and Tenorio, T. (2012). A

semantic tool to assist authors in the instantiation of

software product lines for intelligent tutoring

systems context. IEEE Technology and Engineering

Education (ITEE), 7(3):52-61.

Pinto, R., Silva, L., Lucena, M., and Santos, I. (2015).

Criatividade Combinacional para Geração de

Requisitos Inovadores: Um Relato de Experiência.

In: 18 Workshop em Engenharia de Requisitos

(WER), 2015, p. 592-605.

Pinto, R. (2016). Uma Linha de Processo de Software

para Elicitação de Requisitos baseada em

Criatividade Combinacional. Master's thesis.

Universidade Federal do Rio Grande do Norte,

2016.

Aleixo, F. A.; Kulesza, U.; Junior, E. A. O. (2013)

Modeling variabilities from software process lines

with compositional and annotative techniques: A

quantitative study. In: Springer. International

Conference on Product Focused Software Process

Improvement. 2013. p. 153-168.

Bhowmik, T., Niu, N., Mahmoud, A., and Savolainen, J.

(2014). Automated support for combinational

creativity in requirements engineering. In

Requirements Engineering Conference (RE), 2014

IEEE 22nd International, pages 243-252. IEEE.

Boden, M. A. (2004). The creative mind: Myths and

mechanisms. Psychology Press.

Falbo, R., Menezes, C., and Rocha, A. (1998). Using

ontologies to improve knowledge integration in

software engineering environments. Proceedings of

SCI, 98.

Fuggetta, A. (2000). Software process: A roadmap.

pages 25-34.

Kano, N., Seraku, N., Takahashi, F., and Tsuji, S.

(1984). Attractive quality and must-be quality.

Lemos, J., Alves, C., Duboc, L., and Rodrigues, G. N.

(2012). A systematic mapping study on creativity in

requirements engineering. In Proceedings of the

27th Annual ACM Symposium on Applied Comput-

ing, pages 1083-1088. ACM.

Maiden, N. (2013). Requirements engineering as

information search and idea discovery (keynote). In

2013 21st IEEE International Requirements

Engineering Conference (RE), pages 1-1. IEEE.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

368

Maiden, N., Gizikis, A., and Robertson, S. (2004). Pro-

voking creativity: Imagine what your requirements

could be like. Software, IEEE, 21 (5) :68-75.

Maiden, N., Jones, S., Karlsen, K., Neill, R., Zachos,

K., and Milne, A. (2010). Requirements

engineering as creative problem solving: A research

agenda for idea finding. In Requirements

Engineering Conference (RE), 2010 18th IEEE

International, pages 57-66. IEEE.

Matell, M. S., and Jacoby, J. (1971). Is there an optimal

number of alternatives for Likert scale items?

Study. Educational and psychological

measurement, 31, 657-64.

Mich, L., Anesi, C., and Berry, D. M. (2005). Applying

a pragmatics-based creativity-fostering technique to

requirements elicitation. Requirements Engineering,

10(4):262275.

Nguyen, L. and Shanks, G. (2009). A framework for

understanding creativity in requirements

engineering. Information and software technology,

51(3):655-662.

Nuseibeh, B. and Easterbrook, S. (2000). Requirements

engineering: a roadmap. In Proceedings of the

Conference on the Future of Software Engineering,

pages 35-46. ACM.

Pohl, K. and Rupp, C. (2011). Requirements engi-

neering fundamentals: a study guide for the

certified professional for requirements engineering

exam-foundation level-IREB compliant. Rocky

Nook, Inc.

Rombach, D. (2005). Integrated software process and

product lines. In Unifying the Software Process

Spectrum, pages 83-90. Springer.

Saha, S. K., Selvi, M., Buyukcan, G., and Mohymen,

M. (2012). A systematic review on creativity

techniques for requirements engineering. In

Informatics, Electronics 6 Vision (ICIEV), 2012

International Conference on, pages 34-39. IEEE.

Sternberg, R. J. (1999). Handbook of creativity.

Cambridge University Press.

Vetterli, C., Brenner, W., Uebernickel, F., and Petrie,

C. (2013). From palaces to yurts: Why requirements

engineering needs design thinking. Internet

Computing, IEEE, 17(2):91-94.

Yang-Turner, F. and Lau, L. (2011). A pragmatic

strategy for creative requirements elicitation: from

current work practice to future work practice. In

Requirements Engineering for Systems, Services

and Systems-of-Systems (RESS), 2011 Workshop on,

pages 28-31. IEEE.

Zowghi, D., and Coulin, C. (2005). Requirements

elicitation: A survey of techniques, approaches, and

tools. In Engineering and managing software

requirements (pp. 19-46). Springer Berlin

Heidelberg.

A Software Process Line for Combinational Creativity-based Requirements Elicitation

369