Stakeholder WinWin Requirements Nupul Kukreja 3 rd November, 2014
Stakeholder WinWin Requirements
Nupul Kukreja3rd November, 2014
Agenda• What and Why of Requirements?• Cost and Sources of Ambiguity• Need for multiple requirements elicitation
techniques• WinWin Negotations• “Winbook” for logging WinWin Negotiations
“Requirements” – Cont’d• Sommerville & Sawyer (1997):
– A specification of what should be implemented – They are descriptions of how the system should
behave or of a system property or attribute– They may be a constraint on the development
process of the system
“Why” Requirements?• Incorrect requirements are a major cause of
project failure• Exponential cost of fixing an incorrect
requirement after system in operation• Cornerstone of project and product
management activities• Basic currency to help estimate by “when will
you be done”• Primary vehicle to go from “vision” to
“realization”
Project Success Rate
6
2000 2002 2004 2006 20080
10
20
30
40
50
60
4951
53
4644
23
1518 19
24
28
34
29
3532
2010 Standish Group CHAOS Summary Report
ChallengedFailedSucceded
Challenged: Over budget/schedule or undelivered projectsFailed: Cancelled projects
Lack of Stakeholder involvement and convergence viewed as major causes of project failure
1. User Involvement2. Executive Support3. Clear Business Objectives4. Emotional Maturity5. Scope Optimization6. Agile Process7. Project Management Expertise8. Skilled Resources9. Execution Capability10.Tools and Infrastructure
CHAOS ’10 – Factors Influencing Project Success
7
One-Minute ExerciseCreate a means for protecting a small group of human beings from the hostile elements of their environment
Ambiguity in Requirements• A major source of headache and cost overruns• Diverse interpretations of the same
requirement• Cost of ambiguity
Phase in which found Cost Ratio
Requirements 1
Design 3-6
Coding 10
Development/Testing 15-40
Acceptance Testing 30-70
Operation 40-1000
Removing Ambiguity
The universe of everything that’s possible
What we want that we don’t ask for OR
What we ask for that we don’t want
Sources of Ambiguity
Test for Attentiveness
How many points were in the star that was shown on the previous slide of this presentation?
Sources of Ambiguity• Observational & recall errors:
– (Not) seeing the same things or retaining what you saw
• Interpretation errors– What did “points” refer too?
• Mixtures of above• Effects of human interaction
– Things lost in conversation
Multiple Elicitation Tools/Techniques• A pure direct questioning approach would only
succeed with “perfect” human beings!• Direct questioning needs to be supplemented with
other tools/techniques– Context Free Questions– Interviews/Workshops– Focus Groups/Observational studies– UI analysis– Mockups/Prototyping– Visual Representations: Activity diagrams, Data Flow
Diagrams, Decision Trees etc.,– …
Three Dimensions & Goals of Requirements Engineering
• Content:All relevant requirements are explicitly known and understood at the required level of detail
• Agreement:A sufficient agreement about the system requirements is achieved between the success critical stakeholders
• Documentation:All requirements are documented and specified in compliance with the relevant documentation/specification formats & rules
18
Visualizing The “Three Dimensions” Content
Documentation
Agreement
complete
vague
informal compliant with rules
individual views
consolidated views
Goal
19
MOMMY, WHERE DO THE REQUIREMENTS COME FROM?
Stakeholders• Not any and every stakeholder but success
critical stakeholders• Common mistake: Leaving an essential
stakeholder out of the software development process (remember Win-Lose Lose-Lose?)
• Critical to identify the right stakeholders• How?
– Brainstorming/Pruning– Checklist– Benefits Chain
Other Sources• Existing systems & documentation• Legacy systems• External interfaces• Social media• Creative thinking• Competitive analysis• Customer survey• …many many more
DOCUMENTING REQUIREMENTS
SSRD in Practice
In 2D
The true 3D view
Too much detail and too much
to capture
26
Change Management & SSRD?
27
Along came a
User Stories
SSRD
Story
What we thought… What was actually intended…
28
The User Story – 3Cs
Lightweight Ecstasy
Card
A promissory note of intent
Conversation
Discussion & clarification of intent (a.k.a requirement)
Confirmation
Acceptance Tests
29
User Stories• Written on small index cards• Usually of the form:
As a <role>, I can <activity> so that <business value>
“As a Consumer I can see my daily energy usage so that I can lower my energy costs and usage”
• Lacks details captured by traditional requirements specifications
• Details conveyed primarily through conversations• Formalized via acceptance tests
30
INVEST-ing in User Stories
I = IndependentN = NegotiableV = ValuableE = EstimableS = SmallT = Testable
31
Commonly used acronym in the Agile World to describe attributes of a good user story:
Theory-WCustomer
Developer
STOP THIS MADNESS!
Think of requirements as stakeholder negotiated win
conditions!!
As a team discuss what will make each of you “win”
(a.k.a. win conditions)
Identify any issues and come up with options to resolve them
Reach a mutual consensus and move
forward (WinWin Equilibrium)
Dr. Boehm
32
33
Win ConditionWin Condition
AgreementAgreement OptionOption
I ssueI ssueinvolves
addresses
adopts
covers
WinWin Taxonomy (a.k.a. WIOA Model)
Win-Win Equilibrium:• All win conditions covered
by agreements• No outstanding issues
Win Condition: Stakeholders’ desired objectives stated in a form understandable by users, customers and other stakeholders and formalized only where necessary
Issue: captures conflicts between win conditions and their associated risks and uncertainties
Option: candidate solutions to resolve an issue
Agreement: captures shared commitment of stakeholders with regard to accepted win conditions or adopted options
34
We also capture a 3rd dimension of “Relative Penalty” – Degree of project failure if WC not deilvered
1. Refine and expand negotiation topics2. Collect stakeholders’ win conditions3. Converge on win conditions4. Define glossary of key terms5. Prioritize win conditions on:
Business Value vs. Ease of Realization
6. Reveal issues and constraints7. Record issues and options8. Negotiate agreements
WinWin Negotiation Primer
Shared taxonomy of topics to understand project scope
Record first draft of stakeholder’s needs/wants for all to view
Disambiguation and de-duplication
Domain vocabulary to develop mutual understanding
Degree of project success dependent on win condition
Technological, social, political or economic feasibility
Variance in prioritization provokes discussion of issues/constraintsIssues recorded along with possible resolution tactics
Mutually agree to win conditions/optionsAbove steps accelerated by a “Shaper” i.e. a facilitator who guides the negotiation
WinbookTheory - W
Requirement Specifications
Putting It All Together
User Stories
Facebook Gmail
37
Winbook• A collaborative, social networking based tool
for requirements brainstorming similar to facebook…
• …with requirements organization using color-coded labels similar to Gmail…
• …to collaboratively converge on software system requirements reaching win-win equilibrium (based on Theory-W)…
• …by keeping it short and simple like XP’s user stories!
38
39
40
Requirements @ CSSE• Requirements are treated as “Win Conditions”• Win Conditions are captured in Winbook• Win Conditions subsume user stories:
– Capability/Functional Requirements/Win Conditions can be conveniently phrased as user stories
• Win Conditions are negotiated within Winbook itself
• Win Conditions are linked to corresponding use-cases facilitating “downstream value traceability”
41
Challenges with Requirements• Things that can (and do) make life difficult
– Missing Requirements– Ambiguous Requirements (major problem)– Changing Requirements (changes in technology,
marketplace, political & legal changes, economic changes etc.,)
– Non-identified Stakeholders– Location/Time differences and communication
overhead– IKIWISI (I’ll know it when I’ll see it)– Implicit Assumptions
42
Key Takeaways• Requirements are very critical to the field of Software
Engineering• Negotiation is “always” done • Almost everything documented information is a form of
requirement• No single artifact to rule them all – content usually split across
various artifacts• Very cooperative and iterative• Assumptions/Conflicts must be made explicit and
validated/resolved• SSRD is more commonly found in the wild• 577 uses Winbook for documenting ‘requirements’ making the
process ‘fun and lightweight’43