See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/352128522

Handling Non-Functional Requirements in Software Architecture

Conference Paper · May 2021

CITATIONS READS
0 235

2 authors:

Mohammad Gulam Lorgat Hugo Paredes

Universidade Católica de Moçambique Institute for Systems and Computer Engineering, Technology and Science (INESC TEC)
7 PUBLICATIONS   1 CITATION    204 PUBLICATIONS   1,199 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

NanoSTIMA – Research Line 2: Health data collection and visualization View project

MULTIS & MULTIS II - Integration of Virtual Worlds in LMS View project

All content following this page was uploaded by Mohammad Gulam Lorgat on 04 June 2021.

The user has requested enhancement of the downloaded file.

 Innovation Management and information Technology impact on Global Economy in the Era of Pandemic

Handling Non-Functional Requirements in Software Architecture

Mohammad Gulam LORGAT

Universidade Católica de Moçambique – Faculty of Engineering, Chimoio, Mozambique

mlorgat@ucm.ac.mz

Hugo PAREDES

INESC TEC and Universidade de Trás-os-Montes e Alto Douro, Quinta de Prados, Vila Real, Portugal
hparedes@utad.pt

Abstract

The requirements are defined at the start of the process of developing a system. And the both types of requirements are
equally important and are supposed to be elicited, specified, and represented to ensure a good quality system. Though it has
been verified that more attention is given to the functional requirements, when the relationship of NFRs is stronger with
software architecture than other activities related to the software development process, especially architectural decision-
making. Thus, poor handling of NFRs may affect in the architectural decision-making. Therefore, multiple frameworks,
methods and tools have been developed to handle the NFRs in software architecture. This work, through a literature
review, aims to present the relationship between NFRs and software architecture, how the NFRs are currently handled in
software architecture and, present recently developed and proposed tools that may help to adequately handle the NFRs in
software architecture in order to deliver a good quality system. And, of which, three recent tools were highlighted,
ArchiTech, URML and Breeze.

Keywords: Non-Functional Requirements, Software Architecture, Decision-Making, Requirements Engineering.

Introduction
System requirements play the role of describing the services a system will provide and what the limitations, its operations
will have. They are divided in two types, functional and non-functional requirements (NFRs). The functional requirements,
state the services the system should provide, how they will react to specific inputs and how it will behave in specific
situation, or in simple terms, it tells what the system will do. Then we have the non-functional requirements which are
concerned in specifying the limitations on the services and tasks provided by the system, for example, security, usability,
performance, efficiency, etc. (Sommerville, 2016).

The requirements play a large role and have a straight relationship with software architecture, especially the NFRs.
Software architecture is considered of pertinence to achieve success when developing a system. They are a set of patterns,
which is composed of software elements, how they relate and their properties, and these, help reasoning about the system
that is being developed (Bass et al., 2013). And they have been traditionally built and documented, reflecting the functional
requirements and NFRs as a set of architectural views (Kruchten, 1995; Rozanski and Woods, 2005).

The requirements are defined at the start of the process of developing a system, the both types of requirements are equally
important and they are supposed to be elicited, analysed, specified and validated to ensure a good quality system. Though it
has been verified that more attention is given to the functional requirements. And poor handling of NFRs may affect in the
architectural decision-making. Additionally, the lack of knowledge on handling the NFRs that has been seen, may be the
reason of the NFRs not being considered by many architects. Thus, this raises a question on how to adequately handle the
NFRs in the software architecture in order to deliver a good quality system.

Consequently, this work addresses the raised question through a literature review, by firstly presenting the relationship
between NFRs and software architecture, then how the NFRs are currently handled in software architecture, later by
presenting some developed and proposed tools that may help to adequately handle the NFRs in software architecture in
order to deliver a good quality system and finally, by presenting some directives for future research.

__________________
Cite this Article as: Mohammad Gulam LORGAT and Hugo PAREDES “ Handling Non-Functional Requirements in Software
Architecture ” Proceedings of the 37th International Business Information Management Association (IBIMA), 30-31 May 2021,
Cordoba, Spain, ISBN: 978-0-9998551-6-4, ISSN: 2767-9640

3674
 Innovation Management and information Technology impact on Global Economy in the Era of Pandemic

Methodology
A bibliographic research was carried out on the relationship between the NFRs and software architecture, how the NFRs
are handled and on different proposed tools that may help to adequately handle the NFRs in software architecture in order
to deliver a good quality system. The databases used to obtain the literature source were: IEEE Xplore and Google Scholar.
To obtain the literary sources, publications were considered with the following topics: non-functional requirements in
software architecture, decision-making in software architecture, requirements engineering, tools and software engineering.
And the keywords used were: non-functional requirements, quality attributes, architectural decision, software architecture
and modelling non-functional requirements.

