=Paper=
{{Paper
|id=Vol-2490/paper11
|storemode=property
|title=Challenges in Modeling Non-Functional Requirements Collaboratively
|pdfUrl=https://ceur-ws.org/Vol-2490/paper11.pdf
|volume=Vol-2490
|authors=Roxana Portugal,Julio Cesar Sampaio Do Prado Leite
|dblpUrl=https://dblp.org/rec/conf/istar/PortugalL19
}}
==Challenges in Modeling Non-Functional Requirements Collaboratively==
https://ceur-ws.org/Vol-2490/paper11.pdf
Challenges in Modeling Non-Functional Requirements
Collaboratively
Roxana L.Q. Portugal, Julio Cesar Sampaio do Prado Leite
PUC-Rio, Rio de Janeiro, Brasil
{rportugal,julio}@inf.puc-rio.br
Abstract. Modeling Non-Functional Requirements (NFRs) is a challenge,
mainly from the subjective character of their elicitation. Modeling NFRs as a
collaborative process may create a consensus among stakeholders, combining
modeling and elicitation in a learning cycle. However, the collaboration presents
challenges, such as the different viewpoints, the influence of creativity, the mod-
eling tool, the domain/scope of the target software system, and the fundamental
aspects of configuration management. This paper reports our observations on col-
laboratively modeling an intentional model for the handling of fruits and vegeta-
bles in a futuristic kitchen.
Keywords: Non-Functional Requirements, Qualitative Requirements, Inten-
tional Modeling, Collaboration, Configuration Management, Smart Homes.
1 Introduction
i* stresses the "why" rather than only the "what" in software production [1], focusing
on organizational actors' dependencies to address system goals. Since groups may per-
form software modeling, a collaboration between stakeholders contributes to achieving
a shared understanding of the desired software through negotiation, the convergence of
ideas, and the identification of problems [2]. However, despite the increase of collabo-
ration in agile practices for RE [3], few initiatives support collaborative modeling [4].
To the best of our knowledge, collaboration in modeling NFRs lacks more research.
Collaboration has been primarily used in software coding, mainly due to configuration
management (CM) support, which is central in software evolution [2][4][5][6]. Leite
[7] stresses the characteristics that make the prevalence of coding over the modeling,
as platforms such as GitHub promotes collaboration, traceability, and transparency [5].
Notwithstanding, collaborative modeling initiatives (browser and cloud-based solu-
tions) are starting to come out, using CM strategies similar to coding environments [4].
This paper reports on observations gathered during an experience of modeling the
handling of fruits and vegetables in a futuristic kitchen1. This work relies on require-
ments information elicited by a vignette based interviews, and a questionnaire. This
information was elicited from prospective stakeholders of a 2045 kitchen [9]. Using a
1 The vignette technique [8] (Fig. 1) uses small impressionist narratives to enhance understanding.
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons
License Attribution 4.0 International (CC BY 4.0).
Imagine a kitchen in 2045 where the fruit and vegetable delivery
model-driven elicitation [10],
service is done through a Drone that uses the kitchen window to which fills in the model in question
leave orders. For food to be ready for consumption, they must go
through a food belt to follow a cleaning, organization, and cooling (i* model), we modeled as softgoals
process. (Fig. 2), the qualities found in the
questionnaire answers. Later, we
evolved the model by adding
awareness quality by reusing the
Awareness catalog [11].
2 Background
Several authors report concerns
when dealing with NFRs. Yu [1]
states that NFRs are updated late in
the development process, or are de-
Figure 1. Futuristic Kitchen – Vignette
veloped in parallel, separately, from
the functional design. Chung &
Leite [12] stress that real-world problems are heavily dependent on quality issues e.g.
“productivity, cost, security, esthetics ...” Ameller et al. [13] argue that NFRs elicitation
is an iterative process, corroborating with the view that it has to be addressed through-
out the system construction. Modeling with a focus on "why" creates uncertainty in
modelers as NFRs are subjective and may conflict among themselves [14]. Thus, as
modeling does not happen in a vacuum, it is influenced by the modeler's background
[15]. As a result, different groups of modelers may produce different models, with dif-
ferent quality. Prescriptive methods [16] are a possible strategy to improve quality, but
as pointed out by [17], this is a function of several socio-cognitive issues affecting
modelers.
We modeled a futuristic kitchen within a group with different level of expertise in
i* [1]. In [18] we provide the history of our modeling process. Besides the elicited
qualities (Table 1), we had a particular interest in the awareness quality [11], given the
level of automation in a 2045 kitchen. Believing in Linus law ("given enough eyeballs,
all bugs are shallow"), the group collaboratively built the model. We describe the chal-
lenges observed during this process.
3 Modeling Software Awareness for Susana
Susana is the name given to a humanoid that will be able to act as a Requirement En-
gineer by 2045 [9]. We follow Lutz vision [19], in which near to 2045, we would have
requirements elicitation tasks performed by humanoids specialized in certain types of
software. As such, Susana was conceived to understand kitchens of the future. Our i*
model describes the knowledge needed by this humanoid.
3.1 Eliciting Future Needs
Previously, a four-member research group worked towards the understanding of what
a humanoid elicitor would need to meet inhabitant’s needs [9]. Would it use the same
techniques that RE engineers apply nowadays? What knowledge would it need to attend
the future demands? As such, the group used a vignette to conduct interviews with 11
stakeholders that identified 10 future needs that we modeled as objectives in Fig. 2.
Later, we used a questionnaire with 109 people to evaluate and suggest other needs [9].
They suggested another 32 needs.
Figure 2. Ten future goals for the 2045 kitchen
Fig. 3 shows the modeling of the elicited goals [9] with relation to one goal of the
actor (Kitchen, 2045) in Fig. 2: menus based on preference, inventory, or food re-
strictions (health) be suggested.
Figure 3. i* model for the Kitchen 2045 goal - menus based on preference, inventory, or food
restrictions be suggested 2.
2 Prana: (in Hindu philosophy) the force that keeps all life in existence. Source: Oxford Dictionary
3.2 Non-functional Requirements for Susana
Three researchers (including the two co-authors) performed the collaborative modeling
aiming to understand how a Softgoal Interdependency Graph (SIG) for software aware-
ness [11] would be part of Susana's reasoning. We modeled collaboratively and syn-
chronously (in a research meeting), using GitHub as support for Configuration Man-
agement.
With the previous elicited information [9], we conducted a series of meetings. The
meetings used an i* model-driven elicitation [10], anchored on the information of needs
[9], and the awareness catalog [11]. After a post mortem review, we found that the
model produced [18] (Fig. 4) was highly influenced by three correlated NFRs, explic-
itly stated in Fig. 2: sustainability, automation, and self-cleaning. Others NFRs were
implicit since they were inferred from the elicited information (Fig. 2). Table 1 traces
the inferences used to name the implicit NFRs.
Table 1. Future NFRs of the kitchen in 2045
Explicit NFR self-cleaning, sustainability, automation
Implicit NFR efficiency (facilitate recycling, consumption in validity dates, shopping list updated),
learnability (taught), timely (automated), usability (adjustable)
Concerning the effort, about 90 person-hours were spent in modeling without aware-
ness, and about 54 person-hours were used to add awareness [1111] (See the gray ele-
ments in Fig. 4).
Figure 4. Part of the model for handling fruits & vegetables (F&V)[18]
Briefly, the meetings’ dynamic was: 1) Project the latest version of the model using
the tool [20]. 2) Free use of creativity. 3) Modeling in the whiteboard while discussing
the proper i* notation. 4) What we agreed in was persisted by the tool [21]. 5) Making
notes of tool limitations related to usability, as well as limitations of the i* language.
This dynamic intertwined modeling with elicitation based on the needs and the Aware-
ness SIG.
On three occasions and outside the meetings, two members of the group performed
the verification of the model produced in meetings. Also, before some of the meetings,
one of the researchers performed asynchronous work on the tool [21].
4 Challenges in collaborative modeling of NFRs
During the modeling, we observed the following challenges: the support of a modeling
tool, the different viewpoints, creativity, the problem scope, and, through all of them,
the basics aspects of CM.
An intentional modeling tool for web browsers suited our needs for ease of access
and the portability of a web browser, together with the freedom provided by a cloud
server to persist the models. Also, the availability of the source code of a tool [20]
allowed us to adapt it to our needs. We also needed to differentiate the characteristics
related to software awareness by using other colors of elements, and arrows as proposed
in [11]. The result is an adapted tool [21].
We use GitHub CM to track versions of models made by similar initiatives such as
GenMyModel [4]. However, we see as a challenge for the tool, a feature that would
allow the model to evolve using visual comparison with previous versions. This limi-
tation affected our model when we began to add aspects of awareness [11] that triggered
more significant changes in the model, thus limiting the easy revision of the reasoning
used in previous versions.
Leite [15] believes that requirements must be obtained using different viewpoints.
We used the diversity of opinions, which allowed identifying the identification of miss-
ing information and conflicts in the requirements. In our experience in the meetings,
we learned to understand each modeler point of view, so that the model evolved more
where we had more consensuses and shared understanding; for instance; in the objec-
tives related to the organization of food and packaging (Fig. 4).
However, a challenge encountered in reaching consensus among modelers is the
strong influence of explicit NFRs (Table 1) that cross multiple goals, as seen with the
sustainability NFR. The implicit NFRs, such as learnability and usability if used, could
have taken our model to another result. Another challenge is the time it takes to reach
consensus when the requirements for addressing NFRs are being invented [22] in a
model-driven elicitation. In time constraints projects, a challenge would be to deal with
situations where all points of view win. It is important to stress that different viewpoints
strategy is a validation process in itself [15], which corroborates the Linus law. How-
ever, it is a challenge to identify errors in an asynchronous collaborative environment.
Creativity in collaboration is a quality that can be affected due to some concerns.
As we follow an i* model-driven elicitation, we found that in the first meetings, the
expertise of one of the members had a negative influence on the equilibrium of interests
of modelers [23]. The necessary training in the technologies used [24] also restricts
creativity. In this sense, the tool [20] often reduced our reasoning for lack of undo func-
tion. Another technology, such as GitHub CM, which will be central to the evolution
of modeling editors [4], poses a challenge as it allows for individual collaboration in an
asynchronously way. A positive influence towards creativity was the fact that all mod-
elers had similar knowledge of the problem [24], as the group also participated in the
elicitation of needs performed previously [9].
Finally, the scope of the problem is a challenge when dealing with NFRs. We have
identified the lack of modularization techniques to help model-driven elicitation. With
more NFRs in the model, whether due to the reorganization of already modeled struc-
tures or the addition of new ones, dependency links grew. With more links, visualiza-
tion became a problem, which led to problems in model understanding.
5 Conclusion
This work presents some of the challenges in NFRs collaboratively modeling, but other
studies may be done on the model evolution as registered in the GitHub CM [18]. Future
work should address challenges to improve the tool [20]. On the other hand, we are
continuing the modeling of Susana as a means to better understand how awareness
driven software may profit from intentional modeling.
References
1. Yu E.S. Towards modelling and reasoning support for early-phase requirements engineer-
ing. In Requirements Engineering Proceedings of the Third IEEE International Symposium.
pp. 226-235. (1997).
2. Whitehead J. Collaboration in software engineering: A roadmap. In Future of Software En-
gineering. IEEE Computer Society. pp. 214-225. (2007).
3. Paetsch F, Eberlein A, Maurer F. Requirements engineering and agile software develop-
ment. In Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure
for Collaborative Enterprises. (WET ICE). pp. 308-313. (2003).
4. Gray, J. and Rumpe, B. The evolution of model editors: browser-and cloud-based solutions.
Software & Systems Modeling. Vol. 15(2), pp. 303-305. (2016).
5. Dabbish, L., Stuart, C., Tsay, J. and Herbsleb, J. February. Social coding in GitHub: trans-
parency and collaboration in an open software repository. In Proceedings of the ACM Con-
ference on Computer Supported Cooperative Work. pp. 1277-1286. (2012).
6. Lanubile, F., Ebert, C., Prikladnicki, R. and Vizcaíno, A. Collaboration tools for global soft-
ware engineering. IEEE software. Vol. 27(2), pp.52-55. (2010).
7. Leite, J.C.S.P. The prevalence of code over models: turning it around with transparency.
Keynote in IEEE 8th International Model-Driven Requirements Engineering Workshop
(MoDRE). pp. 56-57. (2018).
8. Hibshi, H., Breaux, T.D. and Broomell, S.B. Assessment of risk perception in security re-
quirements composition. In 2015 IEEE 23rd International Requirements Engineering
Conference (RE). pp. 146-155. (2015).
9. Cavalcanti, R., Portugal, R.L.Q., Teixeira, B., and Leite, J.C.S.P. Em Busca dos Requisitos
para Susana: Requisitos para uma Humanóide Construtora De Requisistos. Technical-Re-
port, PUC-Rio. Available: http://bib-di.inf.puc-rio.br/techreports/2018.htm (2018).
10. Leite, J.C.S.P. Elicitation Awareness in Conceptual Modeling: The Role of Transparency.
Keynote Talk at Istar´15 - 8th International i* Workshop, Ottawa. Available: http://www-
di.inf.puc-rio.br/~julio/transp-istar-15-ottawa.pdf. (2015).
11. Cunha, H. and Leite, J.C.S.P. Reusing non-functional patterns in i∗ modeling. In IEEE 4th
International Workshop on Requirements Patterns (RePa). pp. 25-32. (2014).
12. Chung, L. and Leite, J.C.S.P. On non-functional requirements in software engineering. In
Conceptual modeling: Foundations and applications. pp. 363-379. Springer, Berlin, Heidel-
berg. (2009).
13. Ameller, D., Ayala, C., Cabot, J. and Franch, X. Non-functional requirements in architec-
tural decision making. IEEE software, Vol. 30(2), pp.61-67. (2013).
14. Mylopoulos, J., Chung, L. and Yu, E. From object-oriented to goal-oriented requirements
analysis. Communications of the ACM, 42(1), pp.31-37. (1999).
15. Leite, J.C.S.P. Viewpoint resolution in requirements elicitation. (Doctoral Thesis, Univer-
sity of California, Irvine). Available: http://www-di.inf.puc-rio.br/~julio//bd.htm (1988).
16. Franch, X. Fostering the adoption of i* by practitioners: some challenges and research di-
rections. In Intentional Perspectives on Information Systems Engineering. pp. 177-193.
Springer, Berlin, Heidelberg. (2010).
17. Doorn, J. H., Hadad, G. D., Elizalde, M. C., García, A. R., and Carnero, L. O. Críticas
Cognitivas a Heurísticas Orientadas a Modelos. In 22nd Workshop on Requirements
Engineering, (WER19). (2019).
18. Portugal, R.L.Q., Cavalcanti, R., and Leite, J.C.S.P. Modelo intencional para a gestão de
frutas e vegetais em uma cozinha futurista. (Version iStar19). Zenodo.
http://doi.org/10.5281/zenodo.3387709. Available at GitHub: https://git.io/JeOGK. (2019).
19. Robyn R. Lutz. RE at 50, with a Focus on the Last 25 Years. In Proceedings of 25th IEEE
International Requirements Engineering Conference (RE). pp. 482-483. (2017).
20. Pimentel, J. and Castro, J. piStar Tool–A Pluggable Online Tool for Goal Modeling. In Pro-
ceedings of 26th IEEE International Requirements Engineering Conference (RE) (pp. 498-
499). (2018).
21. Portugal, R.L.Q. piStar tool adapted during a model-driven elicitation (Version iStar19).
Zenodo. http://doi.org/10.5281/zenodo.3418479. (2019).
22. Potts, C. Invented requirements and imagined customers: requirements engineering for off-
the-shelf software. In Proceedings of IEEE International Symposium on Requirements En-
gineering (RE'95) (pp. 128-130). (1995).
23. Carmeli, A. and Schaubroeck, J. The influence of leaders' and other referents' nor-mative
expectations on individual involvement in creative work. The Leadership Quarterly, 18(1),
pp.35-48. (2007).
24. Amabile, T.M., Conti, R., Coon, H., Lazenby, J. and Herron, M. Assessing the work envi-
ronment for creativity. Academy of management journal, 39(5), pp.1154-1184. (1996).