1. Requirements
Wants versus Needs

2. The Problem
My stakeholders are treating my requirements like a wishlist.
ACTIVITY
Cite one example where stakeholders…
started off with too high for a project. (INITIAL SCOPE).
piled on requirements as the project went (SCOPE CREEP).
too narrowly defined a requirement, complicating it (GOLD PLATING).
took too long to agree on a requirement (DECISION ANALYSIS).

3. Challenge your stakeholders. Make your stakeholders prioritize.
The Solution
Challenge your stakeholders. Make your stakeholders prioritize.
ACTIVITY
In the previous examples, how would the best BA in the world have handled it?
started off with too high for a project. (INITIAL SCOPE).
piled on requirements as the project went (SCOPE CREEP).
too narrowly defined a requirement, complicating it (GOLD PLATING).
took too long to agree on a requirement (DECISION ANALYSIS).

4. Communicate
Tell your stakeholders in advance how and when you’ll deal with requirements, prioritization, and decision making. This is a constant, iterative process.
This is part of
BABOK v2
KA: Requirements Analysis
Task: Prioritize Requirements (6.1)
KA: BA Planning and Monitoring
Task: Plan BA Approach
KA: Enterprise Analysis
Task: Define Solution Scope (5.4)
KA: Solution Assessment and Validation
Task: Allocate Requirements
KA: Requirements Management & Communication
Task: Manage Solution Scope and Requirements
ACTIVITY:
Name 3 examples of times or situations that you’ll review/communicate the prioritization/scope process.
How would the best BA in the world communicate this in these situations?

5. Techniques and Tasks Timeboxing / Budgeting Voting Prioritization
These are per BABOK v2.
I’m still getting to know BABOK v3.

6. Technique: Budgeting / Timeboxing
A requirement is only a requirement IF we’re willing to pay for it.

7. Budgeting / Timeboxing
We pay for requirements in:
Cost to buy
Time to build
Complexity
Risk

8. Timeboxing
Timeboxing is fitting the development into a set amount of time. Requirements are developed in this timebox in order of importance. Example: What can we build in two weeks? This is great for setting expectations with stakeholders.
ACTIVITY:
What software development methodology relies heavily on this technique?
How could this be put to use in a more Plan-based approach such as waterfall?

9. Technique: Budgeting If requirements are always
infinite wants versus limited resources,
how do you start the discussion?
All in
All out
Selective

10. All In Budgeting
Start with all the requirements included in scope. Remove requirements until you meet the budget or calendar dates.

11. All Out Budgeting
Start with no requirements in scope. Add requirements until you max out the budget or time duration.

12. Selective Budgeting
Start with high priority requirements in scope. Add or remove requirements until the budget or time duration is met.

13. Opportunity Cost
Each requirement means another requirement, project, support function, etc that is delayed or cancelled.
Do your stakeholders understand that if we do X today, they have to wait before we start on Y?

14. Technique: MoSCoW Analysis
Categorize each requirement into
Must
Requirement must be included in the final solution to be successful.
Should
Requirement is a high priority, include if possible.
Could
Requirement is desirable but not necessary.
Won’t
Requirement that stakeholders agree is out of scope for the project.
People often think “Won’t” is for requirements that are written “The system shall NOT…”. This is incorrect. That would be a “Must” requirement.
ACTIVITY
You have limited resources and are trying to spin up an ecommerce site. Do a MoSCoW analysis on the following:
The system shall allow customers to pay with credit cards.
The system shall allow customers to pay with PayPal.
The system shall allow customers to leave reviews of products.
The system shall allow customers to submit their own pictures of products.
The system shall allow customers to check the status of their order.

15. Technique: MoSCoW Analysis
Good Rule of thumb:
Write your requirements
and then allocate them equally

16. Technique: Voting Who gets a say in the decision?
Does everyone have equal say?
How can we make this painless?
How can we speed up the decision making?

17. Priority Poker Stolen from Agile’s Planning Poker
Use cards to rank features against one another
Use cards numbered Ace, 2, 3, 5, 8, King
Values Ace through 8 represent the priority of the feature from low to high
King indicates the feature is a must-have
If all participants are within a card of each other, average the cards for a score.
For anyone much higher/lower than average, have them explain.
Revote if necessary.
Try to do this quickly

18. Monopoly Money Create baskets labeled with each feature.
Give each stakeholder a finite amount of play money.
Stakeholders use money to buy features.
Features can be broken into subfeatures/high level requirements

19. Task: Prioritization Basis for Prioritization Business Value
Regulatory or Policy Compliance
Business or Technical Risk
Relationship to Other Requirements
Implementation Difficulty
Stakeholder Agreement
Likelihood of Success
Urgency

20. Business Value Where is the return on investment for this requirement?
How does it stack up to other requirements?

21. Business or Technical Risk
Some projects focus on the highest project risks.
Requirements are prioritized so that the biggest risks are solved first.
Four Risk Strategies:
Avoid
Mitigate
Accept
Transfer

22. Implementation Difficulty
Develop the easiest requirements first.
Often used for new processes or tools.

23. Likelihood of Success The opposite of Business/Technical Risk
The project team focuses on the requirements most likely to succeed.
Very helpful when a project has a history or politics surrounding it.

24. Regulatory or Policy Compliance
Requirements that meet regulatory or policy demands are prioritized higher than other requirements.
Remember: Sometimes it’s cheaper to pay the fine than to fix the problem! Obamacare (if you never get sick) and parking in Boston are examples.

25. Relationship to Other Requirements
When a requirement isn’t a high priority itself, but supports a high priority requirement

26. Stakeholder Agreement
Let’s make a deal!
Often used along other bases

27. Urgency
Projects use this basis when time is an important factor.

28. Prioritization Challenges
Non-negotiable Demands What do you do when they’re all high priority requirements?

29. Prioritization Challenges
Unrealistic Tradeoffs What happens when the development team influences (intentionally or not) by over estimating the difficulty of implementing certain requirements?

30. Mathew McConnell
GIANT EAGLE Senior Business Analyst, Supply Chain Technologies PITTSBURGH CHAPTER OF THE IIBA VP of Marketing and Communication Find me on LinkedIn.