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

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.

Audience for this Presentation
• [Marketing] Product Managers Who…
• 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

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

CLARIFY TERMINOLOGY
“Product”
Requirements
Backlogs

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

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.

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.

Types of Backlogs
• 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)

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

PRODUCT REQUIREMENTS
DEVELOPMENT TOOLS

Product Requirements
Development Tools
1. Requirements Backlog: Statements & User Stories
2. Problem and Purpose Statements
3. New Product Summary
5. Context Diagram
6. Process Flow Charts
7. Prototypes
9. Voice of the Customer (VoC) Validation

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

Example: Product Requirements Backlog
Red7 Management Solutions
Product Requirements [date] [Product Manager]
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.

Product Requirement Details
• Requirement No.
• for reference and traceability across other
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

Requirement Statements & User Stories
• Requirement Statements
• Not required but implied: “The product shall have the “…
• Begin Descriptions with: “Ability to …”
• 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

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 ?
• Reuse
• Product Summaries
• Sales & marketing tools

New Product Summary
• 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

Example: Red7 MNaneawge mPenrot Sdoulutciotn Ss ummary
NEW PRODUCT SUMMARY
[NEW FUNCTIONALITY NAME]
[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.

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.
• Reuse
• Sales Presentations & Proposals
• Analyst Relations

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
Futures
• Feature 8
• Feature 9
• …

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 11    
Feature 13    
Category D
Feature 14    
Feature 16 

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

Context Diagram
• 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

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

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.

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)
• Use
• Initial version from Product Manager
• Update after cross-functional review
• Tool: Microsoft Visio
• Business, Cross Functional Flowchart Stencil

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

Example: Simple Screen Prototype
• Use Word Processor, Spreadsheet, Drawing Program
• KISS [Purpose is to communicate intent, not design!]
SCR-001: Registration
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

Example: Page Description Diagram

Example: HTML Screen Prototype
• Doesn’t have to be fancy (shouldn’t be),
just something to provide a common view for further
discussions

Product Use Cases [User Scenarios]
• 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]

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.
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,
….

Voice of the Customer (VoC) Validation
• Why? Validate your
• Requirements definition
• Requirements prioritization
• Business case assumptions
• 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)

PUTTING IT ALL
TOGETHER

The Product Requirements Development
Process Requirements
Backlog
High Level
Requirements
Release
Roadmap
Project
Release
Summary
Context
Diagram
Product
Process Work
Flows
Product Use
Cases
Prototypes
VoC
Research
Product
Requirement
Documents

Agile PLC Scoping
Sprint 1: Scope Definition
1. Initial Backlog and User Stories
2. High Level Requirements: Problem and Purpose Statements
4. Project Release Summary
Sprint 2: Requirements Definition
5. Context Diagram
6. Process Workflow Diagrams
Sprint 3: Requirements Validation
7. Prototypes
9. Market Research: Client Presentation draft & feedback survey
Sprint 4: Approval
• Requirements Quality Check
• PRD assembly, reviews, & approvals
• Ready to kickoff Design & Development project
• PRD = product project requirements backlog

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

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

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.

CODA
Closing Thoughts & Suggestions

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

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]

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Red7 Developing Product Requirements: Tools and Process

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

More from Robert Grupe, CSSLP CISSP PE PMP

More from Robert Grupe, CSSLP CISSP PE PMP (12)

Recently uploaded

Recently uploaded (20)

Red7 Developing Product Requirements: Tools and Process

Editor's Notes