Role of Requirement Prioritization Technique to Improve the Quality of Highly-Configurable Systems

Highly-configurable systems are such systems which are not developed for single scenario. However, perhaps they have variable functionality and they are developed for hybrid scenarios. Producing a good highly-configurable system within time and with customer satisfaction is not easy. Handling requirements effectively in such a way that it take least time to market, is one of the most difficult tasks in highly-configurable system. In this paper, a quantitative requirement prioritization technique for highly-configurable systems is proposed. This technique involves all stakeholders and can be used primarily for large scale software projects. The proposed technique is evaluated by taking a case study of the highly-configurable point of sale for automotive industry. The result shows that the proposed technique provides promising results and can be enhanced with more future work.


I. INTRODUCTION
With the advent of technology, nowadays a lot of software systems are highly-configurable. A highly-configurable system keeps unchanged the core functionality of the software and allows the customer to customize the distinct objects of the program [1]. Therefore, it aids the customer with flexibility by providing hundreds and thousands of performance parameters. Furthermore, during the process of development; i.e., maintenance and testing, the system is customized by stakeholders such as; clients, customers, managers or designer to achieve improved functionality or greater performance [2]. Highly-configurable system (HCS) gives typical center usefulness and an arrangement of discretionary highlights to tailor variations of the options as indicated by a given arrangement of prerequisites [3]. The improvement of HCSs give clear advantages to IT businesses, encouraging the outline and execution of various software systems that offer a typical center set of capacities diminishing expenses and time-to-market to organizations. Yet, these frameworks The associate editor coordinating the review of this manuscript and approving it for publication was Aakash Ahmad . likewise exhibit noteworthy difficulties, for example; their approval. The issue of approving a solitary design has been supplanted with considerably more difficult issue of approving the entire arrangement of designs that can be created by the greater part of the unique conceivable blends of features in HCSs [4].
HCSs are software systems which have a set of core functionalities, and some variable functionalities that are based on a set of configuration options. Changes in these aforementioned configuration options will result in a change of the program's behavior [5].
Besides, most of the software systems are not developed for a single scenario or use case; however, they also developed for hybrid scenarios. Therefore, software systems are typically developed as configurable systems. This emergent system not only allows specific variants but also map this variant to the requirements of different application scenarios and use cases. Some elicited capabilities, named as requirements, which formalized in requirement engineering phase are the grounds for the development of a highly-configurable software system.
Though, the Requirements Engineering (RE) is the process that is necessary to develop the services or facilities that VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see http://creativecommons.org/licenses/by/4.0/ are the needs of the customer from the system [6]. These services are inside the pre-defined constraints of functions and development. The quality product is only produced by using the high-quality requirement engineering. In the conventional approach, RE incorporates different phases, like elicitation, analysis, documentation, verification and validation, management and significantly prioritization. It tends to help in selecting the requirements that is most important to the customer at a time. This results in affecting several factors such as, price, economic constraints, accessibility of workforce, logical implementation order, client association and negative impact, etc. [4]. No other activity cripples developed system as compared to the requirement prioritization being wrong. Requirement prioritization (RP) plans system for execution in a request that attempts to increase their effectiveness to meet some performance goals, typically prioritizing the requirements as quickly as time permits. Effective RP techniques play a vital role in successful releases of software systems. Early imperfections in requirements (practical and non-useful) leave genuine operational impacts in the configuration stage. The Goal-based requirements analysis method utilizes objective topography to structure and compose such requirements data as situations, objective hindrances, and limitations.
Additionally, the quality of the HCS can only be attained by connecting the customer feedback in RP phase [4]. With this thought, advancement can be limited to more engaged prioritization consideration by the customer for one's value creation. The furnished solution of the paper declines the gap between RP and customer value creation. Creating Customer Value expands the consumer loyalty and the client experience. Customer value helps in identifying which service or feature is important to the customer rather than focusing on the available possible option. The critical point upon where success can be declared is ''customer''. Therefore, customer value creation tends to be an evolutionary process in which all diverse stakeholders declare a project as a successful project when customer satisfaction is earned [4].
Cost and time reduction to market is empowered by using the HCS architecture. Their architectures are mostly used in developing a complex software system. The software is tested for the assurance of high quality of HCSs [7]. This testing ensures that the specific feature has been tested in every possible configuration. Many test suites are required to ensure the quality assurance of HCSs. It increases the sizeable effort and time for the testing. The quality of HCS focuses on testing phase only and not in requirement prioritization which may effect on cost and resources. Therefore, the right requirement prioritization technique for the HCS is required to save resources and cost. The objectives of current research are: to extract the advanced requirement prioritization techniques, to explore the unique HCSs, to focuses on literature-based systematic mapping of extracted requirement prioritization techniques for HCSs related to software, yielded from the first part, and to propose and evaluate a novice quantitative requirement prioritization technique for HCSs. This paper is structured as follows: section II will discuss the related work. In this section, two states of the art literature reviews are performed along with a systematic mapping. Section III emphasis on the research methodology which proposes a quantitative requirement prioritization technique. Section IV shows the results and Section V will the final section contain the conclusion and future work.

