Abstract—Requirements Engineering (RE) is a decision-centric activity which is highly data-intensive. The results of this process are known to have key impact on the results of the project. As known from the experience in other fields and disciplines, visualization can potentially provide more insights into data, information and knowledge studied. While research in the area of information visualization and its application to software engi- neering has rapidly increased over the last decade, there is only a limited amount of studies addressing the usage and impact of visualization techniques for RE activities. In this paper, we report on the results of a Systematic Literature Review (SLR) related to RE visualization. Extending the established SLR process by the usage of grounded theory for the encoding of papers, we synthesize 18 usage patterns. Even though there are punctual applications, there is a clear deficit on a holistic perspective across the different RE activities. As another conclusion, we derive the clear need for more research on visualization support in particular for tackling requirements uncertainty, requirements verification, and modelling, as well as Non-Functional Require- ments (NFRs).

I. INTRODUCTION AND BACKGROUND

Requirements Engineering (RE) activities and tasks such

as identifying projects stakeholders, exploring their needs

and expectations, communicating requirements and goals, and

managing and monitoring requirements changes are the most

data-intensive and media-rich activities in every software de-

velopment project [1]. In addition, decision-making lies at the

heart of early RE activities, and most of these decisions, such

as allocating requirements to a specific release or transferring

business objectives to technical specifications, are often made

with inevitable uncertainties about the final cost, schedule, user

needs and expectations, and the systems’ functionalities [2].

The high level of uncertainty in requirements decisions, cou-

pled with the massive, heterogeneous, and dynamic volumes

of information in the RE process, makes this process the most

error-prone activity in every software development project [1].

However, it is believed that visualization techniques which

aim to facilitate information flow in RE activities and increase

awareness of project stakeholders can improve the RE process,

and consequently provide practical solutions to reduce misun-

derstandings and communication gaps related to identifying

and communicating the requirements [3].

Software Visualization (SV) is a field of Software Engi-

neering (SE) that uses computers to visualize the software de-

velopment process and its related artifacts (e.g. requirements,

design documentations, bug reports), and it can be effectively

used to support human reasoning and insight, and to foster the

productivity of software development processes [4]. According

to the results of an empirical experiment in which 111 re-

searchers in SE were asked about the importance of SV, Rainer

Koschke [5] reported that 82% of the participants believed

SV is important for the success of the software development

process. Likewise, Bassil and Keller [6] conducted a study on

a SV tool with 107 participants mostly from industry. Based

on the results of this study, better understanding of software, increasing productivity and quality of the development process, and complexity management are the main advantages for which practitioners use SV.

The importance of RE visualization in effectively commu-

nicating and managing stakeholder expectations and conflicts

has been extensively discussed by researchers [1], [4], [5], [7].

RE visualization, such as visualizing RE decisions and their

consequences and relationships, is critical to alleviate conflicts

among stakeholders and to manage requirements changes.

While gathering, categorizing, and analyzing the existing

visualization techniques can be of use to practitioners and

researchers seeking to apply these techniques in their work,

there has been no effort to systematically gather, classify, and

analyze the RE visualization literature. In order to fulfill this

research gap in the literature and to summarize research on the

application of visualization techniques in the area of RE, we

conducted a Systematic Literature Review (SLR). Moreover,

conducting this SLR is in line with the research agenda of our

previous work [8] (presented at RENext! 2015) to visualize

the uncertainty inherent in requirements debt decisions.

This review seeks to analyze, classify, and present the

common visualization techniques which have been developed

to support various dimensions of RE, such as requirements

activities, stakeholders and domains (Table I). Since various

paradigms of visualization, such as Data Visualization (DV),

Information Visualization (IV), and Knowledge Visualization

(KV) differ regarding their ability to transfer and communi-

cate data, in this review we classified studies from various

visualization perspectives: (1) Data Visualization: graphical representation of unprocessed information [9] (e.g. points,

lines or bars). (2) Information Visualization: Card et al. [10] defined IV as “The application of computer supported, visual representations of abstract data to amplify cognition”. (3)

2016 IEEE 24th International Requirements Engineering Conference

DOI 10.1109/RE.2016.61

RE 2016, Beijing, China Research Paper

TABLE I VARIOUS DIMENSIONS OF RE

RE Stakeholders [12], [13] -Users: who will actually operate and interact with the system -Developers: who design, build, and maintain the system, such as analyst, designer, programmer, tester, and so on -Decision-makers: who have executive power and control over projects decisions to build the system, such as the managers of the development and users organizations, business, and product managers. -Clients: who will pay for the system

RE Domain [14] -Problem: requirements that represent the stakeholders’ needs and expec- tations, -Solution: requirements that represent the subsequent layers (e.g. system requirements) RE Activities [12], [15] -Elicitation: Identifying the users and project sponsors needs and expectations, projects stakeholders, sources of requirements, and understanding the application domain -Modelling: Representing the RE process as well as a whole range of RE artifacts. Enterprise, data, behavioural, and domain modelling are some general categories of RE modelling. -Communication: Circulating the identified requirements among project’s stakeholders. -Validation and Verification: Evaluating the completeness and correctness of the elicited requirements and artifacts. -Evolution: Managing and monitoring requirements changes (e.g. adding, deleting, or modifying requirements)

Knowledge Visualization: Burkhard [11] defined the concept of KV as an approach that “examines the use of visual

representations to improve the transfer of knowledge between

at least two persons or group of persons”. The two significant

contributions of this review to the RE visualization body of

knowledge are:

1) This SLR reports on the process of identifying, gathering,

classifying, synthesizing, and analyzing a set of relevant

papers on RE visualization techniques based on prede-

fined inclusion and exclusion criteria, and rigorous data

extraction and analysis methods.

2) This SLR applied the grounded analysis technique to

make a body of knowledge for RE visualization. This ev-

idence can be of use to researchers and practitioners from

various perspectives, such as identifying the research gaps

in the area of RE visualization and elaborating on the

existing RE visualization techniques and their relation

with various visualization paradigms and various RE

perspectives.

The rest of this paper is structured as follows: Section II

describes the details of our review methodology, including

research questions, inclusion and exclusion criteria, our search

strategies for both manual and automated searches, and the

methodology for data extraction and analysis. In Section III,

we discuss the results and findings of the review based on

our research questions. Threats to the validity of our review

results are discussed in Section IV. In Section V, we present

related work and discuss the scope and limitations briefly.

Finally, in Section VI, we conclude the review and provide

recommendations for future research.

II. REVIEW METHOD

In this review we followed the guidelines provided by

Kitchenham and Charters [16] and Zhang et al. [17] for

