Product planning
Download
1 / 47

Product Planning - PowerPoint PPT Presentation


  • 132 Views
  • Uploaded on

Product Planning. #2 reason for project failure: Incomplete requirements. Cost of a bug in requirements. Data from the Late 70 th. Modern environment. Rapid Application Development Tools Cost of development < Cost of Planning

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Product Planning' - jontae


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Product planning
Product Planning

#2 reason for project failure: Incomplete requirements


Cost of a bug in requirements
Cost of a bug in requirements

Data from the Late 70th


Modern environment
Modern environment

  • Rapid Application Development Tools

    • Cost of development < Cost of Planning

    • Extreme case: Throw-away prototypes instead of document updates (Agile Approach)

  • New Deployment Models

    • SaaS, Automatic Updates

    • Reduced cost of update deployment


Can the planning phase be skipped
Can the planning phase be skipped?

  • Still have old models around

    • Large scale projects: Plane throwaway prototyping?

    • Desktop Software: cost of a bug in MS Office?

  • Requirements and specifications are captured in

    • In the Code and UI screens

    • In head of a developer/CEO

    • Product Lifecycle Management Systems

    • Word documents, Excel tables, Visio diagrams


Waterfall vs agile
Waterfall vs. Agile

  • Waterfall

    • Complete specifications/design before coding

  • eXtreme Programming(XP)

    • Short User Stories

  • Myriad of approaches in-between


A word on methodologies
A word on methodologies

  • No methodology is perfect

  • “The list of tricks and common situations for which these tricks were found to be helpful for some(many) people”

  • Special case: methodology imposed by your organization


This course
This course

  • Create 3 requirements documents

    • What user need? (Problem)

    • What system should do to meet user need? (features)

    • How system should behave? (implement features)

    • MRD,PRD,FRD

  • Short, Informative

  • Will be updated during the course


Good requirements are
Good requirements are:

  • Correct

  • Necessary

  • Prioritized

  • Unambiguous

  • Verifiable

  • Feasible

  • Complete


Every document is a proposal
Every Document is a Proposal

  • You want(propose to) somebody to take actions on your documents

    • Customer :Sign the contract

    • User: Provide you with a feedback

    • Developers: Commit on it

    • Manager: Praise you


Crash course on proposal writing
Crash Course on Proposal Writing

  • Proposal should be ( in that order)

    • Convincing

    • Correct

    • Complete

  • 100% of real life could not be put on paper

  • People have short attention span

  • Short informative documents capturing the essence of the requirements/specifications


Short informative documents
Short informative documents

“I have made this letter longer than usual, because I lack the time to make it short”

Blaise Pascal,(1657) 



Problem feature behavior
Problem->Feature->Behavior

  • MRD/CRS

    • A user needs…

    • In terms of the problem

    • Try to keep solution out

  • PRD

    • A system should….

    • In terms of the solution/features

    • Try to keep behavior/technology out

  • FRD/SRS

    • A system will….

    • In terms of UI, actions sequences, data flows

    • Try to keep inner working(classes, architecture) out

Strict boundaries are not always realistic:

“A user needs a large green button in the middle of the screen”


Example
Example

  • Customer: last month our system is crashed and we lost all of our data. It was terrible, we lost $1M in revenues

  • Business Analysts: A user needs to be able to retain following data (D1,D2) in XXX time frame in case of systems failures: F1,F2,F3. This a critical requirements

  • Product Manager: A system should automatically periodically backup data at remote site according the policies P1,P2. The maximal data capacity is Z. The configuration options are O1, O2,O3. A system should be restored using saved data and following procedures….

  • Program Manager: A system will perform following actions when backup event is triggered (S1,S2,S3) The following screenswill be presented to a user for data backup policies configuration


A problem have many solution
A Problem Have Many Solution

  • Program Manager: The system will continuously synchronize following data with standby reserve (“shadow”) copy of the system. In case of the failure the system automatically switch to the reserve copy


A feature may be supported by different system behavior
A feature may be supported by different system behavior

  • Program Manager: the configuration of the system will be performed using configurations files F1, F2


Example 2
Example #2

  • Problem:

    • A user should be able to verify that the text is in correct English

  • Solution:

    • Automatically correct spelling mistakes as user types

    • Indicate suspected spelling mistakes

    • A proofing tool to run on whole documents

  • Behavior

    • Red underlying of suspected misspelling after user put a separator character at the end of the word

    • Yellow highlighting of misspelled words

    • Separate window with suggested correction for current paragraph


Managing change requests
Managing Change Requests

  • Unique characteristic of Software Engineering is rate and dimension of changes

  • Software change is inevitable

  • Anticipating changes is in the core of almost every software engineering activities

  • Traceability is a key technique for coping with changes during the planning phase


Traceability
Traceability

  • Keep track on connection between market ,product and functional requirements

  • Unique labels of requirements/specification

  • Tractability of: bugs, releases, test cases ,project work items

  • Traceability Matrix


