Integration of Software Architecture in Requirements Elicitation for Rapid Software Development

Software Architecture describes system components and their connections. Requirement elicitation catering the perspective of software architecture is quite challenging and relatively less explored research area for the rapid software development. It has gain growing interest due to reusability of existing modules with less cost and quick developmental time. Software architecture in the context of requirement engineering is an abstraction of software system performing a particular task with the help of group of executable architectural components. In this paper, systematic literature review is adapted as a methodology to explore software architectural elements that provides better performance and simplicity in requirement engineering. We analyzed, reviewed and listed the strategies, tools & techniques along with state-of-the-art mechanisms, pros and cons and application areas. Architectural components that are already implemented in the requirement elicitation process for effective software architectural design are briefly analyzed. Purpose of the paper is to explore and discuss the elements that make software architecture more integral and flexible for traceability of requirements. Another purpose is to identify relation between the software requirements and architecture along with exploring the components to bridge gap between requirements and architecture by critically evaluating industrially and academically proposed methods, tools and frameworks. We also highlighted the open research challenges of Software architecture in requirement elicitation for better software development. In the later section, a resource bank is created acting as a valuable model that encompasses targeted relevant groups, sub-groups with latest software architecture tools & techniques, methods and framework sources to facilitate effective requirement engineering.


I. INTRODUCTION
Software requirements outline the purpose of the development and design. It serves as the foundation of software intended to develop [1]. Requirements are defined in the beginning and act as a developmental milestones to accomplish successful executable software components [2]. Software requirement engineering is a systematic approach that is significantly developed in the course of the most recent decade [3] [4] [5]. Software architecture can be viewed as an organization of a system that comprehensively includes components interactions, operational environments, design principles, software functionalities, and often covers future evolutionary software perspective [6] [7] [8] [9].
Software architecture differs from software design. Software architecture specifically targets structure of a system while software design merely deals with implementation details of the system (e.g. code level design) [10]. On the other hand, software architecture and design are different from software system architecture as it deals with the placements of software components [11]. Contrary to these three terms, "Architecture Centric Requirement Elicitation" (ACRE) covers architectural perspective of softwareintensive components based on requirement engineering processes, practices, modelling, and designing in order to automate the requirement elicitation process [12].
We have considered "Architecture Centric Requirement Elicitation" (ACRE) as a central point of discussion in order to categorically analyse and critically investigate its impression on requirements engineering process for rapid software development. ACRE can be considered as a broader term that establishes the convenient path to bridge architectural constraints with requirement engineering or requirement elicitation more precisely [13]. In simpler context, ACRE ensures and maintains the balance between software architecture and requirement elicitation operations and functionalities to facilitate rapid software development [14]. It additionally reviews the connections among different software components established during requirement elicitation processes.
Difference among software design, software architecture, software requirements engineering and ACRE is illustrated with detailed process flow in Figure 1. Requirements are subjected to prompt the architecture and facilitate the process of elicitation within scope, structure and context [15]. Accomplishing requirement specification from architectural models can give the requirements engineers a head start even before utilizing customary methods like workshops and situation based elicitation [16]. ACRE can be time and cost effective with better and quick software developmental cycles. It can precisely provide smooth and progressive flow of events with better accountability and traceability factors [17] [18].
In the light of the existing state of requirement engineering technicalities, the goal of this Systematic Literature Review (SLR) is to distinguish the most recent researches where ACRE approach has been utilized for the advancement of software development. The distinguished researches are grouped according to our research questions defined below; RQ1: How software architecture and requirements elicitation are connected to each other? What are their state-of-the-art tools & techniques, pros and cons, operational applicability, current challenges and domain analysis? RQ2: Is it possible to accommodate requirements in software architecture based on recent and latest software architecture frameworks, tools and techniques? RQ3: What are research, industrial and academic gaps between software architecture and requirements based on current architectural trends and adopted measures for rapid software development? RQ4: How to bridge the research gaps using Architecture Centric Requirement Elicitation approach for critically analyzing the balance between software architecture and requirement elicitation operations and functionalities? RQ5: Interpreting the requirement elicitation processes in the context of their tools, techniques and relativity with architecture centric approaches.
The above mentioned Research Questions (RQs) are discussed in detail in the later sections of the paper where primary research contributions of this SLR are as follows; 1) A Systematic Literature Review (SLR) is performed for thorough and in-depth examination of the recent schemes, tools and platforms application on software requirement, software architecture and architecture centric requirement elicitation. We have identify various gaps for further research in this area. 2) We highlighted 60+ useful tools, schemes and patterns to justify proposed research questions. Relevant categorical analysis, preferable application environment, constraints, strengths and weaknesses to better guide researchers about industry practices, academic lapses and loopholes among components/modules of rapid software developments are highlighted.
3) A comprehensive Dendrogram is designed to underline research gaps and challenges for architecture centric requirements elicitation with appropriate discussion in order to grasp attention of researchers for real-time hindrances. Therefore, this opens the way of further investigations to resolve the identified problems. 4) Above mentioned RQs served as a motivation for this research in investigating the architectural concerns of requirement engineering for rapid value-oriented software development. A considerable gap between requirement engineering, software design and architecture is reduced keeping in view of the architecture of the system.  Taxonomical Resource Bank is featured to  group together recent and peer-reviewed valuable sources  under proposed RQs with the classification of Groups, Sub-Groups and Functionalities to delve deeper. This resource  bank is an efficient yet quick model to reach targeted category of concern under scope of study while saving time and eradicating the need of extensive resource engines surfing. 6) To the best of our knowledge, this is the first preliminary study that collectively investigate software design, software architecture, software requirement engineering and software requirement elicitation and architecturally centric requirement elicitation all together. Secondly, this is first perspective cohort study presenting association and interconnections among above mentioned fields through relevant tools, techniques and frameworks summative evaluation contemporaneously.
Rest of the paper is organized as: Section II discusses the research methodology for SLR where each sub task is also explored. Section III gives answer to RQ1, Section IV and V to RQ2 and RQ3 with detailed Dendrogram, Section VI covers RQ4 and Section VII analytically discusses RQ5 with detailed categorical Table of relevant tools and techniques followed by a resource bank model. Each section is supported through various sub-headings and tables. Section VIII concludes the paper and Section IX discovers the possible future work.

