Chapter 10 — Requirements Prioritization

01

Why Prioritize Requirements?

Requirements prioritization is necessary because resources are always limited and you can rarely implement everything. Here are the core difficulties:

🚫 Structural Difficulties

Too many requirements from too many sources
Resources are limited (budget, time, people)
Developers may not know the business value of requirements
Clients may not know the implementation complexity
Companies often lack systematic data and metrics to support prioritization
Often done manually, informally, on an ad-hoc basis

👥 Human & Political Difficulties

Different stakeholders have conflicting goals and priorities
Some stakeholders' decisions carry more weight than others
Difficult to establish and communicate priorities
Attitude problem: "No need for priorities, we can do everything!" — until the deadline arrives
When the deadline approaches, requirements get cut chaotically instead of strategically

💡

What Prioritization Must Help You Do

Make acceptable trade-offs among value, cost, and time-to-market · Allocate resources based on importance · Determine when a requirement should become part of the product · Offer the right product at the right time.

The 80-20 Rule (Pareto Principle) IMPORTANT

20%

of functionalities provide

80% of revenues

80%

of functionalities provide only

20% of value

20% of Cause	80% of Effect
Criminals	Crimes
Drivers	Accidents
Factories	Pollution
Company products	Overall sales
Employees	Accomplished results

🚫

The 80% Trap

The remaining 80% of functionalities offer a lower return on investment while adding delays, development costs, and maintenance costs. Think of MS Word — how many features do you actually use? The challenge is finding and focusing on the impactful 20%.

02

Requirements Triage

Requirements prioritization is also called triage — a medical term for sorting patients by urgency. In RE it means deciding which requirements really matter and which should be implemented in the current release.

⚡ Requirements Triage Process — Must Be

Simple and fast for industry adoption
Accurate and reliable results
Consider the value of requirements to stakeholders (maximize)
Consider the cost of implementation (minimize)
Consider time to market (minimize)
Important to agree on requirements granularity first (e.g., use cases, features, or detailed functional requirements)

🔍

High Value, Low Cost = Top Priority

The highest priority requirements are those that provide the largest fraction of total product value at the smallest fraction of total cost. Visualize a Cost vs. Value matrix and target the high-value, low-cost quadrant.

🏠

Volvo Car Example — Cost Complexity vs. Customer Value

Volvo mapped car components on a matrix of Customer Value (Y-axis) vs. Cost Complexity (X-axis). Components in the top-left (high value, low cost) were prioritized as "Platform-Strategy-/-Profitable-Proliferation." Components in the bottom-right (low value, high cost) were flagged to avoid. This is a real-world application of the triage principle.

03

1st Technique — Prioritization Scales

The simplest technique: define criteria and a scale, then assign every requirement a rating. Two commonly used dimensions are Urgency and Importance.

⏱ Urgency Scale

High — Mission critical; required for next release
Medium — Supports necessary operations; required eventually but could wait
Low — Functional or quality enhancement; nice to have if resources permit

⭐ Importance Scale

Essential — Product unacceptable unless these requirements are satisfied
Conditional — Would enhance the product but product is acceptable without it
Optional — Functions that may or may not be worthwhile

💡

Small Projects vs. Large Projects

On a small project, stakeholders can agree informally on priorities. On large or contentious projects with many stakeholders, a more structured approach is needed to remove emotion, politics, and guesswork from the process.

04

2nd Technique — Wiegers' Prioritization KEY

A semi-quantitative analytical approach to requirements prioritization based on value, cost, and risk. Relies on estimating relative priorities rather than absolute ones.

📊 The 4 Dimensions (each scored 0–9)

Relative Benefit — value gained by having this requirement
Relative Penalty — harm to stakeholders if requirement is NOT included

Relative Cost — effort to implement this requirement
Relative Risk — technical and other risks involved

Wiegers Priority Formula

Priority = Value% ÷ ( (Cost% × CostWeight) + (Risk% × RiskWeight) )

Value% = (Benefit × BenefitWeight + Penalty × PenaltyWeight) / TotalValue · Relative Weights: Benefit=2, Penalty=1, Cost=1, Risk=0.5

Chemical Tracking System Example:

Feature	Rel. Benefit	Rel. Penalty	Value %	Rel. Cost	Cost %	Rel. Risk	Risk %	Priority
1. Query vendor order status	5	3	8.4	2	4.8	1	3.0	1.345 ▲
2. Generate stockroom inventory	9	7	16.2	5	11.9	3	9.1	0.987
4. Print chemical safety datasheet	2	1	3.2	1	2.4	1	3.0	0.833
8. Search vendor catalogs	9	8	16.9	7	16.7	8	24.2	0.586 ▼
10. Import from drawing tools	7	4	11.7	9	21.4	7	21.2	0.365 ▼

