The quality of a software product delivered to the customer is frequently determined by the ability to satisfy the needs of the customers and users [1] . Quality can be defined as the degree to which a system, component, or process meets customer or user’s needs or expectations. Thus the delivered product should be traceable to the requirements given by the customer. Hence, requirements elicitation is a major step towards the success of any project. If wrong requirements are implemented and users start resisting using the product, it does not matter how firm the product is or how thoroughly it has been tested. The entire effort afforded for the development will go waste.

Traditional way of creating software products starts with requirements analysis followed by high and low level designs, implementation and testing. These steps found to be useless and annoying in today’s fastest world. As a result, several development methodologies have been proposed by practitioners to accommodate the needs of industry. To cope up with the ever-changing needs of the industry, software industry is moving towards agility from the traditional approach taking into account the advantages being fast and when delivery of products is not in full but in pieces to customer. Through the concept of having multiple working iterations, the implementation of agile methods allows the creation of quality, functional software with small teams and limited resources.

Requirements Engineering (RE) is the process of establishing the services that the customer requires from a system within the specified constraints of operation and development. A high quality Requirements Engineering can produce a quality product [2] . The following quote from Fredrick Brook’s illustrates why requirements are so important: “The hardest part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all of the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later”. In the traditional approach, Requirements Engineering includes various activities like elicitation, analysis, documentation, validation and management. RE starts and comes to an end in the first phase of project development itself. Agile takes a different approach by allowing RE during the development of product thereby allowing the changes in the development.

In RE, Requirements prioritization seems to be a very major activity and it can be defined as the process of selecting the most important requirement at the particular time and this can be affected by so many factors like cost and budget constraints, availability of personnel, logical implementation order, importance to customers, negative effect, etc. [3] . Several researchers [4] - [6] have analyzed the above role of requirements prioritization in software development methods. Ruhe et al. summarize the importance of requirements prioritization as: “The challenge is to select the ‘right’ requirements out of a given superset of candidate requirements so that all the different key interests, technical constraints and preferences of the critical stakeholders are fulfilled and the overall business value of the product is maximized” [6] . This attitude toward requirements makes cost, effort estimation and software architecture development more difficult. But it makes verification easier than traditional methods. Without knowing the final form of the product, or marketplace demands, estimation seems to be impossible [7] . Requirements prioritization in agile environment seems to be even more difficult due to so many factors like changing requirements during the course of software development, the constraint that the piece of product once delivered should not be altered during the subsequent release of other pieces etc. The way of handling requirements seems to be different among companies that range from small scale to enterprises. Most importantly, the meaning of user-specified requirements is clearly known to the developers only during the development of the project. Taking into account all these criteria, RP seems not to be a onetime activity but has to be continued during the course of the project.

Various prioritization techniques are suggested and used to prioritize the most important requirements; and the process is still immature [7] . Those methods prioritize on the basis of factors such as cost, time, and relevant importance. Since the aspects are dependent on each other, existing approaches cause conflicts. These conflicts are initiated due to the effect of one aspect on another aspect. The proposed approach in this paper reduces the conflict by providing thresholds for each stakeholder. The method optimizes the view of multiple stakeholders through the use of arriving at concordance for each requirement. The method is found to be useful and can be completely automated which makes the ability of collecting requirements from geographically distributed stakeholders easier.

This paper has been organized as follows. Sections 2 deals with the background work to be performed for prioritization. A detailed analysis of existing techniques is discussed in Section 3. In Section 4, we have discussed about the description of chosen method ELECTRE. Section 5 deals with the proposed prioritization approach. The case study with a detailed numerical example is given in Section 6. Sections 7 and 8 present the comparison between traditional method and proposed method.

Requirements prioritization can be done by taking the attributes of the requirement into account. An attribute or a factor of a requirement is the property of it. Various authors refer to this factor by various names like aspect, criteria, element etc. Several factors that accounts for prioritization are importance, penalty, cost, time, volatility, risk, resources, market strategies etc. Determining priority among the requirements depending upon one factor seems to be easier. But in practice, prioritization needs to be done by taking more than one factor into account. Variation in one factor certainly affects other factor. The list of factors to be considered depends upon the situation of development. Some of the important factors that should be considered for prioritization are listed below.

Racheva et al. [15] presented a survey by assessing a number of requirements prioritization techniques. Based on the descriptions suggested by them, these techniques can be classified into two main categories: techniques that can be used to prioritize small amounts of requirements (small-scale) and techniques that scale up to very large scale (medium-scale or large-scale), thus can be used for the prioritization of larger amounts of requirements. Small-scale techniques can usually be used without the aid of a software tool and are often relatively simply structured.

The techniques mentioned by Racheva et al. [15] are the round-the-group prioritization, the $100 allocation technique, the multi-voting system, the pair-wise analysis, the weighted criteria analysis, the dot voting technique, and the Quality Functional Deployment approach. Thomas Bebensee et al. discussed about the use of Binary Priority List to prioritize the requirements. The technique works well when the number of decision maker is one. It is not able to satisfy situations when the number of people involved in decision making grows. Jim Azar et al. proposed a methodology named value oriented prioritization for prioritizing requirements in small scale firms. Philip et al. [16] presented a systematic literature review about the various researches carried out in this field. In all the methodologies, rankings are done either using one criterion or almost two criteria.

