Prioritize Requirements - Business Analyst


Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements.


Requirement prioritization is a decision process used to determine the relative importance of requirements. The importance of requirements may be based on their relative value, risk, difficulty of implementation, or on other criteria.

These priorities are used to determine which requirements should be targets for further analysis and to determine which requirements should be implemented first.


Business Case: The business case states the key goals and measures of success for a project or organization, and priorities should be aligned with those goals and objectives.

Business Need: Serves as an alternative to the business case if no business case has been defined.

Requirements: Any requirement may be prioritized, it any point in its lifecycle. Requirements prioritization requires that requirements have been stated by stakeholders; however, the requirements may not have been fully analyzed or in their final form.

Requirements Management Plan: Defines the process that will be used to prioritize requirements.

Stakeholder List, Roles, and Responsibilities: The list of stakeholders, annotated with their levels of authority and influence, is used to determine which stakeholders need to participate in prioritization.


1. Basis for Prioritization.

Requirements may be prioritized using a number of different criteria, including:

Business Value: This approach prioritizes requirements based on cost - benefit analysis of their relative value to the organization. The most valuable requirements will be targeted for development first. This approach is common when enhancing an existing solution that already meets specified minimal requirements, or when delivering the solution incrementally.

Business or Technical Risk: This approach selects requirements that present the highest risk of project failure. Those requirements are investigated and implemented first to ensure that if the project fails it does so after as little expenditure as possible.

Implementation Difficulty: This approach selects requirements that are easiest to implement. This approach is often selected during a pilot of a new development process or tools or when rolling out a packaged solution, as it allows the project team to gain familiarity with those things while working on lower - risk requirements.

Likelihood of Success: This approach focuses on the requirements that are likely to produce quick and relatively certain successes. It is common when a project is controversial and early signs of progress are needed to gain support for the initiative.

Regulatory or Policy Compliance: This approach prioritizes 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.

Relationship to Other Requirements: A requirement may not be high value in and of itself, but may support other high - priority requirements and as such may be a candidate for early implementation.

Stakeholder Agreement: This approach requires the stakeholders to reach a consensus on which requirements are most useful or valuable. It is often used in combination with one or more of the other approaches described above.

Urgency: This approach prioritizes requirements based on time sensitivity.


Challenges in facilitating a requirements prioritization session include:

Non-negotiable Demands: Stakeholders attempt to avoid difficult choices, fail to recognize the necessity for making tradeoffs, or desire to rank all requirements as high priority.

Unrealistic Tradeoffs: The solution development team may intentionally or unintentionally try to influence the result of the prioritization process by overestimating the difficulty or complexity of implementing certain requirements.


1. General Techniques

Decision Analysis : Decision analysis may be used to identify high - value requirements.

Risk Analysis : Requirements that are considered risky may need to be investigated or implemented first, so that if risks cause the project to fail, the organization has invested as little as possible at that point.

2. MoSCoW Analysis

MoSCoW analysis divides requirements into four categories: Must, Should, Could, and Won’t. Category descriptions are as follows:

Must: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

Should: Represents a high - priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

Could: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

Won’t: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

3. Timeboxing / Budgeting

Timeboxing or budgeting prioritizes requirements for investigation and implementation based on allocation of a fixed resource. It is used when the solution approach has been determined. Timeboxing prioritizes requirements based on the amount of work that the project team is capable of delivering in a set period of time. By contrast, budgeting is used when the project team has been allocated a fixed amount of money. The approach is most often used when a fixed deadline must be met or for solutions that are enhanced on a regular and frequent basis. There are a number of approaches that can be taken to determine which requirements can be included in a timeboxed iteration:

  • All In: Begin with all the eligible requirements with assigned Duration or Cost. Remove the requirements in order to meet the calendar dates or budget limit.
  • All Out: Begin with adding the requirement(s) with assigned duration or cost to the calendar or budget. Stop when the calendar dates are met or budget limit is reached.
  • Selective: Begin by identifying high priority requirements added to the calendar or budget. Add or remove requirements in order to meet the calendar date or budget limit.

4. Voting

Voting methods allocate a fixed amount of resources (votes, play money, or other tokens) to each participant for them to distribute among proposed features or requirements.

The requirements that receive the most resources are the ones that will be investigated or developed first.


Domain SME: Domain subject matter experts may be invited to participate in the prioritization of requirements, to assess the relative business need, and to negotiate their importance.

Implementation SME: Implementation subject matter experts may be asked to evaluate the relative complexity or risk associated with the implementation of certain requirements.

Project Manager: The project manager is responsible for the implementation of the solution and will use the priority of requirements as an input into the project plan.

Sponsor: Since sponsors are ultimately accountable for the business solution and major project decisions, they need to be invited to participate in the discussion.


Requirements [Prioritized]: A prioritized requirement has an attribute that describes its relative importance to stakeholders and the organization. At the completion of this task, each requirement should have an assigned priority. The priorities may apply to a requirement or to a group or related requirements.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Business Analyst Topics