Feature #1 has the highest priority (1.345) despite moderate benefit — because its cost and risk are very low. Feature #10 has the lowest priority (0.365) because it has high cost AND high risk.

✔ Strengths

Systematic and analytical — removes some emotion and politics
Considers multiple dimensions simultaneously
Produces ranked, comparable priorities
Can be adapted with different weights for different projects

✘ Limitations

Still limited by ability to properly estimate values
Interdependent requirements difficult to treat individually
Inconsistencies between individual stakeholder estimates
Requires adaptation and calibration per project

📋 Volere Prioritization Spreadsheet

A weighted spreadsheet approach using 4 factors totaling 100% weight:

Factor	Weight	Description
Value to Customer	40%	How much does the customer want this?
Value to Business	20%	How much will the business benefit?
Minimize Implementation Cost	10%	Lower cost = higher priority contribution
Ease of Implementation	30%	Technical and organizational ease

Priority Rating = Sum of (score × weight%) for each factor. Higher score = higher priority. In the example, Requirement 6 scored highest at 6.9.

05

3rd Technique — Kano Surveys KEY

The Kano Model groups requirements based on customer perception in order to select requirements that deliver the greatest customer satisfaction. It uses a survey with paired questions.

🔵 Basic

Requirements the customer takes for granted. If absent, extreme dissatisfaction. If present, no extra satisfaction (expected). Example: a car must have brakes.

📈 Performance

Requirements the customer specifically asked for. More = better satisfaction. Example: better fuel economy = happier customer.

🤩 Excitement

Requirements the customer does not request or expect. Surprise and delight when present, no dissatisfaction if absent. Example: unexpected premium feature.

🔜 Indifferent

Requirements the customer does not care about. Present or absent — makes no difference to satisfaction.

😖 Reverse

"Requirements" the customer actively dislikes. Including them causes dissatisfaction. These should be avoided entirely.

How Kano Surveys Work:

❓ The Two Questions for Each Requirement

Functional question: "What-is-your-reaction-if-this-requirement-IS-included-in-the-product"

Dysfunctional question: "What-is-your-reaction-if-this-requirement-is-NOT-included"

For each, possible answers are:

I like it I expect it I am neutral I can tolerate it I dislike it

Kano Conclusions Matrix:

Functional ↓ Dysfunctional →	Like	Expect	Neutral	Tolerate	Dislike
Functional ↓ Dysfunctional →	Like	Questionable	Excitement	Excitement	Excitement	Performance
Expect	Reverse	Questionable	Indifferent	Indifferent	Basic
Neutral	Reverse	Indifferent	Indifferent	Indifferent	Basic
Tolerate	Reverse	Indifferent	Indifferent	Questionable	Basic
Dislike	Reverse	Reverse	Reverse	Reverse	Questionable

🏆

Priority Order of Kano Categories

Basic > Performance > Excitement > Indifferent > Reverse
Always satisfy Basic requirements first (table stakes), then Performance, then Excitement (delighters). Ignore Indifferent. Avoid Reverse.

💡

Memory Trick — Kano BPEIR

