Business Analysis 101: Requirements Life Cycle Management - Prioritizing Requirements, MoSCoW, Kano, Backlog Ordering

## What This Is
Prioritizing requirements is the systematic way a Business Analyst (BA) decides which needs will be delivered first, later, or not at all. It sits in the Requirements Life Cycle Management knowledge area and directly influences the solution scope, schedule, and budget.
Real?world example: A financial services firm is rolling out a new Customer Relationship Management (CRM) system. The BA must decide whether “real?time credit?score lookup” (must?have) or “customizable dashboard widgets” (could?have) should be built in the first release.

## Key Terms & Techniques

• MoSCoW – A four?tier classification (Must, Should, Could, Won’t) used to rank requirements; belongs to Requirements Life Cycle Management; deliverable: Prioritization Matrix.
• Kano Model – Categorises features as Basic, Performance, or Delighters based on customer satisfaction; part of Stakeholder Analysis and Requirements Analysis; deliverable: Kano Diagram.
• Backlog Ordering – The act of arranging product backlog items (PBIs) by value, risk, and effort; falls under Solution Evaluation and Agile practices; deliverable: Ordered Product Backlog.
• Weighted Scoring – Assigns numeric weights to criteria (e.g., ROI, compliance) and scores each requirement; used in Business Analysis Planning & Monitoring; deliverable: Scoring Sheet.
• Value?vs?Complexity Matrix – Plots requirements on a 2?axis chart to visualise high?value/low?effort items; linked to Requirements Analysis; deliverable: Prioritization Quadrant.
• Stakeholder Map – Visual representation of stakeholder influence and interest; informs who gets to vote on priorities; part of Stakeholder Analysis; deliverable: Stakeholder Influence Diagram.
• Definition of Ready (DoR) – Criteria that a requirement must meet before it can be taken into a sprint; belongs to Solution Scope; deliverable: DoR Checklist.
• Definition of Done (DoD) – Acceptance criteria that signal completion; part of Solution Evaluation; deliverable: DoD Document.
• Business Value – The measurable benefit (e.g., revenue, cost?avoidance) a requirement delivers; core to Strategy Analysis; deliverable: Business Value Statement.
• Risk?Adjusted Prioritization – Adjusts priority scores based on risk exposure; used in Risk Management; deliverable: Risk?Adjusted Scorecard.

## Step?by?Step / Process Flow

1. Gather Input & Identify Stakeholders – Review the Stakeholder Register and collect business goals, constraints, and initial requirement ideas.
2. Select Prioritization Technique(s) – Choose MoSCoW, Kano, Backlog Ordering, or a hybrid (e.g., MoSCoW + Weighted Scoring) based on project size, methodology, and stakeholder preferences.
3. Facilitate a Prioritization Workshop – Run a structured session (often with voting cards or online polling) where participants apply the chosen technique to each requirement.
4. Document the Prioritized List – Capture the outcome in a Prioritized Requirements Document (or ordered backlog) and note any “must?have” constraints that affect scope.
5. Validate & Baseline – Review the prioritized list with the sponsor and key stakeholders; obtain sign?off and baseline it as an input to the Solution Scope and Release Plan.

## Common Mistakes

• Mistake: Treating “Must” as synonymous with “high?value” in MoSCoW.
  Correction: “Must” reflects regulatory or contractual necessity; value is captured separately (e.g., Business Value).

• Mistake: Using Kano only for UI features and ignoring core functional requirements.
  Correction: Apply Kano to any requirement that impacts user satisfaction, but still classify essential functional needs as Basic in the model.

• Mistake: Ordering the backlog solely by stakeholder preference without considering effort or risk.
  Correction: Combine stakeholder ranking with effort estimates (e.g., Story Points) and risk adjustments to produce a realistic delivery order.

• Mistake: Skipping the “Won’t” category and assuming everything will be built later.
  Correction: Explicitly capture “Won’t” items to protect scope and to provide a clear reference for future phases.

• Mistake: Forgetting to revisit priorities after a change request.
  Correction: Re?run the prioritization technique (or a quick re?score) whenever a significant change is introduced, per BABOK’s Requirements Life Cycle Management guidance.

## Certification Exam Tips

1. Know the Knowledge Area – Prioritization techniques belong to Requirements Life Cycle Management; exam questions often ask “Which BABOK knowledge area addresses this activity?”
2. Distinguish MoSCoW from Kano – MoSCoW is a categorisation method; Kano is a customer?satisfaction model. Look for keywords like “delighter” or “must?be” to pick the right answer.
3. Remember the Input/Output – Input: Stakeholder Requirements, Business Objectives, Constraints. Output: Prioritized Requirements (or Ordered Backlog). Exam traps often swap these.
4. Agile vs. Waterfall – In Agile, “Backlog Ordering” is the primary technique; in predictive projects, you’ll see MoSCoW or Weighted Scoring more often.

## Quick Check Questions

1. Scenario: After a requirements workshop, the sponsor insists that a “mobile?first UI” be delivered in the first release, but the development team warns it will double the effort. Which technique should the BA use to resolve the conflict?
   Answer: Weighted Scoring (or a Value?vs?Complexity matrix).
   Justification: It quantifies business value against effort, allowing an objective discussion of trade?offs.

2. Scenario: A banking application’s new feature list includes “account balance display” (basic), “instant fraud alerts” (performance), and “personalized greeting messages” (delighter). Which model is being applied?
   Answer: Kano Model.
   Justification: The classification of basic, performance, and delighter aligns directly with Kano categories.

3. Scenario: The product owner asks the BA to mark items that will never be built in the current project. Which MoSCoW category is appropriate?
   Answer: Won’t.
   Justification: The “Won’t” bucket explicitly captures out?of?scope items for the current release.

## Last?Minute Cram Sheet

1. Requirements Life Cycle Management = where prioritization lives.
2. MoSCoW = Must, Should, Could, Won’t (categorisation).
3. Kano = Basic, Performance, Delighter (customer?satisfaction).
4. Backlog Ordering = Agile?specific, produces an Ordered Product Backlog.
5. Weighted Scoring = numeric weighting of criteria-Scoring Sheet.
6. Value?vs?Complexity Matrix = visual high?value/low?effort quadrant.
7. Input-Prioritized Requirements-Output (BABOK flow).
8. Definition of Ready (DoR) = pre?sprint entry criteria; Definition of Done (DoD) = completion criteria.
9. Exam trap: “MoSCoW is a technique for estimating effort” – it is for prioritizing need, not estimating.
10. Exam trap: “Kano replaces stakeholder analysis” – Kano complements stakeholder analysis; it does not replace it.