II. RESEARCH METHODOLOGY
We adopted the research method proposed by Petersen et al. [19] and used the suggested template for describing SLR approach. SLR is defined as a type of reviewing technique that facilitates repeatable analytical methods in order to critically appraise research in order to answer set of clearly formulated questions [20].

A. REVIEW PROTOCOL DEVELOPMENT
We have developed a review research protocol by following the standards of SLR proposed in [19]. As per the standards of the review protocol, the search process is comprised of the following stages: 1) Development of Review Protocol, 2) Criteria for Selection and Rejection 3) Search Strategy, and 4) Data Extraction and Synthesis. The base questions have already been defined in the Introduction section. The remaining content is defined in the sub-sequent sections.

B. SELECTION AND REJECTION CRITERIA
A specific selection and rejection criterion is defined for the research process. This criteria in different categories is described as follows; 1) Subject Relevance: The research papers that are relevant to the subject are selected for the proposed study of interest.
2) Latest Schemes: The research papers carrying the tools and techniques from 2009 till today are only included to satisfy recent area of study.

3) Publishers:
The publishers of the referenced/ used papers are IEEE, ELSEVIER, SPRINGER, ACM and Taylor & Francis (peer-reviewed journals). No other papers from different engines are considered for highlighting Tools, schemes and patterns.

4) Crucial Effects:
The selected papers must have the positive effect on the area of research and study. The papers selected for the topic ACRE must be affecting it productively. Papers that are not affecting the study are excluded.

5) Result Oriented:
The selected papers should have properly concluded results via case studies so that those results would help in concluding better results. 6) Repetition: All the papers having the similar content, is not included in order to avoid time wastage and knowledge replication. 7) Inclusion and exclusion criteria: are applied in order to find relevance among selected articles and ACRE. This process is completed by considering the title relevance filter and abstract study of the selected papers. We have considered various query strings, i.e. "Architecture centric requirements", "tools for architectural requirements", "requirements impact on architecture", "requirement gathering tools", "requirements related to architecture", "architecture and requirement specs", architecture and requirement relatedness", "architecture Significant requirements". All other papers that were found mismatched as a result of the query words are excluded. AND/OR operations are applied to keywords. AND/J is for AND/Journal. Detailed summary is given in Table 1 that describes the total count in response to query words.   1  Architecture centric requirements  366  OR  77  OR  274  AND  78,655  OR   2  Tools for Architectural Requirements  135  OR  117  OR  438  AND  19,327  OR  3  Requirements impact on architecture  662  OR  525  OR  103  AND  56,524  OR  4  Architecture based requirements  7,785  OR  541  OR  609  AND  108,

C. SEARCH PROCESS
After the selection and rejection process, total of 61 Tools, Techniques, Schemes, and Patterns are selected. Figure 3 illustrates the search process with the number of articles that are rejected on the basis of title, abstract, general study and detailed study. It also presents the number of selected scheme after performing inclusion/exclusion criteria as per specifications of SLR. As shown in Figure 3, IEEE, Elsevier, ACM and Taylor & Francis provided plenty of research material in reference to our query words.

FIGURE 3. Search process based on inclusion-exclusion criteria
Since all research articles could not have reviewed manually, so short-listing is based on title and abstracts. After a short-listing, a detailed study of the paper is done in order to get a detailed analysis for each research question. Summary of each paper was made as per relevance to the questions that helped in compiling the final results. A selected number of papers, i.e. 61 indicate those specific papers that are presenting Tools/Techniques with reference to our research title. However, many other research articles are utilised and used to make our proposed research valuable.

D. DATA EXTRACTION, SYNTHESIS AND QUALITY EVALUATION
As per Table 2, Title, year, concept, publisher, research Problem, proposed solution, contribution, and future works for extracting related schemes with detailed analysis are considered in data extraction, synthesis, and quality evaluation. During data synthesis and quality evaluation following conditions are met: i) identification for architecturecentric techniques, ii) identification of tools for requirements and architecture mapping, iii) identifying research gaps, iv) identifying research trends related to requirement gathering.

FIGURE 4. Evaluation criterion of the quality of selected studies
Evaluation criterion of the quality of selected studies is given in Figure 4. Selected studies are identified, interpreted and than evaluated based on degree of relevance to draw suitable data. Outer loops complete performance analysis. Another inner loop evaluates research questions being answered in a selected studies based on adapted methodology's strengths and data contribution to desired context in order to ensure quality of selected studies. This section covers relevance of software architecture and requirements elicitation on the basis of various state-of-theart tools & techniques, their pros and cons, operational applicability, future setbacks and domain challenges as follows.

