Software Architecture and Requirements: A
Systematic Literature Review
Dur-e-Benish Batool1, Yasir Hafeez Molta2, Amber Sarwar3, Mateen Ahmed Abbasi 4, Javeria Jabeen 5
PMAS-Arid Agriculture University,
Rawalpindi, Pakistan
benimalik@rocketmail.com1, Yasir@uaar.edu.pk2, ambersarwar@hotmail.com3,
Mateenabbasi@msn.com4, javeria.jabeen@yahoo.com
Abstract- Research in software architecture (SA)
can be seen in two perspectives: a traditional and
modern one. Software architecture is represented
using graphical diagrams (Models, Frameworks)
of the system, Architecture Description
Languages, Ontology. The main focus of this
paper is to know about the software architecture
and to find out the strength of evidence in
empirical work reported within literature. The
outcome of this systematic literature review will
be useful for researchers and practitioners and
this SLR also includes widely used tools, models,
and techniques used in SA; software architecture
challenges/Issues widely reported; the SA areas
which are under major consideration; the SA
areas that require sufficient attention. In the end
we also provide information model regarding
requirements and architecture, which handles
portability and contextual issues regarding
platform dependency. Main purpose of
information model is to facilitate practitioners
for achieving traceability between requirements
and architecture.
Keywords: Systematic literature review; software
architecture; Ontology; Architecture description
languages.
I. INTRODUCTION
Software architecture is defined as the structure or
blueprints of the system, which is made up of
software components, connectors, and properties of
those components which are extremely visible, and
making relationships among them visible [17][6].
The field of software architecture which is
considered as a subfield of software engineering is
now about two decades old. In recent years, there has
been growing awareness towards the documenting
value of architecture rather than just building
architecture, but also focus on why and how
decisions of architecture are taken [22][6][21].
Architecture of a software system has to ensure that
design is able to support all requirements as well as
able to incorporate any changes requested by
customers and stakeholders. Also incomplete or
inconsistent requirements have been recognized as
the major cause of software errors and failure [19]
[23]. Empirical studies have suggested that to fix
requirements errors early in the development
process is very cost effective [6]. Similarly,
architecture business cycle proposed by Bass et al.
[20] defines different factors which influence
software architecture, i.e. architect’s experience,
stakeholders, developing organization and technical
environment. In contract, application architecture
has considerable effects on the quality factors such
as performance, reliability, maintainability etc. [22].
This paper is planned as follows. Section II gives the
Background and motivation. Section III describe the
research methodology (SLR), Section IV illustrate
conclusion. Finally, we summarize the paper and
discuss the future work.
II. BACKGROUND AND MOTIVATION
This section provides a brief overview of software
requirements and software architecture, which plays
the central role in address software evolution
challenge. It also explains the interplay between
requirements and architecture, their traceability and
synchronization [10]. The IEEE definition of SA is
“The fundamental organization of a system
embodied in its components, their relationships to
each other, and to the environment, and the
principles guiding its design and evolution”. The
purpose of embedding software architectures is as
follows:
1. Blue-print which outlines a design for the
software of a system.
2. Roadmap which allows to plan ahead the
evolution of the software of a system, and
3. Supports a software architect to align the
software with a company’s long-term business
strategy.
4. Communication vehicle which enables
different stakeholders to communicate about
 the major decisions in order to steer and
