GO PRO GO PRO MANAGEMENT, INC. Robin F. Goldsmith, JD SYSTEM ACQUISITION & DEVELOPMENT QUALITY/TESTING PRODUCTIVITY

Transcription

1 Requirements Are Requirements- or Maybe Not Robin F. Goldsmith, JD SYSTEM ACQUISITION & DEVELOPMENT BUSINESS ENGINEERING QUALITY/TESTING PRODUCTIVITY TRAINING 22 CYNTHIA ROAD NEEDHAM, MA (781)

2 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. -2

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

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

5 Common, Reasonable Distinction Between Features and User Stories Theme Features» Epics User Stories No sequence of definition implied -5

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

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

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

9 Any Issues with this User Story? As a filling station attendant, I want a gas pump, so I can pump gas Many use stories have similar issues as this, even those written by supposed experts -9

10 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. -10

11 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? Contact me at for a copy -11

12 Two Types of Requirements: Business/User/Customer 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 Many possible ways to accomplish Product/System/Software Language & view of a humandefined 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) -12

13 Even Requirements Experts Think the Difference Is Just Level of Detail Business Requirements (High-Level, Vague) BABOK v3 2.3 p. 26 Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. Product/ System/ Reqs. Software (Detailed) -13

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

15 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 Not an issue for small changes What users should provide for developers to build from -15

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

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

18 Problem Opportunity Challenge The thing that will provide value when addressed adequately. Problem Pyramid Cause(s) As Is What Should Be (Requirements) The way things are now that cause the undesirable results we are getting. Deliverable results, that when delivered, reasonably will achieve the Goal Measure. The measure of the problem now that tells us it is a problem. Measure- Now A specific way the Should Be results can be delivered. Benefit/Value How (Design) Measure-Goal The desired measure of the problem that indicates it s been solved. -18

19 Problem Opportunity Challenge Reuse data are not globally accessible Example (1 of 3) Cause(s) As Is What Should Be (Requirements) Give everyone access via web and intranet People use standalone PCs Low priority for intranet implementation X number of people don t have access Measure- Now How (Design) Measure-Goal Obvious project Benefit/Value All people have access -19

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? 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? -20

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

22 Cause(s) As Is Problem Opportunity Challenge Reasonable, but not only, key Causes What Should Be (Requirements) Not a What Give everyone access via web and intranet People use standalone PCs Low priority for intranet implementation Simply restates Goal Reuse data are not globally accessible A Cause X number of people don t have access Example (2 of 3) Measures do fit Measure- Now How (Design) Measure-Goal Obvious project FAILURE A How Benefit/Value No Real Value All people have access -22

23 Problem Opportunity Challenge Not reusing to advantage Example (3 of 3) Cause(s) As Is What Should Be (Requirements) 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 Measure- Now How (Design) Measure-Goal People understand how to do reuse (Hi) X+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 Spend Y-$ Take Z- months to build systems -23

24 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. -24

25 Robin F. Goldsmith, JD 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 for Software Test Documentation Standard Revision Committee. Member IEEE Std 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 Write Right Agile User Story and Acceptance Test Requirements Right -25

26 Go Pro Management, Inc. Seminars/Consulting--Relation to Life Cycle Proactive Systems/Software Quality Assurance (SQA) Credibly Managing Projects and Processes with Metrics System Measurement ROI Test Process Management Feasibility Analysis Proactive User Acceptance Testing Systems Analysis Defining and Managing Business Requirements Reusable Test Designs System Design Writing Right Agile User Story and Acceptance Test Requirements Right Testing Early in the Life Cycle 21 Ways to Test Requirements Test Estimation Risk Analysis Making You a Leader Development Implementation Operations Maintenance Proactive Testing: Risk-Based Test Planning, Design, and Management Managing Software Acquisition and Outsourcing: > Purchasing Software and Services > Controlling an Existing Vendor s Performance -26