ELECTRE has been identified as the best ranking strategy in so many sectors. B. Roy [17] [18] stated the advantage of ELECTRE over different ELECTRE methods and has presented the fact that ELECTRE is best taking decisions with multiple criteria. Juan Carlos, Leyva-Lopez et al. discussed about the use of ELECTRE-III in group decision making [9] . Christos Giannoulis, Alessio Ishizaka [8] discussed the advantage of using ELECTRE-III in ranking universities.

The ELECTRE (Elimination and Choice Translating algorithm) family was introduced by Benayoun, Roy and Sussman in 1968. The method was later developed by Bernard Roy (Roy, 1996). This family includes ELECTRE I, II, III, IV, IS and TRI methods (Vincke, 1992; Roy, 1996). All ELECTRE methods appear to be similar in describing the concepts but differ in type of decision problem being solved. It has been proved that ELECTRE I is found to be best suited for selection problems, ELECTRE TRI seems to be suited for assignment type problems and the other ELECTRE methods are for ranking problems. Especially, ELECTRE III is proved to be more suitable for ranking problematic. ELECTRE III has been identified to be useful in different applications [8] [19] [20] .

A typical MCDM (Multiple Criteria Decision Making) problem can be defined as a ranking aid to arrange a finite number of decision alternatives, each of which is clearly described in terms of different characteristics. These characteristics are also often called attributes or decision criteria as in Figure 1. A typical MCDM can be represented by using a two dimensional matrix as in Figure 1.

Also, for every criterion, every decision maker has to define the following:

1) Preference threshold (p)

2) Indifference threshold (q)

3) Veto thresholds (v) where (v≥q≥p)

4) Importance rating (w_j) for each criterion j.

To start with, ELECTRE requires the evaluation of two indices, the concordance index and the discordance index, defined for each pair of alternatives. Figure 2 depicts the main steps of ranking using the ELECTRE III model. In the following subsections, the complete description of the ELECTRE III model has been summarized.

Figure 3 depicts the web based decision support system built using PHP as frontend and MySQL as backend for performing prioritization. The priorities of requirements are collected from stakeholders using the web interface. Interface has been developed in such a way that the product manager can either send the request either to specified

group of people in case of Be-spoken product or to a general mass in case of market-driven product. The inputs from the stakeholders are collected using 100-point method [21] . The stakeholders are given the liberty to distribute the 100 points to the requirements according to their perceived priority. The inputs given by stakeholders are stored in MySQL database which is then processed using ELECTRE. The layer where ELECTRE is implemented is independent from the other layers and hence, can be upgradable for similar decision problems.

Our approach for validation of the project starts with selection of a project to assess the effectiveness of the method. After careful analysis, we have decided to take “Library Management System” as the pilot project. The standard set of requirements was identified after having done a detailed literature survey on the topic. In order to ascertain the effectiveness of the proposed method, we have associated ourselves with a web based development company. The project manager of the company was asked to do the project using his own view. In order to standardize it has been planned to have working hours from 9:00 AM to 4:00 PM with a break of 1 ½ hours lunch break in between. Also, after having discussion, it has been decided to use Visual Basic as front end and Ms? Access as backend. The results were recorded that include the number of days taken for completion, number of Lines of Code and customer satisfaction.

As the second step, we have planned to implement the same Library Management System using the proposed method. The set of personnel used to control prioritization was identified which take in 2 developers, 1 project manager, 1 customer and 2 end users one each with and without computer background. Selected persons are asked to prioritize the requirements using 100-point method. The personnel are given the liberty to choose their own criteria for ranking requirements. For e.g., the Project manager may rank the requirements by having cost as his criteria. The end user may rank the requirements by having value as the criteria. Along with the ranking of requirements, the ranking personnel are asked to give indifference, preference and veto thresholds according to their view.

A simple user-friendly model has been developed and the stakeholders are asked to enter the data according to the criteria they have set. The concordance and discordance matrices are calculated and the distillation process is applied. Further, the final ranking is applied and the results are recorded. The comparative results are shown in Figure 5 and Figure 7. The results are discussed in Section 7.

Requirements engineering, the backbone of software industry, includes various activities like elicitation, analysis, prioritization, etc. Several methods have been proposed by the researchers for prioritization, but only a very few methods support automation along with multi-criteria decision making.

The proposed method is found to be appropriate for the ranking problem due to the following reasons:

・ It allows multiple stakeholders to represent their views without the need for face-to-face discussion and hence provides a feel of independency to the stakeholders.

・ The comparisons between requirements are not required, hence, make the stakeholders comfortable.

・ Thresholds provide a convenient way of ranking requirements.

・ It reveals shattering criteria by using veto thresholds.

The method is validated using a case study with fewer requirements. Literature shows that the method is scalable, but the validation is not done in this research work. In the future, the method is planned to be validated with large scale requirements. Exact distribution of 100 points to all the requirements by the stakeholders is not possible in practice. Hence, fuzzy concept is planned to be adopted to collect requirements from stakeholders. In this study, the weightage for stakeholders is given by the product owner. This may create a bias on ranking. In the future, the weightage for the stakeholders will automatically be generated using the results of a generally collected dataset.

S. A. Sahaaya Arul Mary,G. Suganya, (2016) Multi-Criteria Decision Making Using ELECTRE. Circuits and Systems,07,1008-1020. doi: 10.4236/cs.2016.76085