Extending OpenUp for Elicitation of Non-Functional Requirements

Extending OpenUp for Elicitation of Non-Functional
Autonomous Software Requirement

Viviane Priscila S. Santos, Anselmo Leonardo O. Nhane, Humberto Torres Marques-Neto
Department of Computer Science
Pontifical Catholic University of Minas Gerais (PUC MINAS)
Belo Horizonte – Brazil – 30.535-901
vpssantos@sga.pucminas.br, anselmo.nhane@sga.pucminas.br, humberto@pucminas.br

Abstract— In the last decade several contributions to the would compromise the software quality [3, 6, 7]. Taking
development of autonomic computing were presented in the this into consideration, this paper proposes an extension of
literature. However, it is clear that there is still a need for the OpenUP process for developing autonomous softwares
further research to consolidate this computing paradigm. This focusing on the elicitation of NFRs. This extension was
paper proposes the extension of the OpenUP software process
done including new artifacts for independent elicitation of
to promote the development of applications emphasizing the
analysis of non-functional requirements (NFRs) related to the NFRs in this process, because, usually, NFRs are
autonomic capabilities: self-configuration, self-optimization, described together functional requirement.
self-healing, and self-protection. Basically, the changes were We present a case study of Brazilian Emergency
made in the software requirements discipline of OpenUP, more System for illustrating the usage of proposed extension
specifically for proposing two new artifacts: NFR Description done. The results show that the new artifacts can help
and Misuse Case. These changes were important to discover software engineers in the task of the elicitation of NFRs.
other NFRs. In order to illustrate the proposed extension, we This paper is organized in five sections. Section 2
present a case study of the Brazilian Emergency System. presents the Related Work and describes aspects and
Keywords-component: Open UP; Autonomic computing;
concepts used in this work. In Section 3, we show our
Autonomous system; Non-functional Requirements; Software proposal of extending OpenUP for autonomic computing.
Process; Section 4 presents an illustrative case study and, finally, in
Section 5 we offer the conclusions.
I. INTRODUCTION
II. RELATED WORK
In recent decades, the development of computing
power and the growth of the number of devices used for A. Autonomic Computing
processing information have grown exponentially [24]. The concept of Autonomic Computing (AC) was
The computing has a very important role in the introduced by Paul Horn [5]. This concept is inspired by
information society. It is noticed that computing the Human Nervous System in order to find new ways of
technologies are developed and incorporated quickly to implementing software able to answer some challenges
existing computer systems, which increase the complexity posed by the increasing complexity of current IT systems.
[5]. Such complexity hampers the human intervention The AC refers to a system that incorporates mechanisms
required for software maintenances. It is expected that the for self-management based on the following qualitative
autonomic computing (AC) can be used to tackle part of characteristics: self-configuration, self-optimization, self-
these needs, because the autonomic systems may be able healing and self-protection [10, 12, 13].
to evaluate themselves and take appropriate action, thus The MAPE-K (monitor, analyze, plan, execute,
avoiding the need for human intervention for its operation. knowledge) is a reference model for autonomic control
In 2000s, software processes were focused on the loop, generally used to provide architectural aspects for
agility and integration [14], emphasizing collaborative autonomic systems [11]. The control loop defines the
methods, infrastructure environment, values-based elements that help to be in accordance with autonomic
methods, architectures and business systems built by users. characteristics which are linked to the NFR. Approach for
Different software processes, like RUP, XP, OpenUP, designing the software require multi-disciplinary group
among others, were used for software developing and its [16, 18] of systems engineering, once the software process
maintenance. However, these processes do not give the should consider all the autonomic characteristics, which
attention needed for the non-functional software affect the software design. In this context, MAPE-K plays
requirements (NFRs) because, normally, they focus on the a crucial role for satisfying the self-management qualities.
handling of functional requirements which can be easily
noticed and tested by final user [4]. Nevertheless, the B. Software Process
NFRs are very important for some kinds of software and The first generic processes, such as Waterfall model, V
the lack of their elicitation may cause problems which models, among others, did not always work for all

