Red7 Developing Product Requirements: Tools and Process

Red7 Developing Product Requirements: Tools and Process
Red7 :|: product management DEVELOPING PRODUCT REQUIREMENTS Tools and Process robertGrupe, CISSP, CSSLP, PE, PMP tags :|: product management, requirements, user stories, use cases, Agile, Sprint, Scrum, UML © Copyright 2011-2014 Robert Grupe. All rights reserved. 1
Red7 :|: product management Why this Presentation ? • Consequences of Poorly Defined Requirements • Software Studies… 60-80% of errors originate in the user requirements and functional specification stage • Slows the product design and development phases by having to define and clarify objectives and requirements • Increases production costs due to change requests caused by having to fix execution errors or omissions • Challenges In Determining • How do you know that you have the right requirements ? • How do you know you have all the requirements you need to start work ? • How can others effectively interpret the intent and context of your requirements ? • This presentation is about practical tools and an approach that can be used to iteratively develop high quality product requirements. © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Audience for this Presentation • [Marketing] Product Managers Who… © Copyright 2011-2014 Robert Grupe. All rights reserved. • Are responsible for • defining new products (and/or services) • enhancing existing products (and/or services) • Primarily for • Software application development with • Remote developers, or • Matrix organizations with project assigned staffing • Working on • Defining product project requirements to be designed and developed by others • Who want • a specific result at the end • Also Applicable To • Business Analysts • defining or enhancing internal use business applications • Small, independent development teams • to clarify objectives
Red7 :|: product management Table of Contents • Clarify Terminology: speaking the same language • Product Requirements Development Tools 1. Requirements Backlog: Statements & User Stories 2. New Product Summary 3. High Level Problem and Purpose Statements 4. Functionality Roadmaps 5. Context Diagram 6. Process Flow Charts 7. Prototypes 8. Product Use Cases 9. Voice of the Customer (VoC) Validation • Putting It All Together [with Agile] • Requirements Quality Evaluation Criteria • The Product Requirements Document • Closing Thoughts & Suggestions © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management CLARIFY TERMINOLOGY “Product” Requirements Backlogs © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management What Is A Product? Well, it depends upon whom you ask • Project Management definition • The outcome of an activity, especially in contrast to a process by which it was created or altered. • The amount of an artifact that has been created by someone or some process. © Copyright 2011-2014 Robert Grupe. All rights reserved. • Marketing definition • A commodity offered for sale. • Any tangible or intangible good or service that is a result of a process and that is intended for delivery to a customer or end user. • Product  Systems + People • System - not just software applications, but also any process used to deliver a service. • i.e. automated and manual processes to provide valuable customer services
Red7 :|: product management What Are Requirements? • Product Requirements - attributes of the final product • Functionality • Computer application user interfaces, • Communications • Reports • Customer services • User help manuals & self-help tutorials, • Service delivery staffing licensing/certifications • etc. • Project Requirements - things that need to be done • Types of testing & validation • Product launch promotion • User support readiness • Customer/user training development • Etc. © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Types of Product Requirements [ Product Requirements Document (PRD) Outline ] • Functional Requirements • What a product/service must do for the customer and users • i.e. “The product shall do…” • Nonfunctional Requirements • Product attributes (appearance, performance, legal, legal/regulatory compliance, etc.) • i.e. “The product shall be…” • Look and Feel • Usability • Performance • Operational • Maintainability and Portability • Security • Cultural and Political • Legal • Upgrading • User Documentation. © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Types of Backlogs © Copyright 2011-2014 Robert Grupe. All rights reserved. • Product Backlog • Complete listing of all future product enhancement ideas and requirements • Project Backlog • Prioritized listing of product backlog items to be addressed in a project • From the Product Requirements Document (PRD): prioritized product backlog requirements • Project Deliverables: product components & management reporting items • From the Project Plan • Project Sprint Backlog • Incremental product and project deliverables • To be completed in a time-boxed period (1-6 weeks)
Red7 :|: product management Project Product Requirements Backlog • The Product Requirements Document (PRD) • Defines the overall objectives and scope of the project • Specification for a project end-deliverable • Created and maintained by the Product Manager • The [Business/Marketing/Brand] “Owner” • Starting point for the product design (high level requirements) • Baseline for QA acceptance testing criteria • Why Product Projects Need a PRD • Defines the scope for the project • Provide a historical record for retrospective review and process audits • Agreed definition • Project performance reviews for process improvement • Can be thought through, reviewed and edited • Easily shared with others • Reduces developer gold plating © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management PRODUCT REQUIREMENTS DEVELOPMENT TOOLS © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Product Requirements Development Tools 1. Requirements Backlog: Statements & User Stories 2. Problem and Purpose Statements 3. New Product Summary 4. Functionality Roadmaps 5. Context Diagram 6. Process Flow Charts 7. Prototypes 8. Product Use Cases 9. Voice of the Customer (VoC) Validation © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management The Product Requirements Backlog • Create an initial list of requirement candidates • What you already know • Suggestion box submissions (internal ideas, customer requests) • Solicited input from others • Brainstorming sessions • Deferred features from previous releases, • Unfixed defects • Etc. © Copyright 2011-2014 Robert Grupe. All rights reserved. • Organize list • Categories/types: reporting, user registration, security, support, etc. • Importance prioritization • Methods • Sticky notes: • Small project agile teams using Kanban boards and Oobeya space • Index cards: LoTec • Spreadsheet: Most common • Product Requirements Management Database: Nice if you can
Red7 :|: product management Example: Product Requirements Backlog Red7 Management Solutions Product Requirements [date] [Product Manager] © Copyright 2011-2014 Robert Grupe. All rights reserved. Unique # Planned Release Release Priortity Customer Attractive-ness Customer Disappoint-ment Category Requirement Statement User Story Product Use Case Notes Source 0001 ABC 3.1 1 - Must Regulatory Ability to … As a [user role], I want to [functionality] so that I can [reason]. ABC 3.x PUC-003 Further descriptive, historical, etc. 0002 ABC 3.2 2 - Should Reporting Ability to … 0003 ABC 4.0 3 - Could Usability Ability to … 0004 Futures 4 - Wont Ability to … Requirements Unique Identifiers: BL-001, BL-002, etc.
Red7 :|: product management Product Requirement Details • Requirement No. • for reference and traceability across other © Copyright 2011-2014 Robert Grupe. All rights reserved. documents • Unique # never changes • Target Release • Urgency: Current, Next, Future • Prioritization • For final delivery only, not planning • MoSCoW: Must, Should, Could, Won’t • Then Ranking 1-999x • Statement/Description • One sentence statement of the intention of the requirement. • User Story [Who, What, Why] • Fit Criterion: A quantification of the requirement use to determine whether the solution meets the requirement • Rationale: Why the requirement is important or necessary. (“… because” / “…so that”) • Customer Attractiveness • Desire to have the requirement • Customer Disappointment • Dissatisfaction if not implemented • Category/Type • PRD section • Product Use Case No.: • Origin of the requirement • Source • Who raised the requirement, when • Notes (further details) • Dependencies: other requirements with a change effect • Conflicts: requirements that contradict this one • Supporting Materials: reference to other information • History: Origin and changes to the requirement
Red7 :|: product management Requirement Statements & User Stories • Requirement Statements • Not required but implied: “The product shall have the “… • Begin Descriptions with: “Ability to …” © Copyright 2011-2014 Robert Grupe. All rights reserved. • Examples • Ability to report the number of active users • Ability to process sales orders for multiple items in a single transaction • User Stories • As a [User Profile], I want to [Goal] so I can/because [Reason] • Example: As a registered user, I want to log in so I can access subscriber-only content
Red7 :|: product management Problem and Purpose Statements [for High Level Requirements] • [Customer] Problem and [Product Feature] Purpose Statements • What is the customer problem (background) that this product will address (business need)? • For “High-Level” Product Requirements • Example • Backlog Requirement Statement: • “Shall reduce customer order transaction costs” • Backlog Requirement Notes: • Purpose: To save money on sales order processing • Advantage: Reduce administrative overhead costs • Measurement: The cost of transactions shall be reduced by 25% of the current cost of order processing, and processing time shall be reduced by 50%. • Quality Evaluation Criteria • Purpose: what is the product to do? • Advantage: what business advantage does it provide? • Measurement: how do you measure the advantage? • Reasonable: is the product development effort expected to have a positive ROI? • Feasibility: can the product achieve the measure? • Achievable: does the organization have the resources to develop and operate the products ? © Copyright 2011-2014 Robert Grupe. All rights reserved. • Reuse • Product Summaries • Sales & marketing tools
Red7 :|: product management New Product Summary © Copyright 2011-2014 Robert Grupe. All rights reserved. • Purpose • Establish common understanding regarding focus and expectations • Clarifies the product manager’s scope of effort with regards to the current project with their supervisor (aka project charter) • Provides a high-level quick summary for stakeholders • Outline (2 page maximum!) • Background and Description • Where did this idea/request/need come from • What it is to be delivered by this project • Summary Table: Problems & Solutions • Goals & Objectives (for this project only) • For the final product • To be addressed through the project (i.e. further research to validate assumptions, etc.) • Measure of Success • In this project by completion • After release into the market • Business Case • During Scoping to be enhanced through further market research if required, ROM estimates based on scoped and requirements. • Notes • Initial draft – no more than 2 hours work! • Write only what you currently know. • Then iteratively update throughout the requirements development phase as you gather more information. • Reuse: PRD Executive Summary for PRD
Red7 :|: product management Example: Red7 MNaneawge mPenrot Sdoulutciotn Ss ummary NEW PRODUCT SUMMARY [NEW FUNCTIONALITY NAME] © Copyright 2011-2014 Robert Grupe. All rights reserved. [Product Manager], [date] BACKGROUND DESCRIPTION Known information of how we got to this point Problem to be solved Perceived Benefit Major issue #1 Benefit of solving #1 Major issue #2 Benefit of solving #2 GOALS & OBJECTIVES General goals for the product to be delivered by this project, and the specific goals to be accomplished in this product project. MEASURE OF SUCCESS Specific and measureable objectives to be addressed in this product project. BUSINESS CASE Summary of current known business case: forecasted revenues, cost-savings, competitive positioning, etc.
Red7 :|: product management Product Functionality Roadmap [Program Projects Phases & Scope] • Purpose • Shows what is being addressed in this immediate version, and items that have been considered but are being deferred to subsequent future releases. • Use: Planning prioritization with, and summaries for, • Executive Sponsors, Investors • Trusted External Partners & Suppliers • Etc. © Copyright 2011-2014 Robert Grupe. All rights reserved. • Reuse • Sales Presentations & Proposals • Analyst Relations
Red7 :|: product management Product Roadmap Timeline YYYYQ1 YYYYQ2 YYYYQ3 YYYYQ4 This Version • Feature 1 • Feature 2 • Feature 3 • Feature 4 Next Version • Feature 5 • Feature 6 • Feature 7 © Copyright 2011-2014 Robert Grupe. All rights reserved. Futures • Feature 8 • Feature 9 • …
Red7 :|: product management Comparative Functionality Matrix Roadmap Competition New Solutions Functionality Product 1 Product 2 New v1 New v2 New v3+ Category A Feature 1      Feature 2    Feature 3   Feature 4     Category B Feature 5  Feature 6     Feature 7      Category C Feature 8      Feature 9    Feature 10    Feature 11     Feature 13     Category D Feature 14     Feature 15    Feature 16  © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Functional Capabilities Roadmap Version 4+ Feature 38 Feature 39 Feature 46 Feature 45 Feature 51 Version 3 Feature 24 Feature 25 Feature 31 Feature 36 Feature 40 Feature 41 Feature 47 Feature 52 Feature 26 Feature 27 Feature 32 Feature 42 Feature 48 Feature 28 Feature 33 Feature 37 Feature 43 Feature 49 Feature 53 Feature 29 Feature 34 Feature 44 Feature 50 Feature 54 Feature 30 Feature 35 Feature 1 Feature 2 Feature 4 Feature 5 Feature 6 Feature 7 © Copyright 2011-2014 Robert Grupe. All rights reserved. Function A Function B Function C Function D Function E Function F Function G Version 1 Feature 8 Feature 11 Feature 3 Feature 9 Feature 10 Version 2 Feature 12 Feature 13 Feature 14 Feature 20 Feature 23 Feature 15 Feature 21 Feature 16 Feature 17 Feature 18 Feature 19 Feature 22
Red7 :|: product management Context Diagram © Copyright 2011-2014 Robert Grupe. All rights reserved. • Purpose • External interfaces • Users and administrators • Tool: Microsoft Visio • Basic Shapes Stencil + UML Use Case Stencil (for Actors) • Reuse • Product Use Case (User Scenarios) development • PRD Summary figure • User roles for access permissions matrix
Red7 :|: product management Example: Product Context Diagram Red7 Product Context Diagram Online Ordering System Internet application to enable customer product ordering. · Create account · Manage account · Place order · Cancel order · Verify order status · Online Support chat assistance Customer Payment © Copyright 2011-2014 Robert Grupe. All rights reserved. E01 Customer E02 Customer Support Rep E03 Warehouse Shipping Manager Bank Shipping Company Pickup Order Place Order Order Status Assistance Chat Order Pick List Shipment Order Registration
Red7 :|: product management Product Process Flow Charts Process Flow Charts Unique Identifiers: PFC-001, PFC-002, etc. Screen Unique Identifiers: SCR-001, SCR-002, etc. Letters Unique Identifiers: LTR-001, LTR-002, etc. Reports Unique Identifiers: RPT-001, RPT-002, etc. © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Product Process Workflows • Process Flow Diagrams (people and systems): • Current process work flow mapping • New processes • New client implementation processes • Maintenance processes (anticipated updates and changes) © Copyright 2011-2014 Robert Grupe. All rights reserved. • Use • Initial version from Product Manager • Update after cross-functional review • Tool: Microsoft Visio • Business, Cross Functional Flowchart Stencil
Red7 :|: product management © Copyright 2011-2014 Robert Grupe. All rights reserved. Prototypes • Note: These are preliminary prototypes by the Product Manager to communicate their intentions clearly with others. • Does not involve others (which spends project resources – time and money) • Will be refined during Planning Phase of project • The product developers will own the design specification (layout, look-feel, etc.), but PM own the input requirements • Screen Prototypes • MS Word: list of user input fields (required y/n, format), result output fields, • MS Excel • Scanned images of hand drawn concepts • Marked up screenshots using MS Paint • For Windows applications: MS Visio Software and Database, Windows UI stencils • For Web applications • MS Office SharePoint Designer • Wireframe prototyping online app (beta) - http://www.genericframe.com • Communication Prototypes (letters, reports, etc.) • MS Word • Definite data fields
Red7 :|: product management Example: Simple Screen Prototype • Use Word Processor, Spreadsheet, Drawing Program • KISS [Purpose is to communicate intent, not design!] SCR-001: Registration © Copyright 2011-2014 Robert Grupe. All rights reserved. Title: Red7 Prototype Registration Request · Your Information o First Name* [20 characters wide] o Last Name* o Email Address*[validate format] o Email Confirmation* · Your Account Information o Your Desired User Name * o Password*? [validate password strength policy, help: cannot contain name] o Password Confirmation* Buttons: Clear, Submit
Red7 :|: product management Example: Page Description Diagram © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Example: HTML Screen Prototype • Doesn’t have to be fancy (shouldn’t be), just something to provide a common view for further discussions © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Product Use Cases [User Scenarios] © Copyright 2011-2014 Robert Grupe. All rights reserved. • Context Diagram • summarizing entities and interactions • Description • Goal to be achieved by use case and sources for requirement • Actors/Entities • List of actors/entities involved in use case • Assumptions • Conditions that must be true for use case to terminate successfully • Steps • Interactions between actors and system that are necessary to achieve goal • Variations: Any variations in the steps of a use case • Non-Functionals: List any non-functional requirements that the use case must meet • Issues: List of issues that remain to be resolved • (Scenario) user sequence: PUC-BL### Product Use Case [References mock-ups]
Red7 :|: product management Example: Product Use-Case Sales Order System Product Use Cases PUC-001: User Registration Users: Customer Assumptions: User has an Internet connection without SSL blocking. © Copyright 2011-2014 Robert Grupe. All rights reserved. Sequence Step User System B.1 SCR-000: Click on “New User? Start here.” B.2 Display logon page B.3 SCR-001 1. Enter email address 2. Select “I am a new user” 3. Click “Sign-In” button B.4 Verify if email address already registered OK: Display secure registration page, step B.5 Existing: Display Error, step A.5 B.5 SCR-002 1. Enter name 2. Confirm email address 3. Enter phone number (optional) 4. Enter desired password 5. Confirm password 6. Click “create account” button B.6 Validate form items, …. A.5 SCR-E01 1. Enter new email address 2. Click “Sign-In” button A.6 Validate form items, ….
Red7 :|: product management Voice of the Customer (VoC) Validation • Why? Validate your • Requirements definition • Requirements prioritization • Business case assumptions © Copyright 2011-2014 Robert Grupe. All rights reserved. • How? • Client Presentation: with selected Prototypes • Feedback Survey: to collect and summarize results • Who? • Customers (people who will make the financial decision) • Users (those who will used your product) • Influencers (those who will advise or support customers and users) • Sale representatives (direct and resellers)
Red7 :|: product management PUTTING IT ALL TOGETHER © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management The Product Requirements Development Process Requirements Backlog High Level Requirements © Copyright 2011-2014 Robert Grupe. All rights reserved. Release Roadmap Project Release Summary Context Diagram Product Process Work Flows Product Use Cases Prototypes VoC Research Product Requirement Documents
Red7 :|: product management Agile PLC Scoping Sprint 1: Scope Definition 1. Initial Backlog and User Stories 2. High Level Requirements: Problem and Purpose Statements 3. Functionality Roadmaps 4. Project Release Summary Sprint 2: Requirements Definition 5. Context Diagram 6. Process Workflow Diagrams Sprint 3: Requirements Validation 7. Prototypes 8. Product Use Cases 9. Market Research: Client Presentation draft & feedback survey © Copyright 2011-2014 Robert Grupe. All rights reserved. Sprint 4: Approval • Requirements Quality Check • PRD assembly, reviews, & approvals • Ready to kickoff Design & Development project • PRD = product project requirements backlog
Red7 :|: product management Individual Requirements Quality Evaluation Criteria1/2 • Concise • Stated in language that is brief and easy to read, yet conveys the essence of what is required. © Copyright 2011-2014 Robert Grupe. All rights reserved. • Completeness • Stated entirely in one place and in a manner that does not force the reader to look at additional text to know what the requirement means. • Ambiguity • Meaningful to all stakeholders. • Susceptible to only one interpretation. • Traceably • To business goal, event, use case, constraints • To functional and test specification
Red7 :|: product management Individual Requirements Quality Evaluation Criteria2/2 • Consistency • Does not contradict other stated requirements nor is it contradicted by other requirements. • Uses terms and language that means the same from one requirements statement to the next. © Copyright 2011-2014 Robert Grupe. All rights reserved. • Relevancy / Necessary • Something that must be included or an important element of the system will be missing for which other system components will not be able to compensate. • Gold plating • Is it really necessary? • Viability / Reachability • A realistic capability that can be implemented for the available money, with the available resources, in the available time. • Requirement or Solution? • Not how they should be solved, but what is it that the client really wants (easy to use, as opposed to “has a GUI”) • Ask “why?” • Verifiable (testable) • Must be able to determine that the requirement has been met through one of four possible methods: inspection, analysis, demonstration, or test.
Red7 :|: product management The PRD Quality Evaluation Criteria • Are these the right requirements? • Is this the product that should be built? • Are the requirements complete? • Does it need more functions? • Can some of the requirements be dropped? • Are they achievable? • Are they reasonable? • Tradeoff between schedule, cost, performance, reliability, and system resource utilization. © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management CODA Closing Thoughts & Suggestions © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Parting Thoughts • These are just some available tools • Might not be necessarily, or beneficial, for every instance • Styles & level of required detail vary • Based on team/organizational preferences • Discuss with team for any existing preferences • Tools Use Guidelines • For New Functionality © Copyright 2011-2014 Robert Grupe. All rights reserved. • Probably all of them • For Functional Improvements • Updates to previous requirement definition documents • For Simple, incremental enhancements • Just Requirement Statements & User Stories will suffice • Process & Quality Improvement is a Journey • Don’t try achieving perfection all at once • Try something, reevaluate and refine over multiple projects • Expect learn-curve and/or resistance to change • Ensure you have upper management support
Red7 :|: product management Consequences of Cutting Corners • The more specific you are, the more likely you will get what you [and your customers] expect • Whatever is unspecified is left for others to omit or interpret any way they want • Contracted partners will only deliver what is explicitly stated: omissions are your responsibility • Internal resources may decide to add or embellish items or ignore potential issues • Incomplete, ambiguous, and missing requirements leads to project delays and increased costs • Confusion clarifying or defining with various groups • Product and specifications rework project disruptions • Lower customer satisfaction • Product released with defects and omissions because testers could not create meaningful test plans [if your project has testing] © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management Requirements Development Tools Reuse • Executive phase reviews and approvals • Voice of the Customer (VoC) requirements validation & feedback • Technical design and testing requirements validation collaboration • Development & ongoing support estimations • Design specifications development • Acceptance testing criteria and testing scenarios development • Sales & Marketing product information brochures • User training materials and examples development • User support documentation development • Leveraging well documented requirements • Executive Sponsorship and cross-functional coordination • Clear communication of scope and outcomes expectations • Market input and feedback from customers, users, partners • Regulatory compliance (Sarbanes Oxley), Personal Data Protection, Financial Data Protection, etc. • Facilitate solution design optimization • Basis for process improvement analysis: Six Sigma / Value Stream Mapping • Improved Quality Assurance Testing © Copyright 2011-2014 Robert Grupe. All rights reserved.
Red7 :|: product management © Copyright 2011-2014 Robert Grupe. All rights reserved. Finis • This Presentation & Further Resources • www.red7managementsolutions.com • Questions, suggestions, & requests • Robert Grupe, CISSP, CSSLP, PE, PMP • robert.grupe@red7managementsolutions.com • +1.314.278.7901

Red7 Developing Product Requirements: Tools and Process

Check these out next

Red7 Developing Product Requirements: Tools and Process

Recomendados

Mais conteúdo relacionado

Apresentações para você(20)

Destaque(20)

Similar a Red7 Developing Product Requirements: Tools and Process(20)

Mais de Robert Grupe, CSSLP CISSP PE PMP(12)

Último(20)

Red7 Developing Product Requirements: Tools and Process

Notas do Editor