A. ARCHITECTURE TYPES & SIGNIFICANCE
Service-Oriented Architecture (SOA) is defined as a model with organized capabilities that can be used for providing solutions for defined domain of interest [21]. It is partially related to information system architecture [22]. Through SOA, knowledge sharing and information reusing, the relationship among requirements and architecture can be visualised conveniently [23]. SOA is achieved through consistent R&D (Research and development). R&D provides a better model-based platform for defining a relationship between architecture and requirements. WSDL (Web Description Services Language) is used for web-based requirements [24].
Knowledge-Sharing Architecture (KSA) complements relationship among strategies, results and theoretical and empirical contributions to deduce the better working collaboration of knowledge and design architecture [25]. KSA digs down deeper to provide better affiliation between requirements, design and architectural connections [26]. KSA's strategic efforts helps to attain underlying objectives driven by qualitative and quantitative measures. Requirements elicitation on the basis of both theoretical and empirical facilitates inter-components/modules relationship formation with testable and uncovered association. KSA help in learning about alliance environment. On the other hand, SOA application is better operational at abstract level. It helps in shedding light on practical aspects requirements, specification, requirement validation and requirement management [27].

B. IMPACT OF REQUIREMENTS DESIGN ON SOFTWARE ARCHITECTURE
Diversity poses great challenge to software requirement engineers in identifying actual interaction of each segments, suitable elicitation techniques and RE process capable of handling complexities of software architecture [28]. Requirements design influences directly in terms of meeting necessary conditions of project success [29]. The high interrelation between requirements design and software architecture for software artefacts reduces complexity in system design and leads to subjective decisions judgment. Controlled architecture intervention not only facilitates better adaptability, but also guides in smooth requirements elicitation phases.
Tools and technological software modules that are product of requirements designed from systematic software architecture demonstrates feasibility, better lifecycle and less developmental time [30]. Methods and approaches of architecture-centric design are targeted through New Product Development (NPD). It emphasises client-services centred architecture through component and testing based repetitive interpretative cycles [31].
High-level knowledge gained through architecture centered system designs establishes testable software components comprised of plug and play principle. Moreover, this factor also encourages reusability element for related state of software events and components. These are mostly repetitive cycles that holds traceable bonding among architecture and requirements [32]. Less repetition and iterative approaches are best suited for defining architecture and requirements where complexity of system is declared average overall [33].