conducting a SLR and identifying relevant studies in software

engineering. This section elaborates on the steps we followed

during our review process:

A. Research Questions

This review aims at addressing the following Research

Questions (RQs):

RQ1: What visualization techniques are used to support various dimensions of RE?

The RQ1 aims at investigating how and to what extent the

various dimensions of RE (i.e. activities, stakeholders, and

domains) are supported by visualization.

RQ 2: What are the different purposes of the visualiza- tion techniques applied in RE?

This question aims to identify the main functionality of the

visualization techniques used to support RE (e.g. coordination,

recall, attention).

RQ 3: What are the different visualization types used to support RE activities?

This question seeks to find out the visualization types (e.g.

sketch, diagram, image, map, object, etc.) that are most used

to visualize various aspects of RE.

RQ 4: How much evaluation is done to analyze the adap- tion of RE visualization techniques in practical contexts?

This question guides us to identify the maturity of the ex-

isting RE visualization techniques. The results of this question

help researchers identify new topics of empirical studies, and

enable practitioners to investigate the maturity of the proposed

RE visualization techniques.

B. Inclusion and Exclusion Criteria

The following criteria were used as inclusion and exclusion

criteria for the selection of the primary studies in our review:

1) Exclusion Criteria: we excluded publications that meet the following criteria: (1) publications that were not related to

RE visualization (2) tutorials, proposals, and position papers

and other non-peer reviewed publications (3) peer-reviewed

publications that do not meet the minimum requirements of

any type of visualizations: (V1) the results of the visualization should be based on the raw data. This requirement implies that

image processing and photography, in which the source of data

is an image are not treated as visualization. (V2) The outcome of the visualization should be one (or more) image(s) that

represent and communicate the data. (V3) The results of the vi- sualization should be readable and understandable by a viewer

(e.g. decision makers, requirements engineers) [18]. Visual

variables such as size, shape, orientation, colour, value, and texture are basic characteristics of visual representations that must meet these requirements, as stated by Carpendale [19].

Considering these requirements, we excluded publications that

only addressed UML and Goal modeling as a visualization

technique (27 papers in total). While these techniques are

widely being used by researchers and practitioners to model

system requirements, they consider only one of these required

visual variables (shape), and, as stated by Diehl [4], the visual efficiency of these models is low (V2 and V3 are not met).

2) Inclusion Criteria: We included publications that: (1) addressed visualization techniques to represent various dimen-

sions of RE (2) provided some details about their visualization

technique and its application in RE (e.g. journal, conference,

and workshop papers) (3) considered the visualization prereq-

uisites discussed in Section II-B1.

C. Search Strategy

To retrieve the maximum number of relevant literature

for our review, we conducted both manual and automated

searches. To this end, we followed the steps provided by Zhang

et al. [17] to identify the relevant studies in SE as follows:

1) Step 1- Manual Search: we first identified a set of publication venues and databases related to the areas of SE,

RE, and information visualization. Next, these venues were

evaluated and finalized by two experts from the areas of SE

and information visualization independently, who determined

if each of the identified venues should be included for the

manual search step. These include: RE, REV (the Require- ments Engineering Visualization workshop, with the main

focus on visualizing and representing RE activities), ICSE, IEEE VIS, VisSoft, EASE, FSE, JSS, IST. The included papers from this venue were a great input for the process of frequency

analysis (section II-C2) that was performed to identify the

search strings required for the automated search step. Next,

we manually reviewed the proceedings and journals of these

venues and judged their relevance to our research questions

based on their title, keywords, and abstract. In situations where

the inclusion decision was not possible based only on these

components, we reviewed the conclusion, headers/sub-headers,

and references of the papers. At the end of this step, we

identified 16 papers that addressed RE visualization.

To evaluate the reliability of our inclusion and exclusion

decisions we used the Cohen’s Kappa statistic [20], which calculates the degree of agreement between two raters, in our

case, the first two authors of the paper. The calculated Kappa

value was 0.87, which shows significant agreement, as stated

by Landis and Koch [21]. All of the identified papers in this

step are used to form the Quasi-Gold Standard (QGS), an

approach for evaluating the quality of the keywords string [17].

2) Step 2- Identifying Search Strings: in this step, we used text mining techniques to extract the most frequently

used words in the papers identified in the manual search step.

To this end, we used the Text Mining Package (tm) 1 of R2. As stated by Keshav [22], the title, abstract, introduction, section/subsection headings (not their content), and conclusion

of a paper represent its general idea and main contributions.

Thus, before conducting the frequency analysis, we applied the main steps of text pre-processing on these parts of the

16 papers identified in the manual search step (Section II-C1).

1http://tm.r-forge.r-project.org/ 2https://www.r-project.org/

TABLE II SEARCH TERMS

Category 1 Category 2 Category 3 Visualization � � Requirements Engineering � Functional �

Visualisation � � Requirement � Non-functional �

Model(ling) � � Goal � Software Engineering � �

Design(ing) � � NFR(s) �

Interaction � Release Planning �

Communication � Stakeholder�

Diagram � �

Collaboration �

For the purpose of pre-processing, we conducted the following

steps iteratively: (1) Manual Transformation (e.g., removing hyphens which appeared after converting the pdf files to plain

text). (2) Removing numbers and punctuations (e.g. years and in-text reference numbers). (3) Removing stop words (e.g. articles, conjunctions, and common verbs). (4) Stemming (e.g. reducing visualization, visualizing, and visualize to their root visual.

Next, we performed the frequency analysis on the resulting

text files and extracted the most frequent words of the 16

identified papers. Table II lists these words and demonstrates

how the search terms can be combined to form the search

strings using Boolean operations. Each search string can be

formed by using a Boolean “AND” operator between search

terms of different columns with the same colour, and a

Boolean “OR” operator between different search strings. For

instance, “Visualization AND Requirements Engineering” OR “Communication AND Stakeholder AND Software engineer- ing” are two valid search strings for the automated search step.

3) Step 3- Automated Search: in this step, we first queried Google Scholar (GS) using the search terms listed in Table II. However, Dean et al. [23] recently performed an experiment

to evaluate if GS is sufficient to be used for systematic

reviews, and concluded that GS does not meet the required search standards for systematic reviews, and is not able to identify all known and relevant papers in a specific area. Thus, at the next step we searched the following electronic

databases to find more relevant papers: ACM Digital Library,

ScienceDirect, SpringerLink, and IEEE Xplore. This yielded

559 articles published within the last 16 years (2000- 2016),

the studies before 2000 were only focused on UML modeling

as a technique of RE visualization.

4) Step 4- Quasi-Gold Standard Evaluation: To evaluate the reliability and quality of the search terms we identified

