Requirements Are Requirements—or Maybe Not

Requirements Are Requirements- or Maybe Not- 1©2014GO PRO MANAGEMENT, INC.
Requirements Are
Requirements-
or Maybe Not
GO PROMANAGEMENT, INC.
SYSTEMACQUISITION&DEVELOPMENT
QUALITY/TESTING
PRODUCTIVITY
22 CYNTHIA ROAD
NEEDHAM, MA 02494-1461
INFO@GOPROMANAGEMENT.COM
WWW.GOPROMANAGEMENT.COM
(781) 444-5753
BUSINESS ENGINEERING
TRAINING
RobinF.Goldsmith, JD

Objectives
 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
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
Product 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
Between Features and User Stories
 Theme
– Features
» Epics
 User Stories
No sequence of definition implied

User Stories Actually Are a Bit More
 Card
– As a <role>
– I want <something>
– So that <benefit>
 Conversation
 Confirmation
– User story acceptance criteria, tests
“Placeholder, reminder for a conversation”
Working code

People Often Refer to User Stories as
Agile Requirements and also….
Refer to other things as “requirements”
Such as
“The system shall…” statements
User
Stories
Use
Cases
Often without clear, conscious, consistent distinctions

Some (Generally-Unrecognized)
Issues with User Story Requirements
 Many are written inappropriately
– Grooming and splitting still may not address
– Excessive trivial proliferation
 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?
As a filling station attendant,
I want a gas pump,
so I can pump gas
Many use cases have similar issues as this,
even those written by supposed experts

Issues with These Acceptance Criteria?
Displays gallons dispensed, price per gallon,
and total dollar cost.
Resets gallons dispensed and total dollar
cost to zero.
Price per gallon can be set or modified.

Conventional Requirements Practices
Are 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
 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://www.requirementsnetwork.com/node/1367

Two Types of Requirements:
Business/User/Customer Product/System/Software
 Business/user/stakeholder/
customer language & view,
conceptual; exist within the
business environment
 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
 Language & view of a human-
defined product/system
 One of the possible ways
How (design) presumably to
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
the Difference Is Just Level of Detail
Business Requirements
(High-Level, Vague)
Product/
System/
Software
Reqs.
(Detailed)
BABOK v2 1.3.3.1 p. 5
“Business requirements are
defined as higher-level
statements of the goals,
objectives, or needs of the
enterprise.”

When Business/User Requirements Are
Detailed First, Creep Is Reduced
(High-Level)
Business
Product/System/Software
Reqs.(High-Level)
Reqs.
(Detailed)
Reqs.
(Detailed)
Product/
System/
Software

Other Common Erroneous Business
Requirements Beliefs
We already define Business Requirements
Hows are only technical design details
Whatever the business/user says
Always clearly known by top managers and
product owner
Not an issue for small changes
What users should provide for
developers to build from

Requirements Overview
Stakeholders
Business needs,
problems, value
Discovery
Analysis
High-Level & Detailed
REAL Business/
Stakeholder Requirements
Deliverable Whats  Value
Product/System/
Software
Requirements
Features Hows
Respond to
Functional Requirements
Use Cases
Software Requirements Specifications
[Non-Functional Requirements]
Quality Factors, Attributes, ‘Ilities’
(Supplemental Specifications)
User/
(Usage)
High-Level
Detailed
Technical/
Engineering
Design
Code

What Could Possibly Go Wrong?
Stakeholders
Business needs,
problems, value
Discovery
Analysis
High-Level & Detailed
REAL Business/
Stakeholder Requirements
Deliverable Whats  Value
Product/System/
Software
Requirements
Features Hows
Respond to
Functional Requirements
Use Cases
Software Requirements Specifications
[Non-Functional Requirements]
Quality Factors, Attributes, ‘Ilities’
(Supplemental Specifications)
User/
(Usage)
High-Level
Detailed
Technical/
Engineering
Design
Code
User
Stories
C
O
N
V
E
R
S
A
T
I
O
N
S

Problem
Opportunity
Challenge
Cause(s)
As Is
Measure-
Now
What Should Be
(Requirements) How (Design) Measure-Goal




 
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.
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
What Should Be




 
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
Give everyone
access via web
and intranet
All people
have access
Problem
Opportunity
Challenge
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
What Should Be




 
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
Give everyone
access via web
and intranet
All people
have access
A Cause
Measures do fit
No Real Value
A “How”
Not a
“What”
Simply restates Goal
Problem
Opportunity
Challenge
Reasonable, but not only ,
key Causes
Benefit/Value
Obvious project
FAILURE

Cause(s)
As Is
Measure-
Now
What Should Be




 
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
(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.
Problem
Opportunity
Challenge
Benefit/Value

Reconsider this User Story?
As a filling station attendant,
I want a gas pump,
so I can pump gas
Problem, opportunity, challenge?
REAL Value?
Roles/actors?
REAL business requirements deliverable whats  Value
Epics/User Stories

Consider Ability/Likelihood of
Original User Story to Address…
 Self-serve
– Credit , debit
– Cash
– Frequent user
 High-test, regular, diesel
 Safety

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

Robin F. Goldsmith, JD
robin@gopromanagement.com www.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.
 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 for Software Test Documentation Standard Revision Committee.
 Member IEEE P1805 working group to develop a standard for Requirements Capture Language (RCL).
 Member IEEE P730 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
Analysis
Systems
Analysis
System
Design
Develop-
ment Implement-
ation Operations
Maintenance
Proactive Testing:
Risk-Based Test Planning,
Design, and Management
Testing Early in the Life Cycle
Re-Engineering: Opportunities for IS
Credibly Managing Projects and Processes with Metrics
21 Ways to Test Requirements
Making You a Leader
Managing Software Acquisition and Outsourcing:
> Purchasing Software and Services
> Controlling an Existing Vendor’s Performance
Proactive User Acceptance Testing
Reusable Test Designs
Test Estimation
Risk
Analysis
Defining and Managing
Writing Testable SW Requirements

Requirements Are Requirements—or Maybe Not

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Requirements Are Requirements—or Maybe Not

Similaire à Requirements Are Requirements—or Maybe Not (20)

Plus de TechWell

Plus de TechWell (20)

Dernier

Dernier (20)

Requirements Are Requirements—or Maybe Not