Requirements Are Simply Requirements—or Maybe Not

26
Requirements Are Requirements Are Simply Simply Requirements Requirements- or Maybe Not or Maybe Not GO PRO MANAGEMENT, INC. Robin F. Goldsmith, JD Requirements Are Simply Requirements- or Maybe Not -1 © © ©2015 2015 2015 2015 G G GO O O O P P PRO RO RO RO M M MANAGEMENT, ANAGEMENT, ANAGEMENT, ANAGEMENT, INC INC INC INC. . . SYSTEM ACQUISITION & DEVELOPMENT QUALITY/TESTING PRODUCTIVITY 22 CYNTHIA ROAD NEEDHAM, MA 02494-1461 [email protected] WWW.GOPROMANAGEMENT.COM (781) 444-5753 B U S I N E S S E N G I N E E R I N G T R A I N I N G

Transcript of Requirements Are Simply Requirements—or Maybe Not

Requirements Are Requirements Are Simply Simply

RequirementsRequirements--

or Maybe Notor Maybe NotGO PRO MANAGEMENT, INC.Robin F. Goldsmith, JD

Requirements Are Simply Requirements- or Maybe Not- 1©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

GO PRO MANAGEMENT, INC.SYSTEM ACQUISITION & DEVELOPMENT

QUALITY/TESTINGPRODUCTIVITY

22 CYNTHIA ROAD

NEEDHAM, MA [email protected]

(781) 444-5753

BUSINESS ENGINEERING

TRAINING

ObjectivesObjectives

� Contrast common requirements interpretations,

including user stories, features, and

‘requirements.’

� Describe REAL business requirements

deliverable whats that provide value when met.

Requirements Are Simply Requirements- or Maybe Not- 2©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

deliverable whats that provide value when met.

� Offer some tips for avoiding traps of typical,

especially Agile, requirements.

Requirements in Agile Generally Are Requirements in Agile Generally Are

Considered to Be User Stories Considered to Be User Stories

As a <type of user>

I <want/can/am able to/need to/etc.>

Requirements Are Simply Requirements- or Maybe Not- 3©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

so that <some reason>

Mike Cohn

“User Stories, Epics and Themes”http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

User Stories Usually Are the Items in User Stories Usually Are the Items in

Product and Sprint BacklogsProduct and Sprint Backlogs� Small enough to be accomplished within a sprint

� Groomed and refined

� Split as needed to get small enough

Requirements Are Simply Requirements- or Maybe Not- 4©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

Some call backlog items “features”

Common, Reasonable Distinction Common, Reasonable Distinction

Between Features and User StoriesBetween Features and User Stories� Theme

– Features

» Epics

Requirements Are Simply Requirements- or Maybe Not- 5©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

� User Stories

No sequence of definition implied

User Stories Actually Are a Bit MoreUser Stories Actually Are a Bit More

� Card

– As a <role>

– I want <something>

– So that <benefit>

Requirements Are Simply Requirements- or Maybe Not- 6©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

– So that <benefit>

� Conversation

� Confirmation

– User story acceptance criteria, tests

“Placeholder, reminder for a conversation”

Working code

People Often Refer to User Stories as People Often Refer to User Stories as

Agile Requirements and also….Agile Requirements and also….

Refer to other things as “requirements”

Such as

“The system shall$” statements

Requirements Are Simply Requirements- or Maybe Not- 7©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

“The system shall$” statements

User

Stories

Use

Cases

Often without clear, conscious, consistent distinctions

Some (GenerallySome (Generally--Unrecognized) Unrecognized)

Issues with User Story RequirementsIssues with User Story Requirements� Many are written inappropriately

– Grooming and splitting still may not address

– Excessive trivial proliferation

� Accuracy mistakenly tends to be assumed

Requirements Are Simply Requirements- or Maybe Not- 8©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

� Accuracy mistakenly tends to be assumed

