Requirement Prioritization Techniques

Today, it is time to describe the requirement prioritization techniques. We can transmit them using a number of techniques. Those are as follows:


This technique consists in a selected group of stakeholders determining the available priorities for the requirements according to the adopted criteria.


This technique consists in stakeholders selecting the most important requirements defined according to the adopted criteria. For these requirements, their ranking is defined by describing the validity of requirements with regard to specific criteria.

Classification of a single criterion

In this requirement prioritization techniques, the requirements are assigned a priority depending on the impact of implementing a given requirement on the success of the system being created. The requirements are given one of the three available priorities:

  • Mandatory requirements must be implemented regardless of costs and are necessary for the success of the system being created.
  • Optional: An optional requirement specifies a requirement that does not necessarily have to be implemented. The omission of several optional requirements does not affect the success of the system being created.
  • Nice-To-Have: Requirements that do not affect the success of the system being created if they are not implemented.

Priority matrix according to Wiegers

The essence of this requirement prioritization techniques is the priority matrix, thanks to which the rank of individual requirements can be calculated on the basis of specific criteria and weight for these criteria.

Using Wiegers’ priority matrix is ​​very time-consuming compared to previous techniques; therefore, it should be used in cases where previous techniques did not yield the expected results. An example of a hierarchy of priorities by Wiegers [Picture and description comes from “Requirements Engineering Fundamentals” Klaus Pohl, Chris Rupp]

Calculation of priorities in a prioritization matrix according to Wiegers

The calculation of priorities in a prioritization matrix according to Wiegers can be performed as follows:

  1. Determine the relative weights for the benefit, detriment, cost, and risk.
  2. Determine the requirements to be prioritized.
  3. Estimate the relative benefit.
  4. Estimate the relative detriment.
  5. Calculate the total values and percentage values for each requirement: Value%(Ri) =Benefit(Ri) ×WeightBenefit + Detriment(Ri) × WeightDetriment
  6. Estimate the relative cost and calculate the cost percentage for each requirement.
  7. Estimate the relative risks and calculate the risk percentage for each requirement. Calculate the individual requirement priorities:
    Priority(Ri)=Value%(Ri)/(Cost%(Ri) ×WeightCost + Risk%(Ri) ×WeightRisk)
  8. Assert the rank of the individual requirements.

In my experience, the technique of a single criterion works best. By setting the value of the criterion, I negotiate the value of the criterion for each requirement with the stakeholders.

More from my site

  • Categorization of Requirements According to the Kano Model Defining the requirements that will increase the satisfaction of stakeholders from the system being created is crucial for the process of acquiring requirements. Implementation of too many […]
  • Requirements Documentation Based on Use Cases Use cases are used to document the functionality of the system and are based on two commonly used concepts: Use case diagramsSpecifications of use cases Objects Use case: The use […]
  • Business Requirements vs System Requirements There is a lot of talk about the need to identify project goals, organization goals and the need to identify business and system requirements. All in order to better understand the […]
  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]
  • User Stories vs Requirements When writing any specification of requirements and the product register and sprint register, non-functional requirements should be included in this specification. While the user's […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top