requirement writing for product management

http://www.nainil.com/research/

Requirements Writing

By Nainil Chheda


Intentionally Blank


Prioritizing Software

Requirements with Kano Analysis


Requirements

Essential Customer

Requirements

Incremental

Requirements


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


Writing the Market Requirements

Document


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


Characteristics

HowSpecification

WhatRequirement

WhyUse Scenario

WhenGoal

WhatProblem

WhoPersona

Verifiable

Unambiguous

Consistent

Complete

Feasible

Design Free

Concise –

To the point

Necessary

Requirement


Requirements

Education8

Documentatoin7

Localization6

CustomizationSecurity5

ImplementationInterface4

InstallationConstraints3

CertificationPerformance2

StandardizationFunctional1

Business 2 Business (B2B)IEEE


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


Elements In:

Tracking Information (author)

Attachments (sample)Tracking Information (author)

EffortSource

Confidence LevelType of Requirement

DifficultyPersona (who is affected)

DescriptionDescription

NameName

Functional SpecificationRequirement Document


Agile Market Requirements


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


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”


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


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.


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)


Feature Police: Following Through

on Requirements


Forgotten

Not so Important

after some time

Standard

v/s

Custom Product

Latest request

is the

Greatest

Requirements


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


Working the Plan Using a Plan

That Works


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”


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


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


Managing Product Requirements:

Where did all my Customer Insights

Go?


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


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”


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


Requirements: Like Lambs to the

Slaughter


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”


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”


Software Development Pitfalls:

Requirements


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


Planning & Requirements

• Requirements and

Planning:

>> Requirements: What

>> Planning: Development sits

down and decides how to divide up and order the tasks


Requirements:

>> Different types of

requirements

>> Split: Technical and Market

requirements


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


Uncertainty, Democracy & Dictatorship


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


Software Development Pitfalls:

Planning


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.


Requirements & Planning

• Planning and

Requirements:

>> Planning is not requirements gathering

• Planning and Planning: >> Plans can be very detailed or

very broad-brush


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


Planning & Development

• Planning and Design: >> Should you plan before design?

• Planning and

Development:

>> Planning: Defined Structure

>> Development: Methods and Steps to develop software


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


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([email protected]). 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.