Requirements prioritization is one of the key factors in deciding the success of the project and hence the software industry. One of the major concerns in software prioritization techniques is that the existing ranking techniques have a very modest support to different criteria used by stakeholders to present their ranking. The current techniques are not suitable for arriving at anoptimized view of multiple stakeholders using multiple criteria. This research analyzes the issues in existing techniques. A web based decision support model using ELECTRE as the method for prioritization is proposed. ELECTRE is a multi-criteria decision making model that is proved to be effective in ranking several decision making problems. The proposed system takes input from multiple stakeholders using 100-point method. An optimized ranking is obtained using ELECTRE method. The developed system is validated using a pilot project and is found to be efficient in terms of saving cost of implementation and man-hours needed for implementation.
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 [
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 [
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. [
Various prioritization techniques are suggested and used to prioritize the most important requirements; and the process is still immature [
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.
The concept of prioritization is backed up by so many people called stakeholders. Number of stakeholders involved in the project may range from one to many. Even if the stakeholder is one, in practical it will not be so. For example, the owner and user of a product may be different. Usually, stakeholders may range from customers, developers, project managers etc. Every stakeholder involved in the prioritization process will have their own view and they don’t want to get compromised on others views. Customers used to prioritize the requirements according to the perspective of how valuable it is to them. And also Individual customer’s decision upon the prioritization of requirements seems to be inefficient in making decisions.
Developers used to prioritize the requirements according to the cost, risk involved and other criteria associated with a specific requirement. Developers also concern more about the impact of requirements on the product architecture and hence decide the priority. A project manager needs to balance about the scope of the project aligned with the schedule, budget, staff availability, quality of the product etc., while setting priorities, manager has to balance the benefit that each requirement provides against its cost and the penalty it has for the product’s architectural foundation for future evolution. The importance of different stakeholders involving in a project has been studied by so many researchers [
Small and Medium firms are often considered “motors” of industrial growth: They are very dynamic, innovative and efficient. In a survey by Uolevi Nikula, Jorma Sajaniemi and Heikki Kälviäinen [
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.
Importance of a requirement refers to the weight of corresponding requirement of the system under development. The meaning of importance depends on the viewpoint of the stakeholder. It may be the urgency of implementation due to market competitions, importance concerned to the product under development, importance concerned to the company etc.,
Penalty refers to the price the company has to loss when the requirement is not satisfied and it can be taken as a complement of importance of a requirement. While calculating penalty, the rate of how unhappy the customers will be if the feature is not present needs to be calculated. Penalty also includes the rate to be suffered by the developer when the requirement is satisfied late in the development process.
Cost is a major factor in prioritizing requirements and it is usually calculated by the organization. Most organizations consider cost purely in terms of money, but this may also be calculated in other terms such as number of man hours used for creation of a requirement etc., Many factors correspond to the estimation of cost and it includes the complexity in the development of a requirement, whether or not the code can be reused, the documentation models to be produced, availability of technical personnel etc.,
Risks associated with each and every requirement plays a vital role. Risk includes both internal risks that exists within the organization (for e.g., technical and market risks) and external risks (regulations given by the regulatory bodies, survival of customers etc) . People may attempt to implement the requirements having the highest risk first so as to deal with the resulting problems during development. Alternatively, it may make sense to implement the lowest risk requirements first in order to maximize the amount of the system implemented by ensuring that limited resources are not wasted on trying to implement high risk aspects of the system that may be impossible for successful completion. Postponing the implementation of high risk requirements can also maximize the time available to analyze about the risks and determine appropriate risk easing approaches.
Time refers to the lead time which starts when the request is received from the customer and ends at delivery of product to customer. This is actually the customer sees. Prioritization helps in reducing the lead time thereby increasing several factors like increasing the trust with the customer, increasing sales etc.
Requirements volatility represents the tendency of requirements to change over time. Unstable requirements affect the stability and planning of a project and probably increase the costs since changes during development increase the cost of a project. The rate of volatility is measured as a ratio of the total number of requirements changes (add, delete, and modify) to the total number of requirements in the system over a period of time.
Resources refer to the budget, staff and schedule. Resource estimation is one of the crucial factors in requirement prioritization, e.g., instead of waiting for a developer, the requirement that can be satisfied by the existing developer can be fulfilled which may reduce the lead time.
Certain requirements depend on other requirements. The dependency among different requirements can be known by drawing use-case diagram for the given list of requirements. Dependency plays a major role in prioritization the delivered piece of the product should not be altered at any time.
The priorities of requirements will change during the course of product development. Some of the reasons for changing requirements are:
・ Customers tend to prioritize requirements initially from the perspective of how valuable the functionality is to them. After having the discussion with developer, designer etc., about the cost, technical risk, or other trade-offs associated with a specific requirement, though, the customers might decide it isn’t as essential as they thought earlier.
・ The business environment and needs may change.
・ The developers might also determine that certain functions which have low priority should be implemented early on because of their impact on the product architecture [
・ In environments where agile methodologies are followed, some requirements may essentially need to be implemented before others since agile does not encourage change in delivered pieces of software.
・ There may be change in stakeholders due to movement of people.
・ Requirements with respect to individuals may change.
Racheva et al. [
The techniques mentioned by Racheva et al. [
ELECTRE has been identified as the best ranking strategy in so many sectors. B. Roy [
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 [
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
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 (wj) 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.
The strength of the hypothesis that alternative Ai is at least as good as alternative Aj is measured by the concordance index between the pair of alternatives Ai and Aj and is calculated by using Equation (1),
where,
The discordance index measures the strength of evidence against the hypothesis and is calculated using Equation (4).
Credibility matrix indicates the reliability of outranking hypothesis. If the concordance index is higher or equal to the discordance index for all criteria, then degree of credibility is equal to concordance index. If the concordance index is strictly below the discordance index, then the degree of credibility is equal to the concordance index lowered in direct relation to the importance of those discordances. Hence,
where π(a,b) is the set of criteria for which
The first pre-order is obtained using descending distillation, by selecting the best rated alternatives initially, and finishing with the worst. The second pre-order is obtained using ascending distillation, selecting the worst rated alternatives initially, and finishing with the best. The two pre-orders which are set based on a qualification score for each alternative as follows:
Step 1: Set λ0 equals to the maximum value of S(a,b) in credibility matrix (A) as per the Equation (6).
Step 2: A cutoff level of outranking λ1 is defined as the largest outranking score which is just less than the maximum outranking score minus the discrimination threshold.
and
where, s(λ0) is the discrimination threshold at the maximum level of outranking λ0. The values of α and β are usually 0.3 and −0.15 [
Step 3: At initial cutoff level, a outranks b if S(a, b) is greater than the cutoff level and S(a, b) exceeds S(b, a) by more than the discrimination threshold satisfying the condition.
Step 4: Every time when a outranks b, a is given a score of +1 (strength) and b is given −1 (weakness). For each alternative, the strengths and weaknesses are added together to give a final qualification score.
Step 5: Within Descending Distillation, the alternative with the highest qualification score is assigned to a rank and removed from the procedure and the process is repeated for all remaining options. Within Ascending Distillation, the alternative with the lowest qualification score is assigned to a rank and removed from the procedure and the process is repeated for all remaining options.
The results of the two procedures Descending Distillation and Ascending Distillation are combined to form complete ranking that is consistent with the two procedures.
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 [
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
Through a detailed literature survey about the software, “Library management system”, the following requirements are identified.
・ R1: Login form for customers.
・ R2: Search form for customers.
・ R3: Login form for librarian.
・ R4: View and Update customer profile.
・ R5: Adding customers and library cards.
・ R6: Handling Issue and return of media.
・ R7: Applying, Receiving, and updating fine details.
・ R8: Adding and removing media from library.
・ R9: View availability of books.
The dataset is generated by sending the username and password to access the web system to all the possible stakeholders of the system. The stakeholders are record their priorities using 100-point method. In addition to the following threshold values are entered by every stakeholder. Indifference threshold represents the value below which the priorities can be neglected. Preference threshold represents the fact that the priorities above it must be considered for decision making.
Distillation process is applied using the Equations (6)-(8).
Stakeholders | |||||||
---|---|---|---|---|---|---|---|
S1 | S2 | S3 | S4 | S5 | S6 | ||
Requirements | R1 | 05 | 20 | 15 | 05 | 10 | 10 |
R2 | 15 | 05 | 04 | 10 | 05 | 05 | |
R3 | 10 | 14 | 20 | 15 | 10 | 10 | |
R4 | 05 | 15 | 10 | 10 | 10 | 10` | |
R5 | 10 | 15 | 18 | 15 | 15 | 20 | |
R6 | 10 | 10 | 12 | 10 | 15 | 10 | |
R7 | 15 | 07 | 04 | 10 | 10 | 10 | |
R8 | 20 | 13 | 12 | 15 | 10 | 20 | |
R9 | 10 | 05 | 05 | 10 | 15 | 05 | |
Indifference threshold (q) | 05 | 05 | 05 | 05 | 05 | 05 | |
Preference threshold (p) | 15 | 10 | 10 | 10 | 10 | 10 | |
Veto threshold (v) | 20 | 15 | 15 | 15 | 15 | 15 | |
Weight of stakeholder (w) | 1 | 4 | 4 | 2 | 3 | 3 |
R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | R9 | |
---|---|---|---|---|---|---|---|---|---|
R1 | 1.00 | 0.00 | 0.88 | 1.00 | 0.71 | 1.00 | 0.97 | 0.65 | 0.00 |
R2 | 0.53 | 1.00 | 0.58 | 0.72 | 0.18 | 0.68 | 1.00 | 0.54 | 0.82 |
R3 | 0.95 | 0.00 | 1.00 | 1.00 | 0.82 | 1.00 | 0.00 | 0.79 | 0.00 |
R4 | 1.00 | 0.97 | 0.76 | 1.00 | 0.68 | 1.00 | 0.97 | 0.76 | 1.00 |
R5 | 1.00 | 0.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 0.97 | 0.00 |
R6 | 0.76 | 1.00 | 0.86 | 1.00 | 0.78 | 1.00 | 1.00 | 0.79 | 1.00 |
R7 | 0.53 | 1.00 | 0.67 | 0.81 | 0.45 | 0.86 | 1.00 | 0.64 | 1.00 |
R8 | 0.91 | 0.00 | 0.86 | 1.00 | 0.95 | 1.00 | 1.00 | 1.00 | 0.00 |
R9 | 0.53 | 1.00 | 0.58 | 0.76 | 0.91 | 1.00 | 0.56 | 0.56 | 1.00 |
From the credibility matrix with α = 0.82 shown in
R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | R9 | |
---|---|---|---|---|---|---|---|---|---|
R1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
R2 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
R3 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
R4 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 0 | 1 |
R5 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 |
R6 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
R7 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
R8 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 |
R9 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
From
From
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.
R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | R9 | |
---|---|---|---|---|---|---|---|---|---|
R1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
R2 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 0 | 1 |
R3 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 0 |
R4 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 0 | 1 |
R5 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 |
R6 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
R7 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 1 |
R8 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 |
R9 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
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