O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Requirement Writing for Product Management

Requirement Writing / Gathering for Product Management includes the following concepts: requirement writing, requirement gathering, product management, product design, product development, knowledge management, product manager, knowledge manager, Requirements analysis, Requirements management, Requirements engineering, Requirements traceability, Requirements Development (RD)

  • Entre para ver os comentários

Requirement Writing for Product Management

  1. 1. Requirements Writing By Nainil Chheda http://www.nainil.com/research/
  2. 2. Intentionally Blank http://www.nainil.com/research/
  3. 3. Prioritizing Software Requirements with Kano Analysis http://www.nainil.com/research/
  4. 4. Requirements Essential Customer Incremental Requirements Requirements http://www.nainil.com/research/
  5. 5. Requirements Quadrant • Surprise & Delight • More is Better – Wow factor – Increasing Utility – Follow the laws of Diminishing Marginal Utility • Must be • Better not be – Required Functionality – Bad Functionality http://www.nainil.com/research/
  6. 6. Writing the Market Requirements Document http://www.nainil.com/research/
  7. 7. Roles Product Manager Team • Finds problems and conveys to development Product Manager • Represents the customer • Owns the Business Case Product Designer Functions of the Team Find A Problem Program Manager Test Analyze It Developer QA Code Design A Solution http://www.nainil.com/research/
  8. 8. Characteristics Persona Who Necessary Problem What Concise – Verifiable To the point Goal When Unambiguous Design Free Requirement Use Scenario Why Requirement What Consistent Feasible Complete Specification How http://www.nainil.com/research/
  9. 9. Requirements IEEE Business 2 Business (B2B) 1 Functional Standardization 2 Performance Certification 3 Constraints Installation 4 Interface Implementation 5 Security Customization 6 Localization 7 Documentatoin 8 Education http://www.nainil.com/research/
  10. 10. Elements In: Requirement Functional Business Case Document Specification Requirements Name Name Executive Summary Description Description Business Case Persona (who is Difficulty Market Requirements affected) Type of Requirement Confidence Level Functional Specs Source Effort Go-to-Market Strategy Tracking Information Attachments (sample) Tracking Information http://www.nainil.com/research/
  11. 11. Elements In: Requirement Document Functional Specification Name Name Description Description Persona (who is affected) Difficulty Type of Requirement Confidence Level Source Effort Tracking Information (author) Attachments (sample) Tracking Information (author) http://www.nainil.com/research/
  12. 12. Agile Market Requirements http://www.nainil.com/research/
  13. 13. The Problem The Trouble • Product Managers are part technical “Requirement • Product Managers try to Sell • Product Managers try to write is the Requirement Specs (part problem, part implementation) problem” Some Terms • Requirement: Short stmt of the problem • Specification: Detailed description of how to solve the problem http://www.nainil.com/research/
  14. 14. The Problem - continued.. • Executives are constantly adding new requirements “Agile is often an – Thus Projects frequently exceed the budget and attempt to manage schedule of the project our executives • Building products is like rather than to be moving a train. – It takes a long time to get more responsive everyone organized and to the market” started. http://www.nainil.com/research/
  15. 15. Management Talk • Management: • Management: “How long would it take you to build it?” “Yes, but give me a date • Developer: “Well, that anyway.” depends on what it is, doesn’t it” http://www.nainil.com/research/
  16. 16. The Answer • Functional Specs describes how a product will work “Functional entirely from the users perspective. It talks about Specification features, specific screens, menus and so on. is the • Technical Spec describes the internal implementation of Answer” the program. It talks about data structures, database models, programming language etc. http://www.nainil.com/research/
  17. 17. The Solution • The product manager should: – serve as the customer representative in planning and requirements definition – Define the requirements and the product roadmap for a market of customers – Support the ideals of agile development (we want process, but not to much process) http://www.nainil.com/research/
  18. 18. Feature Police: Following Through on Requirements http://www.nainil.com/research/
  19. 19. Latest request is the Greatest Standard Forgotten Requirements v/s Custom Product Not so Important after some time http://www.nainil.com/research/
  20. 20. Issue & Solution • Issue: Requirements are often forgotten, mostly to save time in order to meet deadlines and get projects completed • Solution: Making sure important requirements are not forgotten like a broken record http://www.nainil.com/research/
  21. 21. Working the Plan Using a Plan That Works http://www.nainil.com/research/
  22. 22. Planning “Developments Planning efforts are important as the rest of the company depends upon the success of such planning in order to plan their own work” “No plan at all leads to resistance, time waste and chaos” http://www.nainil.com/research/
  23. 23. Software Developers Resist Planning • They feel they are being asked to estimate how long it will take to complete work which is: – Undefined – Can’t be Determined – Feature overload on a tight deadline http://www.nainil.com/research/
  24. 24. Off Track • The shorter your cycle to plan and review development, the shorter the possible amount by which you can get off track • It’s important to focus status meetings on: – Clarifying delays periods – Understanding the reason for delay – Applying new knowledge to reset future estimates – Adhering to the newest version of the plan http://www.nainil.com/research/
  25. 25. Managing Product Requirements: Where did all my Customer Insights Go? http://www.nainil.com/research/
  26. 26. Product Requirements Doc (PRD) • Characteristics: • Methodology: – Should be Dynamically – Capture all valuable Evolving customer insights – Should change form to – Separate core suite the needs of its requirements from audience peripheral information – Should have the right – Distinguish short-term level of detail requirements from long- term requirements http://www.nainil.com/research/
  27. 27. Customer Insight “Customer Insights “These Customer Insights are one of your typically company’s the most valuable disappear as assets” fast as they are collected” http://www.nainil.com/research/
  28. 28. Developing & Prioritizing Product releases tend to offer an abundance of surprises (not nice) “If we have been developing and prioritizing requirements for future products on an ongoing basis, we will have success” Iron Triangle of Project Management Scope Schedule Resources http://www.nainil.com/research/
  29. 29. Requirements: Like Lambs to the Slaughter http://www.nainil.com/research/
  30. 30. The Plot “A lot of the ideas you propose won’t make it to the high priority pile, and from there to the product development plan” http://www.nainil.com/research/
  31. 31. The Debate (Prod Mgr v/s Developer) • The conversation: – That’s Easy! “In the end, you can – It’s not as Easy as it rest assured that Sounds only the fittest – There’s a much better way to do it requirements – That Depends survive for the – We Can’t Do This most part” – Sacrificial Lamb (some requirements will not make it) http://www.nainil.com/research/
  32. 32. Software Development Pitfalls: Requirements http://www.nainil.com/research/
  33. 33. Solving Your Problems & Design • Requirements and Solving >> Myth: Solving requirements challenges will solve all your Problem: problems • Requirements and Design: >> Requirements are not design specs. >> Requirements: WHAT Design Specs: HOW http://www.nainil.com/research/
  34. 34. Planning & Requirements • Requirements and >> Requirements: What Planning: >> Planning: Development sits down and decides how to divide up and order the tasks • Requirements and >> Different types of requirements Requirements: >> Split: Technical and Market requirements http://www.nainil.com/research/
  35. 35. What, How, Constituents, Compromise • What and How: >> If What & How are not separated, the document becomes a voluminous design spec • Constituents and >> Constituents: Requirements come from different areas Compromise: >> Compromise: Product Managers have to balance the needs of various groups http://www.nainil.com/research/
  36. 36. Uncertainty, Democracy & Dictatorship • Requirements and >> Uncertain Goal & Scope Uncertainty: >> How to use Software Requirements? When to complete? >> Solution: Establish fixed dates • Democracy and >> Encouraging requirements Dictatorship: from all can result in an expectation of mob rule http://www.nainil.com/research/
  37. 37. Software Development Pitfalls: Planning http://www.nainil.com/research/
  38. 38. Solving Your Problems & Planning • Planning and Solving your >> By planning every effort a little better, you can achieve a Problem: number of incremental improvements that adds up to major progress • Planning is not your only >> While planning is involved in virtually everything, it will Problem: not solve all your problems. http://www.nainil.com/research/
  39. 39. Requirements & Planning • Planning and >> Planning is not requirements gathering Requirements: • Planning and Planning: >> Plans can be very detailed or very broad-brush http://www.nainil.com/research/
  40. 40. Uncertainty & Outside Help • Planning and Uncertainty: >> Planning addresses the future >> When faced with uncertainty mark: minimum, maximum and midpoint • Planning and Outside >> There is a lot of outside expertise from outside Help: available while planning for the software industry http://www.nainil.com/research/
  41. 41. Planning & Development • Planning and Design: >> Should you plan before design? • Planning and >> Planning: Defined Structure Development: >> Development: Methods and Steps to develop software http://www.nainil.com/research/
  42. 42. References • Pragmatech Marketing: http://www.pragmaticmarketing.com • http://www.pragmaticmarketing.com/publications/magazine/4/3/0605ss/?searchterm=writing%20requirements • http://www.pragmaticmarketing.com/publications/topics/01/0104sj/?searchterm=writing%20requirements • http://www.pragmaticmarketing.com/publications/magazine/6/1/agile-market-requirements • http://www.pragmaticmarketing.com/publications/topics/05/0511jm2/?searchterm=writing%20requirements • http://www.pragmaticmarketing.com/publications/topics/05/0509jm/?searchterm=writing%20requirements • http://www.pragmaticmarketing.com/publications/magazine/4/1/managing-product-requirements • http://www.pragmaticmarketing.com/publications/topics/02/0204sj • http://www.pragmaticmarketing.com/publications/topics/03/0311jm • http://www.pragmaticmarketing.com/publications/topics/06/0604jm1 • http://www.pragmaticmarketing.com/publications/topics/06/0604jm2 http://www.nainil.com/research/
  43. 43. Copyright Information • No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of Nainil Chheda (nainil@eliteral.com). The information contained herein may be changed without prior notice. • Data contained in this document serves informational purposes only. • The information in this document is proprietary to Nainil Chheda. This document is a preliminary version and not subject to other agreement with Nainil Chheda. Nainil assumes no responsibility for errors or omissions in this document. Nainil does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. Nainil shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. http://www.nainil.com/research/