1

domains. On the other hand, it motivates the proposal for
the customization of generic software processes to work
well in a specific domain. For instance, the software
process for embedded systems should focus on the
determination of various challenges of integration between
software and hardware [23]. Moreover, in the ubiquitous
computing (any computing device can build dynamically
computational models of the environment in which it is
inserted and configure their services depending on the
needs) the software process should focus on, e.g. the
limitations imposed by the characteristics of the devices in
the environment [27].
According to Dhaminda [22] SOTA (“Stat Of Affair”)
is a general model for modeling the adaptation
requirement. This model enables a uniform and
comprehensive way of modeling functional and non-
functional software requirements. SOTA initially allows
the verification of requirements, identification of the
knowledge needed for self-adaptive and identifying Figure 1. NFR in the Autonomic Systems Qualities
patterns of self-adaptive more appropriate [22]. SOTA is
an integration of context modeling multidimensional and it The OpenUP is a software process with a minimal
tries to identify the general needs for the systems and content for developing software of high quality. Thus, it
dynamic components for self-adaptive focusing on the does not provide guidance on various topics that can
system architecture. The same happen on the SASSY handle projects, such as contractual situations, safety or
(Self-Architecting Software System) proposal, a model- mission critical applications, technology specific guidance,
driven framework target at dynamics settings in which a etc. [26]. Thus, to meet the requirements that are not
system´s requirement might change [25]. covered in your content, the OpenUP is extensible to be
Other research [8] has an architecture for self-adaptive, used as a basis on which process content can be added or
and it proposes a framework of quality metrics – as a modified.
methodology for software engineering based on IEEE Std Moreover, the OpenUP is iterative and agile process.
1061-1998, which makes explicit the qualities of The process consists of a few disciplines, including roles,
autonomic computing. The paper [15] proposes a Multi- artifacts and tasks, which are divided in Requirements,
Agent Systems approach and highlights the importance of Architecture, Development, Test, Project Management,
NFR for autonomic computing. and Configuration & Change management [9, 26].
As the AC properties are directly connected to NFRs, This work was extended only the discipline of the
as shown in Figure 1, the inadequate processing along the requirements. This extension is reported in subsection B.
generic software processes can be a problem. These There were no direct changes in other disciplines, but
generic software processes, like RUP, are focused on taking into account the iterative phases of OpenUP, we
continuous iterations with stakeholders to achieve the presented in subsection C that the impacts can be avoided.
functional requirements during the software process. The A. Adapting OpenUp for AC
same finding was observed in the software processes for
embedded systems, which leads us to conclude that non- Our proposal is to insert two new artifacts in the
functional requirements have always been on the margins requirements discipline of the OpenUP. The first one is the
of software processes. However, aspects conducive to NFR Description, which contains a list of NFRs with their
achieving the AC requirements are strongly conditioned to detailing, identifying ambiguities, disability/inconsistency
of these requirements and conflicts. NFRs defined by
the NFR that requires special attention in the treatment of
different actors can run between them, with the solution, as
the software process, and in the modeling of autonomic
can be seen in Figure 2. The main goal of this new artifact
systems, as documented in Figure 1. Current studies are
is to make feasible a greater focus on NFRs elicitation.
focused on proposed models for AC architecture based on
To identify ambiguities among the requirements, both
the standard cycle control MAPE-K as well as those
NFR and FR must declare them consistently and
proposals affect the design and analysis of systems.
objectively, avoiding double interpretation. The
III. EXTENDING OPENUP FOR THE ELICITATION OF inconsistency is reflected in the development and typically
NON-FUNCTIONAL AUTONOMIC SOFTWARE REQUIREMENT results in a system where user satisfaction is a question [2].
Ambiguity or inconsistency of NFRs can result in system
As mentioned before, this paper proposes some crashes such as the famous example of the London
extensions to the OpenUP process in order to tailor it to Ambulance System [1].
the development autonomous systems. These extensions
were done in the activities of the requirement discipline.

