requirements are requirements—or maybe not

Requirements Are Requirements- or Maybe Not- 1©2014 GO PRO MANAGEMENT, INC.

Requirements Are Requirements- or Maybe NotGO PRO MANAGEMENT, INC.

SYSTEM ACQUISITION & DEVELOPMENT

QUALITY/TESTINGPRODUCTIVITY

22 CYNTHIA ROADNEEDHAM, MA 02494-1461

[email protected]

(781) 444-5753

B U S IN E S S E N G IN E E R IN G

T R A IN IN G

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

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

UserStories

UseCases

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

Business Requirements(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 StakeholdersBusiness needs, problems, value

DiscoveryAnalysis

High-Level & DetailedREAL Business/ Stakeholder Requirements Deliverable Whats Value

Product/System/ Software Requirements Features Hows

Respond to

Functional RequirementsUse CasesSoftware 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? StakeholdersBusiness needs, problems, value

DiscoveryAnalysis

High-Level & DetailedREAL Business/ Stakeholder Requirements Deliverable Whats Value

Product/System/ Software Requirements Features Hows

Respond to

Functional RequirementsUse CasesSoftware Requirements Specifications

[Non-Functional Requirements]Quality Factors, Attributes, ‘Ilities’(Supplemental Specifications)

User/

(Usage)

High-Level Detailed Technical/ Engineering Design

Code

UserStories

CONVERSATIONS


ProblemOpportunityChallenge

Cause(s)As Is

Measure-Now

What Should Be (Requirements) How (Design) Measure-Goal

ProblemPyramid™

The thing that willprovide value whenaddressed adequately.

The way things arenow that cause theundesirable resultswe are getting.

The measure of the problem now that tells us it is a problem.

Deliverable results, that when delivered, reasonably will achieve theGoal Measure.

A specific waythe Should Beresults can bedelivered.

The desired meas-ure of the problemthat indicates it’sbeen solved.

Benefit/Value


Cause(s)As Is

Measure-Now


Example(1 of 3)

Reuse data are not globally accessible

People use stand-alone PCsLow priority forintranet implementation

X number ofpeople don’thave access

Give everyone access via web and intranet

All peoplehave 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 PCsLow priority forintranet implementation

X number ofpeople don’thave access

Give everyone access via web and intranet

All peoplehave access

A Cause

Measures do fit

No Real Value

A “How”

Not a“What”

Simply restates Goal


Reasonable, but not only , key Causes

Benefit/Value

Obvious projectFAILURE


Cause(s)As Is

Measure-Now


Example(3 of 3)

Not reusing toadvantage

Lack of awareness No incentivesNot invented here Hard to find itemsLimited data access

(Low) X% reuseSpend Y dollarsTake Z monthsto build systems

(Hi) X+ reuseSpend Y- $Take Z- monthsto build systems

People understand how to do reuseand 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


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 ValueEpics/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, [email protected] 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

mailto:[email protected]

http://www.gopromanagment.com/


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

Systems QA Software Quality Effectiveness Maturity Model

Software, Test Process Measurement & ImprovementFeasibilityAnalysis Systems

Analysis SystemDesign

Develop-ment Implement-

ation OperationsMaintenance

Proactive Testing:Risk-Based Test Planning,Design, and Management

Testing Early in the Life CycleRe-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 TestingReusable Test Designs

Test EstimationRiskAnalysis

Defining and Managing Business Requirements

Writing Testable SW Requirements

requirements are requirements—or maybe not

Software

agile requirements

user story requirements

pro management

mike cohn user stories

unrecognized issues

similar issues

total dollar cost

use cases