II. RELATED WORK
This section discusses the related work of the research. In the last few years, various studies have been carried out regarding highly configurable systems. Here, we present the studies which focused on implementation, testing, debugging and evolution of HCSs. We also specify how some of these studies achieved software quality in their HCSs. Additionally, we also detail the literature on requirement prioritization to enhance the credibility of our research, and to avoid the mishap of reinventing the wheel. Fig. 1 exhibits the number of studies conducted on requirement prioritization and HCSs from 1990 to 2018. To identify the gaps and gather the relevant information of aforementioned domains, we have performed a systematic literature review. Respective details of these various SLRs are discussed below.
The details of the SLR are as follows: The methodology of this research is four-folds: the first two parts emphasizes to explore the state-of-the-art requirement prioritization techniques and state-of-the-art HCSs, independently. The third part focuses on literature based systematic mapping of extracted requirement prioritization. The final part focuses to propose and evaluate a novice requirement prioritization technique for HCSs.

B. SYSTEMATIC LITERATURE REVIEW
The current section follows the guidelines of Barbara Ann Kitchenham to perform two different systematic literature reviews (SLR) using a protocol. The SLR explores a partic- ular area for the identification, analyzation and exploration of the information. Following is the research protocol for the identification and examination of highly configuration systems and requirement prioritization techniques, separately. SLR is a literature-based study that considers inclusion and exclusion criteria for the exploration of particular information. It comprises of three broad phases, i.e., plan, conduct, and report. The steps under these categories are assented in Table 1.

C. PLANNING 1) RESEARCH QUESTIONS
In order to achieve the initial objective of the study, following research questions are focused. RQ1: What are the state-of-the-art highly-configurable systems exist in the literature? RQ2: What are the state-of-the-art requirement prioritization techniques exist in the literature? RQ3: What are the requirement prioritization techniques most suitable for highly-configurable systems?

2) DATA SOURCE
The search for this research was a manual and only conference and journal articles are focused, therefore, we have selected the most common and influential databases were selected based on the previous experience.
Following points are considered when selecting and finalizing the studies.
• The language of the article is considered English only. • The publication is a must for each article. • Only conference, journal and/or a workshop is considered.
• We selected articles related directly to our research questions.
• There should be a/n technique/approach/method/system proposed in the article.

4) EXCLUSION CRITERIA
Following points are considered when rejecting and scrutinizing the studies.
• The language of the article other than English is not considered.
• The articles that do not discuss any technique/approach/ method/system are not considered.
• Web pages, blogs, and Wikipedia articles are not the part of current research.
• The unpublished articles are also excluded.
• All those articles that discuss only the domain, however, not the technique/approach/method/system are also excluded.

5) SEARCH STRING
The search string is formulated by considering the keywords selected form research question which gets updated during the searching of relevant studies the literature. Such search strings were injected into five most common databases. Sometimes we have grouped one or more keyword by quotes, commas and parenthesis. Whenever, we changed the string the result was different. The keywords of the search strings we have used are as under: Highly-configurable system, customizable systems, reconfigurable system, /'' OR ''limitations/'' OR ''shortcomings/'' OR ''practice/''. Requirement * prioritization technique, Requirement * prioritization categories, prioritization taxonomies, prioritization classifications, prioritization processes, prioritization method, prioritization practices.

