Jump to content

User:Gekko416/Requirement prioritization

From Wikipedia, the free encyclopedia

Requirement prioritization is used to rank or grade requirements according to importance and upcoming implementation releases[1]. It is an essential step done in making key decisions to improve a system's economic worth. To reduce risk during development, requirements are prioritized so that the most crucial or high-risk requirements are implemented first. There are various methods to for assessing the prioritization of software requirements.

Existing prioritizing techniques have a variety of drawbacks, including challenges with scalability, managing rank updates as requirements change, stakeholder collaboration, and needs reliance. Requirement prioritization is performed during requirements engineering.

Introduction to requirement prioritization

[edit]

The conceptualization of requirements engineering is made up by five sub-processes: requirements elicitation, requirements modeling, requirements analysis, requirements verification & validation, and requirements management. An crucial component of requirements elicitation is requirements prioritization[2].

Requirements prioritization is the process of determining which requirements should be implemented first and establishing the right order of implementation[3]. It is one of the design ideas that makes it possible for software that is being considered for development to work as planned. Establishing this order is important since most projects have to compromise on the set of requirements that can be implemented, due to limited time and resource constraints[4].

Prioritizing requirements is thought to be a difficult multi-criteria decision-making procedure[5]. Long-standing research has shown that requirements must be thoroughly gathered, examined, and prioritized for software systems to be acceptable to users or stakeholders[6][7]. Requirement prioritization is concerned with identifying critical needs as seen by important stakeholders[8]. Its main goal is to implement stakeholders' fundamental needs in terms of cost, quality, resource availability, and delivery time[9]. The development team and the stakeholders are both involved in the process of requirement prioritizing. The business analyst, as part of the development team, facilitates the process of prioritizing demands[10].

Prioritizing requirements is a procedure that is closely related to release planning. The development team establishes a timeline during release planning for when particular features or functionalities will be made available to end users. The importance of the needs is often determined by the priority of the requirements[11].

Requirement prioritization process

[edit]

Requirement prioritization is the process of ordering requirements in an ascending order of relative importance and urgency[12]. The necessity for requirements prioritizing is determined by several project restrictions like time and money. The project and product development team must prioritize some requirements to be immediately implemented and some to be saved for a later release. Requirements need prioritizing due to the fact that projects do not have unlimited resources, and setting requirements into priority order is a means to make the most of the limited resources.

Prioritizing requirements is a challenging endeavor that calls for analytical, technical, and interpersonal abilities. To take into account the opinions and demands of both parties, the product development team and stakeholders must cooperate and reach a compromise. The project team must have a thorough understanding of the project scope and the business case, notably the business analyst who serves as the process facilitator for requirements prioritization.[10]

The process of prioritizing requirements offers support for the following activities[13]

  • for stakeholders to choose the fundamental specifications for the system
  • to organize and choose the best possible set of software requirements to be used in subsequent versions
  • to compromise between the planned project scope and sometimes-conflicting restrictions including budget, time to market, resources, and quality
  • to evaluate each requirement's business benefits against its expense
  • to weigh the effects of requirements on the software architecture, future product development, and associated costs
  • to choose just a portion of the specifications while still creating a solution that will please the customer(s)
  • to predict anticipated client satisfaction
  • to obtain a competitive advantage and maximize market potential
  • to reduce rework and scheduling delays (plan stability)
  • to manage competing demands, concentrate the negotiation process, and settle disputes between parties
  • to determine the proportional relevance of each need in order to deliver the best value at the most affordable price

Criteria of requirement prioritization

[edit]

