CS 564 – Lecture 11

Requirements Risk Management and WinWin

Risk

• Risk is the possibiloity of economic loss or injury

• Risk Exposure =

(Probability of unsatisfactory outcome) X (Loss if unsatisfactory outcome)

Types of Risks

• Risks affect • the project plan (project risks),• the quality (technical risks), or• the viability of the product (business risks).

Risk Classification

Risk Watchwords

• Identify the Risks and compute Risk Exposure.

• When the risk exposure to do something, is unknown DON’T do it.

• When it’s risky not to do something, DO IT.

Risk Exposure

For event E, P(E) = m/n• P = Probability • m = favorable events• n = total events

The Risk = 1-P(E)

The Risk Exposure = Risk * Cost given that the event actually happens

Requirements Risk Management

• Win-Win Spiral

• Anchor Points • Life Cycle Objectives (LCO)• Life Cycle Architecture (LCA)• Initial Operational Capability (IOC)

Functions of Risk Management

Fct Description

Identify Search for and locate risks before they become problems.

AnalyzeTransform risk data into decision-making information. Evaluate impact, probability, and

timeframe, classify risks, and prioritize risks.

PlanTranslate risk information into decisions and mitigating actions (both present and

future) and implement those actions.

Track Monitor risk indicators and mitigation actions.

Control Correct for deviations from the risk mitigation plans.

Comm. Provide information and feedback internal and external to the project on the risk

activities, current risks, and emerging risks. Note: Communication happens throughout all the functions of risk management.

Risk Do’s and Don’t

• Don’t overestimate the risks : too much contingency planning

• Don’t underestimate the risks : leads to panic management later

• Don’t look for scapegoats

• Do deal with the top 10 risk exposures first

1989

1. Personnel shortfalls

2. Schedules and budgets

3. Wrong software functions

4. Wrong user interface

5. Gold plating

6. Requirements changes

7. Externally-furnished components

8. Externally-performed tasks

9. Real-time performance

10. Straining computer science

1995

1. Personnel shortfalls

2. Schedules, budgets, process

3. COTS, external components

4. Requirements mismatch

5. User interface mismatch

6. Architecture, performance, quality

7. Requirements changes

8. Legacy software

9. Externally-performed tasks

10. Straining computer science

Top 10 Risk Items: 1989 and 1995

Primary Risk Items

• People

commitment; compatibility; ease of communication; skills

• Schedule

project scope; critical-path items • Mismatched user Interfaces and Objectives• Performance and overhead • External Dependencies

Client/User/Administrator

Commitment to transition

Risk Analysis Template

Structure

Tech-nology

Size Risk Scale QA Local Tests

Formal Planning

Config Control

High Low Large Low 3 no no yes yes

High Low Small Lowest 1 no no no yes

High High Large Medium 7 yes maybe yes yes

High High Small Low-med

5 maybe

no yes yes

Low Low Large High 8 yes yes yes yes

Low Low Small Medium 7 no no yes yes

Low High Large Highest 10 Yes Yes yes yes

Low High Small High 8 yes yes yes yes

COTS and External Component Risks

• COTS

Trustworthiness

Compatibility

Performance

Controllability• Non-commercial off-the shelf components

Open Source

Reuse libraries

Technical Background

• Waterfall focuses on formal Project Control• Spiral focuses on Risk management• WinWin Spiral focuses on requirements risk

management• WinWin Risk Driven Spiral with Anchor Points

(LCO, LCA, IOC)• Agile focuses on Schedule• Lambda focuses on Trustworthiness

Risk Management Importance

• Contains Complexity

• Quantitative Techniques used to manage risks and set priorities

• Reduces ReworkTypically 40-50% of software costs

Rework Costs are Concentrated

If Risk Management is so important, why don’t people do it?

• ‘Can Do’ culture• Unwillingness to admit risks exist

• Leaves impression that you don’t know exactly what you’re doing

• Leaves impression that your bosses, customers don’t know exactly what they’re doing

• “Success-orientation”

• Tendency to postpone the hard parts• Maybe they’ll go away• Maybe they’ll get easier, once we do the easy parts

• Up front effort, time and investments• It is hard to say ‘no.’

Motivation for Risk Management

• Death March Experience

• Project Failure

• Fear of Failure

• Unrealistic Expectations

• Risk Management Skills

Unrealistic or Unknown Expectations

WinWin

• A process that lets stakeholders work out and agree to a known set of mutually shared commitments.

• The win-win process is composed of a set of principles, practices, and tools.

Outsourcing Risks

MediumUnique Dev

Loose coupling

HighUnique Dev

Tightly coupled

LowExisting pattern

Stand Alone

MediumUnique Dev

Loose coupling

High

High

Low

Low

Level of Integration

Level of Customization

Key Stakeholders

• Purchasing Agents, End Users, IT staff, Customers, Developers, Testers and Maintainers

• Sometimes other project managers, Subcontractors, Supplier’s, Venture Capitalists General Public