– Product Owner determination seldom questioned

– Adequacy of user story acceptance criteria/tests

� Misunderstood, mistaken models

– REAL Business vs product requirements

– Developer conversations analysis skills

Any Issues with this User Story?Any Issues with this User Story?

As a filling station attendant,

I want a gas pump,

so I can pump gas

Requirements Are Simply Requirements- or Maybe Not- 9©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

Many use cases have similar issues as this,

even those written by supposed experts

Issues with These Acceptance Criteria?Issues with These Acceptance Criteria?

Displays gallons dispensed, price per gallon,

and total dollar cost.

Resets gallons dispensed and total dollar

cost to zero.

Requirements Are Simply Requirements- or Maybe Not- 10©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

cost to zero.

Price per gallon can be set or modified.

Conventional Requirements Practices Conventional Requirements Practices

Are Reflected in BABOKAre Reflected in BABOK

� “Elicitation” often is largely passive dictation

– From senior executives about business objectives

– From those more directly involved about what the

product, system, or software features should be

Requirements Are Simply Requirements- or Maybe Not- 11©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

product, system, or software features should be

� Major part of business analysis focuses

“analysis” on the product, system, or software

� [Creep is rampant and is blamed on users]

See “Should BABOK Include Shorthand?”

http://enfocussolutions.com/thought-leader-robin-goldsmith/

��Two Types of Requirements:Two Types of Requirements:Business/User/CustomerBusiness/User/Customer Product/System/SoftwareProduct/System/Software

� Business/user/stakeholder/ customer language & view, conceptual; exist within the business environment

� Serves business objectives

� Language & view of a human-

defined product/system

� One of the possible ways

How (design) presumably to

accomplish the presumed

Requirements Are Simply Requirements- or Maybe Not- 12©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

� Serves business objectives

� What business results must be delivered to solve a business need (problem, opportunity, or challenge) and provide value when delivered/satisfied/met

accomplish the presumed

business requirements

� Often phrased in terms of

features/external functions each

piece of the product/system must

perform to work as designed

(Non/Functional Specifications)Many possible ways to accomplish

Even Requirements “Experts” Think Even Requirements “Experts” Think

the Difference Is Just Level of Detailthe Difference Is Just Level of Detail

Business Requirements

(High-Level, Vague)

Product/

System/Reqs.

(Detailed)

Requirements Are Simply Requirements- or Maybe Not- 13©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

System/

Software(Detailed)

BABOK v3 2.3 p. 26

“Business requirements:

statements of goals,

objectives, and outcomes

that describe why a change

has been initiated.”

When Business/User Requirements Are When Business/User Requirements Are

Detailed First, Creep Is ReducedDetailed First, Creep Is Reduced

Business Requirements

(High-Level)

Business

Product/System/Software

Reqs.(High-Level)

Reqs.Reqs. Product/

Requirements Are Simply Requirements- or Maybe Not- 14©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

Business Reqs.

(Detailed)

Reqs.

(Detailed)

Product/

System/

Software

Other Common Erroneous Business Other Common Erroneous Business

Requirements BeliefsRequirements BeliefsWe already define Business Requirements

Hows are only technical design details

Whatever the business/user says

Requirements Are Simply Requirements- or Maybe Not- 15©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

Always clearly known by top managers

Not an issue for small changes

What users should provide for

developers to build from

Requirements OverviewRequirements Overview

Stakeholders

Business needs,

problems, value

Discovery

Analysis

High-Level & Detailed

REAL Business/

Stakeholder Requirements

Deliverable Whats� Value

Product/System/

Respond to

User/

High-Level

Detailed

Requirements Are Simply Requirements- or Maybe Not- 16©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

Product/System/

Software

Requirements

Features Hows

Functional Requirements

Use Cases

Software Requirements Specifications

[Non-Functional Requirements]

Quality Factors, Attributes, ‘Ilities’

(Supplemental Specifications)