2

For some NFRs are only identified among the functional
requirements, i.e. are hidden among the FRs beyond those
specified by the stakeholders. Thus, for this purpose it is
proposed to use the Misuse Case artifact.
The Figure 3 modifies the basic OpenUP [28],
demonstrates the tasks of the requirements elicitation in
extended OpenUP which included the two new artifacts
here indicated by circles: Misuse Case and NFR
Description. This provides inputs and outputs of
Requirements elicitation in order to identify and refine
requirements. In Input 1 has the artifacts Glossary and
Vision. These are the tasks of the system specifications in
the view of stakeholder and analyst. This input produces
other artifacts, output 1, will be explained only those are
proposed in this paper. The output 1 produces besides the
Figure 2. Description NFR Structure
ancient artifacts of OpenUP. NFR Description and Misuse
Cases are new artifacts where all the specifications
The NFRs obtained through different actors of the
described above are followed. This is the first iteration.
system may have conflicts with each other. It is necessary
The second input, the level of NFRs seeks to use the
that all the functional and non-functional requirements are
Misuse Cases for modifying the NFR Description. They
satisfied. It is very difficult to tell when NFR are satisfied.
are inserted into the new NFRs discovered through faults
Hence, the term partial NFR satisfaction is used when
in the FRs of the system in the NFR Description.
there is a solution considered good, even if this is not ideal
Therefore, all NFRs are defined. Procedures are applied to
[17]. Therefore the conflict must be explained including all
find out if there are ambiguities and conflicts between
its dependencies. The decisions to resolve the conflict
them after that obtains the final NFR.
must be based on the classification of priorities [19],
which seeks to apply the NFR. B. Impacts of Changes in OpenUP
The indentify and Refine Requirements are present in
three phases of Patterns of Inception phase Elaboration
Iteration Phase Construction Phase Iteration what the
requirements are presents and Transition Phase Iteration.
Thus the changes proposed here can impact and add new
goals to these iterative phases.
In the initiation phase iteration of the objectives of this
stage, affects the pattern model iteration (the identification
and refinement requirements) in order to determine a
relative solution autonomic possible. Assess the key
features based on the autonomic system. realizes all
limitations associated with non-functional and functional
requirements, which will impact the product by
minimizing maintenance and future corrections due to this
requirement.
The iteration of the elaboration phase - this phase, the
process OpenUP impact on goals in two fundamental
aspects: Definition of the architecture (must allow
modification with changes of context, which will require
an additional study of restrictions and changes that may
occur) and in the detailing of non-functional requirements
according to our proposal, will highlight new non-
functional requirements. Another relevant aspect is in
accordance with the need for the project, identifying
Figure 3. Steps Requirements elicitation OpenUP, modified for professionals of different areas that are covered by the
elicitation of NFRs
characteristics of the system under study.
Iteration of the construction phase - this phase the
The Misuse Case was also added to the OpenUp
OpenUP also recommends the Refinement of the
software process. This is based on scenarios of negative
requirements that will impact the development, including
circumstances used in situations where error occurs in the
how to identify the policies that define the behavior of the
system. Misuse Cases can improve the elicitation process
autonomic system.
they may lead to yet unidentified NFRs that are hidden [2].

3

