requirements are simply requirements—or maybe not
Post on 17-Aug-2015
10 Views
Preview:
TRANSCRIPT
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 02494-1461INFO@GOPROMANAGEMENT.COMWWW.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.
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, JDrobin@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.
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
top related