D. CONDUCT 1) PRELIMINARY STUDY
The research papers selected during the preliminary study were refined using a tollgate approach. Following are the phases of the tollgate approach.
Phase 1: Searching for the relevant article. Phase 2: Title based inclusion and exclusion. Phase 3: Abstract and introduction-based inclusion and exclusion.
Phase 4: Full text-based inclusion and exclusion. Phase 5: Remaining articles were included in the final SLR.

2) DATA ANALYSIS
A number of requirement prioritization techniques and number of HCSs were extracted from the selected papers using the aforementioned approach. The research questions were also evaluated using the data extracted from the literature. A snapshot of article searching and selection data is shown in Table 2. VOLUME 8, 2020

3) DATA EXTRACTION
The data extraction and related details are as follows:

a: HIGHLY-CONFIGURABLE SYSTEMS
Highly-configurable systems are software systems which have a set of core functionalities and some variable functionality that are based on a set of configuration options. Changes in these aforesaid configuration options will result in a change of program's behavior. HCSs have been discussed across various studies in the context of implementation, testing, debugging, and evolution. Figure 2 shows the various domains of application of HCSs. Explanation for these domains is provided in the following sections.
• Automotive Software -Automotive software is related to automotive industry, i.e., making of motor vehicle. It involves both automotive products and services. System related to automotive system can be firmware, embedded software. Automotive software has a lot of configurations which are marked as feature.
The requirement of the automotive software is a very important and critical as it need to handle multiple configurations. Therefore, HCS includes automotive systems.
• Embedded Software -It is a type of computer software which is used to embed in any device (e.g., watch or chip) and its main purpose is to control the device it is embedded on. The embedded software runs on special hardware and it usually have memory constrains. Most of the configurations of the embedded software are handled by the machine interface. That is why it is discussed in HCS.
• Software Product Line -Software product line concept has been around for a while. It is defined as the group of software which utilizes the common set of features which fulfills the core goal of software application. It is important to manage the requirements of software product lines so that all new requirements can be easily integrated in the existing set of requirements. Furthermore, the selection of core requirements is an important aspect of software product line systems.
• Smartphone Applications -With the advent of smartphone, the technology has change drastically. There is a variety of smartphone out there with multiple configurations such as Android and iPhone and also, the hardware is being upgraded very rapidly. the application created should support all available platform (both software and hardware) but its reality, it is difficult to support all present configuration, so requirements should be prioritized which support the maximum available configuring.
• Web Applications -Web application is a type of software application which runs on the remote server and usually a web browser is used to access the web application over the internet. With cloud computing application, a lot of configurations are now required to be supported as the cloud is offered as a foundation and Software-as-a-Service (SaaS). It is important to handle requirements for all scenarios.
• Random Software Applications -All other applications with multiple configurations are included in this category. Table 3 specifies the details of the literature on HCSs. This table better specifies the description and limitations of the HCSs. Furthermore, Appendix A focuses the name the study of HCS and their research problem.