In general, the process extension increases the attention shows the sequence of events where a most events can
given to non-functional requirements, instead of relying occur simultaneously (eg as in box 6 and 10).
only on use cases. The process focuses on the qualities and
NFR based on metrics for autonomic computing. OpenUP B. Appling Extended OpenUp in SBE
provides guidance on the specification of autonomic For requirements elicitation this system was applied to
software quality(self-configuration, self-healing, self- the artifacts here proposed as an extension of the OpenUP,
optimization, etc..) That best suits the project under study. so defined correctly the NFRs.Firstly, we got the system
description and produce traditional artifacts of OpenUP as
C. Non-Functional Requirements and MAPE-K a list of requirements and UML diagrams, which were
It is very important to define correctly the NFRs of the specified FRs and NFRs normally. After this was done
autonomic system, as well as conflicts, if any, between where the NFR Description was identified first order two
them. It can directly influence the political system NFRs ambiguous, ie, those that could be bad roles played
management. How goals are often expressed using by others, such as Architects, Developers and Testers.
political event-condition-action (ECA) the policies of goal, After it was built the Misuse Case.
or political utility function [21]. As the policies define how The next step is the built of the Misuse Case, where it
and when MAPE-K should act in relation to managed was possible to discover other NFRs hidden amid the FRs.
Element, Plan and Knowledge, influence that the actions These NFRs could not be identified in most processes
taken by the autonomic system. Furthermore, through the commonly used for modeling focused FRs [2] and thus,
NFRs is possible to define what properties (self-Healing, the analyst cannot perceive them. Generally, all NFRs are
self-protection, self-configuration and self-optimization) not specified by stakeholders. It requires observation of the
are added to the AC system, as can be seen in Figure 1. analyst, which does not always happen due to the short
An example would be an autonomic system that time frame for completion of the system. This can result in
detects two sub-problems at the same time as one of software (system) that does not solve completely the
configuration, and other Healing, priorities of NFRs problem of users [28], leading to the need for corrections
determine which decision is the highest priority and should when the process is already at an advanced stage or system
be executed first, if it is not possible to place them at the in use. This is very bad because NFRs corrections are
same time. much more expensive and difficult to do [2].
Another factor is that this information is possible to Some NFRs found integrations with external systems
select which application analyst MAPE-K is appropriate to are already in use. This is shown in Figure 5, where the
the system. Example a system that has as NFRs system should decrease the time of the traffic lights on the
Performance and Maintainability can be implemented route traced, but it must be integrated into the control
using the tool ABLE, this has performance monitoring, system. Moreover, there is also integration with traffic
health monitoring, prediction level and length of service system that was forgotten in the first instance, whose need
for contract management [20]. was perceived when simulations of traffic problems in
using functional part Misuse Case, where it is necessary to
IV. CASE STUDY divert the route in case of traffic blockage. As well as
A. Brazilian Emergency System changes in the climate where drastic changes in climate
should also divert the route of MSU, so it is necessary
As a Case Study to illustrate this changes proposed integration with the weather system. These integrations in
here, we applied the two new artifacts in set of the both the systems, traffic and weather, was also required in
requirements of the Brazilian Emergency System (SBE). the case of Figure 6, where the system checks the necessity
This system aims to integrate the attendance of SAMU of sending helicopter, if such is available. Also noted is
(Emergency Phone Number: 192), the emergency care unit other NFR a need for integration in real time.
in Brazil, and Fire Department (Emergency Phone In the second iteration, the NFR Description has been
Number: 193), in order to solve problems caused by the redone and all NFRs uncovered from Misuse Case were
disjunction of these systems of care. These two units are added. In this new list were sought ambiguities and
disjoint emergency entities and sometimes we can observe conflicts. The only conflict was found that the external
problems of communication among them. In an emergency system for diversion of priority, i.e. the climate and traffic.
situation, SAMU ambulance and firefighter’s vehicle are In this case the climate was chosen as a priority, as in the
called unnecessarily, causing disputes between service case of certain roads may flood rains. Moreover, there
units and allocation of professional and unnecessary were some NFRs that could be misinterpreted and its
vehicles that could meet other cases. description was improved so that it is more objective.
This paper proposed an autonomous system that is
selected for the best care unit for each type of call. Its
operation can be seen in Figure 4, where the numbering

4

Figure 4. Operation of Emergency System

