2017 IEEE International Conference on Big Data (BIGDATA)
Towards a Big Data Requirements Engineering Artefact Model
in the Context of Big Data Software Development Projects
Poster Extended Abstract
Darlan Arruda and Nazim H. Madhavji
Department of Computer Science
University of Western Ontario
London, Canada
darruda3@uwo.ca, madhavji@gmail.com
Abstract — In this paper, we describe our ongoing research
aimed at defining a Requirements Engineering Artefact Model
(REAM) in the context of Big Data software applications. This
model aims to provide a “big picture” of the Requirements
Engineering work products created and used in Big Data
software development projects. REAM are important tools
that can be used as references for the definition of domain-
specific RE models, system life-cycle processes and artefact-
centered processes, currently bereft in the Big Data Software
Engineering research.
Keywords - Big Data; Requirements Engineering; Artefact
Model; Big Data Requirements Engineering Artfect Model.
I. INTRODUCTION
Based on literature analysis, it is clear that the field of Big
Data is growing in industry. However, as yet there is no
recognisable body of knowledge concerning the development
of Big Data software applications. This void is also reflected
in the field of Requirements Engineering (RE). For example,
a search for the state of the art literature in RE involving Big
Data applications initially yielded 311 papers which, upon
closer scrutiny, were filtered down to only 13 papers that
actually addressed some aspect of RE involving Big Data
software applications.
In an attempt to add to the RE body of knowledge on end-
user applications on Big Data, we mined the filtered
literature for RE activities, work products, constraints,
methods, and related elements and relationships involved in
the development of end-user Big Data software applications
in order to create an artefact-model. An artefact-model, with
domain elements and inter-relationships, is a means for
understanding the domain and the context for creating a
software application [1], [2]. The model details are also
promoted as an aid in product maintenance and in
establishing project-specific RE processes [1].
II. RE ARTEFACT MODEL CREATION
We adhered to the following key steps in the definition of the
978-1-5386-2715-0/17/$31.00 ©2017 IEEE 4725
artefact-model [1]: (i) identification of elements and
concepts. A Systematic Literature Review (SLR) was
conducted on the topic related to RE artefact models from
which artefacts were identified and a glossary of terms was
created (see Table I); (ii) definition of the artefact
relationships. Using the glossary of terms, we created t a
table of artefacts and their inter-relationships (see Table II);
(iii) definition of cardinalities. Using the basic table of
artefacts and inter-relationships and interpreting the domain
knowledge from the scientific literature, a relationship
cardinality document was created; (iv) synthesizing the
model using fragments of artefacts, their inter-relationships,
and cardinality information, they were inter-connected
iteratively as made sense in the RE domain, eventually
resulting in the artefact model shown in Figure 1.
The proposed model is composed of three basic elements:
(a) Artefact: a rectangular shape; (b) Association: a labelled
line connecting two artefacts; and (c) Cardinality: indicating
quantity. If the cardinality is not expressed in the association
line, it means that it is unity cardinality.
The following relationships are represented in the model:
(i) Is-derived-from represents the relationship between the
artefacts when from one artefact (e.g., Big Data scenarios)
one or more artefacts can be derived and specified (e.g.,
quality requirements are derived from Big Data scenarios);
(ii) Is-identified-from represents the relationships when from
one artefact (e.g., organisational goals) one or more artefacts
(e.g., Big Data Scenarios, Constraints and Concerns, etc.) are
identified; (iii) Is-part-of relationship represents aggregation
and it is illustrated when one or more artefacts are part of one
or more major artefacts (e.g., functional requirement is part
of software requirements); (iv) Contains relationship is used
when one or more artefacts have or hold information from
another artefact within (e.g., software requirements contains
analysed requirements); and (v) Used in relationship means
that one artefact can be used to guide in the definition of
other artefacts (e.g., project constraints are used in Big Data
scenarios).
 Legend: ADK - Application Domain-knowledge | Cons - Constraints |
Figure 1. Big Data Requirements Engineering Artefact Model (BD-REAM) Depicting its Elements, Relationships, and Cardinalities.
III. SUMMARY AND FUTURE WORK
Software engineering of Big Data end-user applications is
relatively new. Currently, to our knowledge, there is no
domain or artefact model for Requirements Engineering
(RE). This paper thus aims to fill that gap though the artefact
model depicted in Figure 1 is still preliminary and pre-
empirical-validation. The model has been created through
systematic literature review (SLR).
One observation from the SLR results is that there isn’t
much research addressing the RE aspects of Big Data. While
this necessarily limits the richness of the artefact model we
have created, the resultant model does provide a preliminary
baseline to the research community for further research in
this field and to the practicing community an understanding
of the key artefacts and relationships in the model which can
be used in the design of RE projects.
Further work is envisaged: (i) validation and improvement
of the model through empirical studies; and (ii) the definition
4726
Association line | Aggregation Line | Artefact
of RE life-cycle processes in the context of Big Data
software application projects.
ACKNOWLEDGMENT
This research is in part supported by grants from CNPq, The
National Council of Technological and Scientific
Development – Brazil and NSERC, Natural Science and
Engineering Research Council of Canada. We thank the
reviewers for providing helpful feedback that has improved
this paper.
REFERENCES
[1] Berenbach,B.D. J. Paulish, J. Kazmeier, and A. Rudorferx. Software
& Systems Requirements Engineering: In Practice. New York,
McGraw-Hill, 2009, pp.19-38.
[2] B. Penzenstadler, D. M. Fernandez, and J. Eckhardt, “Understanding
the impact of artefact-based RE - Design of a replication study,” Int.
Symp. Empir. Softw. Eng. Meas., October, pp. 267–270, 2013.