SLR Course Paper - Analyzing and Visualizing Data
See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/303696963
Requirements Engineering Visualization: A Systematic Literature Review
Conference Paper · September 2016
DOI: 10.1109/RE.2016.61
CITATIONS
27 READS
772
3 authors, including:
Some of the authors of this publication are also working on these related projects:
Who Should Take This Task?: Dynamic Decision Support for Crowd Workers View project
Task Interruptions In Software Development Projects View project
Mohammad Noaeen
The University of Calgary
9 PUBLICATIONS 51 CITATIONS
SEE PROFILE
Guenther Ruhe
The University of Calgary
264 PUBLICATIONS 4,256 CITATIONS
SEE PROFILE
All content following this page was uploaded by Zahra Shakeri on 27 September 2016.
The user has requested enhancement of the downloaded file.
Requirements Engineering Visualization: A Systematic Literature Review
Zahra Shakeri Hossein Abad, Guenther Ruhe Department of Computer Science
University of Calgary, Calgary, Canada
Email: {zshakeri, ruhe}@ucalgary.ca
Mohammad Noaeen Department of Electrical and Computer Engineering
University of Calgary, Calgary, Canada
Email: mohammad.noaeen@ucalgary.ca
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
2332-6441/16 $31.00 © 2016 IEEE
DOI 10.1109/RE.2016.61
6
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
7
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
8
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
9
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
E
M
C
V
Ev
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
Ev
(b) [P2]
E
C
V
(c) [P3]
E
C
V
(d) [P1]
E
C
V
(e) [P4]
M
(f) [P5]
E
C
Ev
(g) [P6], [P7]
C
Ev
(h) [P8]
E
M
(i) [P9]
E
C
V
Ev
(j) [P10], [P11]
E
M
C
V
(k) [P12], [P13]
C
V
Ev
(l) [P14]
M
C
(m) [P15], [P16]
C
V
(n) [P17]
E
C
(o) [P18], [P19]
C
(p) [P20]
E
V
Ev
(q) [P21], [P22]
E
M
(r) [P23]–[P25]
E
C
(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-
10
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,
11
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
12
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]
(c) Stereotype Symbol Set [P5]
(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
13
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.
14
[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. Hö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.
15
View publication statsView publication stats