Figure 5. Misuse case part applied to the SBE Figure 6 - Misuse case part applied to the SBE

C. Impact properties AC  As Self-configuration: The emergency system in
Brazil (SBE) have to change settings and route
These changes were important because aside from
traffic lights, according to the external conditions
discovering other NFRs that they could be disregarded by
to be monitored by this, among other;
not receiving adequate attention on the beginning of the
 Self-optimization: SBE should increase or reduce
project [2], these requirements were also attached the
its performance according to the system need;
properties of the autonomic system. This can be seen in
Figure 1, largely Self-Healing and Self-configuration due  Self-healing: SBE must be able to function even
to the nature of the system. This connection between the with faults such as networks and repairs them.
AC and properties NFRs are exemplified below: This is because the system must always be
available to users; and

5

 Self-protection: The system must recognize and [10] J. A. McCann and M. C. Huebscher. “Evaluation Issues in
replace, malicious services by other suitable Autonomic Computing”, Grid and Cooperative Computing
- GCC 2004 Workshops, Springer Berlin / Heidelberg, vol.
through the result of the discovery. 3252, 2004, pp. 597-608.
Thus, it is clear that when the NFRs receive due [11] M. C. Huebscher and J. A. McCann. “A survey of
attention positively impact the outcome ddo process, may autonomic computing—degrees, models, and applications”,
reduce costs and delays [2]. For this reason, the extension ACM Comput. Surv., vol. 40, Aug. 2008, pp. 7:1--7:28,
here proposed NFRs attempts to identify the beginning of doi: 10.1145/1380584.1380585.
the process software, as proposed in [3] and [4]. [12] L. D. Paulson. “Computer System, Heal Thyself”,
Computer, vol. 35, Aug. 2002, pp. 20--22, doi:
V. CONCLUSION 10.1109/MC.2002.1023783.
[13] A. J. Ramirez, D. B. Knoester, B. H. Cheng and P. K.
There are clearly problems in the elicitation of NFRs in Mckinley. “Plato: a genetic algorithm approach to run-time
conventional software processes, which may generate reconFiguretion in autonomic computing systems,” Cluster
system failures. This includes standalone systems, as Computing, vol. 14, Sep. 2011, pp.229-244, doi:
realized during this work, the AC is intertwined with 10.1007/s10586-010-0122-y.
NFRs. Bearing this in account the work done here [14] B. Boehm et al; A View of 20th and 21st Century Software
Engineering; University of Southern California, University
provides a new way of NFR elicitation supported by Park Campus, Los Angeles, 2006.
Misuse Cases. This proposal appears to be adequate, since [15] H. Kuang and O. Ormandjieva, "Self-Monitoring of Non-
it focuses on the NFRs since the beginning of the software Functional Requirements in Reactive Autonomic Systems
process. Thus, we conclude that the extension made in Framework: A Multi-Agent Systems Approach"; IEEE,
OpenUP can get good results, facilitating the identification Concordia University, Montreal, Canada, 2008.
and refinement of NFRs using the NFR Misuse Case [16] E. Shahriar at al, "Software Process Engineering: Strengths,
Description and which are present in the process since the Weaknesses, Opportunities and Threats", Malasia, 2010.
beginning of the process. It is still desired changes in the [17] L. M. Cysneiros, "Evaluating the Effectiveness of
test area and adding documentation to choose the best Using Catalogues to Elicit Non-Functional Requirements,"
Proceedings of 10th Workshop in Requirements
application through the specified NFRs for autonomous Engineering, 2007.
system development. Furthermore, we intend to review the [18] J, Cleland-Huang; "Goal-Centric Traceability for
impact on all other process disciplines, for these managing Non-Functional Requirements", ICSE, USA,
modifications. 2005.
[19] D. K. Barham Paech, "Non-Functional Requirements
REFERENCES Engineering - Quality is Essential," 10th Anniversary
[1] A D. J. Finkelstein, "A comedy of Errors: The London International Workshop on Requirements Engineering:
Ambulance Service Case Study," IEEE Computer Society Foundation for Software Quality(REFSQ'04), 2004.
Press pp 2-5 1996. [20] Bigus, J. P.; Schlosnagle, D. A.; Pilgrim, J. R.; Mills III,
[2] Ullah, S.; Iqbal, M.; Khan, A.M.; , "A survey on issues in W. N.; Diao, Y.; , "ABLE: A toolkit for building
non-functional requirements elicitation,", 2011, pp.333-340 multiagent autonomic systems," IBM Systems Journal ,
doi: 10.1109/ICCNIT.2011.6020890. vol.41, no.3, pp.350-371, 2002 doi: 10.1147/sj.413.0350.
[3] L. M. Cysneiros., J. C. S. P, Leite. "Non-functional [21] J.O. Kephart, and W. E. Walsh. "An artificial intelligence
requirements: from elicitation to modelling languages," perspective on autonomic computing policies." In
Software Engineering,. ICSE 2002. Proceedings of the 24rd Proceedings of the 5th IEEE International Workshop on
International Conference, pp.699-700, 2002. Policies for Distributed Systems and Networks. 3–12 2004.
[4] B. A N. Lawrence Chung. Eric Yo, and John Mylopoulos, [22] B. Dhaminda, Abeywickrama et ali, SOTA: toward
"Non Functional Requirements in Software General Model for Self-Adaptative Systems; IEEE 21st
Engineering," Boston: Kluwer Academic Publishers, International Wetice, 2012.
2000. [23] D. E. Damkeres; “Aplicação da abordagem GQM para a
[5] Horn P., 2001. "Autonomic computing: IBM’s perspective definição de um processo de engenharia de requisitos de
on the state of information technology". URL: software embarcado”, Masterdegree, Universidade Católica
http://researchweb.watson.ibm.com/autonomic. de Brasilia; Brazil; 2008.
[6] M. S.Emami , N. Binti Ithnin and O. Ibrahim, “Software [24] Would Statistics, http://www.factfish.com/statistic/. Accessed
Process Engineering: Strengths, Weaknesses, Date: 07.11.12;
Opportunities and Threats”. Networked Computing (INC), [25] D. Menascé et ali; SASSY(Self-architecting software
6th International Conference on, IEEE, 2010. system), IEEE Software, 2011
[7] L. M. Cysneiros and J. C. S. P. Leite. “Using UML to [26] Introduction to OpenUP (Open unified Process. Project.
reflect non-functional requirements”. In Proceedings of the URL: http://www.eclipse.org/epf/general/OpenUP.pdf.
2001 conference of the Centre for Advanced Studies on [27] C. Cirilo; "Computação Ubíqua: definição, princípios e
Collaborative research (CASCON '01), 2001. tecnologias"; Cientifc article, Universidade Federal de São
[8] P. Lin, A. Mac, J. Leaney, “Defining Autonomic Carlos, Brasil.
Computing: A Software Engineering Perspective,” [28] A. Matouss and R. Laleau , "A Survey of Non-Functional
Proceedings of the 2005 Australian Software Engineering Requirements in Software Development Process" TR-
Conference (ASWEC’05), Mar. 2005; Australia. LACL-2008-7. 2008.
[9] Eletronic Document: OpenUp: Unified Project. URL: [29] OpenUp/Basic "Maneged Requeriments". 2012. URL:
http://epf.eclipse.org/wikis/openup/ <http://epf.eclipse.org/wikis/openuppt/index.htm>

6

Extending OpenUp for Elicitation of Non-Functional Requirements

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Extending OpenUp for Elicitation of Non-Functional Requirements

Similaire à Extending OpenUp for Elicitation of Non-Functional Requirements (20)

Dernier

Dernier (20)

Extending OpenUp for Elicitation of Non-Functional Requirements