b: REQUIREMENT PRIORITIZATION
Requirements are the features, functionalities and capabilities stated by various stakeholders that software must possess in order to consider a complete quality system. Although, requirements form the foundation of HCSs; therefore, the requirement engineering process is vital for successful development of quality software. Requirement engineering consists of various phases, namely: elicitation, analysis, documentation, verification, validation, and prioritization. The prioritization phase helps to execute the development of a system in a manner that would not only allows the timely creation of major components, but also incorporate quality and many other values into the system.. Error! Reference source not found. Table 4 lists the various types of techniques used in existing studies, whereas, Appendix B provides the name of the study that discusses the RP techniques.
After reading literature, the details of the different problems that exist in previous methodologies are as follows: • Prioritization technique is subjective and unsystematic- The prioritization technique is qualitative and heavily relies on the expert opinion with no clear requirements on how to scale the requirements, the evaluation changes from person to person. This makes the proposed technique subjective and unsystematic.
• Prone to errors-The proposed techniques usually have a complex methodology and unclear structure. This problem leads to a lot of problems especially unreliable requirement prioritization which might lead to time delays or even the complete system failure.
• It doesn't take interdependencies between requirements into account-If the technique does not use modular or grouping approach, then the proposed techniques must consider the dependencies between the requirements.
• It doesn't define the value of linguistic terms to aid in the calculation of weights-In the proposed techniques, the values are not clearly defined for the scale which leads to the confusion. Either the units or selection methodology is not clearly defined or the values completely rely on the expert opinion or stakeholder choice.
• No evaluation-If the proposed techniques are not evaluated, the claims and reliability related to that technique cannot be ensured.
• Simple/informal ranking or grouping with no priority value of requirements-The techniques just utilize the expert opinion and there is no numerical assignment to the requirement or no clear ranking method to prioritize requirements.
• For small number of stakeholders and could confuse stakeholders-The techniques in which there is no VOLUME 8, 2020  • Semi-quantitative-The techniques, which are not quantitative or semi quantitative leads to the ambiguous requirement prioritization which might lead to error.
• Difficulty in reaching consensus-The negotiationbased techniques require all clients to sit and communicate with one another. In these techniques, there is a chance that stakeholders might not reach at some conclusion.
• It doesn't consider user need-The client is not involved the process which leads to the customer dissatisfaction.
To create customer value, client must be involved in the prioritization phase.
• Negative correlation not managed-Increase in one factor might lead to decrease of some other important factor. These types of relationships are not handled in the proposed techniques.
• Aggregation strategy of attributes don't capture conceptual properties of membership and similarity-All stakeholders are not involved or wither the attributes which are considered important for the requirement prioritization, are not used in the proposed methodology.
• Complex-Complex prioritization techniques which cannot be utilized without special training or workshop.
• Unscalable-The proposed methodology has certain constraints which prevents its utilization for the largescale projects.
• Time consuming-The requirement prioritization technique takes significant time from software development life cycle as it is a complex and lengthy process or there is no automation support for the proposed technique.
• Stakeholders can manipulate results according to their own objective-When the whole prioritization process depends on the stakeholders, there is a threat that results might be manipulated by the stakeholder for their own motives.
• Unsuitable for large number of requirements-The proposed methodology is not scalable and can be utilized only for the limited size projects or projects of specific domain. Table 5 below gives a mapping of limitations in existing RP techniques. The variable nature of HCSs can put forth various challenges. One of these challenges is to fulfill all not only major requirements but also to gain customer satisfaction. This is hard to achieve considering many unique arrangements in which number of features can be placed and used. We can leverage the strengths of requirement engineering to better handle this scenario. Requirement Engineering do not only help us in identifying the most important requirements as specified by customer, but it also ensures on-time delivery, decrease the system's cost, and improve chances of project's success. Nevertheless, the development of a quality system is highly dependent on the amount of customer input at the requirement gathering and prioritization phase. Although, the requirement prioritization and customer value creation are two separate paradigms, however, they can significantly affect one another. Therefore, we want to propose a method of delivering a good quality HCS by incorporating maximum customer feedback during the requirement prioritization phase.