Database Found more

Search using than 100
Keywords results

Works related to:

Software architecture decision makings and Found 36 works and
Finally identified
NFRs; applied other criteria to
13 results
Handling NFRs in software architecture; and assess their relevance
How the NFRs should be handled.

Figure 1: Works’ selection process for the paper

The logical operators “OR” and “AND”, were taken into consideration while searching the databases using the keywords
and generated more than 100 results of which many were duplicates and were not written in English language hence, they
were excluded. Each article’s abstract was verified if they were related to software architecture decision-makings and
NFRs, if they presented how the NFRs were handled in software architecture and how the NFRs should be handled. This
verification resulted in 36 works. By default, the databases show the relevant results but to ensure the inclusion of current
and relevant developments, only the ones published in the last 10 years and of which the authors, journals and conferences
are well known in the field, were considered and some works’ references was verified to ensure their relevance as well.
And following this, 13 works were identified. The selection process can be seen in Figure 1.

Non-Functional Requirements and Software Architecture

According to Glinz (2007), the NFRs express the desired qualities of the system to be developed. They refer to observable
qualities, such as system performance, availability and reliability, as well as relative internal characteristics, for example,
ease of maintenance and portability.

In software architecture, many decisions are made. And there is a close relationship between the NFRs and software
architectures in software engineering (Bajpai and Gorthi, 2012; Kazman and Bass, 1994). NFRs influence software
architecture decisions. They serve as a criteria for selecting from a variety of projects and implementations. For example, it
may be justified to choose a layered architecture style in terms of maintenance or portability, or to choose a particular
database technology in terms of efficiency (Ameller et al., 2013; Subramanian and Chung, 2005). The NFRs are
sometimes referred as quality attributes, constraints, goals, and non-behavioral requirements in software architecture.

Furthermore, according to Pohl and Rupp (2011), the relationship of NFRs is stronger with software architecture than other
activities related to the software development process. Especially in architectural decision-making, the NFRs tend to
influence the architecture of the system more than the functional requirements.

Over the years, software engineers say that it is not feasible to produce a software system that meets the needs of
stakeholders without taking NFRs into account. Therefore, software development projects currently invest heavily to
satisfy NFRs (Buschmann, 2010). However, information about NFRs is rarely described, there is a lack of its proper
treatment in requirement models and specification languages, and dealing with NFRs is a major challenge in software
development (Chung and do Prado Leite, 2009).

3675
 Innovation Management and information Technology impact on Global Economy in the Era of Pandemic

Additionally, NFRs are neglected and are very rarely stated, even if stated they are done informally in most of the software
development and the reasons are lack of support from any language or tools (Babar and Capilla, 2008; Bajpai and Gorthi,
2012).

Ameller et al. (2013), in their survey, observed that the collection of NFRs is one of the challenges in requirements
engineering, customers usually mention functional requirements, what the system should do, but they do not always
mention the NFRs. NFRs are often defined by software architects based on their experiences.

They further noted that collecting NFRs is an iterative process that expands throughout the software life cycle. NFRs are
not considered complete after developing the first version of the software and some NFRs as security is not verified before
implementing the software itself.

They also noted that software architects rarely documented the NFRs, thus they believe the NFRs to be more hidden than
documented. Sometimes they are documented in natural language or in risk models. Some documented NFRs initially in
natural language, but subsequently did not update or observe changes in them. For the notation of the functional
requirements there is the UML (Unified Modelling Language), but software architects did not have knowledge of a specific
notation for the NFRs.

Another observation they made was related to the validation of the NFRs, which is a more difficult task than the collection
itself, because each NFR differs and its validation methods as well. Some validate NFRs, based on tests, such as stress and
load tests to evaluate performance, and for usability, create prototypes to guarantee customer satisfaction. However, to
assess security, some waited customers to complain. And these encountered difficulties and problems, have a connection
with the previous aspect addressed in documentation. Therefore, NFRs influence almost all decisions made in the software
architecture. For example, in the choice of architectural standards, in the implementation strategy, transversal decisions and
in the choice of technological platforms.

Consequently, this raises a challenge to handle the NFRs, from eliciting, analysing, specifying and validating. And because
the NFRs keeps changing, another challenge would be to handle their modifications and the affects it may have on the
architectural decisions.

And, according to Babar and Capilla (2008), many tools, frameworks and approaches have been proposed by researchers,
so that different activities of the software architecture processes are supported, through capturing and sharing architectural
knowledge.

NFRs Handling Tools

This section presents some papers, which developed or proposed tool, that answer some of the challenges identified above
and which deal or at least try to deal with NFRs and that have a link with the architecture. And finally, a comparison of
these tools is displayed based on the NFRs identified challenges.