The Business Analysis Body of Knowledge 3.0 states that there are seven mentioned criteria that influence the priority of requirements. Regardless of the prioritization technique[12]. A Guide to the Business Analysis Body of Knowledge is a guide about business analysis, issued by the International Institute of Business Analysis.

  • Benefit: This is the benefit that the company will get if a certain condition is met right away. The advantages of implementing a particular need may include achieving corporate objectives or improving functionality, quality, cost, time, and resource use.
  • Penalty: The penalty or result of failing to comply with a requirement is the penalty. The project and the end product may suffer if certain requirements are not given top priority. As a result, a key deciding factor in needs prioritization is the penalty that the project teams and stakeholders will have to pay. Poor client satisfaction, wastage, excessive use of project resources, or poor product usability can all result in a penalty.
  • Risk: The risk is whether or not the need will provide the anticipated value. Several factors, including trouble understanding the requirement, difficulty carrying out the requirement's activities, and problems implementing the need, might prevent requirements from being completed.
  • Dependency: A relationship between two needs called a dependence exists when one cannot be completed or implemented without the other. A requirements dependency map is required before starting requirements prioritization.
  • Time Sensitivity: The time limit is frequently the most important consideration when prioritizing requirements. Certain criteria must be implemented before others because they are so urgent. This mainly applies to initiatives and goods that must address seasonal requirements. Implementing certain requirements prior to a specific date or time is crucial in these circumstances.
  • Stability: In order to avoid repetition, rework, and resource waste, requirements that are not stable or whose definition is constantly changing are given a lower priority. Stability is determined by the likelihood that a demand will remain fixed and static.
  • Regulatory/Policy Compliance: For the company or the stakeholders to comply with regulations or policies, there are several conditions that must be mandatory. An organization's adherence to business policy requirements for its standard business procedures is referred to as policy compliance.

Challenges

[edit]

The process of requirement prioritization involves complex, context-specific decision-making, which presents a number of challenges that must be taken into consideration. The process of requirement prioritization can involve multiple stakeholders, which all communicate with each other[14]. Communication has been proven to be a challenge when it comes to accurately identifying and describing priorities, which often results in errors and uncertainty. Stakeholders can experience difficulties when communicating with others due to different reasons such as speech, language or communication needs. There are different ways in which communication difficulties can arise, for example, stakeholders may struggle to communicate verbally or visually, to convey their own ideas and opinions, and to comprehend the words and actions of others.[15]

Developers who are working on the prioritization process are mostly working separately from the stakeholders and usually have no common practices to communicate information throughout the process. Developers often do not have a clear understanding of the actual priorities of the stakeholders and why certain requirements are important, resulting in insufficient prioritization[4].

Another challenge is that due to the ranking of requirements, stakeholders frequently worry that only the most crucial ones will be executed and the lower-ranked requirements will be ignored. This results in the fact that stakeholders may indicate that they prefer not to prioritize their requirements, which can cause a major bottleneck in the software requirement prioritization process[16]. Determining the priority of a single requirement deals with a lot of factors, which includes different point of views that need to be considerated. For example, the stakeholders view is that of the importance of the requirement. However the developers view regarding the implementation itself also needs to be taken into account as which needs should be implemented first depends on the company's resources, the manufacturing environment, and the logical sequence of implementation[4].

Requirement prioritization techniques are proven to often be complex to implement and prone to errors, which results in some techniques being unreliable due to faulty results. Although the majority of prioritization techniques are efficient, scaling up to more requirements turns out to be detrimental. As the project grows in scope, the requirement prioritization becomes more complex and ambiguous[17]. And for larger projects with a wide range of requirements, the majority of techniques are not suitable[18].

Prioritization techniques

[edit]
Requirement prioritization techniques ordered by scales

In the literature, a variety of strategies have been proposed to make the requirement prioritizing task precise, effective, dependable, and conflict-free. However, each method has its drawbacks and has implicit and explicit assumptions regarding the project context in which requirement prioritization is carried out[19]. There are three primary scales that can be used to portray the outcomes of the prioritization techniques, these are nominal scale, ordinal scale, and ratio scale[20].

Nominal scale: Mechanisms for nominal scale prioritizing produce an array of classes into which objects can be subdivided. In other words, requirements are categorized based on their significance. As a result, the priority of all criteria that fall under the same category is the same[20]. Only the MoSCoW technique and the Numeral assignment technique are included in this category.

