Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Requirements Are SimplyRequirements Are Simply
RequirementsRequirements--
or Maybe Notor Maybe Not
GO PRO MANAGEMENT, INC....
ObjectivesObjectives
Contrast common requirements interpretations,
including user stories, features, and
‘requirements.’
D...
Requirements in Agile Generally AreRequirements in Agile Generally Are
Considered to Be User StoriesConsidered to Be User ...
User Stories Usually Are the Items inUser Stories Usually Are the Items in
Product and Sprint BacklogsProduct and Sprint B...
Common, Reasonable DistinctionCommon, Reasonable Distinction
Between Features and User StoriesBetween Features and User St...
User Stories Actually Are a Bit MoreUser Stories Actually Are a Bit More
Card
– As a <role>
– I want <something>
– So that...
People Often Refer to User Stories asPeople Often Refer to User Stories as
Agile Requirements and also….Agile Requirements...
Some (GenerallySome (Generally--Unrecognized)Unrecognized)
Issues with User Story RequirementsIssues with User Story Requi...
Any Issues with this User Story?Any Issues with this User Story?
As a filling station attendant,
I want a gas pump,
so I c...
Issues with These Acceptance Criteria?Issues with These Acceptance Criteria?
Displays gallons dispensed, price per gallon,...
Conventional Requirements PracticesConventional Requirements Practices
Are Reflected in BABOKAre Reflected in BABOK...
Two Types of Requirements:Two Types of Requirements:
Business/User/CustomerBusiness/User/Customer Product/System/SoftwareP...
Even Requirements “Experts” ThinkEven Requirements “Experts” Think
the Difference Is Just Level of Detailthe Difference Is...
When Business/User Requirements AreWhen Business/User Requirements Are
Detailed First, Creep Is ReducedDetailed First, Cre...
Other Common Erroneous BusinessOther Common Erroneous Business
Requirements BeliefsRequirements Beliefs
We already define ...
Requirements OverviewRequirements Overview
Stakeholders
Business needs,
problems, value
Discovery
Analysis
High-Level & De...
What Could Possibly Go Wrong?What Could Possibly Go Wrong?
Stakeholders
Business needs,
problems, value
Discovery
Analysis...
Problem
Opportunity
Challenge
Cause(s)
As Is
Measure-
Now
Problem
Pyramid™
The thing that will
provide value when
addresse...
Cause(s)
As Is
Measure-
Now
Example
(1 of 3)
Reuse data are
not globally
accessible
People use stand-
alone PCs
Low priori...
Guidelines for Getting the Problem
Pyramid™ Right (1 of 2)
Is the Problem really the problem?
– Do the measures fit it?
– ...
Guidelines for Getting the Problem
Pyramid™ Right (2 of 2)
Problems can be hierarchical, appropriate level is
– The lowest...
Cause(s)
As Is
Measure-
Now
Example
(2 of 3)
Reuse data are
not globally
accessible
People use stand-
alone PCs
Low priori...
Cause(s)
As Is
Measure-
Now
Example
(3 of 3)
Not reusing to
advantage
Lack of awareness
No incentives
Not invented here
Ha...
ObjectivesObjectives
Contrast common requirements interpretations,
including user stories, features, and
‘requirements.’
D...
Robin F. Goldsmith, JDRobin F. Goldsmith, JD
robin@gopromanagement.comrobin@gopromanagement.com www.gopromanagment.comwww....
Go Pro Management, Inc. Seminars/Consulting--Relation to Life Cycle
Systems QA Software Quality Effectiveness Maturity Mod...
Prochain SlideShare
Chargement dans…5
×

Requirements Are Simply Requirements—or Maybe Not

284 vues

Publié le

When talking about requirements, people use identical terms and think they have a common understanding. Yet, one says user stories are requirements; another claims user stories must be combined with requirements; and yet another has a different approach. These “experts” seem unaware of the critical inconsistencies of their positions. No wonder getting requirements right remains a major challenge on many projects. Robin Goldsmith analyzes several often conflicting and not-so-shared-as-presumed interpretations of what requirements are, reveals likely implications, and challenges not-so-wise conventional wisdom. Robin describes a more appropriate model of REAL business requirements whats that provide value when combined with product/system/software hows. He introduces the powerful Problem Pyramid™ systematic disciplined guide to help you more reliably get requirements right. With this structure you can more easily see where user stories do—or do not—fit, identify pitfalls of the “as a <role>” format, and reconcile some of the conflicts between user stories, features, use cases, and requirements.

Publié dans : Logiciels
  • Identifiez-vous pour voir les commentaires

Requirements Are Simply Requirements—or Maybe Not

  1. 1. 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
  2. 2. 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 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... deliverable whats that provide value when met. Offer some tips for avoiding traps of typical, especially Agile, requirements.
  3. 3. 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.> Requirements Are Simply Requirements- or Maybe Not- 3©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO 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
  4. 4. 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 Requirements Are Simply Requirements- or Maybe Not- 4©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... Some call backlog items “features”
  5. 5. Common, Reasonable DistinctionCommon, 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 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... User Stories No sequence of definition implied
  6. 6. 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 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... – So that <benefit> Conversation Confirmation – User story acceptance criteria, tests “Placeholder, reminder for a conversation” Working code
  7. 7. 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 Requirements Are Simply Requirements- or Maybe Not- 7©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... “The system shall ” statements User Stories Use Cases Often without clear, conscious, consistent distinctions
  8. 8. 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 GGGGOOOO PPPPRORORORO 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
  9. 9. 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 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... Many use cases have similar issues as this, even those written by supposed experts
  10. 10. 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 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... cost to zero. Price per gallon can be set or modified.
  11. 11. 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 Requirements Are Simply Requirements- or Maybe Not- 11©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO 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/
  12. 12. 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 GGGGOOOO PPPPRORORORO 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
  13. 13. 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) Requirements Are Simply Requirements- or Maybe Not- 13©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO 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.”
  14. 14. When Business/User Requirements AreWhen 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 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... Business Reqs. (Detailed) Reqs. (Detailed) Product/ System/ Software
  15. 15. 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 Requirements Are Simply Requirements- or Maybe Not- 15©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO 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
  16. 16. 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 GGGGOOOO PPPPRORORORO 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
  17. 17. 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 Requirements Are Simply Requirements- or Maybe Not- 17©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO 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
  18. 18. 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 GGGGOOOO PPPPRORORORO 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
  19. 19. 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 GGGGOOOO PPPPRORORORO 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
  20. 20. 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 GGGGOOOO PPPPRORORORO 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?
  21. 21. 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 GGGGOOOO PPPPRORORORO 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
  22. 22. 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 GGGGOOOO PPPPRORORORO 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 project FAILURE
  23. 23. 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 GGGGOOOO PPPPRORORORO 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
  24. 24. 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 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... deliverable whats that provide value when met. Offer some tips for avoiding traps of typical, especially Agile, requirements.
  25. 25. 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. Requirements Are Simply Requirements- or Maybe Not- 25©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... • 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
  26. 26. 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 Business Requirements Requirements Are Simply Requirements- or Maybe Not- 26©2015©2015©2015©2015 GGGGOOOO PPPPRORORORO MMMMANAGEMENT,ANAGEMENT,ANAGEMENT,ANAGEMENT, INCINCINCINC.... 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 Business Requirements Writing Testable SW Requirements

×