(Usage)

Detailed

Technical/

Engineering

Design

Code

What Could Possibly Go Wrong?What Could Possibly Go Wrong?

Stakeholders

Business needs,

problems, value

Discovery

Analysis

High-Level & Detailed

REAL Business/

Stakeholder Requirements

Deliverable Whats� Value

Product/System/

Respond to

User/

High-Level

Detailed

User

StoriesC

O

N

V

E

R

S

A

Requirements Are Simply Requirements- or Maybe Not- 17©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

Product/System/

Software

Requirements

Features Hows

Functional Requirements

Use Cases

Software Requirements Specifications

[Non-Functional Requirements]

Quality Factors, Attributes, ‘Ilities’

(Supplemental Specifications)

(Usage)

Detailed

Technical/

Engineering

Design

Code

A

T

I

O

N

S

Problem

Opportunity

Challenge

Cause(s)

As Is

Measure-

Now

��

Problem

Pyramid™The thing that will

provide value when

addressed adequately.

The way things are

now that cause the

undesirable results

we are getting.

The measure of

the problem now

that tells us it is

a problem.

Requirements Are Simply Requirements- or Maybe Not- 18©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

What Should Be

(Requirements) How (Design) Measure-Goal

�� Deliverable results,

that when delivered,

reasonably will

achieve the

Goal Measure.

A specific way

the Should Be

results can be

delivered.

The desired meas-

ure of the problem

that indicates it’s

been solved.

Benefit/Value

Cause(s)

As Is

Measure-

Now

��

Example

(1 of 3)

Reuse data are

not globally

accessible

People use stand-

alone PCs

Low priority for

intranet

implementation

X number of

people don’t

have access

Problem

Opportunity

Challenge

Requirements Are Simply Requirements- or Maybe Not- 19©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

What Should Be

(Requirements) How (Design) Measure-Goal

��

implementation

Give everyone

access via web

and intranet

All people

have access

Benefit/Value

Obvious project

Guidelines for Getting the Problem

Pyramid™ Right (1 of 2)� Is the Problem really the problem?

– Do the measures fit it?

– Does it provide REAL value when goal measures achieved?

� Are the Causes in fact the causes of the Problem?

Requirements Are Simply Requirements- or Maybe Not- 20©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

– Do they reasonably explain why we have the Problem?

– Have we identified all the likely key causes?

� Does the Should Be solve the Problem?

– Is it business whats likely to achieve goal measures?

– Does it address (and reduce/eliminate) each key Cause?

– What else to address that this affects or is affected by this?

Guidelines for Getting the Problem

Pyramid™ Right (2 of 2)� Problems can be hierarchical, appropriate level is

– The lowest level Problem, which

– Produces REAL Value when Goal Measures are achieved

� Causes can look like Problems

Requirements Are Simply Requirements- or Maybe Not- 21©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

– Can be hierarchical too, with Current and Goal Measures

– But, achieving a Cause’s Goal Measure does not produce REAL Value

� Taking to extremes can make distinctions clearer– What if we didn’t do it at all

– What if we did a lot of it

Cause(s)

As Is

Measure-

Now

��

Example

(2 of 3)

Reuse data are

not globally

accessible

People use stand-

alone PCs

Low priority for

intranet

implementation

X number of

people don’t

have access

A Cause

Measures do fit

Problem

Opportunity

Challenge

Reasonable, but not only ,

key Causes

Requirements Are Simply Requirements- or Maybe Not- 22©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

What Should Be

(Requirements) How (Design) Measure-Goal

��

implementation

Give everyone

access via web

and intranet

All people

have access

No Real Value

A “How”

Not a

“What”

Simply restates Goal

Benefit/Value

Obvious projectFAILURE

Cause(s)

As Is

Measure-

Now

��

Example

(3 of 3)Not reusing to

advantage

Lack of awareness

No incentives

Not invented here

Hard to find items

