product planning
Download
Skip this Video
Download Presentation
Product Planning

Loading in 2 Seconds...

play fullscreen
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)
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
slide32
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
ad