influence the software of a system.
5. Quality predictor which provides an early
indicator of the quality of a software system.
Software architecture typically plays an important
role and act as a bridge between requirements and
implementation [14] [20]. Vinay Krishna describe
the architecture roles ,configuration of architecture
and also describe the rate of failure of project design
project and also suggests some activities that are
require to be incorporate in the architecture and
design in order to deal with changes in requirements
related to the business and change of technology to
keep away from such failures [19][3]
According to Weihang Wu et al. Architectural
design of the system is very useful and important
activity, but the relation to the requirements is
limited. [23] It is observe that goal orientation is
progressively known process for gathering,
modelling, and specifying and analysing
requirements of the software. But how the goal
models are related to architectural models are not
completely clear yet [15][8]. Architecture
frameworks are the method used in the modelling of
architecture. [4]
There are many other recently used architecture
frameworks Model driven architecture (Daniel
Perovich et al. 2009), service oriented architecture
(Mohammad Hadi Valipour et al. 2009), i* frame
work, Viewpoint-based Test Architecture Design
(Yasuharu NISHI, 2012), STREAM-ADD (Diego
Dermeval et al 2012) extension of STREAM. [6, 14,
24, 7, 1] and lot of issues in area of software
architecture [5, 7]. The field of software architecture
which is considered as a subfield of software
engineering is now about two decades old. During
this period a number of software Architecture
Description Languages (ADLs) emerged and
vanished. But none of the ADLs became much
popular amongst the practitioners except a few, that
too only in a specific domain. Supporting and
understanding the relation between the requirements
and architecture is challenging activity in software
engineering field. [9] Problem is focus on the
distinction between requirement and architecture
can be arbitrary drawn. [20]
Software architecture covers a large, discontinuous
design space. Currently software architects try to
solve the problem manually, which lead to
suboptimal designs and other issues like time
consuming etc. [5]
III. RESERCH METHODOLOGY
This paper describes the SLR for software
architecture in the domain of web applications.
Systematic reviews aim to provide the means for
carrying out literature reviews that are thorough and
unbiased, such that their results are of scientific
value. Initially, SLR is evidence base paradigm.
Many steps were defined according to that view
point. B.Kitchenham customized those steps and
provided guidelines how to use SLR in Software
Engineering .Kitchenham defines SLR as: “A
systematic literature review is a means of
identifying, evaluating and interpreting all available
research relevant to a particular research question, or
topic area, or phenomenon of interest.”
a. Protocol Development
At the start we performed some important activities
defined by the Kitchenham. Research questions
were specified. Search strategy, inclusion/exclusion
criteria, data extraction and data synthesis were
decided. The aim of this review is to answer the
research questions related to our study.
b. Research Question
RQ1. What are the challenges/ issues of software
architecture in web applications?
RQ2. What are the models used for software
architecture?
RQ3. Role of behavioural characteristics of software
architecture in web applications?
RQ4. How we can deal Requirements and
architecture with respect to rapidly changes in web
applications?
c. Search Strategy
We identified Major/Key Term
x Key search terms were derived from research
questions by identifying population,
intervention and comparison
x Synonyms and alternative meanings were found
for key terms; also substitute terms used in
literature were considered.
x Then the Boolean AND was used to connect
two key terms in the search strings and Boolean
OR to allow synonyms and alternatives.
1. Key Terms
Software architecture, Issues, Models, Behavioural
Characteristics, Web applications
 2. Alternative and synonyms e. Exclusion Criteria

(Software Architecture OR SA OR Architecture of x The articles which are not defined as

software OR Architecture, OR Software architecture reliable (such as web pages) will not
models) (Hurdles OR Issues OR barriers OR included
obstacles OR “risk analysis” OR “critical factors OR
Challenges) (Models OR Framework OR Diagram x Those studies were excluded that were
OR Flow of architecture OR Design OR mock-up based on personal expert opinion.
OR Prototype) (Behavioural Characteristics OR
x Literature surveys and books were
Architecture Behaviour OR web application
excluded.
Behaviour).
f. Selecting Primary Sources
3. Integrating Boolean <AND> and <OR>
Initial selection was based on reading the title and
(Software Architecture OR SA OR Architecture of
abstract of the published paper. Only those studies
software OR Architecture, OR Software architecture
were excluded that are not relevant to our research
models) AND (Issues OR barriers OR barrier OR
question. After removing duplicates
obstacles OR “risk analysis” OR “critical factors OR
inclusion/exclusion criteria were applied. Full texts
hurdle).
of those papers were read carefully that were not
(Software Architecture OR SA OR Architecture of clearly disqualified from inclusion/exclusion
software OR Architecture, OR Software architecture criteria.
models) AND (Models OR Framework OR Diagram
g. Quality Assessment
OR Flow of architecture OR Design OR mock-up
OR Prototype) AND (Behavioural Characteristics Our quality checklist is composed of two parts; first
OR Architecture Behaviour OR web application part contains generic quality criteria that are applied
Behaviour). on all empirical studies. Second part is specific for
each study type.
4. Resources to be searched
h. Data Extraction
Following databases were used for search due to
ease of access in our institution and also authorized We have created two forms: one for gathering
by HEC (Higher Education Commission) Pakistan. general information about second is for data
IEEE Explore, ACM Digital Library, Science Direct extraction for synthesis. This from will be used to
and goggle scholar. extract information like study design methodology,
setting of study, focus on software architecture area,
5. Search Constraints and Validation
frameworks and models for software architecture,
Search is applied on entire range of available SA challenges and some more.
published studies related to our research questions
Table 1 RESULTS AGAINST RESEARCH
and we did not put any range restriction on the
search. Total Related Shortliste
d
d. Study selection criteria OR Inclusion
criteria RQ1 239 20 5
x Studies must have been published in peer RQ2 509 123 11
reviewed journals and conference.
RQ3 107 32 5
x Wikipedia material is not allowed to select.
RQ4 145 20 7
x Read the keywords, title and abstract from
the papers found, exclude those which are
not related to the research questions.

x Multiple studies can be reported in one

paper; if any of them did not stand to our
inclusion criteria then only that study was
excluded.
 j. Information Model

Information model will not only help to understand

the whole process from requirements to architecture
but also manage change on system, process and
artefact level. Figure 2 shows the information
model, the model is based on the findings from
literature.

