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)

1. Requirements Writing
By Nainil Chheda
http://www.nainil.com/research/

2. Intentionally Blank
http://www.nainil.com/research/

3. Prioritizing Software
Requirements with Kano Analysis
http://www.nainil.com/research/

4. Requirements
Essential Customer Incremental
Requirements Requirements
http://www.nainil.com/research/

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. Writing the Market Requirements
Document
http://www.nainil.com/research/

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. 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. 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. 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. 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. Agile Market Requirements
http://www.nainil.com/research/

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. 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. 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. 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. 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. Feature Police: Following Through
on Requirements
http://www.nainil.com/research/

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. 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. Working the Plan Using a Plan
That Works
http://www.nainil.com/research/

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. 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. 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. Managing Product Requirements:
Where did all my Customer Insights
Go?
http://www.nainil.com/research/

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. 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. 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. Requirements: Like Lambs to the
Slaughter
http://www.nainil.com/research/

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. 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. Software Development Pitfalls:
Requirements
http://www.nainil.com/research/

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. 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. 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. 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. Software Development Pitfalls:
Planning
http://www.nainil.com/research/

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