This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Requirements prioritization plays a key role in the requirements engineering process, in particular with respect to critical tasks such as requirements negotiation and software release planning.
Requirement engineering is one of the most significant phases of software engineering. Success or failure of any software project relies heavily on better requirement engineering process. Better awareness of the requirements is fundamental for requirements engineering. Requirement Prioritization is an important component of requirement engineering process. In this paper, we have highlighted some serious shortcomings related to existing requirement prioritization techniques. Based on these findings, we have proposed an intelligent fuzzy logic based technique for requirements prioritization based on the perceived value of each requirement. We have also proposed a framework for evaluation of existing as well as proposed requirement prioritization techniques.
It is now well recognized that requirements are critical to the success of any major project. According to SEI's Square Project the total percentage of project budget due to requirements defects is 25 to 40 percent and costs the economy $59.5 billion annually! As a result, a planned requirements approach is essential to a successful and smooth-running project. Just like the project itself needs a project plan, the requirements process needs a requirements plan.
Once you have identified a set of security requirements, you will usually want to prioritize them. Due to time and budget constraints, it can be difficult to implement all requirements that have been elicited for a system. Also, security requirements are often implemented in stages, and prioritization can help to determine which ones should be implemented first. Many organizations pick the lowest cost requirements to implement first, without regard to importance. Others pick the requirements that are easiest to implement, for example by purchasing a COTS solution. These ad hoc approaches are not likely to achieve the security goals of the organization or the project. To prioritize security requirements, we recommend a systematic prioritization approach.
To be effective and to provide value to the project and to the organization, Business Analysts must be able to develop a requirements plan and have a thorough understanding of what activities they will perform, what deliverables they will produce, and how they will control and manage changes to those deliverables.
Several approaches have been proposed [8, 7, 9, 10, 14], which adopts a common model for the requirements prioritization process, based on the following three steps: (i) selection of one or more prioritization criteria (or prioritization features) among business goals and technical features; (ii) acquisition of a requirements ordering according to a specific criterion from one or more stakeholders (e.g. customers, users, project manager); (iii) composition of the acquired orderings into a final one based upon an appropriate composition schema. These approaches tend to focus on how to choose the most relevant criteria and on how to combine them, while giving minor emphasis to the acquisition of the ranks according to a given criterion.
The paper is canvassed in several identical sections. After the introduction section , a brief overview of related work is presented followed by a section of a literature review of the articles under consideration. Afterwards an analysis of current requirement prioritization techniques , serious shortcomings are identified which need to be addressed in order to achieve more realistic and efficient requirement prioritization.
Requirement Engineering (RE) is one of the earliest and very critical phases of software engineering. RE as a knowledge stream is basically aimed at acquisition, modeling and documentation of requirements for the software product. Requirement engineering aims to define precisely the requirements that need to be met. This is not an ordinary task. According to Fred Brooks, deciding what needs to be built is the most difficult part of software development . We can visualize one software requirement as one documented need that software product should accomplish.
Requirement prioritization is the next logical task once requirements have been elicitated and properly analyzed. In most cases, it is really difficult to meet all the requirements that have been given by various stakeholders. Similarly, in many cases, requirements are implemented in a staggered fashion. In such circumstances, it becomes important to arrange the requirements in a prioritized order to develop the system in more realistic way. According to Karlsson et al , one of the greatest problems of software engineers is development of such a product which doesn't satisfy the needs and expectations of stakeholders. To overcome this problem, same authors came up with the idea of prioritizing the requirements according to their value in the paper  titled "A Cost-Value Approach for Prioritizing Requirements". Subsequently, many other researchers [16, 17] emphasized upon the significance of requirement prioritization.
Recent approaches to requirements prioritization exploits different multi-criteria decision making techniques, such as Analytic Hierarchy Process (AHP) , Multi Criteria Decision Aid (MCDA) , SMART  and Quality Function Deployment (QFD) . Among them the cost-value approach , the Multi-criteria Preference Analysis Requirements Negotiation (MPARN) , and Quantitative WinWin .
Main limits of these techniques are attributed to the strong assumptions they adopt, such as, the completeness and certainty of the set of requirements to be evaluated and the plausibility of a rating scale based on discrete categories. Moreover, they seem to be inadequate in handling the following relevant issues: cost of the elicitation process; subjectivity of the stakeholders opinions; dependencies among requirements; requirements volatility.
A number of prioritization methods have been found to be useful in traditional requirements engineering and could potentially be used for security requirements. We briefly mention here the Binary Search Tree, Numeral Assignment Technique, Planning Game, the 100-Point Method, Theory-W, Requirements Triage, Wiegers' Method, Requirements Prioritization Framework, and AHP.
Binary Search Tree (BST)
Binary Search Tree is an algorithm that is typically used in a search for information and can easily be scaled to be used in prioritizing many requirements . The basic approach for requirements is as follows,
- Put all requirements in one pile
- Take one requirement and put it as root node.
- Take another requirement and compare it to the root node.
- If the requirement is less important than the root node, compare it to the left child node. If the requirement is more important than the root node, compare it to the right child node. If the node does not have any appropriate child nodes, insert the new requirement as the new child node to the right or left, depending on whether the requirement is more or less important.
- Repeat steps 3-4 until all requirements have been compared and inserted into the BST.
- For presentation purposes, traverse through the entire BST in order and put the requirements in a list, with the least important requirement at the end of the list and the most important requirement at the start of the list.
Numeral Assignment Technique
It is probably the most common prioritization technique which is also very easy to use. In the first step, requirements are classified into different groups. These requirements are given to each stakeholder. Each requirement within these groups is assigned a number on a scale of 1 to 5 by individual stakeholders. The final ranking is determined by calculating average of all the ranking given to each requirement by every stakeholder. This technique because of its ease of sue has also been suggested by IEEE Std. 830-1998. Since the requirements are first classified into groups and then prioritized so we can say that this technique does not prioritize requirements at the level of individuality. Instead one level of abstraction is introduced
The Numeral Assignment Technique provides a scale for each requirement. Brackett proposed dividing the requirements into three groups: mandatory, desirable, and unessential . Participants assign each requirement a number on a scale of 1 to 5 to indicate its importance . The numbers carry the following meaning:
- does not matter (the customer does not need it)
- not important (the customer would accept its absence)
- rather important (the customer would appreciate it)
- very important (the customer does not want to be without it)
- mandatory (the customer cannot do without it)
The final ranking is the average of all participants' rankings for each requirement.
Despite its wide applicability, this technique also poses several problems. Clear definition of the groups is one major drawback. Second problem is that even with clear definitions, stakeholders will tend to put most of their requirements into critical groups because of their biases (which can't be overruled). Another fact that we have to be mindful about is that within each group, all the requirements are initially at the same priority level
The planning game is a feature of extreme programming  and is used with customers to prioritize features based on stories. This is a variation of the Numeral Assignment Technique, where the customer distributes the requirements into three groups, "those without which the system will not function," "those that are less essential but provide significant business value," and "those that would be nice to have."
The 100-Point Method  is basically a voting scheme of the type that is used in brainstorming exercises. Each stakeholder is given 100 points that he or she can use for voting in favor of the most important requirements. The 100 points can be distributed in any way that the stakeholder desires. For example, if there are four requirements that the stakeholder views as equal priority, he or she can put 25 points on each. If there is one requirement that the stakeholder views as having overarching importance, he or she can put 100 points on that requirement. However, this type of scheme only works for an initial vote. If a second vote is taken, people are likely to redistribute their votes to get their favorites moved up in the priority scheme.
Theory-W was initially developed at the University of Southern California in 1989 [22, 32]. It is also known as "Win-Win." An important point is that it supports negotiation to solve disagreements about requirements, so that each stakeholder has a "win." It has two principles:
- Plan the flight and fly the plan.
- Identify and manage your risks.
The first principle seeks to build well-structured plans that meet predefined standards for easy development, classification, and query. "Fly the plan" ensures that the progress follows the original plan. The second principle, "Identify and manage your risks," involves risk assessment and risk handling. It is used to guard the stakeholders' "win-win" conditions from infringement. In win-win negotiations, each user should rank the requirements privately before negotiations start. In the individual ranking process, the user considers whether there are requirements that he or she is willing to give up on, so that individual winning and losing conditions are fully understood. Theory-W has four steps:
- Separate the people from the problem.
- Focus on interests, not positions.
- Invest options for mutual gain.
- Insist on using objective criteria.
Requirements Triage  is a multistep process that includes establishing relative priorities for requirements, estimating resources necessary to satisfy each requirement, and selecting a subset of requirements to optimize probability of the product's success in the intended market. This is clearly aimed at developers of software products in the commercial marketplace. Davis's more recent book  expands on the synergy between software development and marketing; we recommend that you read it if you are considering this approach. It is a unique approach that is worth reviewing, although it clearly goes beyond traditional requirements prioritization, considering business factors as well.
This method relates directly to the value of each requirement to a customer . The priority is calculated by dividing the value of a requirement by the sum of the costs and technical risks associated with its implementation . The value of a requirement is viewed as depending on both the value provided by the client to the customer and the penalty that occurs if the requirement is missing. This means that developers should evaluate the cost of the requirement and its implementation risks, as well as the penalty incurred if the requirement is missing. Attributes are evaluated on a scale of 1 to 9.
Requirements Prioritization Framework
The requirements prioritization framework and its associated tool [30, 31] includes both elicitation and prioritization activities. This framework is intended to address the following:
- elicitation of stakeholders' business goals for the project
- rating the stakeholders using stakeholder profile models
- allowing the stakeholders to rate the importance of the requirements and the business goals using a fuzzy graphic rating scale
- rating the requirements based on objective measure
- finding the dependencies between the requirements and clustering requirements so as to prioritize them more effectively
- using risk analysis techniques to detect cliques among the stakeholders, deviations among the stakeholders for the subjective ratings, and the association between the stakeholders' inputs and the final ratings
AHP is a method for decision making in situations where multiple objectives are present [29, 26, 27]. This method uses a "pair-wise" comparison matrix to calculate the relative value and costs of individual security requirements to one another. By using AHP, the requirements engineer can confirm the consistency of the result. AHP can prevent subjective judgment errors and increase the likelihood that the results are reliable. AHP is supported by a standalone tool, as well as by a computational aid within the SQUARE tool.There are five steps in the AHP method:
- Review candidate requirements for completeness.
- Apply the pair-wise comparison method to assess the relative value of each of the candidate requirements.
- Apply the pair-wise comparison method to assess the relative cost of the candidate requirements.
- Calculate each candidate requirement's relative value and implementation cost, and plot each on a cost-value diagram.
- Use the cost-value diagram as a map for analyzing the candidate requirement.
AHP can be considered as a highly sophisticated and complex technique which can establish prioritization at the level of individual requirements. A sample cost value diagram is shown in figure 1. A large number of studies have been made in recent past to determine the effectiveness of AHP for requirements prioritization
Efforts have been made to reduce the number of comparisons. However, this has always enhanced the margin of error. In my humble view point this tradeoff is necessary since some comparisons may actually never be needed Ranking
This technique is more suitable in the environment where a single stakeholder is involved. If there are n number of requirements, these requirements are ranked from 1 (most significant) to n (least significant). This ranking is exclusive in its nature because requirements are not ranked relative to other requirements as is the case of AHP or cumulative voting. Various techniques like bubble sort, quick sort or binary search techniques can be used to achieve this ranking.
There are two major drawbacks associated with this technique. First major problem is that it can cause more conflicts than agreements when applied in an environment of multiple stakeholders. The second drawback is that requirements are viewed and ranked in isolation. The impact of one requirement over the other doesn't play any role in overall prioritization. Requirement prioritization evaluation Indicators It is important to evaluate the performance of our proposed technique against existing requirement prioritization approached. In this section, we propose benchmarks which need to be considered while evaluating the effectiveness of any requirements prioritization approach.
Consistency: The prioritized requirements should show a remarkable consistency through various iterations of software development. We believe it is important that our prioritized requirements should be realistic and have significant probability that their assigned value will not change due to creeping requirements. This will show the consistency of the scheme as the project undergoes changes during its course. This factor should be one benchmark to evaluate effectiveness of any requirement prioritization scheme.
Time: The overall time, which a scheme for requirement prioritization takes, is very critical. Due to scarcity of time, we can't allocate too much of this resource to any task. for any requirement prioritization technique to be acceptable to different stakeholders, it should be able to exhibit impressive results within fairly short amount of time.
Scalability: For a requirement prioritization technique to be effective, it needs to be scalable as well. The technique should be able to prioritize requirements for different types of applications (system software, application software, embedded software etc.) with different kind of stakeholders. It should also be able to show impressive results for applications developed under different kinds of process models (waterfall, iterative, agile etc.)
Ease of Use: Any requirement prioritization technique will gain much wider acceptance if it is easy to use and understand. The automation element can enhance the ease of use since it will reduce a lot of burden of manual work. However it can only be achieved if automated technique is able to show impressive results vis-à-vis other techniques.
Accuracy: The resultant prioritized requirements achieved through any technique lose their significance if those are not correct. This benchmark is directly related to the first benchmark i.e. reliability. The requirement prioritization will be more reliable if it is more accurate. So accuracy is very important factor when considering the overall effectiveness of any requirement prioritization strategy.
Limitations of using existing requirement prioritization methods
As we study different requirement prioritization techniques, some glaring problems emerge that need to be resolved in order to achieve better requirement prioritization. These include:
- Most of these techniques (numerical assignments techniques to be specific) rely on statistical operations only. Statistical approached work better in situations where data is not fluid. In case of requirements, we know that requirements change frequently over the course of time. Mere statistical measures can't fully capture the dynamic and constantly evolving nature of requirements.
- These techniques derive their prioritization from the written statements of requirements and expert judgment. There is no unified framework or a set of factors on which to rank all requirements and use this ranking for further prioritization.
- The techniques rely heavily on human factor. It is very difficult to prioritize requirements in an impartial fashion and in an unbiased manner when all the control relies with experts who are humans. The element of bias can't be over ruled with such human intensive mechanisms.
- The techniques need to create new prioritizations every time requirements undergo some major changes. If requirements are evaluated from the perspective of there persistence, then our prioritizations have more realistic chance of sustaining longer even with changing requirements. Unfortunately no such consideration is given importance in existing techniques.
- The schemes have not been evaluated so far on the parameters of cost, efficiency and reliability. There is an urgent need to compare the existing techniques on these parameters and develop some new technique which betters these results.
The schemes are not able to further improve their results based on previous results and performances. There is an urgent need for a scheme that is able to continuously evolve and improve its performance.
Conclusion and future work
Requirement prioritization is one very important but often neglected component of RE process. There are several techniques for requirement prioritization but these have some serious limitations associated with them. In this paper, we have proposed a value based fuzzy requirement prioritization. We have also presented an evaluation framework on which to evaluate existing as well as proposed requirements prioritization techniques.
Applying artificial intelligence to requirement prioritization based on the perceived value of requirements is an exciting research area. We intend to further explore our fuzzy requirement prioritization technique by developing a fully functional fuzzy logic based system for this technique and using the system to prioritize requirements at the industrial level. Information gathered by applying this technique will be crucial in determining the feasibility of hybridization between requirement engineering and artificial intelligence.
I would like to acknowledge the SZABIST Islamabad Campus and my Supervisor Dr Arfan Jaffar for providing required resources to complete this work. It would have been impossible to complete this effort without their continuous support.
- Y. Akao. Quality Function Deployment: Integrating Customer Requirements into Product Design. Productivity Press, 1988.
- Requirements Prioritization Introduction by Nancy R. Mead, Software Engineering Institute [vita] Carnegie Mellon University University
- Brooks, F., "No Silver Bullet: Essence and Accidents of Software Engineering", IEEE Computer, Vol. 20, No. 4, April 1987, p. 10-19
- W. Edwards and F. Baron. Smarts and smarter: Improved simple methods for multiattribute utility measurement, pages 306 - 325. Number 60. 1994.
- Karlsson J., Ryan K., "Supporting the Selection of Software Requirements", Proceedings of the 8th International Workshop on Software Specification and Design (IWSSD '96), 1996
- H. In, D. Olson, and T. Rodgers. Multi-Criteria Preference Analysis for Systematic Requirements Negotiation. In 26th Annual International Computer Software and Applications Conference, Oxford, England, August 2002.
- J. Karlsson. Software requirements prioritizing. In ICRE'96,1996.
- F.Moisiadis. The fundamentals of prioritising requirements. In System Engineering, Test and Evaluation Conference, Sydney, Australia, 2002.
- A. Ngo-The and G. Ruhe. Requirements Negotiation under Incompleteness and Uncertainty. In Software Engineering Knowledge Engineering 2003 (SEKE 2003), San Francisco, CA, USA, July 2003.
- B. Roy and D. Bouyssou. Aide Multicrit`ere `a la Decision: Methods et Cas. Economica, Paris, 1993.
- G. Ruhe, A. Eberlein, and D. Pfahl. Quantitative win-win - a quantitative method for decisione support in requirements negotiation. In Proceedings 14th International Conference on Software Engineering and Knowledge Engineering (SEKE'02), pages 159 - 166, Ischia, Italy, July 2002.
- T. L. Saaty. Fundamentals of the analytic network process. In Proceedings of International Symposium on Analytical Hierarchy Process, 1999.
- A. Sivzattian and B. Nuseibeh. Linking the selection of requirements to market value: A portfolio-based approach. In REFS 2001, 2001.
- Karlsson J., Ryan K., "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, 1997, vol. 14, No. 5, pp 67 - 75
- Xiaoping L., Veera C.C., Sun Y., Noguchi K., Kyoya Y., "Priority Assessment of Software Requirements from Multiple Perspectives", Computer Software and Applications Conference, 2004, COMPSAC 2004, 2004, vol. 1, pp 410 - 415
- Fellows L., Hooks I., "A Case for Priority Classifying Requirements", Third International Conference on Requirements Engineering (ICRE'98), 1998, pp 62 - 65
- Ahl, V. "An Experimental Comparison of Five Prioritization Methods." Master's Thesis, School of Engineering, Blekinge Institute of Technology, Ronneby, Sweden, 2005.
- Brackett, J. W. Software Requirements (SEI-CM-19-1.2, ADA235642). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990
- Karlsson, J. "Towards a Strategy for Software Requirements Selection. Licentiate." Thesis 513, Linköping University, October 1995.
- Beck, K. & Andres, C. Extreme Programming Explained: Embrace Change, 2nd ed. Boston, MA: Addison-Wesley, 2004
- Boehm, B. & Ross, R. "Theory-W Software Project Management: Principles and Examples." IEEE Transactions on Software Engineering 15, 4 (July 1989): 902-916
- Wiegers, K. E. Software Requirements, 2nd ed. Redmond, WA: Microsoft Press, 2003
- Davis, A. "The Art of Requirements Triage." IEEE Computer 36, 3 (March 2003): 42-49
- Davis, A. Just Enough Requirements Management: Where Software Development Meets Marketing. New York: Dorset House, 2005 (ISBN 0-932633-64-1).
- Karlsson, J. "Software Requirements Prioritizing," 110-116. Proceedings of the Second International Conference on Requirements Engineering (ICRE'96). Colorado Springs, CO, April 15-18, 1996. Los Alamitos, CA: IEEE Computer Society, 1996
- Karlsson, J. & Ryan, K. "A Cost-Value Approach for Prioritizing Requirements." IEEE Software 14, 5 (September/October 1997): 67-74
- Leffingwell, D. & Widrig, D., Managing Software Requirements: A Use Case Approach, 2nd ed. Boston, MA: Addison-Wesley, 2003
- Saaty, T. L. The Analytic Hierarchy Process. New York, NY: McGraw-Hill, 1980
- Moisiadis, F. "Prioritising Scenario Evolution." International Conference on Requirements Engineering (ICRE 2000). June 2000
- Moisiadis, F. "A Requirements Prioritisation Tool." 6th Australian Workshop on Requirements Engineering (AWRE 2001). Sydney, Australia, November 2001
- Park, J.; Port, D.; & Boehm B. "Supporting Distributed Collaborative Prioritization for Win-Win Requirements Capture and Negotiation," 578-584. Proceedings of the International Third World Multi-conference on Systemics, Cybernetics and Informatics (SCI'99) Vol. 2. Orlando, FL, July 31-August 4, 1999. Orlando, FL: International Institute of Informatics and Systemics (IIIS), 1999