during the manual search step, we followed the guidelines

provided by Zhang and Babar [24] and formed the Quasi-Gold

Standard for years 2006-2010 (five years of REV workshop),

which includes 16 papers. After performing the automated

search, we retrieved 15 of these studies. Thus, the quasi- sensitivity is 94%, which represents an acceptable performance for our search process.

5) Step 5- Snowballing: To complement the search results obtained, we used snowballing by scanning the reference list

(backward snowballing [25]) of identified papers. Furthermore,

there were papers that have been published after the selected

Fig. 1. Number of studies per type of visualization they supported per year.

DV IV KV

42%

39%

19%

#o f P ap er s

Year of publication

total

papers, so we performed citation tracking (forward snow-

balling [25]) to identify relevant papers citing the papers in

the previous step. At the end of this stage, we added three

more papers to the list of the primary studies of this review,

a total of 26 papers for our analysis.

D. Data Extraction and Synthesis Method

During this step, we used the following two methods to

extract and synthesize data from each of the 26 primary studies

included in this review:

(1) Grounded Analysis: During this step, we applied a revised version of the grounded theory [26] methodology for

conducting a rigorous literature review and followed the steps

we implemented in our previous SLR [27] to extract data from

each of the 26 primary papers included in this review. We

analyzed all of the included papers line by line to extract

concepts, which involves high volumes of qualitative data. To

help with this process, we used Saturate 3, which is a web-

based open coding tool that enables traceability between codes

and data. Due to limited space, we only report the results of

the open coding and axial coding steps (Table III).

(2) Data Extraction Form: To organize the process of data extraction, we created three data collection forms, in which the

following data points should be captured by the reviewer of

each paper: (1) visualization paradigm (e.g. data, information,

or knowledge visualization) (2) various dimensions of RE

(i.e. RE activities, stakeholders, and domain) (3) various

perspectives of the visualization that have been addressed for

RE (i.e. function, audience, goal, and type). More details about

these parameters are listed in Tables IV, V, and VI.

III. RESULTS AND FINDINGS

A. Overview of Papers

This section gives an overview on the results of analyzing

the primary studies included in this SLR in terms of their

published year and visualization paradigm. As illustrated in

Figure 1, more than 50% of these studies are published in

the period 2010-2012 and there is an increasing trend on

supporting knowledge visualization in RE from 2006.

3www.saturateapp.com

1) Visualization Paradigm: Since RE is a high communi- cation and decision intensive activity, knowledge visualization

can help to improve the communication among stakeholders

and reduce the communication gaps and conflicts among

end-users and technical stakeholders of software development

projects. However, based on the results of this SLR, only 19%

[P22-26] of the studies addressed this visualization paradigm,