C. ARCHITECTURAL MODELLING WITH BUSINESS GOALS & TOGAF
Architecture modelling stands for reusable generic framework for generating executable software platforms in the context of background, specification, and classification demands for accomplishing specified business goal [34]. A very desirable factor in business goals especially in software market place is the ability of designed components to be applicable (good fit) for future business projects (clients). This factor is wellachievable through software architectural integration [28]. In the context of software architecture modelling, a series of models can be established based on categories of enterprise domain that may come handy for future developments thus reducing time, complexity, and resource allocation [35].
Explicit modelling of abstract requirements makes bridging of requirements components positioned rightly [22]. These requirements elaborate on association with architecture. Enterprise architecture rebuilds the modelling technique on the basis of business, application and technology layers [36]. The Open Group Architecture Framework (TOGAF's) is a proactive best practicing framework in developing enterprise architecture for any organization [37]. Architecture Development Method (ADM) is requirements centric management applied to enterprise architecture for multi-stage cycles [31]. ADM defines architecture and requirements relativity during architecture construction and modelling while giving practical benefits [38] [39].

D. SIMILARITY COMPUTATIONS AND ARCHITECTURAL INTEGRATION
Content Based Requirements (CBR) are based on similar requirements that can be used as proxies to retrieve similar software [40]. However, when a new contextual requirement is proposed by a stakeholder, CBR gets exploited in terms of previous affiliations [41]. This factor can be fixed through integrating requirements similarity, software similarity, and software architectural components. These three components are collectively called as similarity computation [42]. This similarity computation not only triggers three-tier application process verification to apply CBR but also integrates tracing and categorization.
Universal and Inclusive design (UID) uses a design approach for including and excluding requirements in locating appropriate/inappropriate designs for the user-centred process [43]. Good requirement design enables better help in communication design for the requirement elicitation process in design management [32]. During UID, two clusters of requirements are generated, i.e. user-centred requirements and process-centred requirements. These requirements are then utilised for establishing requirements and architecture connections together.

E. MULTI-MODEL SOFTWARE ARCHITECTURE APPROACH
Multi-model is an ability of architecture to accommodate multi-perspective (platforms) to assure expected results. However, multi-model catering multi-dimensions are tedious to deign, maintain, and incorporate. Their complex nature holds great potential in assisting gross level software development.
Physical, virtual prototyping, targeted requirement models, design models, visual flow models, specifications, integration of architecture, multi-model requirements and architecture bridging all are the factors that are considered to design it [44] [32]. Designing process seems to be complex, but once generated can do wonders in term if it's greater flexibility and multi-information fusion [45]. This concept is newer in rapid software development and holds great potential for further advancement to join architecture and requirements relativity [46] [47] [44] [48] [49].
CAD tool allows the incorporation of multi-exchange models for architecturally defined requirements. Static translation and dynamic integration requires domain analysis for requirement elicitation and optimisation [33]. Different levels of details and integration illustrate the multi-exchange method by the degree of concurrence [23]. The degree of concurrence further defines specialised tasks to effectively elaborate requirement construction along with analysis and designing of requirement specifying process [22].
CAD tools are efficient in creating 3D visualisation of requirements and architecture relatedness. Simulation tools unlock various deadlocks for user-centred simulation [47]. Capability loss simulation and simulation tool kit are specific in re-defining and improvising conceptual approach that is given as empathic model [22]. Stimulation is the user-centred design tool for architecturally significant requirements to make end-user requirements involvement possible to bridge and design requirements. The simulation tools enable requirements based on capability-centred product interaction to illustrate aarchitecture and requirements relatedness [50].

IV. ACCOMMODATING REQUIREMENTS INTO SOFTWARE ARCHITECTURE (RQ2)
This Section verifies the possibility of accommodating requirements in architecture with discussion on application and operational extent, traceability elements and characteristics of rapid software development integrating architectural perspective. This sections also discusses the limitations of ACRs and factors to overcome it to avoid future obstacles.

A. Characterization of Architecturally Significant Requirements
Characterisation of architecturally significant requirements has a great impact on the rapid software development lifecycle. Integration of architecture requirements is accomplished through identifying requirements based on their impact and critical factor [51]. Architecturally significant requirements are also identified on the basis of quality attributes, constraints, or application environment. Mapping of requirements in software design is attained through maintaining consistency between architecture and requirements. Architecture based requirements are written systematically in a document illustrating the requirements in the form of different architectural views to make it worth considering for future references.
The requirements and concerns of different stakeholders are captured in the 4+1 view model of architecture [52]. The stakeholders whose requirements are captured in the views could be architects, project managers, system engineers, developers etc. Tools and techniques available identify requirements that have an impact on the architecture automatically. They also classify requirements and recommend alternative solutions to adjust requirements in the architecture in the best possible way. The proposed architecture evaluation and application check is based on the Architecture Trade-off Analysis Method (ATAM). ATAM is scenario based technique that covers in-depth quality attributes analysis while prioritizing operational and functional workflows [53] [54].

B. APPLICATION AND OPERATIONAL COMPETENCIES
Accommodating requirements into software architecture raises many concerns in terms of applicability and operational competencies [55]. Secondly, how far these tow distinguished fields can manage simultaneously is another potential concern. To address these possibilities, Architecturally Significant Requirements (ASR) came into existence. ASRs are bidirectional operational i.e. requirements to design the architecture and architectural framework with a set of executable skills for practical re-usage.
ASRs are documented using architectural views [56]. Architectural views act as a tool that helps in knowing the decisions and the rationale behind the system's architecture based on the quality of requirements [57]. Initially architectural views are documented throughout the lifecycle of the project, to draw architecturally significant requirements. Different stakeholders have different quality requirements that are scattered in architectural views and covers reusability levels [58].
Requirements that are done through architectural views enhance the quality of software architecture documents with a keen focus on system architects [59]. It also provides two products i.e. operational software and a framework for further use that ultimately saves time, resources energy, and getting into the development loop unnecessarily.

C. TRACEABLE ARCHITECTURAL CONCERNS
Architecture centric requirement models are subjected to train on group of parameters such as performance check, experimental verification, quality validation, explainability and extent of robustness. These all parameters are specifically designed for making traceable factors controlled and recognizable at any stage of rapid software development [60]. However, every software traceability varies as per the stakeholder demands, but the architecture design choices gives the liberty to cater majority of them with various architectural tactics and authentication ratios (also known as end-product correct recognition rate) [61].
Secondly, traceability between design and architectural centric requirements of different stakeholders can be possible through Decision Centric Traceability (DCT) [62]. DCT covers all the important software engineering activities and planned steps while including validation of requirements through architecture as well. Whether functional or nonfunctional, a particular requirement can be addressed through DCT specific layered approach that helps in simplifying the whole process of the software lifecycle [63]. Incorporation of traceable architectural concerns with requirements elicitation adds extra layer of scrutiny to reflect better complexity of typical software artefact traceability.

D. LIMITATIONS OF ARCHITECTURALLY SIGNIFICANT REQUIREMENTS
Despite being into solving many requirement elicitation concerns and setback, architecture centric requirements posses various limitations that sometimes leads to blind end for rapid software development [64]. The factor that are nonaccommodating are discussed in detailed under research gaps and challenges section. However, notifying and analysing requirements that impact the architecture early in the software development life cycle can save a lot of resources [65].
Skills are required by the designer to capture functional requirements for architectural decisions before-hand. Identification and accommodation of functional requirements in the architecture from the requirement document can be automated through many tools and techniques to avoid blind ends. Thus making this issue easily sorted out through technical expertise. For example, to eradicate these factor, one such tool is ArcheR [66]. This tool predicts non-suitability and inapplicability of various models to save potential setbacks and unexpected results. These kind of tools demands high level expertise with better precision to command better checks [67] [68] [69] [70].

V. GAPS BETWEEN SOFTWARE ARCHITECTURE AND REQUIREMENTS (RQ3)
Requirement engineering, software architecture, and software design are three different processes of the Software Development Life Cycle (SDLC). Conventionally, requirements are gathered in the early phase, while software architecture is considered in the later phases of development.
Although these processes are connected to each other, still certain gaps and lapses exist between them. This Section explores an abstract view of research, industrial and academic gaps between software architecture, design and requirements based on current architectural trends and adopted measures for software development gaps that exist between software architecture and requirements.

A. IDENTIFICATION OF RESEARCH GAPS
Identification of research gaps are tedious and intricate step when it comes to software requirements elicitation and software architecture. Whenever a problem arises, it is catered and fixed through possible solution to meet deadlines and develop software timely [71]. However, to mark an unusual activity as research entity/research gap is rarely done that leaves the situation same and problematic for future handling [72] [73]. Lack of research and open ended statements databases in a given software production houses makes things out of sight for prolonged period and sometimes not even considered as research gap. Figure 5, illustrates in-depth view of research gaps and challenges. Ability to solve a problem and ability to locate a problem that needs out of the box context to resolve are two different things. Requirement engineering and software architecture are fundamental to each other for the success of a software artefact. Identification of research gaps is vital in identifying and establishing traceability between functional and architectural requirements [74].
Research gaps mainly exist between functional and architectural requirements linkages [75]. Secondly, the vague connections between problem and solution domain are critical because software architecture is a fundamental part of a software solution. To overcome research gaps, a better strategy is to treat both requirements and architecture at the simultaneously.
Conventionally and in legacy systems, Software requirement, software design and software architecture are supposed to be treated differently. Separating these domains proves to be problematic because of unanimously bringing hurdles that other domain overtakes. Working on these domains side by side facilitates a smoother process for research gaps identification [65] [76].

B. ADDRESSING QUALITY REQUIREMENTS
Quality of a software product is an intransigence factor. For executable software components, quality comes first and foremost. Addressing quality requirements has always been a challenge for the requirement engineering process and software designing phase [77]. To focus functional requirements of the system, a better designing approach integrating architectural perspective is required along with suitable skills, tools, and techniques.
Quality attributes are the backbone for the success of the software artefacts. Traditionally, quality attributes like usability, reliability and other quality requirements are considered later stages of development that itself leads to late identification of flaws [78]. Therefore, software architecture is considered as favourable choice as it focuses on nonfunctional quality attributes along with functional requirements to make things smoother [78].

C. IDENTIFYING ARCHITECTURALLY SIGNIFICANT REQUIREMENTS
Architecturally Significant Requirements (ASRs) are requirements that determine the shape of the software architecture and help in taking important decisions [79]. ASRs are bidirectional operational (software architecture  software design) requirements to design the software architecture and documented using architectural views [80]. The identification of these requirements is a major challenge for software requirement engineers.
During the elicitation, stakeholders and requirement engineers lack the ability of identifying these requirements at first place. Lack of ability covers factors like poor domain knowledge, lack of skill expertise and sometimes software automation tools ignorance [81]. Furthermore, lack of proper evidence (non-traceability) for identifying and characterising these requirements results in improper design and poorly designed architecture of the system [79].

D. FRAMING BUSINESS REQUIREMENTS TO BUSINESS MODELLING
Modelling a business-oriented system is already a challenging task in reference to software architecture [82]. Few business processes cannot be modelled by using traditional software architecture frameworks and semantics [3] [83]. Advanced studies and methodologies are required for framing businessoriented requirements combined with process modelling [84].
Business requirements are difficult due to different global priorities, varying cultural norms, changed business strategies (region, sector, and domain) and profit expectations [85]. Business factors are never globally alike that makes them difficult to synchronize at single platform to avail standard services [86] [87]. Framing business requirements to business modelling gives promising research platforms to researchers to explore and contribute in the area of study.

E. TRADE-OFFS CONSIDERATION
According to IIIE (Industrial Information Integration Engineering) [88], certain trade-offs are required at the design level for mapping requirements to architecture, but most people lack knowledge of trade-offs that are essential for this purpose [89] [90]. Trade-offs can be defined as an compromise occurred between two desirable, but incompatible features. In requirement elicitation and software design, objected and relevant tradeoffs are required to avoid unforeseeable situation [91].
In software design, correctness of system behavior while keeping appropriate balance among various quality features is challenging task to accomplish [92] [93]. Software systems with higher uncertainty levels and environment is even more complex feature. Design principles and existing tools and techniques are still limited because they don not comply and link with design decision for quality requirements satisfaction.
Moreover, amount of information utilized by a humandesigner is also limited and thus difficult to differentiate actual and right needed solution out of human knowledge pool. A computational tool or scheme to assist in tradeoffs management can bring ease to the process. Secondly, enabling the discussion platforms to design, select, and deselect tradeoffs among specified software development teams can temporary contribute to facilitate comprehension of tradeoffs [90] [94].
The requirement engineering process has two key subprocesses: i) Requirement elicitation and development ii) Requirement management [89]. Trade-offs that requires traceability poses difficult situation [95] [89]. Since new requirements are continuously introduced, trade-offs traceability is difficult, along with mapping of requirements to architecture produces a major challenge [95].