IV. CONCLUSION AND FUTURE WORK

As a result of this SLR we will come to know about

the critical barriers and strength of Software
architecture reported in SA literature and its relation
with the requirements. It also shows the behavioural
characteristics of software architecture in web
Figure 1 FILTRATION STEPS applications. These outputs will be very helpful for
other researchers and practitioners. As software
i. Data synthesis architecture has become very critical field but the
existing SLRs in Software architecture are very
We extract the required data from the studies related
limited and explain the empirical work for some
to our research questions as shown in below table 2.
Specific domain/area. The overall picture is not clear
Table 2 STUDIES AGAINST THE RESEARCH
yet. This step will be very useful for researchers in
RESEARCH REFERENCE knowing the exact empirical work done in areas of
Software architecture and which area is being
QUESTION neglected due to lack of consideration. Web
applications are evolved frequently. The conceptual
RQ1 [R3,R5,R8,R19,R22]
differences are exist between what to do
RQ2 [R1,,R3,R4,R5,R7,R12,R10,R12 (requirements) and how to do it (architecture,
, design, and code) constitutes a gap. This gap has
been often observed and we find that as the
R20,R21,R23, R24,] requirements changed there is need to change
complete architecture because requirements are
RQ3 [R2,R21,R22, R23,]
frozen because almost all existing models are based
RQ4 [R3,R13,R15,R16,R17,R20,R23 on waterfall model. There is a need an architecture
] framework that must be welcome the change, stable,
and adaptable, in the presence of continuously
changing requirements and increases the reusability.

REFERENCES

1. Martens, H. Koziolek, S. Becker, and R.

Reussner, “Automatically improve software
architecture models for performance, reliability,
and cost using evolutionary algorithms,” 2010.

2. Bessam, “Multi-view Meta-modeling of

Software Architecture Behaviour,” 2009.

3. Egyed and M. Del Rey, “Refinement and

Evolution Issues in Bridging Requirements and
Architecture – The CBSP Approach,” 2001.

4. Tang and C. Dsto, “A Comparative Analysis of

Figure 2 Information Model
Architecture Frameworks.”

5. Boehm, “Software Architectures: Critical

Success Factors and Cost Drivers” 2008.
6. Perovich, M. C. Bastarrica, and C. Rojas,
“Model-Driven approach to Software
Architecture design,” May 2009.
7. Dermeval, J. Pimentel, C. Silva, J. Castro, E.
Santos, G. Guedes, M. Lucena, and A.
Finkelstein, “STREAM-ADD - Supporting the
Documentation of Architectural Design
Decisions in an Architecture Derivation
Process,” 2012.
8. Garlan, and, D. Perry “Introduction to the
Special Issue on Software Architecture,” 2009.
20. S. Management, “Weaving Together
Requirements and Architectures,” March, 2001.
21. U. van Heesch, P. Avgeriou, and R. Hilliard, “A
documentation framework for architecture
decisions,” Apr. 2012.
22. V. Krishna, “Software Architecture for Large
Critical Applications,” 2009
23. W. Wu, and T. Kelly “Deriving Safety
Requirements as part of System Architecture
Definition,” 2010.

9. Gorton, I, “Essential software Y. NISHI, “Viewpoint-based Test Architecture

architecture,”2006. Design,” 2012.

10. M. Barnes and D. Garlan, “Challenges in

developing a software architecture evolution
tool as a plug-in,” 2013.

11. R. D. Bastos and J. F. B. Castro, “Integration

between Organizational Requirements and
Architecture,”

12. H. Valipour, B. Amirzafari, K. N. Maleki, and

N. Daneshpour, “A brief survey of software
architecture concepts and service oriented
architecture,” 2009 .

13. M. S, Y. Desphande, S. Hansen, and A. Ginige,

“Web Engineering: A New Discipline for
Development of Web- based Systems,” 2001.

14. Ernst, S. Reges, D. Notkin, R. Mercer, and R.

Boswell, “WEB APP ARCHITECTURES : N-
tier Architectures.”

15. Koch and O. Pastor, “Requirements engineering

for web applications – a comparative study,”
vol. 2, 2004.

16. Bencomo, P. Grace, and P. Sawyer,

“Revisiting the Relationship between Software
Architecture and Requirements : the case of
Dynamically Adaptive Systems.”

17. R. C. de Boer and H. van Vliet, “On the

similarity between requirements and
architecture,” Mar. 2009.

18. R. G. P. IV, “Modeling Behavioural Patterns of

Concurrent Software Architectures Using Petri
Nets,” 2004.

19. S. Anwar, M. Ramzan, A. Rauf, and A. A.

Shahid, “Software Maintenance Prediction
Using Weighted Scenarios: An Architecture
Perspective,” 2010.