III. RESEARCH METHODOLOGY A. LEAST SQUARES ESTIMATION
The least squares abbreviated as (LS) is a technique focuses the minimization of squared differences between empirical data and their desired values for assessing preferred parameters. Considering the regression analysis, it comprises a response variable usually represented by 'Y' and one or multi-covariables usually represented by 'X'. The response variable purely dependent on the variation in covariables. For example, change in grades 'Y ' are mostly due to the change in students' skills and persistence 'X '. Similarly, variant of life 'Y ' are predominantly up for the modifications in ecofriendly settings X. Therefore, for all values of covariables 'X', the finest projection of Y considering mean-squareerror represents mean f (X) studying Y provided X. We can consider this as: Y is a function of X including noise, whereas, f (X) is a regression function, computed from selecting n multi-covariables and corresponding response-variables x 1 , y 1 , . . . , (x n , y n ).
Let's suppose, we have a scenario in which f β is a linear function of β, i.e., where, X 1 + · · · + X p are the multi-covariables of f β (X ). We shall follow matrix notation for (2). So, we have y = (y 1 , ..., y n ). Similarly, X represents n × p data matrix. Whereas, n are the observations for variables p.
where, the X j shows the column having n observations on variable j, j = 1, . . . , n. v is an n-dimensional vector and v 2 is the length power two of v which is further represented by v 2 = v' v = n i=1 v 2 i . Therefore, (1) could be like: y − Xb 2  It shows the distance between the both columns Y and X and joining the b which is the linear combination. Figure 3 shows the distance that could be lessened considering the projection overhang of y on X. By taking the inverse we have Eq. 4 showing the variance: Then, we have provided X , the value ofβ is equivalent to Here, σ 2 is noise variance. Considering the estimator of σ 2 , the equation could be like: Here,ê i shows some residuals.
E.g., estimating the variance ofβ j will be vâr(β j ) = τ 2 jσ 2 where τ 2 j represents a particular element diagonal to (XX) −1 . Taking least squares estimator to approach Equation (7):β j ± c vâr(β j ) Whereas, C is the constant highly dependent on particular confidence level (α). Having value of α 95%, we have c = 1.96 considering a decent estimation while the value of n is larger. On contrary, a moderate c from student distribution tables can be considered n − p degrees of freedom. Keeping in mind the limitations and problems identified in Table 3 and Table 5, we are proposing a requirement prioritization technique which will help to produce a good quality HCS. It will result in creating customer value creation. For this, we are proposing a quantitative requirement prioritization technique for the highly configuration system which VOLUME 8, 2020 uses combination of curriculum-based and ranking method to determine the high priority requirements. This technique considers all stakeholders, even distributed stakeholders, in order to determine the high priority requirement. For this proposed approach, we need to define three Matrixes; named as, Factor Priority Matrix (Matrix X), Number Assignment Matrix (Matrix Y) and Assessment Matrix (Matrix Z). The details of the proposed methodology are defined as follows: • Firstly, all requirements of the HCS are collected from the clients.
• Feasibility analysis is performed whether the given requirement is in given budget and time constraint or not. These resources and scared and any wrong estimation may result in loss or even the system failure. Once the feasibility of the project is performed, convert the requirements to IEEE Software requirement specification format and then we proceed to the next step.
• After the feasibility analysis, the factor priority matrix is used to separate the requirements into different categories and provide a scale to some factors for each requirement. These factors and method of scaling are discussed in detail, later in this section.
• After that, value assignment matrix is considered for the determination of the numerical prioritization estimate of the provided requirement.
• Give evaluation matrix form to all experts to determine the mean result and prioritize result on the basis of collective information of all the team members.
• If the prioritized requirements have a tie, use curriculumbased method to break the tie by involving all stakeholders. The proposed methodology is show in Figure 4, and it is followed by the detailed procedure of all the matrixes.

1) MATRIX X: FACTOR PRIORITY MATRIX
This Matrix is comprised of two different approaches, i.e., setting the prioritized feature list for the requirements [92] and sample quantification matrix to prioritize the N requirements [92]. This proposed approach conforms to the IEEE Software Requirement Specification standard. This approach uses the structured matrix approach to prioritize the requirements for HCSs which comfort to the standards. The requirements are converted to IEEE SRS standard format after the collection process.
Afterward the conversion process, the requirements are separated into functional requirements, system requirements, constraints and system Layout. Functional requirements include all the modular requirements for the system. Whereas, the system requirements are comprised of nonfunctional requirements; such as, performance, scalability  and reliability, etc. Limitations involve different constraints while layout contains all the interfaces, for example, hardware interface, software interface, network interface, etc. All the requirements are assigned a unique index which is used as the identification number. All those requirements which are given the unique identification number are considered for the prioritization. In the next step, the requirements are evaluated for different factors which are; Time, Cost, Complexity, Criticality and Dependency. These factors are identified on the basis of triple constraints; time and cost and scope, whereas, the quality is considered by other three factors which are complexity, criticality and dependency. These factors are measure on the 3-point Likert scale with the values (level 1) high, Level 2 (medium) and Level 3 (low). Once the requirements are evaluated for the aforementioned factors, the precedence is assigned to the requirements. The precedence is set as the critical, urgent, important, normal and optional. The structure of the Matrix X is as shown in Table 6.