Basic (take for granted) · Performance (asked for) · Excitement (unexpected delight) · Indifferent (don't-care)-·-Reverse-(hate-it).-Remember:-"Be Perfectly Excited, Ignore Reverse."

06

4th Technique — Three-Level Scale KEY

Groups requirements into High, Medium, and Low priority based on two dimensions: Importance (does the customer need it?) and Urgency (do they need it in the next release?).

⚠️

Important Caveat

This scale is subjective and imprecise. Stakeholders must agree on what each level means before using it. Without agreement, the labels mean different things to different people.

The Importance × Urgency Matrix:

Urgent

Not Urgent

Important

Not Important

High Priority

H

Implement now

☠ Don't Do These!

💀

Urgent but not important

Medium Priority

M

Important, next release

Low Priority

L

Neither urgent nor important

🟢 High Priority

Both important AND urgent
Must be in the next release or that release is not shippable
Contractual or compliance obligations may dictate inclusion

💀 4th Quadrant (Urgent + Not Important)

Appear urgent to some stakeholders but don't achieve business objectives
Don't-waste-time-on-these-—-they-don't add sufficient value
Either set to Low priority or scrub them entirely

🔄 Iterative Prioritization — When Too Many Are "High"

Include the priority of each requirement in your SRS
Perform prioritization iteratively, especially on large projects
If the number of high-priority requirements is excessive, re-prioritize the high group to divide them into 3 sub-classes: Highest, Higher, High
"Highest" becomes your new top priority; "Higher" and "High" merge with your original medium requirements
High priority definition: "Must be in the next release or that release is not shippable"

07

Other Criteria to Consider

The cost/benefit approach is good but sometimes insufficient. These additional criteria should be considered when prioritizing:

💵 Financial

Cost of implementation — how much to develop?
Value to customer — how much does the customer want it?
Value to company — how much will the business benefit?

⏱ Time & Technical

Time to implement — how long to deliver?
Ease of implementation at the technical level
Ease of implementation at the organizational level (business process changes)

⚖ Legal & Strategic

Obligation to external authority — laws, standards, patents, compliance requirements
Strategic competitive advantage — differentiating the product in the market
Risk — ISO 31000: "the effect of uncertainty on objectives" (includes positive AND negative outcomes)

📜

Risk (ISO 31000:2009)

Risk is no longer just "probability of loss" — it's the "effect of uncertainty on objectives", which means risk includes both negative threats and positive opportunities. In prioritization: identify, characterize uncertainty (threats/opportunities), assess susceptibility, determine potential damage/gain × probability, and identify ways to reduce negative risks.

08

Optional Self-Study Techniques OPTIONAL

These techniques are listed as optional self-study in the slides but are worth knowing:

🔴

In or Out

Binary: is each requirement in scope or out?

⚖

Pairwise Comparison & Rank Ordering

Compare every requirement pair by pair

🧶

MoSCoW

Must / Should / Could / Won't

💵

$100 Method

Distribute $100 among requirements

📊

AHP (Analytic Hierarchy Process)

Mathematical multi-criteria approach

💻 Commercial Tool: TeamBLUE Focal Point

Decision support and portfolio management tool
Pairwise comparisons of features with dynamic algorithm (reduces pairs based on responses)
Creation and validation of web questionnaires
Detection of inconsistency between answers
Priorities for different markets, represented in various ways
Integrates with IBM DOORS (requirements management tool)

09

Techniques Comparison Summary

#	Technique	Type	Best For	Key Limitation
1	Prioritization Scales Urgency/Importance	Subjective	Small teams, quick decisions, early-stage projects	Imprecise; stakeholders must agree on meaning of each level
2	Wiegers'-Prioritization Value / Cost / Risk formula	Semi-quantitative	Large projects needing analytical, formula-based ranking	Requires calibration; still depends on estimates; interdependencies are hard
3	Kano Surveys Customer perception model	Survey-based	Customer-facing products; understanding satisfaction drivers	Time-consuming survey; requires a representative customer sample
4	Three-Level Scale H/M/L × Importance/Urgency	Subjective	Most projects; iterative; easy to communicate to stakeholders	Subjective; "High" bucket can get bloated without iterative refinement

10

Study Tips & Memorization Tricks 🧠

💡 80-20 Is a Mindset

Remember: 20% of features = 80% of value. Your job in prioritization is to find and protect that 20%. The other 80% add cost and delay.

💡 Triage = Medical Analogy

Triage comes from medicine — sorting patients by urgency. In RE, you triage requirements: critical ones first, nice-to-haves later or never.

💡 Wiegers Formula Shortcut

Priority = Value / (Cost + Risk). High value + low cost + low risk = top priority. Use weights: Benefit × 2, Penalty × 1, Cost × 1, Risk × 0.5.

💡 Kano BPEIR

"Be Perfectly Excited, Ignore Reverse." Basic > Performance > Excitement > Indifferent > Reverse. The survey uses functional + dysfunctional question pairs.

💡 3-Level = Importance × Urgency

High = Important AND Urgent. Medium = Important, Not Urgent. Low = Not Important, Not Urgent. 4th quadrant (Urgent, Not Important) = AVOID — that's the skull quadrant.

💡 When Too Many Are "High"

Prioritize the prioritized! Re-run the 3-level scale on your High group to get Highest/Higher/High. Then "Higher" and "High" drop down to become Medium.

💡 Kano: Basic vs. Performance

Basic = taken for granted (absence = disaster, presence = neutral). Performance = the more the better (linear). Excitement = surprise delight (presence = joy, absence = fine).

💡 Small vs. Large Projects

Small project = informal agreement is fine. Large/contentious project = use structured analytical methods (Wiegers, Kano) to remove emotion and politics.

🎯 Exam-Likely Questions for Chapter 10

What is requirements prioritization and why is it necessary?
What does the 80-20 rule mean in the context of requirements prioritization?
What is "triage" in the context of RE? What must the triage process ensure?
What are the 4 dimensions of Wiegers' prioritization and the formula?
What are the 5 Kano categories? How are they ordered by priority?
How does a Kano survey work? What are the two question types asked?
What does the Kano conclusions matrix produce?
Explain the Three-Level Scale (H/M/L) using the Importance × Urgency matrix.
What should you do with requirements in the "Urgent but Not Important" quadrant?
What do you do when too many requirements are classified as High priority?
What are the difficulties of requirements prioritization?
What is the ISO 31000 definition of risk and how does it differ from the traditional definition?