VI. BRIDGING THE RESEARCH GAP USING ACRE (RQ4)
In this Section, different approaches regarding architecturecentric requirements are written and explained that is helpful in answering how we can bridge the architecture and requirements gap. Proposed frameworks for improving the requirement and architecture in software engineering are also discussed. Mapping requirements to architecture pros and cons along with state-of-the-art suggestions are part of this section.

A. BRIDGING REQUIREMENT ELICITATION AND SOFTWARE ARCHITECTURE
Complex and software intensive systems with high operational demands for environment and continuous availability are critical concern to bridge for requirement elicitation along with software architecture simultaneously. It is not always possible to link perfectly both areas for research and practice [96]. Bridging requirements into software architecture demands perfect alignment of steps and application procedures. Both process can be expected executable simultaneously to address sustainability and traceability for better framework and pattern. Bridging both approaches and principal aim to provide foundation and roadmap of intermediate themes and embedded conceptual construct with reusable properties [97].
Bridging requirement elicitation and software architecture emerging, clear and systematic design approaches that gives rise to high-quality, sustainable, maintained and estimated framework for better and rapid software development [98]. In developing software systems, understand-ability and acknowledgement of requirements and architecture is a prominent factor. To attain this factor, traceability between requirements artefacts and software artefacts needs to be monitored through well-designed techniques. There are various techniques available that are working on the classification of requirements into functional problems and architectural problems with the help of knowledge assisted approaches. One such technique is the Twin Peaks model [99] [100] [101]. Twin Peaks model is based on the classification of architecture into sub-contexts in order to bridge requirements and architecture more precisely [102].

