Chapter 5 – 5.3 – Prioritize Requirements

5.3.1 Purpose

The purpose of Prioritize Requirements is to rank requirements in the order of relative importance.

5.3.2 Description

Prioritization is the act of ranking requirements to determine their relative importance to stakeholders. When a requirement is prioritized, it is given greater or lesser priority. Priority can refer to the relative value of a requirement, or to the sequence in which it will be implemented. Prioritization is an ongoing process, with priorities changing as the context changes.

Inter-dependencies between requirements are identified and may be used as the basis for prioritization. Prioritization is a critical exercise that seeks to ensure the maximum value is achieved.

5.3.3 Inputs

Requirements: any requirements in the form of text, matrices, or diagrams that are ready to prioritize.
Designs: any designs in the form of text, prototypes, or diagrams that are ready to prioritize.

5.3.4 Elements

.1 Basis for Prioritization

The basis on which requirements are prioritized is agreed upon by relevant stakeholders as defined in the Business Analysis Planning and Monitoring knowledge area.

Typical factors that influence prioritization include:

Benefit: the advantage that accrues to stakeholders as a result of requirement implementation, as measured against the goals and objectives for the change. The benefit provided can refer to a specific functionality, desired quality, or strategic goal or business objective. If there are multiple stakeholders, each group may perceive benefits differently. Conflict resolution and negotiation may be employed to come to consensus on overall benefit.
Penalty: the consequences that result from not implementing a given requirement. This includes prioritizing requirements in order to meet regulatory or policy demands imposed on the organization, which may take precedence over other stakeholder interests. Penalty may also refer to the negative consequence of not implementing a requirement that improves the experience of a customer.
Cost: the effort and resources needed to implement the requirement. Information about cost typically comes from the implementation team or the vendor. Customers may change the priority of a requirement after learning the cost. Cost is often used in conjunction with other criteria, such as cost-benefit analysis.
Risk: the chance that the requirement cannot deliver the potential value or cannot be met at all. This may include many factors such as the difficulty of implementing a requirement, or the chance that stakeholders will not accept a solution component. If there is a risk that the solution is not technically feasible, the requirement that is most difficult to implement may be prioritized to the top of the list in order to minimize the resources that are spent before learning that a proposed solution cannot be delivered. A proof of concept may be developed to establish that high risk options are possible.
Dependencies: relationships between requirements where one requirement cannot be fulfilled unless the other requirement is fulfilled. In some situations, it may be possible to achieve efficiencies by implementing related requirements at the same time. Dependencies may also be external to the initiative, including but not limited to other teams’ decisions, funding commitments, and resource availability. Dependencies are identified as part of the task Trace Requirements (p. 79).
Time Sensitivity: the ‘best before’ date of the requirement, after which the implementation of the requirement loses significant value. This includes time-to-market scenarios, in which the benefit derived will be exponentially greater if the functionality is delivered ahead of the competition. It can also refer to seasonal functionality that only has value at a specific time of year.
Stability: the likelihood that the requirement will change, either because it requires further analysis or because stakeholders have not reached a consensus about it. If a requirement is not stable, it may have a lower priority in order to minimize unanticipated rework and wasted effort.
Regulatory or Policy Compliance: requirements that must be implemented in order to meet regulatory or policy demands imposed on the organization, which may take precedence over other stakeholder interests.

.2 Challenges of Prioritization

Prioritization is an assessment of relative value. Each stakeholder may value something different. When this occurs, there may be conflict amongst stakeholders. Stakeholders may also have difficulty characterizing any requirement as a lower priority, and this may impact the ability to make necessary trade-offs. In addition, stakeholders may (intentionally or unintentionally) indicate priority to influence the result to their desired outcome.

Different types of requirements may not all respond to the criteria in the same way and may appear to conflict. There may be a need for stakeholders to make trade-offs in prioritization.

.3 Continual Prioritization

Priorities may shift as the context evolves and as more information becomes available. Initially, prioritization is done at a higher level of abstraction. As the requirements are further refined, prioritization is done at a more granular level and will incorporate additional bases for prioritization as they become appropriate. The basis for prioritization may be different at various stages of the change. For example, stakeholders may initially prioritize based on benefits. The implementation team may then re-prioritize the requirements based on the sequence in which they must be implemented due to technical constraints. Once the implementation team has provided the cost of each requirement, the stakeholders may re-prioritize yet again.

5.3.5 Guidelines and Tools

Business Constraints: regulatory statutes, contractual obligations and business policies that may define priorities.
Change Strategy: provides information on costs, timelines, and value realization which are used to determine priority of requirements.
Domain Knowledge: knowledge and expertise of the business domain needed to support prioritization.
Governance Approach: outlines the approach for prioritizing requirements.
Requirements Architecture: utilized to understand the relationship with other requirements and work products.
Requirements Management Tools/Repository: including a requirements attribute for prioritization can help the business analyst to sort and access requirements by priority.
Solution Scope: considered when prioritizing requirements to ensure scope is managed.

5.3.6 Techniques

Backlog Management: used to compare requirements to be prioritized. The backlog can be the location where the prioritization is maintained.
Business Cases: used to assess requirements against identified business goals and objectives to determine importance.
Decision Analysis: used to identify high-value requirements.
Estimation: used to produce estimates for the basis of prioritization.
Financial Analysis: used to assess the financial value of a set of requirements and how the timing of delivery will affect that value.
Interviews: used to gain an understanding of a single or small group of stakeholders’ basis of prioritization or priorities.
Item Tracking: used to track issues raised by stakeholders during prioritization.
Prioritization: used to facilitate the process of prioritization.
Risk Analysis and Management: used to understand the risks for the basis of prioritization.
Workshops: used to gain an understanding of stakeholders’ basis of prioritization or priorities in a facilitated group setting.

5.3.7 Stakeholders

Customer: verifies that the prioritized requirements will deliver value from a customer or end-user perspective. The customer can also negotiate to have the prioritization changed based on relative value.
End User: verifies that the prioritized requirements will deliver value from a customer or end-user perspective.
Implementation Subject Matter Expert: provides input relating to technical dependencies and can negotiate to have the prioritization changed based on technical constraints.
Project Manager: uses the prioritization as input into the project plan and into the allocation of requirements to releases.
Regulator: can verify that the prioritization is consistent with legal and regulatory constraints.
Sponsor: verifies that the prioritized requirements will deliver value from an organizational perspective.

5.3.8 Outputs

Requirements (prioritized): prioritized or ranked requirements are available for additional work, ensuring that the highest valued requirements are addressed first.
Designs (prioritized): prioritized or ranked designs are available for additional work, ensuring that the highest valued designs are addressed first