ArchiTech
Ameller et al. (2012) in their paper, focus on ArchiTech, a tool that deals NFRs in Model-Driven Development. The tool
provides a set of architectural decisions and evaluation of expected quality from a set of quality requirements and
limitations derived from an SRS by the architect, to get the resulting decisions. ArchiTech has two subsystems, ArchiTech-
CRUD and ArchiTech-DM. Once the results are obtained, ArchiTech-CRUD are used to manage and maintain the
Architectural Knowledge through CRUD (Create-Read-Update-Delete) operations with a graphical user interface. And the
other subsystem ArchiTech-DM guides software architects in NFR-driven decision-making using a method called Quark.
This method begins with the SRS, where the NFR can be focused and concludes with a set of architectural decisions and
the evaluation of the overall software quality.

URML
Furthermore, Schneider et al. (2013) in their paper, introduce a new requirement modelling language, named Unified
Requirements Modeling Language (URML), derived from UML and which supports elicitation of functional requirements
and NFRs. URML connects all the concepts (stakeholders, goals, features, product lines, systems, processes, risks and
requirements) in one single modelling language and allows traceability between them. The implementation of URML was
done as an add-in to the Enterprise Architect (EA) CASE tool, defined in UML profile diagrams. The URML graphical
notation is icon-based, instead of generic shapes such as rectangles and ovals, and every concept has its own unique icon.
The add-in offers a new language based on UML, with language specific toolbars that have concepts and relationships of
the language and defines the quick creation of the concept and relationship.

3676
 Innovation Management and information Technology impact on Global Economy in the Era of Pandemic

Breeze
And, Chen et al. (2015) in their paper, present an open-source tool, called Breeze, compatible with UML, because it is
based on Eclipse Framework. It allows modelling and analysing of NFRs at the architecture level. Breeze also permits
users to repair the design defects by defining reconfiguration rules. Breeze is comprised of three modules, architecture
modelling module, on which architecture of software systems are modelled with Breeze/ADL, an XML-based architecture
description language, and it also allows a graphical presentation of Breeze/ADL through corresponding icon button. The
second module is the architecture analysis module, where non-functional requirements are verified and three types of
analysis are supported, correctness, safety and reliability. And the last module is architecture reconfiguration module,
which lets users repair defects in their architecture or to further improve architecture by implementing a reconfiguration
mechanism.

NFRs Handling Tools Comparison

Table 1: NFRs Handling Tools Comparison

NFRs Challenges/Features Tools

ArchiTech URML Breeze
NFRs Elicitation No Yes No
NFRs Analysis No No Yes
NFRs Modelling No Yes Yes
NFRs Validation No No No
Architectural Decision-Making Yes No Yes
Architectural Improvement No No Yes
(NFRs Modification)

Discussion

Thus, clearly functional requirements play an important role in delivering a good quality software and so does the NFRs.
The NFRs also refer to the quality attributes of a software, they affect not only the overall quality of the software but its
architecture decision-makings as well, more than the functional requirements, for instance choosing a specific layered
architecture style based on maintenance or portability or choosing a particular database technology in terms of efficiency.
Therefore, the software core itself, depends on the NFRs.

Even though NFRs importance is justified, its inclusion in the software developments processes is less and are not treated
accordingly and this was identified as a big challenge in the software development. The functional requirements are easy to
gather since the clients have a somewhat idea of what the system should do but they don’t usually know about the NFRs,
hence its collection is another challenge. Some architects may include the NFRs in software development but won’t
document it. And since the NFRs collection process is iterative, this leads to the difficulty of keeping them up to date and
performing their verification, because each NFR has their own method.

Moreover, the lack of support from any language or tools and lack of knowledge on handling the NFRs may be the reason
of the NFRs not being considered by many architects. Therefore, in order to tackle these challenges, some recent tools
were proposed such as ArchiTech, URML and Breeze. But each tool is limited to addressing only a few of the NFRs
challenges. The ArchiTech tool is limited to providing only a set of architectural decisions and lacks the ability to improve
them when found irregularities in the same decision set, and lacks the ability to elicit, analyse, model and validate the
NFRs as well. Furthermore, although the URML tool was implemented as an EA Case tool, the elicitation and modelling
of the NFRs are not done at the architecture level and they also lack the ability to analyse and validate the NFRs, and deal
with architecture decisions and their modifications. On the other hand, the Breeze tool, does not answer the NFRs
elicitation and validation challenges, but it is an improved version of the earlier presented tools, it features NFRs modelling
and analysis at the architecture level and supports improvement of architecture if an NFR problem is detected. Thus, for
future work, the other unaddressed challenges can be explored, an evaluation can be run to assess the effectiveness of each
presented tool and also help increase or spread the knowledge on handling the NFRs in software architecture.