B. BRIDGING PROS AND CONS
In bridging requirements elicitation and architectural research and industrial gaps, there are plenty of problems encountered by application and operational techniques [103]. There are always some good factors and some drawback associated with integrating requirements and architecture. In a generic adaptability approach, good factors are considered with prime importance and valued more then cons while deciding right approach to use [104]. In requirement engineering phases, there is nothing such as either a right choice or a wrong choice.
In integrating two different processes together to have better results, approaches are decided based on lesser odds factor associated with adapting any approach.
While bridging pros and cons, the factors of right and wrong (but fixable) factors are mostly needed and expected [105]. The controlled situation even if with odd (but controllable) factors makes bridging suitable. To retain few odds factor along with positive components are somehow sign of a good choices. This is due to the reason unnecessary connections among requirement and architecture viewpoints may arises in the bridging process while looking for a perfect fit. These unnecessary connections not only make the system complex but also makes hidden sub-links [106].
Sub-links are difficult to eradicate due to high dependency, hidden nature, and interchangeable information during various steps. These sub-links can even cause failures in highlevel systems domains and still remain unrecognizable. Bridging requirements and architecture requires high-level expertise knowledge that is sometimes impossible to identify in the early stages of software development [107]. This factor makes these bridging techniques less applicable to apply for software systems. In other words, less expertise makes easy solution hard to implement [2]. A proper domain knowledge is needed the most for robust, testable, and traceable bridging.

C. SYNCHRONIZATION OF EXPECTED SYSTEM BEHAVIOUR
"What may comes next" is challenging yet success determining factor to keep track of right moves [108]. Anything that occurs unexpectedly raises many concerns i.e. failure in desired performance, ripple effects, inconsistent operations and sometimes whole project failure. Synchronization among expected outcomes and actual results of system behaviour is useful factor in bridging requirement elicitation and software architecture [109]. It helps in keeping track and makes factors traceable. Moreover, it also facilitates controlled environment for bridging and guarantees recognition and performance estimation.

D. BRIDGING AND QUALITY PERSPECTIVE
A system architect and requirement engineer uses quality requirements to design the architecture of a system. System's final design is also an essential perspective achieved through expected quality requirements [110]. Architectural frameworks requires expert skill set for practical usage. However, software quality requirements incorporated into software architectural block enables better accuracy, time performance, robustness, and explain-ability for all the executable components under consideration [111]. Considering quality perspective takes less identification and training time that gives rise to better alternate option if software product turns out differently. Due to supreme importance of quality attributes, it is alternatively named as reusable architectural building blocks. Thus, bridging requirements into architecture is seems nearly impossible without quality perspective [112].

VII. ACRE BASED REQUIREMENT ELICITATION PROCESSES AND TOOLS (RQ5)
In this Section, Architecture centric requirement is identified through state-of-the-art tools, techniques, and schemes. There are many tools and techniques for requirements and architecture mapping. During literature evaluation, various tools, methods, processes, and frameworks, along with few languages and techniques are identified.

A. TOOLS AND TECHNIQUES ANALYSIS
In ACRE based tools and techniques, the most effective is ADL along with a set of a defined rule set from PL-Aspectual ACME and PL-AOV graph [113].Architecture Trade-off Analysis Model (ATAM) was developed to identify Architecturally Significant Work Items (ASWI) and different constraints on the current system, and its requirements that are architecturally significant [114]. Integration of LISA in the Eclipse IDE architecture-related activities along with Architecturally Significant Requirements (ASRs) and architecture design decisions (ADDs) are described as part of the architecture model. In other words, the architecture description contains solution structures as well as architectural knowledge that serve as the basis for solution structures. Strategy for Transition between Requirements models and Architectural Models based on Architectural Patterns (STREAM-AP) also has a great impact as it considers the nonfunctional requirements [115]. To make sure that all requirements are completely described by the architecture AADL (Architecture Analysis and Design Language) software architecture based on rules illustrated in Table 6 that shows the collection of schemes that answered RQ 4. It contains different languages, tools and technologies for mapping requirements to architecture. In Table III, there are four major approaches, including PL-Aspectual ACME and PL-AOV graph [113], use case and feature modelling [116], data mining [66] and Backlog modification, respectively. Figure 6 illustrates detailed a quick Model for Taxonomical resources bank starting from the main heading i.e. ACRE followed by relevant groups and sub-groups with suitable resources that provides a relevant bulk of sources under a specified category. Moreover, six frameworks include methods tools and techniques for bridging requirements and architecture cited as [95] [84] [116] [117] [118] [119]. We have identified the four sub-categories as follows; 1) heuristics; 2) exact searching techniques; 3) hybrid methods with the combination of both heuristics and exact searching techniques; 4) new strategy to deal with the problem. After observing the selected studies, heuristics is considered the most frequently used method in solution search for the problems. Due to the complex relationships among requirements, it is costly enough to find the solution that is optimal for requirements as well as for architecture that completely covers those requirements. Therefore, the heuristics is considered more suitable for uncertainty and difficult at the same time to find the best solution. The detailed percentages and their factors are discussed in Figure 8. Certain studies use the hybrid methods, for instance, Durdik et al. [120] used a combination of quality attributes. According to the authors, though not every decision about architecture deduced from architectural solutions that are available and not every requirement is architecture relevant, the semiautomated proposal and integration of solutions can improve overall system quality targeting sustainability, design speed, and assures that the design decisions are validated before implementation. These methods depicted a capability to resolve real selection of requirements and architecture mapping problems. As per our opinion, the combination of new techniques is recommended to improve the performance and find the best solutions. The studies that adopt the exact method has main focus in programming oriented solution, and as far as the category of new methods are new strategy is concerned for problem solving, like STREAM method by Silva, Lucena et al. [115] and its new variations shows the results about the problem type formulation that can be considered in the selection of software requirements, mentioning three types of objectives: studies with solo objective. With multi-objectives and studies that did research with both. The detailed study shows that the solo-objective design is the frequently used to address the problem in software requirement selection till its conversion to architecture.
However, the paper Goknil et al. [121], was published, with the aim of generating as well as validating the traces by the use of relations of requirements or architecture verification the count of papers that are using the multi-objective approach is increasing. Most of the authors think this approach is more operative and nearer to software engineering in real world as compared to solo-objective. The great benefit of this is the opportunity to unite multiple, conflicting objectives, for instance meet approximately all customers' requirements but with minimal total effort in the whole process. Just, exciting applications of multi-objective approach used for, such as, pay attention on several quality attributes, such as reliability, performance and scalability, besides decrease costs and risks via initial evaluation of decision [120].
Watching and dissecting the selected papers during systematic review, ordinarily, when new research is observed, the first plan utilized is the solo-objective and, after a few conclusion and experimentation, the use of multiple objective definitions is utilized, going for more exact subsequent results. In current state, different contending destinations show up in software engineering issues. For example, the reference [122] had to describe the role of requirement change in which they introduced a model using Twin Peaks and instead of verifying the results for their model they used the expert opinion to justify their model which is not sufficient enough. Figure 7 is categorizing Tools based on hybrid (orange), supervised (yellow) and un-supervised (green) methods. Ratio of supervised methods are in majority, un-supervise in the middle while hybrid are in less.
Targeted approach for analyzing architecturally equipped design with respect to design process is crucial factor to determine. Various tools and methods are used for bridging requirements and architecture. Advancements are made for the implications and practical concern regarding methodologies. Although, theoretical concerns are located, but no quantitative analysis is made to have statistical view of purposed and deduced results. The measurable analysis is not only contributory enough to step forward to keep check on correctness of methodologies, but it will also suitable enough for clear acceptance and rejection in opting out best techniques and tools for establishment of architecture centric requirement elicitation.
Critical and lacking aspect of requirement analysis is its inability to produce future targeted tools. There is might be a case where presently conducted studies are not sufficient enough to produce relevant and most accurate methodologies for the architecture centric requirement elicitation. Secondly, requirements are subjected to have huge variance that is sometime difficult to attain desired certainty and output results. It is somehow replicated, duplicated and missed in such a way that is difficult to eradicate out. Targeted tools and techniques for future work is possible when present concerned conditions are declared suitable for the further research applications.

