Requirements Don’t Have to be Hard

1 Copyright ©2008 Serena Software, Inc.

Requirements Don’t Have to be Hard

Drrs. Kelly Shaw & Rick HubbardSerena Software


The First Step

• Given this year’s theme of Innovation…

• The first step to creating an innovative & achievable solution is to…• …form a well-crafted—and authoritative—statement of the

problem…• …which is attested by the Economic Stakeholder

• Let’s start with a simple list and progress from there…• …what aspects of requirements do you believe are hard, or

problematic?

• Now let’s delve a little deeper into the nature of innovation


What is “Innovation?”


Nature of Innovation

• What is the fundamental nature of innovation?

• Something new?

• Necessary, yet insufficient answer

• Innovation is something new…

• …in the presence of an apparent contradiction(s), and…

• …typically bounded by an assumed constraint(s)

• For Example: A Special Diet…• Story about a college Computer Science project

• Let’s apply this idea to you…


Cardstorm Prototype Candidates

• 5x8 Index Cards• Write Name & Contact Details in Lower Right

• In Quiet• In 15 words, or less, please describe a problem, any

problem, in your organization which is bounded by a contradction(s) and a constraint(s)


Collect Cardstorm Results


What Can Be Done?

• What can be done later in a project to overcome deficiencies—failures—in requirements practices?• Spend More Money

• Rework

• Take Longer

• Higher Risk

• Lower Quality

• Deliver Less

• Reduce ROI• Squander Opportunity Cost

• Disappoint Business/Customers


The Value of Prototyping


With Innovative Thinking—Requirements Don’t Have to be Hard

• Problem: Customer’s Don’t Know What they Want and They Think Requirements Capture Takes Forever

• Recall: What is the Nature of Innovation?• Something new, apparent contradiction & constraint

• Let’s find a way to collect requirements when customer’s don’t know what they want in short periods of time…especially with respect to:• Surfacing Assumptions• Surfacing Tacit Knowledge


Kano Model

Extremely Satisfied

Extreme Dissatisfied

Absolutely Unfulfilled Absolutely Fulfilled

Over Time

Excited

Assumed

Stated


With Innovative Thinking—Requirements Don’t Have to be Hard

• Problem: We don’t know if the solution technology is feasible• Let’s find a way to collect requirements and test a technology

stack in a short period of time

• Problem: What’s the best way to decide to build or buy?• Let’s find a way to collect sufficient requirements to

authoritatively conduct a build/buy decision in a short period of time

• Problem: Customer’s are always changing their minds; especially when they learn the cost of a feature• Let’s find a way to quickly collect, assess and validate

requirements


Could You Apply This Approach to Requirements

and Prototyping?


PDSA/PDCAShewhart/Deming Cycle

Frequently Misunderstood

“D” Really Means…


Ultra, Ultra-Brief Discussion ofPID Controllers

PIDProportional—Current ErrorIntegral—Sum Prior ErrorsDerivative—Rate of Change of Errors


Let’s Find a Way…

• Let’s find a way to collect requirements when customer’s don’t know what they want in short periods of time…especially with respect to:• Surfacing Assumptions• Surfacing Tacit Knowledge

• Let’s find a way to collect requirements and test a technology stack in a short period of time

• Let’s find a way to collect sufficient requirements to authoritatively conduct a build/buy decision in a short period of time

• Let’s find a way to quickly collect, assess and validate requirements


Prototyping

Let’s See How Shaw is Doing…

Let’s Surface Assumptions…

Let’s Surface Tacit Knowledge…


Questions

Requirements Don’t Have to be Hard

Documents

Transcript of Requirements Don’t Have to be Hard