2) MATRIX Y: NUMBER ASSIGNMENT MATRIX
This matrix is used to provide all the possible values combination for the levels provided in the Matrix A. The statistical ranking method is used to rank the items. In order to achieve this, reverse statistical ranking method is used to prioritize the requirements. A table is generated for the possible values by using the formula X n , with numerical value 35, as there are total of x = 5 factors for total combinations are 243. The sample of Matrix Y is shown in Table 7.
To fill up this table is a troublesome task; therefore, a machine learning algorithm is used to generate a tree for the possible combinations and values. The pseudo code is shown above.
Until now, we have assigned the values to the given requirements by using matrix Y. Now, in the matrix X, the value column will be filled by the different team members involved in the requirement process to give a value to each of the factors identified in Matrix Y. A sample of matrix Z is as shown in Table 8.

3) MATRIX Z: ASSESSMENT MATRIX
The procedure to fill up the matrix Z is as follows: Step 1: Once the requirement in the matrix X are assigned the identification number, the matrix Z is provided to all the team members VOLUME 8, 2020  Step 2. All the team members are responsible to provide a value to each factor in the requirement of Matrix X. They assign a criterion to every requirement such as trivial, minor, major, and urgent or showstopper.
Step 3. Once the nature of requirement is identified, they assign a value to it using Matrix Y.
Step 4. As soon as all the values are assigned, find the mean value of the requirement mentioned in the matrix Z.
Step 5. Sort the final value column from highest to lowest value. The formula to find the mean value for each requirement is as follows:

= ( n k=0 (Stakeholder value for the requirement)) Total Number of Stakeholders
Step 6. Plot a graph for presentation. If there is a tie in the mean values of the requirements, the conflict is broken using the curriculum-based approach. Each stakeholder is given fabricated $100 and then in the tied top prioritized requirements, the stakeholder set a price for the requirement from that money. The top requirement is calculated by the following equation.

= ( n k=0 (Cost Assigned by each stakeholder)) Total Number of Stakeholders
The requirement with the highest average cost is given the highest priority. If the conflict remains, the process is repeated again unless the tie is broken. The procedure to resolve conflict is shown in Figure 5.
The main advantages of this technique are as follows: • This technique is not subjective i.e., it is not limited to just HCS; however, it can be used for any. Moreover, it can work for project of any size and any domain which makes it scalable.
• The methodology clearly defines each step hence, it is less prone to error.
• The linguistics for giving numerical values to the requirements is clearly defined.
• It does not influence by the dependencies between the requirements; therefore, it easily prioritizes requirements without any hassle.
• It is easy to reach a consensus due to the hybrid approach which forces the stakeholders to make an unbiased decisions.
• It considers all the user needs and involves all stakeholders.
• This technique can be easily automated to decrease the prioritization time.

B. ESTIMATION USING LSE
In our work, we take Y N as values for p number of factors affecting a requirement and N represents number of requirements. The value of any factor can be of any order depending upon its priority which is given by q n . Now, we multiply the values of each requirement with the values given by the experts. We want to estimate the requirement priority valuesV rM after getting our first idea from the experts as represented in the equation below where M represents the M th expert.
Therefore, considering same example the parameters will be like:

IV. RESULTS AND DISCUSSIONS
The current approach is not focusing on the comparison with the prior techniques, this is because none of the requirement prioritization techniques are compatible with highly configurable system as we have extracted limitations in the former requirement prioritization techniques mentioned in the Table 5. However, to evaluate the proposed methodology, two different processes are followed. Firstly, a case study of highly-configurable point of sale system was considered. Secondly, focus group was considered to score on several parameters which were extracted in the aforementioned section and presented in Table 3.
With the perspective of case study, the system was capable of being customized for all automobiles industries. All the requirements were already gathered from the clients. The requirements were divided into 10 distinct modules. Further, the IEEE standardized SRS document was created for requirement specifications. The considerable system requirements were privacy, scalability, usability, reliability and maintainability. There were some software constraints involve there as limitations. The main layout that was handled was user interface.
For the evaluation perspectives, a group of 5 domain experts were selected. This included a team lead, a requirement analyst, 2 developers and a tester from a private software company. The main task for the participants was to prioritize the given requirements by following the procedure. A two-hour workshop was given to make them completely understand the prioritization process. First, matrix X was formed by all the participants. The values were gathered from the matrix Y. The results concluded from matrix Z are represented in the Table 9.
For all the results of the participants, mean value is computed against each requirement. After this, a plot is generated to prioritize and represent requirements. Prioritized requirements are shown in Figure 6. As, we can clearly see that A3 requirement has the highest priority followed by the I1 requirement. In system requirements, privacy is more important than any other attribute. Therefore, the requirements are successfully prioritized quantifiably.
With the perspective of Focus group, a questionnaire was designed with items extracted from the mapping of requirement prioritization techniques. The items are as shown in Table 5. These items are the existing problems found in the literature of requirement prioritization Techniques. Therefore, it was mandatory to cross check our proposed technique against such problems. In order to achieve this task, a focus group comprising eight members with their experience of 3 to 11 years in the industry was considered. All the members had a questionnaire consisting of all the items need to be score against the Likert scale before the sitting. One of the authors of the research had discussed the working of the proposed technique when the session was actually started. After this presentation, members of the focus group were requested to fill up the questionnaire and ask the queries if there was a need. This session took a total of 45 minutes. The result of the focus group is shown in Figure 7.
In order to analyze the result, descriptive statistics is applied by using SPSS 20.0. The result of focus group is shown in the Table 10. According to the result, all the members of the focus group were agreed on the proposed technique that it is prone to error, support modifiability and suitable for large scaled projects. Moreover, they were also agreed on that it is hard to reach on the consensus. Therefore, curriculum-based approach was used to solve this problem. Similarly, the members were also agreed on that proposed technique is focusing on requirement ranking. Furthermore,  focus group members were not agreed on the proposed technique that it takes requirement interdependencies into the account. They were undecided about the value creation of the customers. They were somewhat dominating towards agree about the complexity, time consuming and scalability of the technique. VOLUME 8, 2020  This technique covers a lot of problems from the existing techniques. Following are some strengths of the proposed technique: • No matter the size of requirements, this proposed technique can prioritize any number of requirements regardless of the dependencies.
• There is no repetition in the ranking and different ranking is assigned to each requirement.
• Focus on the five main factors which impact any requirement.
• Following and SRS standard will automatically create a conformity standard for all the stake holders.
• Every stakeholder can be involved in the process.
• Clearly defined steps with no room for ambiguity.
• Ensure a good quality HCS is produced.

V. CONCLUSION AND FUTURE WORK
Highly-configurable systems have changed the course of the technology. It allows customers to customize the distinct objects of program according to their desires. Producing quality highly-configurable software is a difficult task. A good requirement prioritization technique can help produce a good HCS which can satisfy all customer requirement in time and within budgets.
In this research paper, we have proposed a quantitative requirement prioritization technique for the HCS. It involves all the stakeholders and can work for any number of requirements. The stakeholder team first assign levels to the requirements, after that, numerical values are assigned to the requirement. All stakeholder gives values to the requirement and then mean of those value against each requirement are plotted in the graph to get the highly prioritize requirement.
The leading advantage of the proposed methodology so the conformance of time saving, producing a quality HCS, prioritization of requirement regarding the total number of requirements. All basic scenarios have been covered in this technique. Some complexities are left. We shall try to focus them in our future work. This research can be applicable to prioritize requirements in the domain of internet of things. Additionally, it is also suitable for scaled software development environment.
This study comprises some potential threats to validity, i.e. the case study is just one project. The change in project may change the results. Further, there could be the biasness of the stakeholders voting being human. Change in the type of HCS or change in the evaluation process may produce different results.
We will incorporate the change of requirements in this technique and how the requirement changes will be handled using this approach is a part of our future work. Moreover, we will fully automate the requirement prioritization process by creating a tool and then evaluate against the state-ofthe-art existing solutions. Additionally, it will be focused to apply same methodology for IoT based and scaled software requirements prioritizations. Finally, we will also incorporate machine learning algorithms such as regression and classification which will improve the accuracy of the process.