FIGURE 7. Tools, techniques, models, and frameworks categorization
Most of the techniques that are related to architecture centric requirement gathering are methodology centred. These techniques focus on derivation of output rather than functionalities, traceability and adopted approaches. Focus in requirement analysis is subjected for diverseness to seek results excellence in future to have accurately specified methodology. The problem formulation from software requirements is a critical task. Solo-objective design is beneficial in problem formulation and addresses software requirement selection iteratively until its conversion to architecture. However, Goknil et al. [121] targeted the aim of generating and validating traces by the use of relations of requirements or architecture verification through a multi-objective approach. The multi-objective approach is better in operational software engineering in the real world as compared to solo-objective. Moreover, a solution taken from a multi-objective approach gives various possibilities for quality attributes such as reliability, performance and scalability along with reduced cost and risks [120].
A targeted approach for analysing architecturally equipped design with respect to the requirement process is a crucial factor to determine. Various tools and methods are used for bridging requirements and architecture. Advancements are made for the implications and practical concerns regarding methodologies. Although theoretical concerns are located, no quantitative analysis is made to have a statistical view of purposed and deduced results. The measurable analysis is not only contributory enough to step forward to keep a check on the correctness of methodologies, but it is also suitable enough for clear acceptance and rejection in opting out best techniques and tools for the establishment of ACRE.
The critical and lacking aspect of requirement analysis is its inability to produce future targeted tools. It is somehow replicated, duplicated and missed in such a way that is difficult to eradicate out. Targeted tools and techniques for future work is possible when the present concerned conditions are declared suitable for further research applications.
In the light of Figure 8 and Table 3, there are only 5% hybrid tools and techniques that can support architecture centric requirements elicitation. However, tools with single objective holds major percentage ration i.e. 42%. This factor indicates that multi-objectives specification are only 13% catered while covering 5% hybrid approaches. Only 4% recent and modern tools are encountered that are coping up with recent lapses. The overall solution availability percentages are not yet fulfilling and demands researcher interest to meet current needs as referred in Figure 8. Moreover, Single stands for those techniques that are based on one algorithm/method and Multi stands for multiple algorithmic applications in requirement elicitation. The solution deduced from multiobjective approach not a single solution, but a solution set with multiple possibilities and states to be decided by the person who makes the decision. Hybrid stands for complex tools and techniques that are single at a certain point and gets multiobjective when required. Hybrid tools are dire need of the current scenarios and market needs in order to facilitate better. The great benefit of this is the opportunity to unite multiple, conflicting objectives, for instance meet approximately all customers' and requirements engineer needs with minimal total effort in the whole process.  Table III, holds detailed yet targeted aspects of tools and techniques with pros and cons short meaningful description and computation complexity, user-friendliness along with expertise level. User-friendliness determines that whether a tool and technique is easy to adopt by a requirement engineer while interacting with layman clients. Expertise level covers the level of skill set required by a requirement engineer to adapt a method for a specified purpose. Description is given for reasonable short purpose supported by pros and cons. Pros and cons present a clear picture of the advantages of adapting a method and a possible drawback in order to guide requirements engineer better and ahead of time. requirements that is against object oriented approach.
the complexity is approximately o(m). PL-Aspectual ACME [113] Linear An aspect oriented architectural description language, but requires high technical expertise and skill set.
Can be modelled using conventional ADL description.

