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 Solution Code
Test
Product Manager
Functions of the Team
http://www.nainil.com/research/
Characteristics
How
Specification
What
Requirement
Why
Use Scenario
When
Goal
What
Problem
Who
Persona
Verifiable
Unambiguous
Consistent
Complete
Feasible
Design Free
Concise
To the point
Necessary
Requirement
http://www.nainil.com/research/
Requirements
Education 8
Documentatoin 7
Localization 6
Customization Security 5
Implementation Interface 4
Installation Constraints 3
Certification Performance 2
Standardization Functional 1
Business 2 Business (B2B) IEEE
http://www.nainil.com/research/
Elements In:
Tracking Information
Attachments (sample) Tracking Information
Go-to-Market Strategy Effort Source
Functional Specs Confidence Level Type of Requirement
Market Requirements Difficulty Persona (who is
affected)
Business Case Description Description
Executive Summary Name Name
Business Case
Requirements
Functional
Specification
Requirement
Document
http://www.nainil.com/research/
Elements In:
Tracking Information (author)
Attachments (sample) Tracking Information (author)
Effort Source
Confidence Level Type of Requirement
Difficulty Persona (who is affected)
Description Description
Name Name
Functional Specification Requirement 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,
doesnt 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
Cant 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
Its 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
companys 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
Resources Schedule Scope
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 wont 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:
Thats Easy!
Its not as Easy as it
Sounds
Theres a much better
way to do it
That Depends
We Cant 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.