Traceability matrix safety tool
Traceability Matrix: Safety Tool

  • Make sure all requirements (new and old) are covered

  • Make sure obsolete requirements /changed is not implemented

  • Make sure all critical bugs are fixed

  • Make sure all scenarios are tested

  • Track project progress (% of requirements covered by currently implemented features)


A traceably matrix

Sample traceability matrix

A traceably matrix




Business analyst
Business Analyst

  • Other names: Outbound Product manager, Marketing Product Manager

  • Represent customer, users or other stakeholders (e.g. customer partners)

  • Expert in the problem domain

  • Major information channel (bi-directional) to customer


Customer requirements
Customer requirements

  • A Customer often speaks in terms of current bad solution and not the business problem

  • Different people at customer organization have different views(priorities) on the problem

  • Customer often assumes some facts are common knowledge while they are not


Market requirements
Market requirements

  • None or little customer feedback

  • Changing business environment

  • Requirements to support:

    • Creating value for potential customers

      • What do customer want? (problem definition)

    • Delivering value

      • Fabulous web site that nobody use

    • Capture value

      • Generate revenues to pay programmers’ wages


The essence of market requirements
The Essence of Market Requirements

  • Short problem description

  • Lists/Tables of

    • Stakeholders(Actors)

    • Scenarios/Tasks

    • Requirements

  • What actor should be able to do in order to complete a task?


Stakeholders
Stakeholders

  • External

    • Users (e.g. HR, Management)

    • Buying Decision Maker

    • IT

  • Internal

    • Sales

    • Marketing

    • Support

    • Integrators

  • Stakeholder description

    • Skills and Background (e.g. technical, management)

    • Goals (save time, increase control etc.)


Tasks and requirements
Tasks and requirements

  • Tasks an actors need to perform

    • IT: Backup the system

    • HR: Create new employee

  • Requirements

    • Id

    • Short catchy name

    • Actor

    • Directive: A user should be able…

    • Priority

    • Tasks

    • Other: source, constrains etc.


Example1
Example

  • ID: R1

  • Actors: HR, employee

  • Name: User Authentication

  • Directive: A user should be able to be authenticated by the system

  • Tasks: T1(HR creates new employee record) , T2(an employee change his address)


Assignment 2
Assignment #2

  • Each group plays Business Analyst for the assigned project

  • Short presentation on market requirements (15 minutes)

  • Consult “customer” during the preparation

  • Discussion and brainstorming in the class (15 minutes)

  • A “customer” is expected to provide most of the feedback

  • Product Planning team produces MRD based on obtained feedback

  • MRD(version 1.0) submission deadline: a week after the presentation


Product planning
MRD

  • Keep it short: 2-3 pages

  • Choose format, order of presentation which is most appropriate for the problem

  • Check Google for MRD templates

  • Expect changes, keep change log



Good requirements are1
Good requirements are:

  • Correct

  • Necessary

  • Prioritized

  • Unambiguous

  • Verifiable

  • Feasible

  • Complete


Product planning team
Product Planning Team

  • Product Planning Team(PPT) is an owner of the project and responsible for delivering the product to customer satisfaction

  • PPT should open Google Group for a project

  • Upload presentation, documents

  • Try to perform all further communications about the project with other groups through the Google group postings

  • Send me URL for Google Group




Product manager1
Product Manager

  • Other names: Technical/Inbound Product Manager

  • Good knowledge of the problem domain

  • Solution expert

    • Aware of other solutions for the problem

    • Technological background, understand approximate cost and feasibility of the features

  • Communicate with Business Analyst and Engineering to find best trade-off between scope and cost





Course project
Course Project

  • Duration is fixed : 1 semester

  • Cost(Effort) is fixed: team size and amount of time each member can dedicated to the project

  • Choose scope wisely!


Product requirements document
Product Requirements Document

  • Feature requirements

  • Compatibility requirements

  • Performance/Capacity requirements

  • Internationalization requirements

  • Documentation requirements

  • Deployment requirements

  • Support and training requirements


Our focus
Our focus

  • Feature requirements

    • ID: P1

    • Directive: System should support user authentication

    • Constrains: Some cellular providers block all protocols besides HTTP, so system should support authentication via HTTP protocol (no SSL)

    • Source Market Requirements ID: M3,M4

    • Priority: Critical/High/Nice-to-Have


Assignment 3
Assignment #3

  • Planning team makes a presentation on product requirements (15 minutes, 10 slides)

  • In class discussion, brainstorming (15 minutes)

  • “Customer” is expected to ask questions

  • Submit PRD ver 1.0 in a week after the presentation

  • Upload to Google Group

  • Keep it short (1-3 pages)

  • Don’t forget change log

  • Google for PRD templates/examples

  • Choose your own format/order


Good requirements are2
Good requirements are:

  • Correct

  • Necessary

  • Prioritized

  • Unambiguous

  • Verifiable

  • Feasible

  • Complete