Medium
No SPL [116] Linear/ logarithmic It is better to cater structured requirements, but can be difficult to handle for other unstructured features.
Linear in case of SPL-queues and SPL-arrays whereas quadratic in case of SPL hash table.

Medium No
Common KAD's [125] High It provides better support for industrial design processes, but lower level of constraints and scope are not a good fit for it.
As it works on peer to peer structure.
High Yes UML Profile for MARTE [126] Medium It is particularly suitable for modelling and analysis for real-time and embedded systems, but being a domain specific makes it usage limited .
Complexity depends on the complexity of the UML model used.

High Yes
Business Process Model [84] Low Its area of expertise is related to business and enterprise, but remains an abstract and depends on intended use only.
Very close to real-world, less technical terms. Include both variability and requirement information. Hence difficult to manage.

High No
Quality-Driven Self-Adaption [127] High It helps in incorporating requirements and architecture level to attain quality rich product, but quality parameter differs globally thus challenging its performance.
Continuous adaption of standards to meet quality.

Low Yes
Behave Tree [128] High Its predicts well the expected output along with actual results, but often leads to false predictions based on data requirements.
The use of natural language and high scalability causes complexity.

High No
ATRIUM [78] Low It works better for business intelligence designing, but does not fit well for lower complexity products.
Covers abstraction levels and functional requirements only.

High Yes
Trace lab [129] High It is integrated software solution for trace forward analysis, but only applicable to larger projects with higher traceability requirements.
Traceability is based on architectural decisions.

High
No It is a method of architecture evaluation, but has limited capacity to evaluate requirements along with it.
High in case of excessive cots usage else, it is low.
Medium No STREAM-AP [115] High Efficiently work to reduce gaps between requirements and architecture, but mainly emphasize on functional requirements.
The process includes refinement of NFR.

High No
Conflict Centric Approach [52] High It is suitable for eradicating conflicts through systematic approach, but uses more time along with other processes.
Conflict handling is a quite challenging task.

Low Yes
Component Model [130] High It works to satisfy mechanism and methods for the composition of components, but mainly emphasize on separation of functionalities.
Trying to bridge the gap between requirements and design.

Low Yes
Practitioner Directed Way [89] Low A customize tool, easily adaptable to users requirements, but raises concerns over precision.
Only considering the qualitative approach and parameters to meet quality requirements. Solution structures but also the architectural knowledge.
High No K-RE [117] Low It helps in breaking down software components interactively, but only fits well to larger software components.
Division of architecture into subcategories.

High No
Simulink and Stateflow [118] High Sequential decision making model, but retains dynamic changes and controls oriented solutions.
Deals with dynamic systems, so the operations are also complex.

Low No
Generation/Validation Of Traces [121] High It automatically traces requirements and architecture components, but only applicable for larger industrial projects.
Deals with complex sets of input, e.g. Trace, architecture and requirement model.

Medium Yes
BitKit [132] Low It is a platform for requirements engineering and capability models, but must be incorporated in early prototyping.
It is a prototyping tool and includes the simple business processes.

High Yes
Decision-Centric Traceability [133] Low All links are traced for architectural models based on platforms and constraints. But, holds stakeholder factor which adds time and cost to bring quality. Set of tools for software developers to build and manage applications development.
Low Yes AADL [128] Linear It is modelling language that supports early and iterative analysis, but preferable for performance critical properties.
Modelling language that facilitates early and iteratively system's architecture relevant to its design and performance.

VIII. CONCLUSION
Concluding all, we have studied about requirements and architecture integration. How they are relevant to each other, and whether is it possible to accommodate requirements with architecture along with research gaps between requirements and architecture and challenges. Considerable amount of tools and techniques are mentioned that can bridge gaps using tools and technologies. Moreover, a detailed comparison of these tools is also provided. This paper is a clear proof that the foundation of a software development process is the identification of the relationship between the software architecture and the requirements since the software architecture's quality is dependent on how well the system design has accommodated the requirements. Modelling of requirements through frameworks can be done among various architectures in order trace requirements in software design. Moreover, tools and techniques (Table III) can help in determining the evolving requirements by considering the software architecture only. Architecture centric requirement gathering approaches are vital in mentioning the importance of requirements traceability in software design. It helps in adjusting requirements in architecture during any time for software life cycle.
The method that has been used to conduct this research is based on the fundamentals of systematic literature review (SLR). In this paper, we grouped already proposed different tools, techniques, frameworks, guidelines and languages to accommodate requirements in architecture. An architect can choose anyone of those based on their requirements and domain. Most appropriate techniques can be chosen with the intention to make them more effective for architectural centric requirement elicitation. By analysing all the papers in this SLR, we have observed that requirements that are gathered keeping in view of the architecture of the system helps in reducing the gap between the field of requirement engineering and software design and architecture. The study conducted has concluded the usefulness and applicability of all the latest tools and techniques through an analysis that can be viewed in the papers referred.

IX. FUTURE WORK
The effort required in this research has demonstrated that there could be many dimensions in which our work can be taken forward. The increase of proposed analysis, tools, and techniques with time can extend our research by giving more valuable insights about the importance of the connection between the requirements and architecture. Which would in turn keep reducing the paradigm shift between the two and it would be worth comparing the architecture with the rest of the software development processes by considering software architecture i.e. pillar of the software system.