Limited data access

(Low) X% reuse

Spend Y dollars

Take Z months

to build systems

Problem

Opportunity

Challenge

Requirements Are Simply Requirements- or Maybe Not- 23©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

What Should Be

(Requirements) How (Design) Measure-Goal

��

Limited data access to build systems

(Hi) X+ reuse

Spend Y- $

Take Z- months

to build systems

People understand how to do reuse

and why it helps them get their jobs

done quicker, easier, better.

People have meaningful support and

encouragement to take the time to

make relevant items reusable.

People can easily access, identify, and

retrieve relevant reuse items.

Benefit/Value

ObjectivesObjectives

� Contrast common requirements interpretations,

including user stories, features, and

‘requirements.’

� Describe REAL business requirements

deliverable whats that provide value when met.

Requirements Are Simply Requirements- or Maybe Not- 24©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

deliverable whats that provide value when met.

� Offer some tips for avoiding traps of typical,

especially Agile, requirements.

Robin F. Goldsmith, JDRobin F. Goldsmith, [email protected]@gopromanagement.com www.gopromanagment.comwww.gopromanagment.com

• President of Go Pro Management, Inc. consultancy since 1982, working directly with and training professionals in

business engineering, requirements analysis, software acquisition, project management, quality and testing.

• Partner with ProveIT.net in REAL ROI™ and ROI Value Modeling™.

• Previously a developer, systems programmer/DBA/QA, and project leader with the City of Cleveland, leading

financial institutions, and a “Big 4” consulting firm.

• Degrees: Kenyon College, A.B.; Pennsylvania State University, M.S. in Psychology; Suffolk University, J.D.;

Boston University, LL.M. in Tax Law.

• Published author and frequent speaker at leading professional conferences.

• Formerly International Vice President of the Association for Systems Management and Executive Editor of the

Journal of Systems Management.

Requirements Are Simply Requirements- or Maybe Not- 25©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

Journal of Systems Management.

• Founding Chairman of the New England Center for Organizational Effectiveness.

• Member of the Boston SPIN and SEPG’95 Planning and Program Committees.

• Attendee Networking Coordinator for STAR, Better Software, and Test Automation Conferences.

• Chair of record-setting attendance BOSCON 2000 and 2001, ASQ Boston Section‘s Annual Quality Conferences.

• Member IEEE Std. 829-2008 for Software Test Documentation Standard Revision Committee.

• Member IEEE P1805 working group to develop a standard for Requirements Capture Language (RCL).

• Member IEEE Std. 730-2014 standard for Software Quality Assurance Revision Committee.

• International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK) subject expert.

• TechTarget SearchSoftwareQuality.com requirements and testing expert.

• Admitted to the Massachusetts Bar and licensed to practice law in Massachusetts.

• Author of book: Discovering REAL Business Requirements for Software Project Success

Go Pro Management, Inc. Seminars/Consulting--Relation to Life Cycle

Systems QA Software Quality Effectiveness Maturity Model

Software, Test Process Measurement & Improvement

Feasibility

AnalysisSystems

AnalysisSystem

DesignDevelop-

ment Implement-

ation Operations

Maintenance

Credibly Managing Projects and Processes with Metrics

Proactive User Acceptance TestingReusable Test Designs

Test Estimation

Defining and Managing

Business Requirements

Requirements Are Simply Requirements- or Maybe Not- 26©©©©2015 2015 2015 2015 GGGGO O O O PPPPRO RO RO RO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....

ationMaintenance

Proactive Testing:

Risk-Based Test Planning,

Design, and ManagementTesting Early in the Life CycleRe-Engineering: Opportunities for IS

21 Ways to Test Requirements

Making You a Leader

Managing Software Acquisition and Outsourcing:

> Purchasing Software and Services> Controlling an Existing Vendor’s Performance

Test EstimationRisk

Analysis

Business Requirements

Writing Testable SW Requirements