Requirement Writing for Product Management


Published on

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)

Published in: Business, Technology
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirement Writing for Product Management

  1. 1. Requirements Writing By Nainil Chheda
  2. 2. Intentionally Blank
  3. 3. Prioritizing Software Requirements with Kano Analysis
  4. 4. Requirements Essential Customer Incremental Requirements Requirements
  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
  6. 6. Writing the Market Requirements Document
  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
  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
  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
  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
  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)
  12. 12. Agile Market Requirements
  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
  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.
  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”
  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.
  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)
  18. 18. Feature Police: Following Through on Requirements
  19. 19. Latest request is the Greatest Standard Forgotten Requirements v/s Custom Product Not so Important after some time
  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
  21. 21. Working the Plan Using a Plan That Works
  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”
  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
  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
  25. 25. Managing Product Requirements: Where did all my Customer Insights Go?
  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
  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”
  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
  29. 29. Requirements: Like Lambs to the Slaughter
  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”
  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)
  32. 32. Software Development Pitfalls: Requirements
  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
  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
  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
  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
  37. 37. Software Development Pitfalls: Planning
  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.
  39. 39. Requirements & Planning • Planning and >> Planning is not requirements gathering Requirements: • Planning and Planning: >> Plans can be very detailed or very broad-brush
  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
  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
  42. 42. References • Pragmatech Marketing: • • • • • • • • • •
  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 ( 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.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.