Requirements Are Simply Requirements—or Maybe Not

Requirements Are SimplyRequirements Are Simply
RequirementsRequirements--
or Maybe Notor Maybe Not
GO PRO MANAGEMENT, INC.
Robin F. Goldsmith, JD
Requirements Are Simply Requirements- or Maybe Not- 1©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC....
GO PRO MANAGEMENT, INC.
SYSTEM ACQUISITION & DEVELOPMENT
QUALITY/TESTING
PRODUCTIVITY
22 CYNTHIA ROAD
NEEDHAM, MA 02494-1461
INFO@GOPROMANAGEMENT.COM
WWW.GOPROMANAGEMENT.COM
(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 AreRequirements in Agile Generally Are
Considered to Be User StoriesConsidered 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 inUser 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 DistinctionCommon, 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 asPeople 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 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.
cost to zero.
Price per gallon can be set or modified.

Conventional Requirements PracticesConventional 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?”
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
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” ThinkEven 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 AreWhen 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 BusinessOther Common Erroneous Business
Requirements BeliefsRequirements Beliefs
We 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
Stories
C
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 project
FAILURE

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, JD
robin@gopromanagement.comrobin@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—Put Business Back in Business Analysis to Discover REAL
Business Requirements for Agile, ATDD, and Other 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
Credibly Managing Projects and Processes with Metrics
Proactive User Acceptance Testing
Reusable Test Designs
Test Estimation
Defining and Managing
ation
Maintenance
Proactive Testing:
Risk-Based Test Planning,
Design, and Management
Testing Early in the Life Cycle
Re-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 Estimation
Risk
Analysis
Writing Testable SW Requirements

Requirements Are Simply Requirements—or Maybe Not

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Requirements Are Simply Requirements—or Maybe Not

Ähnlich wie Requirements Are Simply Requirements—or Maybe Not (20)

Mehr von TechWell

Mehr von TechWell (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Requirements Are Simply Requirements—or Maybe Not