Requirement Management Guide
- Stakeholder roles and responsibilities
- Requirements gathering & management process
- Types of requirements
- Requirements artifacts
- Requirements naming and versioning convention
- Requirements prioritization
- Requirements traceability
- Requirements versioning
- Requirements baseline
6. Requirements prioritization
Requirements prioritization is the process of assembling requirements in ascending order of relative urgency and importance. Project constraints such as budget and time dictate the need for requirements prioritization. Clients and stakeholders usually believe all requirements to be both urgent and important, but the project and product development team need to prioritize some requirements to be implemented immediately and some to be reserved for a later release. This is because projects do not have unlimited resources, and prioritization of requirements is a way of maximizing the benefits from finite resources allotted to a particular iteration or release of a project. Requirements prioritization is an essential aspect of software release planning. The requirements that make the top of this list are given top priority, and the work for these requirements takes precedence over others.
It is vital for business analysts to understand the business case and the problem that the product will solve so that they can bridge the gap between the product development team and the stakeholders.
6.1 Factors Influencing requirements prioritization
According to the business analyst’s bible – Business Analysis Body of Knowledge® (BABOK® Guide) 3.0, there are eight factors that determine the priority of requirements. It suggests that the following factors influence requirement prioritization.
- Benefit – This is the advantage that the business will acquire if a particular requirement is fulfilled as a priority. The benefit that the implementation of a specific requirement can be in terms of functionality, quality, costs, time, and resources being utilized in the most optimal way or business goals.
- Penalty – The penalty is the disadvantage or the consequence of not implementing a requirement. Not prioritizing certain requirements can affect the project and the product negatively. Thus, the penalty that the project teams and stakeholders will have to pay is a crucial deciding factor in requirements prioritization. This penalty can be poor customer satisfaction, wastage, or over-expenditure of project resources or usability of the product.
- Risk – Whether the requirement will deliver the expected value or not is the risk. There can be several reasons why requirements may not be fulfilled, such as difficulty in understanding the requirement, execution of tasks of the requirement, to implementing the requirement.
- Dependencies – A dependency is a relationship between two requirements where one cannot be implemented successfully without the completion or implementation of the other one. Before beginning requirements prioritization, it is necessary to have a requirements dependency map.
- Time Sensitivity – Most of the time, the time constraint is the most crucial factor for requirements prioritization. Some requirements are urgent enough to be implemented before certain other ones. This is primarily in the case of projects and products that have to deal with seasonal requirements. In such cases, implementing certain requirements before a certain date or time is of utmost importance
- Stability – Stability is a factor of prioritizing requirements is the probability of the requirement remaining fixed and static so that requirements that are not stable or whose definition keeps changing take a lower priority to avoid repetition, rework, and wastage of time and resources.
- Regulatory/Policy Compliance -There are certain requirements that must compulsorily be met for the organization or the stakeholders to meet the regulatory or policy compliance. Policy compliance is an organization’s conformance to laws, trade, and such regulations, business policy guidelines for its routine business processes.
6.2 Who prioritizes requirements?
It is not the responsibility of the business analyst alone to undertake requirements prioritization. Prioritizing requirements must be done in conjunction and collaboration with all the key stakeholders, such as the clients, customer groups, product owners, executive project sponsors, users, and organizational representatives. Requirement prioritization is quite a task that requires analytical, technical, and social skills. The product development team and stakeholders must collaborate and compromise to accommodate the views and needs of both sides. The project team, especially the business analyst who acts as the facilitator of the requirements prioritization process, needs to understand the project scope and the business case clearly. There are various predefined requirements prioritization techniques to prioritize the requirements statistically.
6.3 Requirements prioritization techniques
- MoSCoW – This is the most commonly used method since it allows stakeholders to rate it in natural language levels of requirement priority such as Must, Should, Could, Would. The acronym MoSCoW stands for the same –
MUST – Requirements that must be completed at all costs, those that are mandatory, belong to this category.
SHOULD – Requirements that are of high priority, but not the highest – that should be completed because they are of high value to the customer. However, not implementing these requirements does not completely derail the product launch.
COULD – These requirements can be called ‘nice to haves’ and may or not be potentially included without too many consequences, efforts, or cost.
WON’T HAVE – Features that are requested but are not going to be included in this particular release. They can be postponed and included in later releases.
- Eisenhower decision matrix:
The Eisenhower decision matrix or the urgency and importance matrix is based on two main factors of decision making, the urgency and the importance of the requirement. Based on this four-quadrant matrix, requirements can be divided into four types:
Priority level 1: Urgent, important: The urgent and important requirements absolutely need to be fulfilled. These are usually about compliance, policy, or adherence to laws.
Priority level 2: Urgent, not important: These requirements are time-sensitive and hence need to implemented first but are not that important for the project or product.
Priority level 3: Not Important, urgent: Requirements that are important to the product but are not immediately required to be implemented.
Priority level 4: Not important, not urgent: These requirements are not urgent nor important and can be skipped for the release entirely.
- Timeboxing and budgeting:
The timeboxing or fixed budgeting process is deployed when there are tight deadlines and budget constraints applied to the project deliverables. This technique suggests having the most essential and the most basic product features in the product and launch it on time rather than implementing all features together and launching the product at a later date. The idea is to move the critical features to earlier phases of implementation to ensure that at least these are completed in an ideal manner at the time of product launch.
- 100 – Point method:
This is the simplest method of requirements prioritization and works best when there are a lot of requirements. Each stakeholder is given a collection of points, say 100 points, and is supposed to allot points to each requirement based on how important it is to him, out of the 100. In the end, each requirement gets points assigned, and all 100 points are accounted for.
- Five Whys:
This method includes asking the question ‘why’ to the stakeholders to get to the root of why they insist on a certain requirement’s importance. The Five Whys method is especially helpful when stakeholders insist that certain requirements are important. However, the business analyst and the product team do not find them essential to the product, business case, or in the best interest of the business. In such cases, to understand the needs of the stakeholders and reasons behind pushing the implementation of some requirements clearly, the Five Whys method works wonders.
- Bubble sort:
The bubble sort technique is based on the comparison of two requirements and swapping the one with the most important to have more priority than the other. Such a comparison is carried out until the very last requirement is sorted. This exercise gives a list of requirements that are ranked in order of importance.
Requirements prioritization guarantees that the most critical and crucial requirements are taken care of immediately so as not to risk running out of budgets and time.