Requirements Are RequirementsRequirements-- or Maybe Not · 2018-09-11 · Requirements Are...

Requirements Are Requirements Are

RequirementsRequirements--

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

Requirements Are Requirements- or Maybe Not- 1©©©©2018 2018 2018 2018 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.



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.>


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


Some call backlog items “features”

Common, Reasonable Distinction Common, Reasonable Distinction

Between Features and User StoriesBetween Features and User Stories Theme

– Features

» Epics


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>


– 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


“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


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


Many use stories 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.


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


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?”

Contact me at [email protected] for a copy

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


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)


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


(High-Level)

Business

Product/System/Software

Reqs.(High-Level)

Reqs.Reqs. Product/


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


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


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


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.


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


What Should Be


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?


– 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


– 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


What Should Be


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


What Should Be


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




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.

Founding Chairman of the New England Center for Organizational Effectiveness.


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 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

Author of forthcoming book: Cut Creep—Write Right Agile User Story and Acceptance Test Requirements

Right

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

Proactive Systems/Software Quality Assurance (SQA)™

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


System Measurement Test Process ManagementROI


ationMaintenance

Proactive Testing:

Risk-Based Test Planning,

Design, and ManagementTesting Early in the Life Cycle21 Ways to Test Requirements

Making You a Leader

Managing Software Acquisition and Outsourcing:

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

Test Estimation

Risk

Analysis


Writing Right Agile User Story and

Acceptance Test Requirements Right

Requirements Are RequirementsRequirements-- or Maybe Not · 2018-09-11 · Requirements Are...

Documents

Transcript of Requirements Are RequirementsRequirements-- or Maybe Not · 2018-09-11 · Requirements Are...