Conclusions
The current work provided a state of the art on NFRs in the software architecture. Starting from its definition, division or
types and how they were handled by the software architect. Many decisions are made in software architecture and most
them are influenced by the NFRs, for example which architecture style to choose. Thus, NFRs need to be handled with

3677
 Innovation Management and information Technology impact on Global Economy in the Era of Pandemic

utmost care as well as the functional requirements to ensure a good quality software. Though lack of attention has been
noticed towards the NFRs, and the lack of support from any language or tools has been identified as the culprit.
Consequently, challenges were raised, on how to handle the NFRs in the software architecture to ensure a good quality
system. And many tools, frameworks and approaches have been proposed by researchers, thus in this work, a few recent
proposed tools were highlighted, such as ArchiTech, URML and Breeze, that try to answer some of the identified
challenges. And for future research a few directives were presented as well.

References

• Ameller, D., Ayala, C., Cabot, J. and Franch, X. (2013), “Non-functional Requirements in Architectural Decision
Making”, IEEE Software, presented at the IEEE Software, Vol. 30 No. 2, pp. 61–67.
• Ameller, D., Collell, O. and Franch, X. (2012), “ArchiTech: Tool support for NFR-guided architectural decision-
making”, 2012 20th IEEE International Requirements Engineering Conference (RE), presented at the 2012 20th IEEE
International Requirements Engineering Conference (RE), pp. 315–316.
• Babar, M.A. and Capilla, R. (2008), “Capturing and Using Quality Attributes Knowledge in Software Architecture
Evaluation Process”, 2008 First International Workshop on Managing Requirements Knowledge, presented at the
2008 First International Workshop on Managing Requirements Knowledge, pp. 53–62.
• Bajpai, V. and Gorthi, R.P. (2012), “On non-functional requirements: A survey”, 2012 IEEE Students’ Conference on
Electrical, Electronics and Computer Science, presented at the 2012 IEEE Students’ Conference on Electrical,
Electronics and Computer Science, pp. 1–4.
• Bass, L., Clements, P. and Kazman, R. (2013), Software Architecture in Practice, 3rd ed., Addison-Wesley
Professional.
• Buschmann, F. (2010), “Value-Focused System Quality”, IEEE Software, presented at the IEEE Software, Vol. 27 No.
6, pp. 84–86.
• Chen, L., Huang, L., Zhong, H., Li, C. and Wu, X. (2015), “Breeze: A modeling tool for designing, analyzing, and
improving software architecture”, 2015 IEEE 23rd International Requirements Engineering Conference (RE),
presented at the 2015 IEEE 23rd International Requirements Engineering Conference (RE), pp. 284–285.
• Chung, L. and do Prado Leite, J.C.S. (2009), “On Non-Functional Requirements in Software Engineering”, in
Borgida, A.T., Chaudhri, V.K., Giorgini, P. and Yu, E.S. (Eds.), Conceptual Modeling: Foundations and Applications:
Essays in Honor of John Mylopoulos, Springer, Berlin, Heidelberg, pp. 363–379.
• Glinz, M. (2007), “On Non-Functional Requirements”, 15th IEEE International Requirements Engineering
Conference (RE 2007), presented at the 15th IEEE International Requirements Engineering Conference (RE 2007), pp.
21–26.
• Kazman, R. and Bass, L. (1994), Toward Deriving Software Architectures from Quality Attributes, Technical No.
CMU/SEI-94-TR-010, Software Engineering Institute, available at: https://apps.dtic.mil/sti/citations/ADA283827
(accessed 25 November 2020).
• Kruchten, P.B. (1995), “The 4+1 View Model of architecture”, IEEE Software, presented at the IEEE Software, Vol.
12 No. 6, pp. 42–50.
• Pohl, K. and Rupp, C. (2011), Requirements Engineering Fundamentals: A Study Guide for the Certified Professional
for Requirements Engineering Exam - Foundation Level - IREB Compliant, 1st ed., Rocky Nook.
• Rozanski, N. and Woods, E. (2005), Software Systems Architecture: Working With Stakeholders Using Viewpoints and
Perspectives, Addison-Wesley Professional.
• Schneider, F., Bruegge, B. and Berenbach, B. (2013), “A tool implementation of the unified requirements modeling
language as enterprise architect add-in”, 2013 21st IEEE International Requirements Engineering Conference (RE),
presented at the 2013 21st IEEE International Requirements Engineering Conference (RE), pp. 334–335.
• Sommerville, I. (2016), Software Engineering, 10th ed., Pearson, Boston.
• Subramanian, N. and Chung, L. (2005), “Relationship between the whole of software architecture and its parts: an
NFR perspective”, Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and
Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Network,
presented at the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and
Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Network, pp.
164–169.

3678

View publication stats