Addressing Quality requirements in software architecture
Kiran Moses Katamreddy
19861114-7219
Kika09@student.bth.se
Ronneby
ABSTRACT
This paper is written as a report for addressing quality
requirements in software architecture. Since quality
requirements play a crucial role in influencing software
architecture, it should be considered at the initial stages of
system. Lack of quality requirements results in the
difficulties in the system. In this paper we focused on
research questions and proposed relevant methodologies to
give a solution.
Aim
The main research aim of this project is to identify, analyze,
and propose a method for addressing quality requirements
during software architecture design. This paper also
discusses the impact of quality requirements on software
architecture.
Objectives
 view handles some quality requirements such as
 Putting software architecture in the context of
quality requirements.
 Identification and improve the way that quality
requirements handled in the software architecture.
 The quality attributes specified in the requirement
specification and their relationship with quality
requirement is discussed.
Keywords
Quality requirements, Quality attributes, Software
architecture design.
1. Background
In the field of software engineering, architectural design
plays a vital role to describe functionality of a system. The
characterization of software systems are done based on their
functionality (what the system will do) and by their non-
functionality (how the system does with respect to quality
attributes like reliability, efficiency, performance etc.,)
[6].Despite of the fact that both concepts are equally active
and influences for the software development, but non-
functionality requirements are often neglected in many
cases during specification. Even though well-specified
functional and interface requirements, many software
projects failed because they had a poor set of quality
attribute requirements [1]. This actually results in the lack
of quality attributes in software architecture. The quality
requirements help to make a boundary for the final quality
of a designed system. So to strictly avoid these
inconvenience, system properties (quality requirements) are
required to specify in SRS. According to [4] without
experience or guidance, an architect could easily pick
wrong details to expose in the architecture and could miss
the important ones. Previous architects experience will be
helpful for architectural design. But there is no effective
methodology to support and guide software architectural
design. However it is quite difficult activity to transform
SRS into software architecture. The main task behind the
challenge is to develop software architecture with desired
quality levels. The software architecture of a system is the
structures of the system, which comprise software
components and relationships between them. Quality
attributes can be addressed by the combination of
components.
According to [4], Hofmiester proposed a method which
depicts four views in Software architecture. Conceptual
performance, maintainability or dependability and makes
architecture available to different stakeholders. In Module
view the functionality of the system is mapped and
controlled. In this view software architect addresses how
the conceptual solution can be realized in today’s software
platforms and technologies. An execution view describes
how modules are mapped to elements provided by the
runtime platform. It also describes the flow of control. The
final view in software architecture is code view in which the
elements are mapped to the implementation.
According to [4] The Quality requirements and desired
quality attributes are forwarded to software architecture
through development tasks like domain analysis,
requirements analysis and risk analysis.
.
2. Definition of software architecture
There were quite confusions with synonyms like
architectural pattern is also known as architectural style and
quality requirements as Non-functional requirements or
system properties. Perhaps to avoid this confusion it will be
better to have a single standard definition. Many authors,
researchers and architects provided their own experiences
and definitions on software architecture. But there is still no
standard definition on software architecture. Even though a
wide popular definition of software architecture is “A
software architecture for a system is the structure or
structures of the system, which comprise components, their
externally visible behavior and the relationships among
them” [2].
3. Software requirements
Software requirements are specified in SRS during the early
point of software development process of the system. It
consists of Functional and Non-functional requirements
(quality requirements) which provides as input for the
software architect design. As per previous authors
Functional requirements is described as “statements of
services the system should provide, how the system should
react to particular inputs and how the system should
behave in particular situations”[7].In past the authors were
concentrating on Functional requirements of software but
now non functional requirements are increasing their
importance towards software architecture. To avoid the
confusion, one of the goals of this research is to reveal the
importance of quality requirements in software architecture
and to ensure they are always taken into account during a
design.
A software system consists of different quality
characteristics. The quality of these software systems
characteristics is a quality attribute. A quality attribute is
“a characteristic of software, or a generic term applying to
quality factors,quality subfactors, or metric values” [5].
The quality attributes exhibits any one of the three kinds of
impacts like passive impact, positive impact, negative
impact each other. By considering the previous authors
reviews we have a diagram explaining about quality
attribute impact and relationships.
Relations between Quality Attribute impact and relationships
[McCall 1994][2]
4. Trade off analysis
It is a design analysis process framed with benefits and
liabilities of quality requirements in architectural design. It
will be beneficial for further analysis of quality
requirements impact on the software system. By
considering above Fig1 it exhibits new conflicts. It should
be performed in the earlier point of specifying SRS and it is
a good approach of balancing quality requirements.
5. Software architecture Patterns
In order to balance the fulfillment of requirements software
architect would be supported by the predefined problems
solutions and the previous experience to handle the
situation. Patterns are best suitable tool for designing
software architecture. It appears as documentation consists
of recurring design problems with the particular solution.
Due to predefined documentation of solutions to the
recurring problems it supports the development and
maintainability of large software architecture systems.
Previous experiences concluded patterns into different
types of categories and these helps to address development
quality requirements.
.
6. Research Gap
The main problem domain of this paper is the fulfillment of
quality requirements in software architecture at high
abstraction level. According to [4] abstraction manages
complexity and many of the details needed are abstracted
and encapsulated during software architecture. To evaluate
this domain author focused on the related researches
through literature survey. Buschmann et al. [8]. Categorized
eight architectural patterns to provide guidance and support
for the architect designers. There is a gap in this research
like it is difficult to identify the suitable pattern to
implement for solving problems..
7. Related Research work
In order to research on this topic, author made a literature
survey and found various research articles related to this
domain. Previous authors proposed different methods to
address quality requirements in software architecture.
Xavier French et.al. [3] proposed an approach to put non-
functional requirements in software architecture. They
proposed a notation to describe non-functionality in a
systematic manner, and used it to analyze two particular
aspects of the meeting scheduler case study, user interaction
and performance.
8. Research Questions
1. How to enhance the way of handling quality
requirements in software architecture?
2. How to choose an architectural pattern which suits
best for the given quality requirements?
9. Research Approach
In order to perform further research we would use rules described
in [8]. Here case study is performed on user interaction and
performance to address non-functional requirements in software
architecture. To accomplish this author uses mixed method of
study where an empirical approach with systematic result is
obtained. We use risk analysis to validate our results.
The research question RQ1 can be answered by conducting an
qualitative methodology of extensive literature survey performed
on all the related articles and books collected by the author. This
extracts the knowledge of proposing a enhanced way to handling
quality requirements. The solution of this question classifies
qualitative factors. As author proposed literature survey in related
research work and further information regarding problem would
become a solution of this research question.
The second research question RQ2 is prepared by a design
support method questionnaire is prepared quantitatively. The
designed questionnaire consists of different parts. Initial part is
prepared by the questionnaire technique to encourage and make
people for participation. Next part consists of introduction of
participants to analyze their experience in software architecture
regarding quality requirements. Further parts consist of few
necessary sub questions about choosing an architectural pattern to
consider on given quality requirements. The architects experience
helps them to fill the questionnaire completely. By following the
questionnaire expected solution can be identified.
10. Goal
This paper mainly focuses on the fulfillment of quality
requirements in software architecture with the help of various
literature surveys. Author proposed a method of case study on
user interaction and performance to address non-functional
requirements in software architecture. The design support method
questionnaire is prepared with different parts and takes the
guidance support of architects for further research.
11. RISKS
We will do risk analysis and will identify various threats to
validity. We will take counter measures for the identified
risks and will validate our results. In the selection of
participants for quality requirements is a fundamental threat
because the feedback received from different users depends
on their expertise in the concerned field of study. We focus
on the importance of software architecture evaluation as a
method of identifying potential risks and verifying that the
quality requirements have been addressed during the
design. It was expected to produce similar results. To
overcome this threat the selection process of guidance from
well experienced software architects and developers has
been taken.
12. REFERENCES
[1] B. Boehm, H. In, “Identifying Quality Requirement
Conflicts”, in IEEE Software 13(2):25-36, 1996.
[2]Bass, L, clements, P,& Kazman,R.Software Architecture
in practice. Reading, MA: Addison-Wesley Longman,1998.
[3]Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad,
M. Stal, Pattern-Oriented Software Architecture. A System
of Patterns, John Wiley and Sons, 1996.
[4]Hofmiester c.et.al, “Applied software architecture”,
From a book.
[5]Institute of Electrical and Electronics Engineers, IEEE
Standard 1061-1998:A Standard for a Software Quality
Metrics Methodology, New York, 1998.
[6]Svanbherg, M. In, “Quality Aspects of Software
Systems”, From lecture notes.
[7]Sommerville, I.,Kotonya G., Requirements Engineering:
Processes and Techniques, John Wiley and Sons, 1998.
[8]Sorensen, C. “This is Not an Article, just some thoughts
on how to write one”, 17th Information systems Research
seminar In Scandinavian at Syöte Conference Centre,
Finland, August 6–9, Syöte, Finland, ed. Penti Kerola, Antti
Juustila, and Janne Järvinen. Oulu University, vol. I, pp. 46-
59.