Ordinal scale: Techniques for ordinal scale prioritization produce lists of criteria that are ranked. The ordinal scale can only indicate if one criterion is more essential than another, not by how much[20]. Techniques used in this area include bubble sort, priority groups, and minimal spanning trees.

Ratio scale: Techniques for ratio scale prioritization produce ranked lists of requirements. The relative difference between can be found in the results of ratio scale procedures[20]. This section makes use of the Analytic Hierarchy Process (AHP), Hierarchy AHP, Minimal Spanning Tree (MST), Cumulative Voting (CV), and Hierarchical Cumulative Voting (HCV).

Overview of five most common requirement techniques[21]
Technique Description Advantage Disadvantage
Analytic Hierarchy Process (AHP) It employs a pair-wise comparison matrix to calculate the cost or value of requirements that are relative to one another and is used by decision-makers to order requirements. Commonly used technique High complexity and can only handle small number of requirements.
Binary Search Tree (BST) When employing a binary search tree for requirements prioritizing, each requirement is represented by a node, with each node having a maximum of two children. The priority of each requirement determines how it is organized on the tree; low priority requirements are placed on the left side and high priority requirements are placed on the right side. Easy to use with high fault tolerance and high reliability of results. It can not handle a very large amount of requirements.
Numerical Assignment Technique This method provides a scale for all requirements. This method categorizes the needs into three categories: mandatory, desirable, and unessential. To rate the relevance of each criteria, we can provide a value between 1 and 5. W here the average of all required rankings makes up the final rating. Low complexity and it can handle a lot of requirements and is fast It has a low reliability of the results and also a low fault tolerance
Minimal Spanning Tree (MST) This approach is predicated on the notion that excess may be overcome if decision-making is made totally constant. For instance, if requirement R1 is more important than requirement R2, and requirement R2 is more important than requirement R3, we can infer that requirement R1 is more important than requirement R3. Easy to use and has high reliability of the results It can not handle a very large amount of requirements.
Hundred Dollar Method This method gives the system's stakeholders 100 fictitious units, where a unit could be time, money, etc. These units are used to allocate resources among the requirements, with the requirement having the highest number of units receiving priority. straight forward method When there are too many requirements, the approach will not work well, the calculation of priorities will be incorrect, and the points will not add up to 100.

See also

[edit]

References