• For each stakeholder identify• Home organization• Know how• Authority

Proposed Solution “Winner” Loser

Quick, Cheap,Sloppy Product

Lots of“bells and whistles”

Driving too hard abargain

Developer &Customer

Developer & User

Customer & User

User

Customer

Developer

Win-lose becomes Lose-lose

WinWin Key Concepts

• Win Condition: an objective that makes a stakeholder a winner

• Issue: conflict or constraint on a win condition

• Option: A way of overcoming an issue• Agreement: mutual commitment to an

option or win condition• WinWin Equilibrium State:

1. All Win Conditions covered by Agreements2. There are no outstanding Issues

Win ConditionWin Condition

AgreementAgreement OptionOption

IssueIssueblocks

addresses

adopts

covers

WinWin Negotiation Model

Why WinWin?

• Alternatives don’t work and leads to lose-lose.

• Avoids costly rework • 60:1 cost increase to fix requirements

error after delivery

• Builds trust and manages expectations

• Makes Teamwork likely• Helps stakeholders adapt to change

Anchor Points

• Life Cycle Objectives (LCO): Stakeholders agreed to system’s requirements and engineers have demonstrated one feasible architecture.

• Life Cycle Architecture (LCA): Developers have detailed an implementation architecture and stakeholders agree to proceed to implementation.

• Initial Operating Capability (IOC): Working system has been implemented, tested, and transitioned to customer site, and stakeholders have agreed to put it into operation.

SPIRAL MODEL

Workflow Balance over the Life Cycle

Inception Elaboration Construction Transition

Management

Environment

Requirements

Design

Implementation

Testing

Deployment

• Do notices look exactly like they always have? • Teachers are conservative and will resist changing their

routine in any way• Possible Model Clashes:

• Teachers makes the following assumption: • success model assumption: no changes should be

made to procedure or forms• Developer makes one or both of following assumptions:

• product model assumption: fancier graphics make product more appealing

• process model assumption: stakeholder interaction is not necessary for requirements gathering

© NJCSE

Library Overdue Book Notices:Stakeholders fear automation

• Is output sorted by class, and then by student name? • Librarian gives notices to teachers to give to students. If s/he

has to sort by hand, s/he won’t use the system.• Possible Model Clashes:

• Librarian makes the following assumption:• success model assumption: system should result in less

work rather than more work• Developer makes one or both of following assumptions:

• product model assumption: output order is unimportant• process model assumption: stakeholder interaction is

not necessary for requirements gathering

© NJCSE

Library Overdue Book Notices: Importance of order of notices

• Is input by books NOT returned, rather than by books returned?

• Far more books are returned on time than not.• Far more work to enter books returned.• Possible Model Clashes:

• Librarian makes following assumption• success model assumption: system should result in

less work rather than more work• Developer makes one of the following assumptions:

• product model assumption: any input model is okprocess model assumption: stakeholder interaction is not necessary for requirements gathering

© NJCSE

Library Overdue Book Notices: Update by Exception

• Does the manual make it clear that data must be saved to floppy after each time the system is used?

• If not, computer-shy librarian may forget.• Possible Model Clashes:

• Librarian makes the following assumption”• success model assumption: all required actions

must be stated explicitly in manual• Developer makes one, two, or three of the following

assumptions:• success model assumption: users are as

sophisticated as I am • process model assumption: stakeholder interaction

is not necessary for requirements gathering• success model assumption: expend least possible

effort

Library Overdue Book NoticesAdministrator Woes

• Is saving done via a menu command?• Teaching librarian to copy files is much harder than teaching

him/her to use a menu command.• Possible Model Clashes:

• Librarian makes one or both of following assumptions:• success model assumption: the simpler the better • product model assumption: “save” function is part of

GUI• Developer makes one or both of the following

assumptions• property (environment) model assumption: users are

sophisticated • process model assumption: stakeholder interaction is

not necessary for requirements gathering

© NJCSE

Library Overdue Book Notices:Matching User Skills

• Does system prompt for save upon exiting?• If not, librarian may very well forget.• Possible Model Clashes

• Librarian makes one or both of the following assumptions:

• success model assumption: I can’t afford to ever lose data

• product model assumption: “save” function should be prompted

• Developers make one or both of the following assumptions

• property (environment) model assumption: users are sophisticated

• process model assumption: stakeholder interaction is not necessary for requirements gathering

© NJCSE

Library Overdue Book NoticesFail Safe Design

• Did you add features/functionality to impress the customer?

• What makes you think they will impress?

• Have you asked the customer if s/he’s willing to pay the extra cost?

• Possible Model clash:

• Librarian makes following assumption:

• success model assumption: I should be able to learn entire system in an afternoon

• AND

• EITHER Customer makes following assumption:

• success model assumption: I don’t want to be charged for things I didn’t ask for

• OR Developer makes the following three success model assumptions:

• I want to maximize profits

• the more features the more customers

• the more customers the more profits

© NJCSE

Library Overdue Book NoticesGold Plating