while 39% ([P12-21] and 42% ([P1-11]) of the studies ad-

dressed information and data visualization, respectively.

TABLE III OVERVIEW OF OPEN CODES EXTRACTED FROM THE PAPERS INCLUDED IN

THIS REVIEW. NUMBERS IN PARENTHESES SHOW THE NUMBER OF OCCURRENCES OF EACH CODE IN THE INCLUDED PAPERS

Categories Open codes

Requirements Communication (42)

Distributed Requirements Engineering (10) [P1, P9, 10], (# of papers: 3) Stakeholders Communication (14), [P1-3, P9-10, P12, P21-22, P25] (# of papers: 9) Communication Gap (18) [P2, P6-7, P9, P12-13, P17, P20, P23, P25-26] (# of papers: 11)

Requirements Evolution (47)

Requirements Change (23) [P6, P11-12, P14, P21, P24-26], (# of papers: 8) Tracing Requirements (11) [P10, P14-15, P18, P23, P26], (# of papers: 6) Requirements Relationships (13) [P6, P10-11, P18, P23, P25-26], (# of papers: 7)

NFRs (19)

Non- Functional Requirements (19) [P4-5, P13, P15, P18, P20, P22, P25] (# of papers: 8)

Requirements Inspection (27)

Requirements Uncertainty (2) [P23-24], (# of papers: 2)

Requirements Validation (8) [P6, P10, P17, P26], (# of papers: 4) Requirements Verification(3) [P12, P24], (# of papers: 2)

Requirements Planning (27)

Requirements Prioritization (15) [P4, P7, P11, P13, P17, P22-25], (# of papers: 9) Requirements Planning (12) [P1, P11, P22-24], (# of papers: 5)

With respect to Knowledge Visualization (KV), S. Feather

et al. [P1] provided two visualization types (i.e. diagram(s)

and Map) to help project stakeholders to understand the how and why of their decisions. For instance, they used a 2D scatter plot to represent the likelihood and impact of a requirement’s

risk(s). They also used Kiviat chart to represent the comparison

among several risk mitigation decisions.

2) Requirements for RE Visualization: we used grounded analysis to extract data from the primary of this review. By

using this technique, we coded all of these papers to explore

the main areas (dimensions) of RE in terms of their need

of visualization support. After similarity analysis of these

codes (open codes and axial codes), we found (Table III):

Requirements evolution and communication were among the most RE activities with visualization support, with each of

them being 30% and 26% of the extracted codes assigned

to each category, respectively. Requirements inspection and planning come next, with 19% of the codes for each category. Visualizing Non-Functional Requirements (NFRs) had less support, with only 12%. More details about the results of

applying grounded analysis are available on the website of

the first author of the paper 4.

Finding 1: Applying grounded analysis revealed that Require- ments Planning and Inspection and NFRs have the strongest deficit of visualization support.

B. RQ1- Visualization Support for Various Aspects of RE

In this section, we report on the results of our review

regarding the current status of visualization support for various

aspects of RE. Table IV lists the studies that supported various

dimensions of RE, as well as some examples of visualization

techniques proposed to support these dimensions.

Based on the results of our review, as demonstrated in Fig-

ure 2 and Table V, representing a project’s requirements and

their related artifacts (what) is addressed in all of the included papers in our SLR. Studies that addressed the process (how) of performing RE activities in their proposed visualization

techniques come next with 19 (73%) studies. Representing

the motivation of performing a specific RE task or making a

requirement decision, as well as representing the roles (who) which are involved in performing the task or making the

decision are addressed in 13 (50%) and 8 (31%) studies,

respectively. Software development teams and companies are

often geographically far from their users and customers. While

visual representation of RE tasks and decisions can alleviate

the difficulties of communication and coordination in globally

distributed RE teams, visualization support for distributed RE

is only addressed in 4 (15%) of the studies.

1) RE Activities: As listed and illustrated in Table IV, requirements elicitation is the most supported task by vi- sualization among all RE activities, with 16 (62%) of the

papers. Visualization support for other RE activities: require- ments verification, modelling, evolution, and communication are addressed in 10 (38%), 8 (31%), 8 (31%), and 5 (19%) of

the papers, respectively. Figure 2 depicts visualization support

for various combinations of RE activities.

We performed further analysis on the results of this RQ

and extracted the common RE Visualization Patterns in the form of < content, focus >, where content shows each of the RE activities, and focus denotes the What, How, Why, Where, and Who components of each visualiza- tion technique. The details of these visualization patterns are

illustrated in Figure 2. As illustrated in this figure, none

of the visualization techniques proposed by the included

studies in our review addressed all of the RE activities.

Further, two combinations of (elicitation, modelling) and (elicitation, communication, validation) are the most fre- quent patterns addressed by these studies.

Finding 2: Based on the results of the analysis we performed on the results of RQ1, we extracted the common RE visualization patterns in the form of < content, focus >, where content shows each of the RE activities, and focus denotes the What,

4http://wcm.ucalgary.ca/zshakeri/home

What?

How?

Why?

Where?

Who?

requirements, RE artifacts

representing the process of performing an RE activity

the motives and causes of RE decisions in each activity

geographically location (distributed teams)

peoject's stakeholders, sources of requirements

(a) Legend

(b) [P2]

(d) [P1]

(e) [P4]

(f) [P5]

(g) [P6], [P7]

(h) [P8]

(i) [P9]

(j) [P10], [P11]

(k) [P12], [P13]

(l) [P14]

(m) [P15], [P16]

(n) [P17]

(o) [P18], [P19]

(p) [P20]

(q) [P21], [P22]

(r) [P23]–[P25]

(s) [P26]

Fig. 2. The common RE visualization patterns (< content, focus >) [E: Elicitation, M: Modeling, C: Communication, V: Validation, Ev: Evolution]

How, Why, Where, and Who components of each visualization technique.

This finding can be used as a reference for selecting visu- alization techniques for a specific combination of RE activities and visualization goal (focus).

2) Requirements Engineering Stakeholders: The results of our review show that “developers” and “decision makers” are the most supported stakeholder group in the studies included

in our review (18 (69%) studies for each category). Among

all the studies, 15 (58%) studies targeted end-users in their

visualization approach, and customers have less visualization support, with only 8 (31%) of the studies.

3) Requirements Engineering Domain: As illustrated in Table IV, while 88% of the studies supported the problem

domain in their visualization techniques, only 50% of the

studies addressed the solution domain.

C. RQ2- Different Visualization Functions Applied in RE

To address this RQ, we used data extraction forms to explore different visualization purposes (functions) proposed

by researchers and practitioners. We used the following func-

TABLE IV RQ1- VISUALIZATION SUPPORT FOR VARIOUS DIMENSIONS OF RE

Dimensions /Related papers The Proposed Visualization Techniques Elicitation (E) [P1-2, P4-6, P8, P10, P12-13, P16-20, P23-24]

• [P19]: A Stacked Pareto chart and horizontal bar charts to visualize the requirements priority and the correlation of each stakeholders votes with the resulting priorities, respectively.

Modelling (M) [P3, P5-7, P10-11, P13, P20]

• [P15]: (1) The application of visual objects (glyphs) and graphical variables (i.e. colour, thickness) to model product- line requirements relationships and inter-dependencies. (2) Highlighting the decisions with the greatest number of inter-dependencies to visualize the strength of the dependencies on the decisions as well as the difficulty of decisions.

Communication (C) [P9, P11, P19, P22, P26]

• [P26]: A visual interactive representation of requirements to involve a large number of geographically distributed users in the process of RE. This approach improves communicating the requirements in two ways: (1) filtering requirements based on their geo-coordinate, and (2) filtering requirements based on the user-assigned keywords, which represents the similarities and dependencies between requirements.

Verification (V) [P6, P12-15, P17-18, P22-23, P26]

• [P12]: A visualization technique to represent NFR patterns including problem patterns (e.g. threats, and vulnerable and undesirable situations) and objective patterns (e.g. different interpretations of NFRs that are provided by a project’s stakeholders and represents their conflicts in defining these NFRs).

R E

A ct

iv it

ie s

Evolving (Ev) [P2, P8, P12, P14, P18, P21, P24, P26]

• [P10]: An interactive visualization technique, which enables a project’s stakeholders to directly manipulate requirements in real time during their decision making process.

End users (Eu) [P3, P6-7, P9-10, P12-13, P15, P17, P19-22, P25-26]

• [P21]: A visualization technique for end-users with different levels of familiarity with computer applications, by which users can select the features of the system from a list of predefined visual objects and make an image of the product based on their needs and preferences.

• [P4]: A 3D visualization of requirements to reduce the gap between developers and end users and to validate the requirements in the earlier stages of the development process.

Developers (D) [P1-2, P4-6, P8-9, P13-14, P17-23, P25-26]

• [P7]: Integrating visual objects, specific to scientific software development, into the requirements models to reduce the learning effort for developers who build scientific applications to successfully create their requirements model and have concrete ideas of the system before starting the development tasks.

Decision-makers (Dm) [P1, P3-7, P9, P11, P13, P15, P19-26]

• [P6]: A three dimensional, space-filling, and growing pyramid, which provides various views of the selected requirements for each group of projects stakeholders. This visualization technique mainly represents the following parameters for each of the system requirements: (R = {Sn, W, Ref}), while Sn, W , and Ref denote the stakeholders to which requirement belongs, requirements scope in terms of its attainment level, and the level of the requirements refinement, respectively.

St ak

eh ol

de rs

Customers (C) [P3, P7, P9, P12, P16, P21, P25-26]

• [P16]: A separate graphical object for the system’s customers to differentiate them from end-users and business stakeholders and to involve them in RE activities and consequently make their needs and operations more clear and understandable (Figure 3(e)).

Problem (P) [P1, P3-7, P9-13, P15-26]

• [P17]: A Visual Requirements Analytics (VRA) technique for improving risk assessment decisions by using the following graphical variables on cohesive bar and arc graphs: (1) colour for representing the level of requirements attainment, (2) height for representing the correlation of a requirement category with other requirements categories in terms of risk components, (3) width for representing the ratio of related risks to a requirements, and (4) order for prioritizing requirements based on their impact on the risk components.

D om

ai n

Solution (S) [P2, P4-6, P8-9, P13-14, P18- 19, P21, P23, P25]

• [P23]: A visualization technique to model NFRs, which impacts various requirements decisions, regardless of if they are system-level or software level.

• [P11]: A visual tool (DREAMER) to represent and model the traceability and coverage of both requirements and design options during the development process.

tions, proposed by Burkhard [11] to classify the visualization

functions proposed by included studies in our review.

• Coordination: coordinating and managing individuals during the communication process.

• Recall: improving the understandability and remem- brance ability of viewers by using conceptual diagrams.

• Maps: following cartographic standards to represent hier- archy of data (e.g. a ground layer represents the project’s

context and individual elements on this layer represent

the project’s milestones, risks, or resources).

• Motivation: inspiring viewers to take actions. • Attention: grabing viewer attention by representing

trends, outliers, and in general all the characteristics that

impact viewer decisions.

• Elaboration: providing more clarification about visual representations.

• New Insights: creating new insights by showing relation- ships between elements and by demonstrating the context

patterns and details.

Table V lists these functions, the studies that addressed

each function, and some examples of visualization techniques

proposed for each function. Among all the studies, 15 (58%)

studies addressed the attention function, which is the most

addressed function. Elaboration and Motivation come next,

with 13 (50%) studies each. Coordination and insight are

addressed in only 10 (38%), and 9 (35%) studies, respectively.

Recall has the least support with only 4 (15%) studies.

Moreover, we analyzed the proposed RE visualization tech-

niques from their audience perspectives, such as individuals,

TABLE V RQ2- DIFFERENT PURPOSES OF VISUALIZATION TECHNIQUES APPLIED IN RE

Visualiation Functions Some Samples of the Proposed Visualization Techniques Coordination [P9, P11, P19, P22, P26]

• [P10]: An interactive Visual Requirements Analytics (VRA) approach which helps stakeholders to overview the system requirements, detect inconsistencies and anomalies, and relate heterogeneous artifacts and concerns.

• [P20]: A notation-based visualization technique to represent the flow of requirements by visualizing both informal and formal communications, and to coordinate the communication among stakeholders in global RE teams.

Attention [P2, P4-7, P11, P13-15, P18, P20, P22-24, P26]

• [P23]: The application of visual variables (e.g. size, colour, texture, and value) to represent four quality attributes such as trustability, performance, feasibility, and certainty, respectively.

Recall [P3, P5, P8, P10]

• [P5]: A set of semantical transparent modelling symbols, which allow end-users without a goal modelling background to participate in RE activities.

• [P8]: Feature Survival Charts (FSC) as to represent dynamic scope changes of projects and past project scoping activities.

Motivation [P1-2, P6, P11, P14-15, P20- 24, P26]

• [P2], [P3]: highlighting the flow of project resources and requirements prioritization options to help project stakeholders to compare multiple alternative lists of requirements together, and select the next release based on the current status of resources and to alert teams about requirements changing priorities.

Elaboration [P6, P8, P10, P15, P17-23, P25-25]

• [P13]: Highlighting goals and other elements within a conflicting path, and sources of these conflict to help decision- makers to easily understand conflicts and their intention, and to identify the domain trade-offs.

• [P11]: A bifocal view of diagrams, which allows viewers to focus on a particular object (e.g. requirement, design object, or artifact) to explore its connection with other objects of the visualization.

Insights [P1, P13-15, P22-26]

• [P14]: The application of visual variables such as colour and value to propose a traceability visualization technique that analyzes and represents the candidate links between project requirements, a visual feedback to validate these links, and represents requirements with high architectural significance and high level of design risk.

group, organization, and network. Based on the results of this analysis, all the included studies in this SLR targeted

individuals in their visualization techniques (e.g. requirements

analysts, architects, developers, or end-users). Supporting RE

activities in group (or RE teams) comes next with 19 (73%)

studies [P3-7, P9, P11, P13-16, P19-26]. Visualization support

at the organization or network level are addressed by only 7

(27%) [P7, P9, P16, P19-20, P22, P25] and 4 (15%) [P1, P9,

P16, P19] studies, respectively.

Finding 3: Following the results of “grounded analysis”, re- quirements communication and change require more visualiza- tion support. However, coordination function, which support this requirement, has been addressed by only 19% of studies. Thus, there is a clear need for more visualization techniques that support this function.

D. RQ3- Different Visualization Types Used to Support RE Activities

To address this RQ, we used data extraction forms to explore visualization types proposed to support various dimen-

sions of RE (See Table I for more details about these dimen-

sions). Table VI gives an overview of these visualization types,

the list of studies addressed each type, and some visualization

techniques proposed for each type. Overall, looking at Table

VI, 81% (21) of the included studies in this SLR used diagrams

(e.g. Sankey, Kiviat and bar charts, and 2D scatter plot) to

represent the structural relationships among various activities

and artifacts of RE. Among all the studies, 11 (42%) proposed

their own graphical objects to add more visual intuitiveness to the visual representations of RE activities and artifacts. Map and interactive representation of RE activities come next, with

7 (27%) studies for each type. Image and Sketch were used in only 4 (15%) and 2 (8%) studies, respectively.

With respect to storytelling as a visualization type that represents a sequence of events, decisions, or changes, each of

which can contain various types of visualization (e.g. image,

diagram, or sketch), text or video or any combination of these

components [28]. Based on the results of our analysis, none

of the included studies (0%) in this review addressed the

application of this technique in RE.

Finding 4: Visualization of Requirements change is not well supported by literature Visualization types that can manage various complexities and challenges inherent in the process of requirements change, are not well supported by researchers and practitioners. For example, by using storytelling visualization type, various as- pects of requirements change can be represented by narrations explaining the current state and the changes as they occur over time. Moreover, filling gaps and continuity in the storytelling approach, as stated by Gershon and Page [28], increases the audience’s awareness of the transition between various states of the system as well as the sequence of requirements decisions.

E. RQ4- Evaluation of Proposed RE Visualization Techniques

To answer this research question, we used the following

hierarchy to evaluate the evidence level [29] of the proposed

visualization techniques: (E1) no evidence, evidence obtained from: (E2) demonstration, (E3) expert opinion, (E4) academic studies, (E5)industrial studies, (E6) industrial practice. Based on the results of our analysis, the main strategies for empirical

evaluation are E3 (27%) [P1, P6, P12, P15-16, P20, P22], E5 (27%) [P4-5, P7-8, P10, P17-18], E6 (19%) [P13, P23- 26], E4 (15%) [P2-3, P9, P21], E1 (8%) [P11, P19], and

TABLE VI RQ3- DIFFERENT VISUALIZATION TYPES USED TO SUPPORT RE ACTIVITIES

Visualization Types Image and Sketch [P2-3, P12, P17]

• [P4]: The application of 3D and animation visualization techniques to develop a 3D image of the final product and to validate its features with the end users. This approach reduces the total development effort by validating requirements in the earlier stages of the project.

Diagram [P1, P4-11, P13-16, P18-20, P22-26]

• [P3]: Combination of Sankey diagrams and Parallel Coordinates in a multiple tree layout to represent the information flow of requirements prioritization and release planning processes.

• [P1] The application of bar, Kiviat, 2D scatter plot, and charts and range to convey the risk status of project requirements and candidate decisions to mitigate these risks and to represent the consequence of uncertainties in the input data about requirements risks and their mitigation decisions.

Map [P2, P19, P21-23]

• [P1]: TreeMap visualization to show requirements and sub-requirements hierarchy, relative importance, and attainment status of each requirement by using size and colour parameters respectively.

• [P22]: Emotional Density Map (EDM) to demonstrate the intended emotional requirements in designing and developing video games by using grayscale shading and graphical objects.

Object [P1-3, P7-9, P11-13, P18, P26]

• [P18], [P22]: The application of graphical objects to manage communicating requirements in distributed teams (Fig 3(a, b)) and to capture and represent the primary and secondary emotional requirements.

• [P5]: Proposing a set of semantical transparent symbols for Goal-oriented modeling by conducting an exploratory study with 104 participants (without any background knowledge of goal modeling). Figure 3 (c,d).

• [P16]: Using semiotic clarity (i.e. defining one notational element for each of the concepts in requirements modeling) to differentiate business stakeholders from end-users, and to represent the concepts of goal, soft-goal, threats, and requirements risk mitigation (Figure 3 (e)).

Interactive Visualization [P6, P10, P12, P17-18, P22, P26]

• [P3]: An interactive brushing technique to help project decision makers to interactively reveal the relationship in data (e.g. tapping on each of the elicited requirements highlights all of the releases it belongs to, as well as the representing stakeholder vote about that specific requirement).

Storytelling –

User Requirementd

Analyst Flow Diagram

(a) Graphical objects [P18]

Sad Sheepish Surprised

(b) Graphical objects [P22]

(d) Prototype Symbol Set [P5]

(e) Prototype Symbol Set [P16]

Fig. 3. Application of graphical objects (Glyph) in RE visualization

E2 (4%) [P14]. Given these data and according to the above classification, most of the studies used preliminary evaluation

methods to evaluate their proposed visualization techniques.

No evidence occurred in two studies [P11, P19]. Additionally,

almost all of these studies employed exactly one type of

evaluation, which implies that there is a clear need for more

evidence to evaluate the quality of the existing RE visualiza-

tion techniques.

IV. THREATS TO VALIDITY

In this SLR, to provide a comprehensive review on the stud-

ies on RE visualization, we followed the guidelines presented

by Kitchenham [16] and Zhang et al. [17] for performing a

SLR in software engineering. However, there are threats to the

validity of the results and findings of our review.

Firstly, the completeness of the list of the primary studies

included in this SLR highly depends on the keywords and

the capability limitations of the employed digital libraries

and search engines. While we used an objective search terms

elicitation approach (i.e. text mining and frequency analysis)

to reduce the risks of subjective search terms, the search

standards and syntax vary among the employed search engines

and libraries in this review, thus we may have missed some

studies related to the research questions of our review.

Secondly, the robustness and comprehensiveness of the

framework we used to classify the studies may affect the

results and findings of this review. We used the framework

proposed by Burkhard [11] to classify the studies based on

their visualization function, goals, types, and audience. To

avoid a framework with insufficient paradigms for the purpose

of classification, we selected a framework related to knowledge

visualization, which covers the other visualization approaches

(i.e. data and information visualization). Moreover, to reduce

the classification bias, all of the classification results were

checked by the first two authors.

V. RELATED WORK

With respect to the related literature reviews on the area

of visualization support for RE, so far, to the best of our

knowledge, there is only one study provided by Amyot and

Mussbacher [30] aimed at describing and analyzing the first

ten years of the User Requirements Notation (URN). The

authors did a study inspired by the systematic literature review

approach, in which 281 research papers related to URN were

analyzed and synthesized to provide a historical overview of

the development of URN together with research implications

and application domains for this notation. However, the review

is limited to URN and does not address other aspects of RE,

such as RE activities and stakeholders. To our knowledge,

the SLR we provided in this paper is the first SLR that

aims to analyze and synthesize the existing evidence on RE

visualization, and to provide insight into the existing research

trend in this area as well as future research implications.

Regarding other types of reviews, such as survey or litera-

ture review, there are different reviews existing that addressed

RE visualization. Cooper Jr et al. [3] conducted a survey of

the research papers that were presented from 2006 to 2008

at the RE Visualization (REV) workshop to represent the

evolution of the research trends in the area of RE over a

specific time period. According to the results of this survey,

many opportunities exist to develop visualization for the early

steps of the RE phase (e.g. understanding the context and

undertaking the groundwork necessary for the RE process)

as well as verification and validation tasks, which is in

line with one of the main findings of this SLR. Gotel et

al. [1], [7] provided two reviews on the primary areas in

which visualization techniques and artifacts can be applied

to support RE activities. The results of this review highlight

the need for visualization techniques to support the multi-

dimensional nature of requirements and to support various

diagnostic activities and decision making tasks during software

development. However, these reviews have been conducted

about 7 to 9 years ago. Thus, new studies are required to

analyze and to synthesize the existing research works in this

area and to define the research trends and implications for

other researchers.

VI. CONCLUSION AND RESEARCH IMPLICATIONS

Visualization techniques are increasingly being used by

researchers and practitioners to understand and to manage RE

decisions and activities. By conducting this SLR, we gath-

ered, classified, and analyzed these techniques from various

perspectives to address the key research questions mentioned

in Section II-A. To this end, we initially identified 559 studies

by querying the employed search engines and digital libraries

(Table VII). After applying the inclusion and exclusion criteria

that were identified at the beginning of our review process

(Section II-B) we selected 26 studies as the primary studies of

our review, while the others were not related to the research

questions. The findings of this review tell us the following:

(1) More investigation and research are needed to support

knowledge visualization in the area of RE, (2) There is

no visualization support for the whole of the RE lifecycle,

(3) Among all RE activities, requirements communication

and evolution (Table IV) have less visualization support, (4)

Visualizing NFRs and requirements uncertainties need more

TABLE VII AUTOMATED SEARCH RESULTS

Library/publisher #Retrieved #QGS #Selected IEEE Xplore 311 13 16 ACM DigitalLibrary 28 0 2 SpringerLink 46 1 5 ScienceDirect 31 1 0 Others 143 0 3 Total 559 15 26

investigation, (5) There is a clear need for more effort in

addressing the following visualization types in the context of

RE: storytelling, maps, and interactive visualization, (6) There is a clear need for more visualization support for distributed

RE, (7) The results of RQ4 show that further evaluation of

the existing visualization methods is mandatory to provide

better evidence regarding the quality and maturity of proposed

visualization methods.

VII. ACKNOWLEDGEMENT

This research was supported by the Natural Sciences and

Engineering Research Council of Canada (NSERC) Discovery

Grant 486565-15 and by an Engage Grant. We appreciate the

constructive comments given by Barbara Kitchenham related

to a former version of the paper.

REFERENCES

[1] O. Gotel, F. Marchese, and S. Morris, “The potential for synergy be- tween information visualization and software engineering visualiza- tion,” in Information Visualisation, 2008. IV ’08. 12th International Conference, 2008, pp. 547–552.

[2] A. Aurum and C. Wohlin, “The fundamental nature of requirements engineering activities as a decision-making process,” Information and Software Technology, vol. 45, no. 14, pp. 945 –954, 2003.

[3] J. Cooper, S. W. Lee, R. Gandhi, and O. Gotel, “Requirements Engi- neering Visualization: A Survey on the State-of-the-Art,” in The 4t̂h International Workshop on Requirements Engineering Visualization,, 2009, pp. 46–55.

[4] S. Diehl, Software visualization: visualizing the structure, behaviour, and evolution of software. Springer Science & Business Media, 2007.

[5] R. Koschke, “Software Visualization for Reverse Engineering,” in Software Visualization, Springer, 2002, pp. 138–150.

[6] S. Bassil and R. K. Keller, “Software Visualization Tools: Survey and Analysis,” in Program Comprehension, 2001. IWPC 2001. Proceed- ings. 9th International Workshop on, 2001, pp. 7–17. DOI: 10.1109/ WPC.2001.921708.

[7] O. Gotel, F. Marchese, and S. Morris, “On Requirements Visual- ization,” in Requirements Engineering Visualization, 2007. Second International Workshop on, 2007, pp. 11–11.

[8] Z. S. H. Abad and G. Ruhe, “Using Real Options to Manage Techni- cal Debt in Requirements Engineering,” in Requirements Engineering Conference (RE), 2015 IEEE 23rd International, 2015, pp. 230–235.

[9] J. Hey, “The Data, Information, Knowledge, Wisdom Chain: the Metaphorical Link,” Intergovernmental Oceanographic Commission, 2004.

[10] S. K. Card, J. D. Mackinlay, and B. Shneiderman, Readings in Information Visualization: Using Vision to Think. Morgan Kaufmann, 1999.

[11] R. Burkhard, “Towards a Framework and a Model for Knowledge Visualization: Synergies Between Information and Knowledge Visu- alization,” in Knowledge and Information Visualization, ser. Lecture Notes in Computer Science, S.-O. Tergan and T. Keller, Eds., vol. 3426, Springer Berlin Heidelberg, 2005, pp. 238–255.

[12] B. Nuseibeh and S. Easterbrook, “Requirements Engineering: A Roadmap,” in Proceedings of the Conference on the Future of Software Engineering, ser. ICSE ’00, ACM, 2000, pp. 35–46.

[13] H. Sharp, A. Finkelstein, and G. Galal, “Stakeholder Identification in the Requirements Engineering Process,” in Database and Expert Sys- tems Applications, 1999. Proceedings. Tenth International Workshop on, 1999, pp. 387–391.

[14] E. Hull, K. Jackson, and J. Dick, Requirements Engineering. Springer Science & Business Media, 2010.

[15] D. Zowghi and C. Coulin, “Requirements elicitation: a survey of techniques, approaches, and tools,” in Engineering and managing software requirements, Springer, 2005, pp. 19–46.

[16] B. Kitchenham and S. Charters, “Guidelines for Performing Sys- tematic Literature Reviews in Software Engineering,” in Technical Report, Ver. 2.3 EBSE Technical Report. EBSE, 2007.

[17] H. Zhang, M. A. Babar, and P. Tell, “Identifying relevant studies in software engineering,” Information and Software Technology, vol. 53, no. 6, pp. 625 –637, 2011.

[18] R. Kosara, “Visualization Criticism - The Missing Link Between Information Visualization and Art,” in Information Visualization, 2007. IV ’07. 11th International Conference, 2007, pp. 631–636.

[19] M. Carpendale, “Considering Visual Variables as a Basis for Infor- mation Visualization,” 2003.

[20] J. Cohen, “Weighted Kappa: Nominal Scale Agreement Provision for Scaled Disagreement or Partial Credit,” Psychological Bulletin, vol. 70, no. 4, p. 213, 1968.

[21] J. R. Landis and G. G. Koch, “The Measurement of Observer Agreement for Categorical Data,” Biometrics, pp. 159–174, 1977.

[22] S. Keshav, “How to Read a Paper,” SIGCOMM Comput. Commun. Rev., vol. 37, no. 3, Jul. 2007.

[23] D. Giustini and M. N. K. Boulos, “Google Scholar is not Enough to be Used Alone for Systematic Reviews,” Online journal of public health informatics, vol. 5, no. 2, p. 214, 2013.

[24] H. Zhang and M. Ali Babar, “On Searching Relevant Studies in Software Engineering,” in Proceedings of the 14th International Conference on Evaluation and Assessment in Software Engineering, ser. EASE’10, UK, 2010, pp. 111–120.

[25] T. Greenhalgh, R. Peacock, et al., “Effectiveness and efficiency of search methods in systematic reviews of complex evidence: audit of primary sources,” Bmj, vol. 331, no. 7524, pp. 1064–1065, 2005.

[26] J. F. Wolfswinkel, E. Furtmueller, and C. P. Wilderom, “Using grounded theory as a method for rigorously reviewing literature,” European Journal of Information Systems, vol. 22, no. 1, pp. 45–55, 2013.

[27] Z. Shakeri Hossein Abad, C. Anslow, and F. Maurer, “Multi Surface Interactions with Geospatial Data: A Systematic Review,” in Pro- ceedings of the Ninth ACM International Conference on Interactive Tabletops and Surfaces, ser. ITS ’14, ACM, 2014, pp. 69–78.

[28] R. Kosara and J. Mackinlay, “Storytelling: The Next Step for Visu- alization,” Computer, vol. 46, no. 5, pp. 44–50, 2013.

[29] V. Alves, N. Niu, C. Alves, and G. Valena, “Requirements Engineer- ing for Software Product Lines: A Systematic Literature Review,” Information and Software Technology, vol. 52, no. 8, pp. 806 –820, 2010.

[30] D. Amyot and G. Mussbacher, “User Requirements Notation: The First Ten Years, The Next Ten Years,” Journal of software, vol. 6, no. 5, pp. 747–768, 2011.

PAPERS INCLUDED IN THIS REVIEW

[P1] M. Feather, S. Cornford, J. Kiper, and T. Menzies, “Experiences using Visualization Techniques to Present Requirements, Risks to Them, and Options for Risk Mitigation,” in Requirements Engineering Vi- sualization, 2006. First International Workshop on, 2006, pp. 10–10.

[P2] T. A. Sedbrook, “Visualizing Changing Requirements with Self- organizing Maps,” The Journal of Computer Information Systems, vol. 45, no. 2, pp. 63–72, 2004.

[P3] B. A. Aseniero, T. Wun, D. Ledo, G. Ruhe, A. Tang, and S. Carpendale, “STRATOS: Using Visualization to Support Decisions in Strategic Software Release Planning,” in Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems, ser. CHI ’15, ACM, 2015, pp. 1479–1488.

[P4] A. R. Teyseyre, “3D Requirements Visualization,” Journal of Com- puter Science and Technology, vol. 3, 2003.

[P5] P. Caire, N. Genon, P. Heymans, and D. Moody, “Visual Notation Design 2.0: Towards User Comprehensible Requirements Engineering Notations,” in Requirements Engineering Conference (RE), 2013 21st IEEE International, 2013, pp. 115–124.

[P6] D. Savio, P. Anitha, A. Patil, and O. Creighton, “Visualizing Re- quirements in Distributed System Development,” in Requirements Engineering for Systems, Services and Systems-of-Systems (RES4), 2012 IEEE Second Workshop on, 2012, pp. 14–19.

[P7] Y. Li, M. Harutunian, N. Narayan, B. Bruegge, and G. Buse, “Re- quirements Engineering for Scientific Computing: A Model-Based Approach,” in E-Science Workshops (eScienceW), 2011 IEEE Seventh International Conference on, 2011, pp. 128–134.

[P8] K. Wnuk, B. Regnell, and L. Karlsson, “What Happened to Our Features? Visualization and Understanding of Scope Change Dynam- ics in a Large-Scale Industrial Setting,” in Requirements Engineering Conference. RE ’09. 17th IEEE International, 2009, pp. 89–98.

[P9] T. Ugai, “Visualizing Stakeholder Concerns with Anchored Map,” in Human Interface and the Management of Information. Interacting with Information, Springer, 2011, pp. 268–277.

[P10] S. Reddivari, S. Rad, T. Bhowmik, N. Cain, and N. Niu, “Visual Re- quirements Analytics: A Framework and Case Study,” Requirements Engineering, vol. 19, no. 3, pp. 257–279, 2014.

[P11] C. Martinie, P. Palanque, M. Winckler, and S. Conversy, “DREAMER: A Design Rationale Environment for Argumentation, Modeling and Engineering Requirements,” in Proceedings of the 28th ACM International Conference on Design of Communication, ser. SIGDOC ’10, ACM, 2010, pp. 73–80.

[P12] S. Supakkul and L. Chung, “Visualizing Non-Functional Require- ments Patterns,” in Requirements Engineering Visualization, 2010 Fifth International Workshop on, 2010, pp. 25–34.

[P13] J. Horkoff and E. Yu, “Interactive Goal Model Analysis for Early Requirements Engineering,” RE, pp. 1–33, 2014.

[P14] C. Duan and J. Cleland-Huang, “Visualization and Analysis in Auto- mated Trace Retrieval,” in Requirements Engineering Visualization, 2006. First International Workshop on, 2006, pp. 5–5.

[P15] D. Sellier and M. Mannion, “Visualising Product Line Requirement Selection Decision Inter-dependencies,” in The Second International Workshop on Requirements Engineering Visualization,, 2007, pp. 7–7.

[P16] B. Berenbach, F. Schneider, and H. Naughton, “The Use of A Requirements Modelling Language for Industrial Applications,” in Requirements Engineering Conference (RE), 2012 20th IEEE Inter- national, 2012, pp. 285–290.

[P17] R. Gandhi and S.-W. Lee, “Visual Analytics for Requirements-driven Risk Assessment,” in Requirements Engineering Visualization, 2007. Second International Workshop on, 2007, pp. 6–6.

[P18] P. Laurent, P. MŁder, J. Cleland-Huang, and A. Steele, “A taxonomy and visual notation for modelling globally distributed requirements engineering projects,” in Global Software Engineering (ICGSE), 2010 5th IEEE International Conference on, 2010, pp. 35–44.

[P19] B. Regnell, M. Höst, J. N. och Dag, P. Beremark, and T. Hjelm, “An Industrial Case Study on Distributed Prioritization in Market-driven Requirements Engineering for Packaged Software,” Requirements Engineering, vol. 6, no. 1, pp. 51–62, 2001.

[P20] K. Stapel and K. Schneider, “Managing Knowledge on Communi- cation and Information Flow in Global Software Projects,” Expert Systems, 2012.

[P21] F. Perez and P. Valderas, “Allowing end-users to actively participate within the elicitation of pervasive system requirements through im- mediate visualization,” in The Fourth International Workshop onRe- quirements Engineering Visualization, 2009, pp. 31–40.

[P22] D. Callele, E. Neufeld, and K. Schneider, “Visualizing emotional re- quirements,” in Requirements Engineering Visualization, 2009 Fourth International Workshop on, 2009, pp. 1–10.

[P23] N. Ernst, Y. Yu, and J. Mylopoulos, “Visualizing Non-functional Requirements,” in Requirements Engineering Visualization, 2006. First International Workshop on, 2006, pp. 2–2.

[P24] W. Farid and F. Mitropoulos, “NORMATIC: A Visual Tool for Modelling Non-Functional Requirements in Agile Rrocesses,” in Southeastcon, 2012 Proceedings of IEEE, 2012, pp. 1–8.

[P25] T. Merten, D. Juppner, and A. Delater, “Improved Representation of Traceability Links in Requirements Engineering Knowledge Using Sunburst and Netmap Visualizations,” in Managing Requirements Knowledge (MARK), 2011 Fourth International Workshop on, 2011, pp. 17–21.

[P26] S. Lohmann, J. Ziegler, and P. Heim, “Involving End Users in Distributed Requirements Engineering,” in Engineering Interactive Systems, Springer, 2008, pp. 221–228.

View publication statsView publication stats

https://www.researchgate.net/publication/303696963