[edit]
  1. ^ Hudaib, Amjad; Masadeh, Raja; Qasem, Mais; Alzaqebah, Abdullah (2018-01-15). "Requirements Prioritization Techniques Comparison". Modern Applied Science. 12 (2): 62. doi:10.5539/mas.v12n2p62. ISSN 1913-1844.
  2. ^ Sadiq, Mohd; Jain, S. K. (2014). "Stakeholder identification method in goal oriented requirements elicitation process". 2014 IEEE 5th International Workshop on Requirements Prioritization and Communication (RePriCo). IEEE. doi:10.1109/reprico.2014.6895219.
  3. ^ Achimugu, Philip; Selamat, Ali; Ibrahim, Roliana; Mahrin, Mohd Naz’ri (2014-06-01). "A systematic literature review of software requirements prioritization research". Information and Software Technology. 56 (6): 568–585. doi:10.1016/j.infsof.2014.02.001. ISSN 0950-5849.
  4. ^ a b c Lehtola, Laura; Kauppinen, Marjo; Kujala, Sari (2004), "Requirements Prioritization Challenges in Practice", Product Focused Software Process Improvement, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 497–508, ISBN 978-3-540-21421-2, retrieved 2023-01-13
  5. ^ Leffingwell; Widrig, Dean; Don (2000). Managing software requirements: a unified approach (1 ed.). Addison-Wesley Professional. ISBN 978-0201615937.{{cite book}}: CS1 maint: multiple names: authors list (link)
  6. ^ Mead, N.R. (2006). "Requirements Prioritization Introduction". Software Engineering Institute Web Publication.
  7. ^ Perini; Ricca; Susi; Bazzanella (2007). "An empirical study to compare the accuracy of AHP and CBRanking techniques for requirements prioritization". Proceedings of the Fifth International Workshop on Comparative Evaluation in Requirements Engineering: 23–35.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  8. ^ Ruhe, Günther; Eberlein, Armin; Pfahl, Dietmar (2003). "Trade-off Analysis for Requirements Selection". International Journal of Software Engineering and Knowledge Engineering. 13 (04): 345–366. doi:10.1142/s0218194003001378. ISSN 0218-1940.
  9. ^ Barney, Sebastian; Aurum, Aybüke; Wohlin, Claes (2008-06-01). "A product management challenge: Creating software product value through requirements selection". Journal of Systems Architecture. Selection of best papers from the 32nd EUROMICRO Conference on ‘Software Engineering and Advanced Applications’ (SEAA 2006). 54 (6): 576–593. doi:10.1016/j.sysarc.2007.12.004. ISSN 1383-7621.
  10. ^ a b "Requirements Management Plan | Requirements prioritization". 2021-09-28. Retrieved 2023-01-12.
  11. ^ Ruhe, Günther (2005). "Software Release Planning". Handbook Software Engineering and Knowledge Engineering. 3 (365–393).
  12. ^ a b BABOK : a guide to the Business Analysis Body of Knowledge. International Institute of Business Analysis (Version 3 ed.). [Toronto]. 2015. ISBN 9781927584033. OCLC 915841228.{{cite book}}: CS1 maint: location missing publisher (link) CS1 maint: others (link)
  13. ^ Berander, Patrik; Andrews, Anneliese, "Requirements Prioritization", Engineering and Managing Software Requirements, Berlin/Heidelberg: Springer-Verlag, pp. 69–94, doi:10.1007/3-540-28244-0_4, ISBN 3-540-25043-3
  14. ^ Aurum, Aybüke; Wohlin, Claes (2003-11-01). "The fundamental nature of requirements engineering activities as a decision-making process". Information and Software Technology. Eighth International Workshop on Requirements Engineering: Foundation for Software Quality. 45 (14): 945–954. doi:10.1016/S0950-5849(03)00096-X. ISSN 0950-5849.
  15. ^ "Communication difficulties". Preventing Exploitation Toolkit. Retrieved 2023-01-13.
  16. ^ Wiegers, Karl Eugene (2013). Software requirements. Joy Beatty (3th ed.). Redmond, Washington: Pearson Education. ISBN 978-0-7356-7962-7. OCLC 857497823.
  17. ^ Awais, Muhammad (2016). "Requirement Prioritization: Challenges and Techniques for Quality Software Development" (PDF). ACSIJ Advances in Computer Science: an International Journal. 5 (2).
  18. ^ Babar, Muhammad Imran; Ramzan, Muhammad; Ghayyur, Shahbaz A. K. (2011). "Challenges and future trends in software requirements prioritization". International Conference on Computer Networks and Information Technology. IEEE. doi:10.1109/iccnit.2011.6020888.
  19. ^ Bukhsh, Faiza Allah; Bukhsh, Zaharah Allah; Daneva, Maya (2020-03-01). "A systematic literature review on requirement prioritization techniques and their empirical evaluation". Computer Standards & Interfaces. 69: 103389. doi:10.1016/j.csi.2019.103389. ISSN 0920-5489.
  20. ^ a b c d Hudaib, Amjad; Masadeh, Raja; Qasem, Mais Haj; Alzaqebah, Abdullah (2018-01-15). "Requirements Prioritization Techniques Comparison". Modern Applied Science. 12 (2): 62. doi:10.5539/mas.v12n2p62. ISSN 1913-1852.
  21. ^ Qaddoura, Raneem; Abu-Srhan, Alaa; Qasem, Mais Haj; Hudaib, Amjad (2017). "Requirements Prioritization Techniques Review and Analysis". 2017 International Conference on New Trends in Computing Sciences (ICTCS). Amman: IEEE: 258–263. doi:10.1109/ICTCS.2017.55. ISBN 978-1-5386-0527-1.

Category:Product management Category:Software requirements

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Gekko416/Requirement_prioritization&oldid=1135416182"