Operations Model`

Object Model

Capability Requirements

System Definition

Class Model

Project Requirements

Statement of Purpose

Project Goals

Organization Goals

System Capabilities

Component ModelOrganization Entities

Behavior Model

Enterprise model

Domain Description System Analysis System Design

Operational Concept Description (OCD)

System and Software Requirements Definition (SSRD)

System and Software Architecture Description (SSAD)

Organization Background

Organization Activities

Interaction Model

Levels of Service Goals LOS Requirements

* Does not include all MBASE models

Release Description

Reqs. Satisfaction

Capability Tests

Data Structures

Methods/functions

LOS Tests

Implementation

Construction,Transition,Support (CTS)

External to MBASE

Coverage/Traceability of MBASE Product Models*

Org. goalsShared Vision

InitialSystem/ProjectGoals

AttractiveCOTS

Revised System/Project Goals

-capabilities -Levels of Service

Component Model

-COTS components-Build Components

Effect of COTS on Mapping Process

Expectations Shortfalls

• Condition for successful LCOa. Feasible architecture b. Meets requirements within cost/schedule/resource constraintsc. Viable business case

d. Equilibrium

• At USC Projects That Failed LCO Condition1996: 4 out of 16 fail(25%)1997: 4 out of 15 (27%)

•Easy/hard things for software people

“If you can do queries with all those ‘ands’, ‘ors’, ‘synonyms’, ‘data ranges, etc.’, it should be easy to do natural language queries.”

“If you can scan the document and digitize the text, it should be easy to digitize the figures too.”

•Easy/hard things for librarians

“It was nice that you could add this access feature, but it overly (centralizes, decentralizes) control of our intellectual property rights.”

“It was nice that you could extend the system to serve the medical people, but they haven’t agreed to live with our usage guidelines.”

Requirements and Expectations: Domain Model Clashes

• Identify application simplifiers and complicators– For each digital library sub-domain– For both developers and clients

Simplifier/Complicator Experiment

Example S&C’s

1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20, 31, 32, 35, 36, 37, 39

Type ofApplication

Simple Block Diagram Examples Simplifiers Complicators

MultimediaArchive

Use standardquery languages

Use standard orCOTS searchengine

Uniform mediaformats

Natural languageprocessing

Automatedcataloging orindexing

Digitizing largearchives

Digitizingcomplex or fragileartifacts

Automatedannotation/description/ or meaningsto digital assets

Integration oflegacy systems

MM assetinfo

Catalog

MMArchive

query

MM assetupdate

query updatenotification

Rapid access tolarge Archives

Access toheterogeneousmedia collections

Specialized Material

Simplifiers Risks and Trade-offs

Generic Uniform Media FormatsSpecific All video clips are stored using an open file format for video/audio (e.g., MPEG).  All film stills are stored using an open image file format (e.g., JPEG). The inverse complicator is to store film clips using streaming video technologies

This means that we may have to convert existing digital assets or digitize the original media, which may be costly. A unique file format limits the user base to those who have viewers for that particular file format The chosen file format may not be the most efficient for the various types of media (in terms of compression rates, quality, etc...)

Generic Use Standard Query LanguagesSpecific Organize catalog and archive relationally so that queries will be limited to standard search formats,: match exactly by value on any of the fields with or without using  boolean combinations (AND, OR, NOT, etc...), or using pattern matching (SQL LIKE keyword)

May not be as effective for "discovering" assets in the archive: users must know what they're looking for, in order to search for it

Generic Use Standard COTSSpecific Use a standard Relational Database Management System (RDBMS) that supports storing multi-media assets

A Relational Database Management System may not be most suited for archival of multi-media assets. A Relational Database Management System may have a high initial cost, high implementation, and high administration cost (requires specialized knowledge skills)

Complicators Risks and Trade-offs

GenericNatural Language ProcessingSpecificStore the information only in one language (e.g., English) and provide dynamic translation into Chinese, Japanese and Korean The inverse simplifier is to store the same information in 4 different languages (English, Chinese, Japanese and Korean). 

The first approach is a complex, error-prone, expensive natural language processing issue The second approach will require more storage space, in addition to acquiring the translations

GenericDigitizing Large ArchivesSpecific Digitizing film clips from the entire collection of films (which grows at a very fast rate of 800 films per year for Indian films alone)

If each film clip requires around 10 MB, then the rate of growth of the database will be of 8GB a year (exclusive of catalog information)

GenericIntegration of "Legacy" SystemsSpecific Do not require Real-Video plug-in for Web browsers to allow users to view streamed film clips

We cannot use more effective multi-media formats, which are becoming standard technologies

The USC Results

• Projects That Failed LCO Criteria1996: 4 out of 16 (25%)

1997: 4 out of 15 (27%)

1998: 1 out of 20 (5%)

1999: 1 out of 22 (4%)

• Simplifier and Complicator analysis helps- To focus on achievable requirements with

tight schedules- To understanding risks and tradeoffs