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