8/7/2019 Advance examination proposal

1/3

Addressing Quality requirements in software architectureKiran Moses Katamreddy

19861114-7219

Kika09@student.bth.seRonneby

ABSTRACTThis 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

Putting software architecture in the context ofquality requirements.

Identification and improve the way that qualityrequirements handled in the software architecture.

The quality attributes specified in the requirementspecification and their relationship with quality

requirement is discussed.

Keywords

Quality requirements, Quality attributes, Software

architecture design.

1. BackgroundIn 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

view handles some quality requirements such as

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 todays 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 architectureThere 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

8/7/2019 Advance examination proposal

2/3

externally visible behavior and the relationships among

them [2].

3. Software requirementsSoftware 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 thesoftware 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 qualitycharacteristics. 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 analysisIt 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 softwarearchitect 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 GapThe 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 workIn 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 qualityrequirements in software architecture?

2. How to choose an architectural pattern which suitsbest for the given quality requirements?

9. Research Approach

8/7/2019 Advance examination proposal

3/3

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 performedon 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 toconsider on given quality requirements. The architects experience

helps them to fill the questionnaire completely. By following the

questionnaire expected solution can be identified.

10. GoalThis 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. RISKSWe 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 fromwell experienced software architects and developers has

been taken.

12. REFERENCES[1] B. Boehm, H. In, Identifying Quality RequirementConflicts,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 Syte Conference Centre,

Finland, August 69, Syte, Finland, ed. Penti Kerola, Antti

Juustila, and Janne Jrvinen. Oulu University, vol. I, pp. 46-

59.