requirement writing for product management
Post on 28-Jan-2015
109 Views
Preview:
DESCRIPTION
TRANSCRIPT
http://www.nainil.com/research/
Requirements Writing
By Nainil Chheda
http://www.nainil.com/research/
Intentionally Blank
http://www.nainil.com/research/
Prioritizing Software
Requirements with Kano Analysis
http://www.nainil.com/research/
Requirements
Essential Customer
Requirements
Incremental
Requirements
http://www.nainil.com/research/
Requirements Quadrant
• Surprise & Delight
– Wow factor
• More is Better
– Increasing Utility
– Follow the laws of Diminishing Marginal Utility
• Must be
– Required Functionality
• Better not be
– Bad Functionality
http://www.nainil.com/research/
Writing the Market Requirements
Document
http://www.nainil.com/research/
Roles
• Finds problems and conveys to
development
• Represents the customer
• Owns the Business Case
Team
Product Manager
Product Designer
Program Manager
Developer
QA
Find A Problem
Analyze It
Design A SolutionCode
Test
Product Manager
Functions of the Team
http://www.nainil.com/research/
Characteristics
HowSpecification
WhatRequirement
WhyUse Scenario
WhenGoal
WhatProblem
WhoPersona
Verifiable
Unambiguous
Consistent
Complete
Feasible
Design Free
Concise –
To the point
Necessary
Requirement
http://www.nainil.com/research/
Requirements
Education8
Documentatoin7
Localization6
CustomizationSecurity5
ImplementationInterface4
InstallationConstraints3
CertificationPerformance2
StandardizationFunctional1
Business 2 Business (B2B)IEEE
http://www.nainil.com/research/
Elements In:
Tracking Information
Attachments (sample)Tracking Information
Go-to-Market StrategyEffortSource
Functional SpecsConfidence LevelType of Requirement
Market RequirementsDifficultyPersona (who is
affected)
Business CaseDescriptionDescription
Executive SummaryNameName
Business Case
Requirements
Functional
Specification
Requirement
Document
http://www.nainil.com/research/
Elements In:
Tracking Information (author)
Attachments (sample)Tracking Information (author)
EffortSource
Confidence LevelType of Requirement
DifficultyPersona (who is affected)
DescriptionDescription
NameName
Functional SpecificationRequirement Document
http://www.nainil.com/research/
Agile Market Requirements
http://www.nainil.com/research/
The Problem
“Requirement
is the
problem”
The Trouble
• Product Managers are part
technical
• Product Managers try to Sell
• Product Managers try to write
Requirement Specs (part
problem, part implementation)Some Terms
• Requirement: Short stmt of
the problem
• Specification: Detailed
description of how to solve the
problem
http://www.nainil.com/research/
The Problem - continued..
• Executives are constantly
adding new requirements
– Thus Projects frequently
exceed the budget and schedule of the project
• Building products is like
moving a train.
– It takes a long time to get
everyone organized and
started.
“Agile is often an attempt to manage our executives
rather than to be
more responsive to the market”
http://www.nainil.com/research/
Management Talk
• Management: “How long would it take you to build it?”
• Developer: “Well, that depends on what it is, doesn’t it”
• Management:
“Yes, but give
me a date
anyway.”
http://www.nainil.com/research/
The Answer
“Functional
Specification
is the
Answer”
• Functional Specs describes how a product will work
entirely from the users
perspective. It talks about features, specific screens,
menus and so on.
• Technical Spec describes the
internal implementation of the program. It talks about
data structures, database
models, programming language etc.
http://www.nainil.com/research/
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/
Feature Police: Following Through
on Requirements
http://www.nainil.com/research/
Forgotten
Not so Important
after some time
Standard
v/s
Custom Product
Latest request
is the
Greatest
Requirements
http://www.nainil.com/research/
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/
Working the Plan Using a Plan
That Works
http://www.nainil.com/research/
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/
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/
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/
Managing Product Requirements:
Where did all my Customer Insights
Go?
http://www.nainil.com/research/
Product Requirements Doc (PRD)
• Characteristics:
– Should be Dynamically
Evolving
– Should change form to
suite the needs of its audience
– Should have the right level of detail
• Methodology:
– Capture all valuable
customer insights
– Separate core
requirements from peripheral information
– Distinguish short-term requirements from long-
term requirements
http://www.nainil.com/research/
Customer Insight
“Customer Insights are one of your company’s the most valuable
assets”
“These Customer Insights typically
disappear as fast as they are
collected”
http://www.nainil.com/research/
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”
ResourcesScheduleScope
Iron Triangle of Project Management
http://www.nainil.com/research/
Requirements: Like Lambs to the
Slaughter
http://www.nainil.com/research/
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/
The Debate (Prod Mgr v/s Developer)
• The conversation:– That’s Easy!
– It’s not as Easy as it Sounds
– There’s a much better way to do it
– That Depends
– We Can’t Do This
– Sacrificial Lamb (some requirements will not make it)
“In the end, you can rest assured that only the fittest requirements survive for the most part”
http://www.nainil.com/research/
Software Development Pitfalls:
Requirements
http://www.nainil.com/research/
Solving Your Problems & Design
• Requirements and Solving
your Problem:
>> Myth: Solving requirements challenges will solve all
problems
• Requirements and Design: >> Requirements are not design
specs.
>> Requirements: WHAT
Design Specs: HOW
http://www.nainil.com/research/
Planning & Requirements
• Requirements and
Planning:
>> Requirements: What
>> Planning: Development sits
down and decides how to divide up and order the tasks
• Requirements and
Requirements:
>> Different types of
requirements
>> Split: Technical and Market
requirements
http://www.nainil.com/research/
What, How, Constituents, Compromise
• What and How: >> If What & How are not separated, the document
becomes a voluminous
design spec
• Constituents and
Compromise:
>> Constituents: Requirements
come from different areas
>> Compromise: Product
Managers have to balance the needs of various groups
http://www.nainil.com/research/
Uncertainty, Democracy & Dictatorship
• Requirements and
Uncertainty:
>> Uncertain Goal & Scope
>> How to use Software
Requirements? When to complete?
>> Solution: Establish fixed
dates
• Democracy and
Dictatorship:>> Encouraging requirements
from all can result in an
expectation of mob rule
http://www.nainil.com/research/
Software Development Pitfalls:
Planning
http://www.nainil.com/research/
Solving Your Problems & Planning
• Planning and Solving your
Problem:
>> By planning every effort a little better, you can achieve a
number of incremental
improvements that adds up to major progress
• Planning is not your only
Problem:
>> While planning is involved
in virtually everything, it will not solve all your problems.
http://www.nainil.com/research/
Requirements & Planning
• Planning and
Requirements:
>> Planning is not requirements gathering
• Planning and Planning: >> Plans can be very detailed or
very broad-brush
http://www.nainil.com/research/
Uncertainty & Outside Help
• Planning and Uncertainty: >> Planning addresses the future
>> When faced with uncertainty mark: minimum,
maximum and midpoint
• Planning and Outside
Help:
>> There is a lot of outside
expertise from outside available while planning for
the software industry
http://www.nainil.com/research/
Planning & Development
• Planning and Design: >> Should you plan before design?
• Planning and
Development:
>> Planning: Defined Structure
>> Development: Methods and Steps to develop software
http://www.nainil.com/research/
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/
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.
top related