Agenda

3. Product Planning
3.1 Product Requirements Engineering
–  Role of Requirements Engineering in Software Product Management
–  Inquiry cycle with elicitation, analysis, and validation
3.2 Release Planning
–  Release Planning Process and its conflicts / Structure of Release Plan
3.3 Roadmapping
–  Product Roadmap and its elements
–  Sources of input / Usage of Roadmaps
3.4 Product Life Cycle Management
–  Phases of the Life Cycle
–  Performance Management
3.5 Impact From Development Methodologies

1 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
What is a requirement?
•  Wish for a future product feature

•  Robertson & Robertson: A requirement is a statement on an action that the

product is requested to do, or a quality that the product is requested to have.
•  IEEE 610.12-1990: A requirement is:
–  A condition or capability needed by a user to solve a problem or achieve an
objective.
–  A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification, or other
formally imposed documents.

•  Can also address needs and wishes outside of the software itself, e.g. sales
channels, support structure, terms and conditions etc.

2 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

All requirements?
•  Tax rates will have to be manually entered, since the product will not interface
with a tax provider program.
•  The system must be able to handle 1,000 concurrent web-users per second.
•  The release must be available before the new tax year.
•  Menlo requires the ability to store a bill-of-lading (shipper's reference number)
and a carrier pro number at the line item level for inbound (purchase) orders.
•  We want the enterprise license to include our subsidiary in Dubai

3 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Three types of requirements (software-related)

•  Functional requirements, which describe what the product should do.

•  Quality requirements, which describe a quality that a product should have.

•  Constraints, which are decisions taken in advance that restrict the scope of the
product, and how the product is developed.

Sommerville (2007), Pohl (2010), Robertson & Robertson (2006), and Wiegers (2003)

4 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

•  Definition:
A functional requirement is a statement of
–  a service the product should provide,
–  how the product should react to particular inputs,
–  and how the product should behave in particular situations.

•  Examples:
–  “Deletion of an order will automatically delete all the lines of the order”
–  “The image viewer must display enlarged images.”

5 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

•  Definition:
A quality requirement defines a quality property of the entire product or of a
product component, service, or function.

•  Examples:
–  “The system functions in a 7x24 mode and must have less than 1 hour
downtime per month.”
–  “The response time of the home page must not exceed five seconds.”

•  Quality requirements are sometimes referred to as non-functional requirements.

•  Can be specified qualitatively, by example, operationally, or quantitatively

6 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Quality requirements

Important primarily Important primarily

to users to developers
§  Availability §  Interoperability §  Scalability
§  Efficiency §  Reliability §  Maintainability
§  Flexibility §  Robustness §  Portability
§  Integrity §  Usability §  Reusability
§  Performance §  Testability

Wiegers (2003)

7 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Quality requirements (users)
•  Availability, concerning the percentage of time that a product is available for use and
fully operational.
•  Efficiency, referring to how efficient the product is in using resources as processor
time, memory, or communication band with.
•  Flexibility, which indicates how easily a product can be extended with new
functionalities.
•  Integrity, concerning protection against unauthorized access, data privacy,
information loss, and infections through maleficent software.
•  Interoperability, referring to how easily the product can exchange data or services
with other systems.

8 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Quality requirements (users)
•  Reliability, indicating how long a product can be used without failure.
•  Robustness, which is the degree to which the product or product component
continues to operate correctly when confronted with invalid inputs, defects in
connected systems, or unexpected operating conditions
•  Usability, which refers to the effort that is needed of the user to prepare input for,
operate, and interpret the output of the product.

9 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Quality requirements (developers)
•  Scalability, refers to the range of workload scenarios in which the software can
run with satisfying performance
•  Maintainability, which indicates the effort it takes to correct a defect or make a
change in the product.
•  Portability, indicating how easy it is to migrate a product or product component
from one operating environment to the other.
•  Reusability, referring to the extent to which a product component can be reused
in other products.
•  Testability, which indicates the effort it takes to test the product (components) to
find defects.

10 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Examples for quality requirements

•  Performance
“The system must be able to handle 1,000 concurrent web-users per second”
•  Integrity
“The parameter setting of the system can only be entered and modified by a
user with super-user rights”
•  Availability
“The system functions in a 7x24 mode"
•  Reliability
“The system must have less than 1 hour downtime per month"

11 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Handling quality requirements

•  Quality requirements should not be “hidden” in a functional requirement. They
are described:
–  Inside a functional requirement in case it is directly related
–  A separate requirement in case it is unrelated and requires significant
workload.
•  Functional requirements should not be “hidden” in a quality requirement.
•  Quality requirements must have a business case, and are not for the sake of the
Development team.

12 Jan 2020
 3. Product Planning
3.1 Product Requirements Engineering
Example of an NFR / underspecified functional requirement
•  “The system shall be secure.”
–  What does “secure” mean?
–  Which properties should it have to be “secure”?
–  How can one check whether the system is “secure”?
•  Breakdown of the NFR:
–  Each user must log in to the system with his user name and password prior to using the
system. (functional requirement)
–  The system shall remind the user every four weeks to change the password (functional
requirement)
–  When the user creates or changes the password, the system shall validate the new password is
at least eight characters long and contain alphanumeric characters. (functional requirement)
–  The user passwords stored in the system must be protected against password theft (quality
requirement – integrity)

13 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

•  Definition:
A constraint is an organizational or technological requirement that restricts the
way in which the system shall be developed.

•  Examples:
–  “The product shall only operate
on a smartphone.”
–  “The product shall be released before
the new tax year.”

14 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Restricting effects of constraints

R-1
Range of realisation
R-2 alternatives for requirement
R-8 without considering constraints

Range of possible realisation

R-7 R-3 alternatives with the
consideration of constraints

R-4 Restricting effect of constraints

R-6
R-5 on a requirement

15 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Stakeholders as sources of requirements
§  User groups
§  Customers
§  Partners
§  Consultants/Professional Services
§  Competitive Analysis
§  Market research
§  Research
§  Development
§  Sales
§  Marketing
§  Support
§  Executive Management

16 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

•  In software product management, it is necessary to distinguish customer

requirements and product requirements

Customer requirements Product requirements

•  Varying quality, vague •  Similar style suitable for internal
•  Varying size: too small, too large communication
•  Combine several wishes •  Oriented towards the standard
•  Non-standard, customer specific product
wishes
•  Often goal-oriented

17 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

•  A customer requirement is a customer wish related to current or future needs,

defined using the terminology and context of the customer.

Consignment stocks of new parts are

managed by DOC and consists of
parts with and without serial numbers.
Management of government owned
stock with associated documents.
Querying, access, inventor

18 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
•  A product requirement is a requirement to be covered by future product releases
described in the company’s own terminology and context.
•  It typically addresses the needs of a larger group of (potential) customers.

19 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
•  Product requirements are usually managed and maintained in appropriate tool
environments.
•  With waterfall approaches, a formal Market Requirements Document can be
used, e.g.

20 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
What about project requirements?

•  Only related to the software developed in the project

•  Often during requirements management project issues or project requirements

appear: issues that apply to the project that builds the product.
–  Project issues clearly do not define the product

•  Not the task of the product manager, but taken care of by the development
manager or project manager.

21 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Customer Requirements Product Requirements Project Requirements

CustReq 1 ProdReq 1 ProjReq 1 M11 ... M1n1

ProjReq 2 M21 … M2n2
ProdReq 2
CustReq 2 ProjReq 3 M31 … M3n3
ProdReq 3 ProjReq 4 M41 … M4n4
CustReq 3
ProdReq 4 ProjReq 5 M51 … M5n5

CustReq 4 ProdReq 5 ProjReq 6 M61 … M6n6

Responsible: Responsible: Responsible:

Sales or Technical Software Product Development
Support Management

Traceability
22 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

23 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Quality criteria for product requirements (1)
•  Complete: The product requirement is complete when it adheres to the rules and
guidelines and it does not omit any information that is relevant for any of the
stakeholders.
•  Traceable: The source, evolution and impact and use in later development
phases should be registered.
•  Correct: The relevant stakeholders should confirm its correctness and demand
that the product must realize the requirements completely. A requirement is
incorrect when it unnecessarily adds functionality or quality properties.
•  Unambiguous: The requirement should be written in such a way that it permits
only one valid interpretation.
Pohl (2010)

24 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Quality criteria for product requirements (2)

•  Comprehensible: The requirement is comprehensible if the content is
understood by all relevant stakeholders.
•  Consistent: The statements in the requirement should not contradict with each
other.
•  Verifiable: The stakeholders should be able to check whether the realized
product fulfils the documented requirements or not. Acceptance criteria can be
defined to facilitate verifiability.
•  Up-to-date: A requirements is up-to-date when it reflects the current status of the
product and product context, such as current legal regulations.

Pohl (2010)

25 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Epics and User Story Specification Template:

As a <type of user>
I want <some goal or objective >
So that <benefit, value>

26 Jan 2020
 3. Product Planning
3.1 Product Requirements Engineering
Ambiguous terms to avoid in product requirements
•  Acceptable, adequate (what constitutes acceptability?)
•  As much as practical (don’t leave this up to the developers)
•  Depends on (describe the nature of the dependency)
•  Efficient, fast (quantify)
•  Flexible (to what?)
•  Ideally (also describe non-ideal behaviour)
•  Optionally (define whether this is a system, user or developer choice)
•  Several (how much?)
•  Shouldn’t (try to state requirements as positives)
Wiegers (2003)

27 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
RE Constraints
Total 419 100%
Shared Understanding 214 51%
Specification Quality 197 47%
Clear Scope 160 38%
Efficiency 155 37%
User Satisfaction 145 35%
Timeliness 139 33%
Fit of Solution 94 22%
Estimation Reliability 65 16%
Architecture Quality 58 14%
Cost/Benefit Analysis 26 6%
Other 4 1%

Fricker (2012): Requirements Engineering State-of-Practice. Blekinge Institute of Technology.

28 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Workshops create an
efficient, controlled, and dynamic setting for quickly eliciting, prioritizing, and
agreeing on requirements.

Fricker (2012): Requirements Engineering State-of-Practice. Blekinge Institute of Technology.

E. Gottesdiener (2002): Requirements by Collaboration. Addison-Wesley.

29 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Recommendations

•  Customer requirements are usually taken from customers, prospects, analysts

on an as-is basis, often by Sales.

•  Product requirements are formulated by the product managers.

•  Communication is key

•  Very small requirements, e.g. ‘extension of field length’, are entered under one
generic PR per area

30 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Managing requirements is complex

•  Large volumes that have to be handled

•  Complex dependencies between the requirements
•  Involvement of a diversity of stakeholders
•  Decisions need to be based on extensive domain knowledge of the (industrial)
applications of the product.

31 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Typical Situation in a Market-Driven Environment
stakeholders
goals
needs >>5‘000 vague needs and ideas
ideas
constraints
funnel

release 500-5‘000 requirement candidates

planning

10-500 concrete requirements

development (to be implemented in software)
project
Gorschek, Wohlin: „Requirements Abstraction Model“, Requirements Engineering, 2006.
Regnell, Svensson, Wnuk: „Can We Beat the Complexity of Very Large-Scale Requirements Engineering?“, RefsQ‘08.

32 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Process and Tools

•  Requirements management process needed

–  Well defined, documented and communicated to all stakeholders
–  SPM as process owner

•  Tools are available and helpful

–  Requirements management tool
–  Requirements database

33 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Product requirement‘s attributes
Attribute Value Assigned in State
State N / A / Sp / Se / D / T / Rel / Rej -
Name Short unique name New
ID Unique identifier New
Source Who issued it? New
Description Short textual description New
Func Component Affected (sub-)modules N / A / Sp
Priority Importance category (1, 2, 3) Specified
Motivation Rationale: Why is it important Specified
Specification Links to Use case, Conc. Solution Specified
Links Links to other reqs; parent-child rel. Specified
Estimation Effort estimation in hours, benefit estimation Specified
Schedule Selected for this release Selected
Design Links to design documents Implemented
Test Links to test documents Tested
Release Ver Released in this version Released

34 Jan 2020
 3. Product Planning
3.1 Product Requirements Engineering
Process in ISPMA terms Available for customers Released

All software components developed Tested

Tested

Planned in release Implemented Testing successful

Validation
Selection Selected
Release planning (release mode)

Requirements management (continuous mode)

Specified
Analysis
Into backlog if not selected
In product scope Approved
Specified; concept validated; business case

New Rejected Permanently out of scope

Elicitation Triage Requirements Inquiry Cycle

Entered in RDB Jan 2020
35
3. Product Planning
3.1 Product Requirements Engineering
Requirements Inquiry Cycle: Elicitation
•  Interviews
–  Structured and unstructured interviews
•  Workshops
–  Creativity techniques: brainstorming, 6 thinking hats, ladders
–  Analysis techniques: card sorting, repertory grids, mind-mapping
–  Design techniques: prototyping (e.g. Joint Application Design, JAD)
–  Feedback techniques: reviews, focus groups
•  Observation
–  Protocol analysis
–  Apprenticing
–  Ethnography
Pohl (2007): Requirements Engineering. d.punkt Verlag. AND
Zowghi, Coulin (2005):”Requirements Elicitation: A Survey of Techniques, Approaches, and Tools”. In Aurum, Wohlin:
Engineering and Managing Software Requirements. Springer.

36 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Requirements Inquiry Cycle: Elicitation
•  Surveys
–  Questionnaires, self-recording
•  Introspection
•  Artefacts
–  Perspective-oriented reading
–  System archeology

Pohl (2007): Requirements Engineering. d.punkt Verlag. AND

Zowghi, Coulin (2005):”Requirements Elicitation: A Survey of Techniques, Approaches, and Tools”. In Aurum, Wohlin:
Engineering and Managing Software Requirements. Springer.

37 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Requirements Inquiry Cycle: Triage

•  Before applying prioritization techniques: perform triage
–  Origins in medicine

•  Some requirements must be included

•  Some requirements should definitely be excluded
•  That leaves a pool of nice-to-haves, which need in-depth
analysis.

38 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Requirements Inquiry Cycle: Analysis
•  Gather and prepare all information that is needed for decision making
–  What is it?
•  Develop a deep understanding of requirement and relevant scenarios
•  Describe it in short text

–  How can it be implemented?

•  Concept
•  High-level specification (e.g. text, use case, model, prototype)

•  With agile development methodologies: a larger part of analysis is done as part

of development

39 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering
Requirement analysis: business case
•  Business value / benefit
–  Absolute values (“How much extra money will we earn when we implement
this requirement?”)
–  Relative values (“Requirement A will generate two times as much revenue
as requirement B.”)

•  Penalty if not developed / harm avoidance

–  Absolute values (“How much money will we lose due to decreasing sales if
we do not make a web version of our product?”)
–  Relative values (“The harm done will be higher if we leave out the
requirements submitted by customer C than customer D.”)

40 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Requirement analysis: business case

•  Cost of development
–  In € or $
–  In person days
–  Relative (“Requirements 1 costs twice as much as requirement 2”)

•  Development risk
–  Requirement volatility / stability (“Is the requirements likely to change?”)
–  Development difficulty (“This requirement concerns a new technology,
which our developers have never used before.”)

41 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Requirements Inquiry Cycle: Selection

•  Decision process for the contents of a particular release

•  Decision based on
–  Evaluation
–  Release themes
–  Prioritization
•  Part of Release Planning process

42 Jan 2020
3. Product Planning
3.1 Product Requirements Engineering

Requirements Inquiry Cycle: Validation

•  Ensure that the specified solution is adequate and gets stakeholder acceptance
•  Methods:
–  Reviews
–  Inspections
–  Simulations
–  Prototyping

43 Jan 2020
Agenda

3. Product Planning
3.1 Product Requirements Engineering
–  Role of Requirements Engineering in Software Product Management
–  Inquiry cycle with elicitation, analysis, and validation
3.2 Release Planning
–  Release Planning Process and its conflicts / Structure of Release Plan
3.3 Roadmapping
–  Product Roadmap and its elements
–  Sources of input / Usage of Roadmaps
3.4 Product Life Cycle Management
–  Phases of the Life Cycle
–  Performance Management
3.5 Impact From Development Methodologies

44 Jan 2020
3. Product Planning
3.2 Release Planning: Types of Versioning

Life Cycle Phase

Software Product Scenarios
New Product Existing Product
Revolution Evolution
Environment

Vendor-Controlled Powerboat Speedboat

Runtime

Customer-Controlled Icebreaker Cruiseship

H.-B. Kittlaus (2015): One Size Does Not Fit All: Software Product Management For Speedboats vs. Cruiseships, in:
Fernandes, J.M., Machado, R.J., Wnuk, K. (Eds.): Software Business, Proceedings of ICSOB 2015, Braga, Portugal, Springer

45 Jan 2020
3. Product Planning
3.2 Release Planning: Types of Versioning
Powerboat + Speedboat
§  High release frequency, smaller releases
§  Special methods and techniques, e.g.:
§  DevOps
§  Product Discovery

Icebreaker + Cruise Ship

§  Medium to low release frequency, bigger releases
§  More elaborate planning

46 Jan 2020
 3. Product Planning
3.2 Release Planning
Evolution of software (intensive) products iPhone 8 (Plus)
Original iPhone iPhone 4 + 4S
iPhone 6S (Plus)

iPhone 11 (Plus)

iPhone 3G iPhone 5S + 5C iPhone 7 (Plus) iPhone X

source: apple
47 Jan 2020
 3. Product Planning
3.2 Release Planning

Evolution of software (intensive) products

Version Version Version Version

Original 3G … X 11 (Plus)

Development Project Development Project

Development Project Development Project
Development Project

48 Jan 2020
3. Product Planning
3.2 Release Planning
Evolution of software (intensive) products

•  A software product exists in different versions during its lifecycle.

•  Conventions:
– „X.0“ = significant changes,
„X.Y“ = improvements
– Alternative: publication year (e.g. Windows 2007)

As few parallel
versions as possible

49 Jan 2020
3. Product Planning
3.2 Release Planning
§  Defining the contents of a release by
§  Selecting the optimal set of requirements to be implemented
§  Documenting the release contents
§  Validating the results of Development

§  Overall objective:
Creation of additional value to customers that can be transformed into
economic success over the product‘s lifecycle

50 Jan 2020
3. Product Planning
3.2 Release Planning
§  Complex iterative process to find a balance between conflicting objectives:
§  Technology push vs. market pull, i.e. innovation vs. customer requirements
§  Thematic theme(s)
§  Prioritized requirements (ideally based on req. business cases)
§  Target cost
§  Release business case (ROI)
§  Complex dependencies (thematic, technical, temporal)
§  Competitive situation
§  Customer commitments
§  Marketing events (fairs etc.)

§  Tightly linked to Requirements Engineering

51 Jan 2020
 3. Product Planning
3.2 Release Planning: Release Types

Release type Contents Issues

Major Significant changes, e.g. new platform, new Often as a new version (within temporal
technology, new user interface etc. versioning) for marketing reasons or price impact

Minor Functional changes of medium magnitude

Update Small functional changes + error correction Consumer market: Often replaced by automatic
online updates;
Enterprise market: Will typically only be installed
by customers who have one of the fixed problems

Service (Patch) Only error correction Consumer market: Often replaced by automatic
online updates;
Enterprise market: Will typically only be installed
by customers who have one of the fixed problems

52 Jan 2020
3. Product Planning
3.2 Release Planning

Heartbeat principle

•  Implement a corporate release heartbeat

•  Advantages are:
–  Clarity for defining a release agenda
–  Professional internal atmosphere
–  Professional image
–  Healthy pressure
–  Managed customer expectations

53 Jan 2020
3. Product Planning
3.2 Release Planning
Fundamental decision: Version/Release Compatibility
•  Upward compatibility
–  Existing functions of version n continue to be supported in version n+1
–  Data from version n can be transferred and used in version n+1 without
changes
–  Interfaces of version n remain unchanged

•  Downward compatibility
–  Data from version n+1 can be transferred to version n without changes
–  Version n+1 can communicate to version n (version n interfaces are
supported)
•  Preferably a standard on corporate level
Kittlaus, Fricker (2017): Software Product Management: The ISPMA-Compliant Study Guide and Handbook.

54 Jan 2020
 3. Product Planning
3.1 Product Requirements Engineering
Process in ISPMA terms Available for customers Released

All software components developed Tested

Tested

Planned in release Implemented Testing successful

Validation
Selection Selected
Release planning (release mode)

Requirements management (continuous mode)

Specified
Analysis
Into backlog if not selected
In product scope Approved
Specified; concept validated; business case

New Rejected Permanently out of scope

Elicitation Triage Requirements Inquiry Cycle

Entered in RDB Jan 2020
55
3. Product Planning
3.2 Release Planning: Selection Criteria
Importance (contribution in % for release decision)
Business: Stakeholder Priority
Management: Delivery Date, Calendar Time
Business: Beneficiaries
Management: Development Cost/Benefit
Management: Resources and Competencies
Business: Competitors
System: Complexity
System: Requirements Dependencies Depends on product type,
System: System Impact development process, and
System: Evolution project phase.
Business: Requirements Volatility
System: Maintenance
Management: Support for Education and Training

- 2.0 4.0 6.0 8.0 10.0 12.0 14.0 16.0 18.0

Wohlin, Aurum: „What is Important when Deciding to Include a Software Requirement in a Project Release?“,
4th Intl Symp on Empirical Software Engineering. 2005.

56 Jan 2020
3. Product Planning
3.2 Release Planning: Selection
•  Goal: to select those requirements, which maximize satisfaction of company objectives
related to the software release
–  Fitness with product roadmap
–  Maximized value/cost ratio
–  Stakeholder satisfaction
–  Feasibility with respect to time and resources

•  Need to select what to implement

–  Stakeholders (usually) ask for way too much
–  Balance time-to-market with amount of functionality
–  Decide which features go into the next release

•  And what if stakeholders disagree?

–  Visualize differences in priority
–  Resolve disagreements
57 Jan 2020
3. Product Planning
3.2 Release Planning: Prioritization Techniques
•  Manual techniques
–  Cost value approach
Simplicity
–  Top-Ten
–  Numerical assignment (grouping)
–  Ranking (sorting)
–  Cummulative voting (100$ Test)
•  Consensus-seeking techniques
–  Planning Poker
•  Analytical techniques
–  Wiegers Prioritization Matrix
•  Tool-based techniques
Precision,
–  Integer Linear Programming Robustness
(ILP with Expert Decisions Release Planner)
–  Analytical Hierarchy Process
(AHP with IBM FocalPoint)
Berander, Andrews: „Requirements Prioritization“. In Arum, Wohlin: Engineering and Managing Software Requirements. Springer. 2005.

58 Jan 2020
3. Product Planning
3.2 Release Planning: Prioritization Techniques

Cost Value Approach

59 Jan 2020
 3. Product Planning
3.2 Release Planning: Prioritization Techniques
Cumulative Voting (or: 100$ Test)
•  Each stakeholder distributes a total of 100 points (or $ or € or coins) on the
requirements.
•  The product manager sums up the points and presents the derived ordering of
the requirements.

•  Facebook example:
Stakeholder 1 Stakeholder 2 Stakeholder 3 Total
Layout customization 10 20 5 35
Dislike button 30 20 25 75
Photo app integration 25 20 20 65
Profile visit stats 25 30 35 90
Email integration 10 10 15 35

60 Jan 2020
3. Product Planning
3.2 Release Planning: Prioritization Techniques
Numerical Assignment (or: Priority Groups)

•  Each stakeholder groups requirements into different priority groups (e.g. critical,
important, useful).
•  The product manager sums up the weights (e.g. critical = 9, important = 3, useful
= 1).

•  Facebook example:
Stakeholder 1 Stakeholder 2 Stakeholder 3 Total
Layout customization useful important useful 5
Dislike button critical important important 15
Photo app integration important important important 9
Profile visit stats important important critical 15
Email integration useful useful useful 3

61 Jan 2020
3. Product Planning
3.2 Release Planning: Prioritization Techniques
Ranking (or: Sorting)

•  Each stakeholder sorts requirements in decreasing order.

•  Product manager sorts requirements by considering the average or median
priority of each requirement.

Stakeholder 1 Stakeholder 2 Stakeholder 3 Rank Requirement Average

Req. 2 Req. 4 Req. 4 4 Email integration 3,67
Req. 3 Req. 1 Req. 2 2 Dislike button 2
Req. 4 Req. 2 Req. 3 3 Photo app integration 3
Req. 1 Req. 3 Req. 5 1 Profile visit stats 1,67
Req. 5 Req. 5 Req. 1 5 Layout customization 4,67

62 Jan 2020
3. Product Planning
3.2 Release Planning: Prioritization Techniques
Top-10 Requirements

•  Each stakeholder selects 10 favorite requirements.

•  Product manager sorts requirements by considering fairness and satisfaction of
stakeholders.

63 Jan 2020
3. Product Planning
3.2 Release Planning: Prioritization Techniques

Planning Poker: Team Consensus for relative effort and value

64 Jan 2020
3. Product Planning: 3.2 Release Planning
Release Plan

•  Formal document (sometimes called release definition)

•  At least a documented list of evaluated requirements that are to be implemented in

the release

•  Better a comprehensive release specification with references to individual

requirements (as described on the following charts)

•  Sign-off by all stakeholders required

•  Level of detail dependent on development approach (waterfall, iterative, agile …)

65 Jan 2020
3. Product Planning: 3.2 Release Planning
Release Plan
•  Include short descriptions and references to requirements
–  Not entire requirement specifications / conceptual solutions

•  Include strategic content

–  Use release themes
–  Indicate release fit to overall product roadmap
–  Identify strategic direction

•  Use consistent and sufficient detail

•  Document sources of requirements

–  Content specifics
–  Source information: who and when

66 Jan 2020
3. Product Planning: 3.2 Release Planning
Release Plan
•  To be written by Product Manager
–  Co-authors: Architect & Marketing

•  Scope
–  Whole product release
–  Only for major and minor releases; not for bug fixes

•  Content
–  Listing of product requirements to be incorporated in the next release
–  Dependencies between product requirements
–  Distributed ownership of work
–  Does not describe solutions, but refers to existing or planned Conceptual
Solutions
67 Jan 2020
3. Product Planning: 3.2 Release Planning
Release Plan Validation

•  Roadmap fit
•  Investments in resources
•  Various ways:
–  Presentation for the company board (and other internal stakeholders)
–  Release business case
–  Return On Investment (ROI) Estimation

68 Jan 2020
3. Product Planning: 3.2 Release Planning
Release Change Management

•  What to do in case of
–  extra requirements forced by the company board
–  a delay due to an absent engineer
–  an opportunity from a customer or prospect
during the development phase?

•  Implementation of a scope change process (PRINCE2, ASL, SCRUM, etc.)

69 Jan 2020
3. Product Planning: 3.2 Release Planning
Release Validation

•  Ensure that the specified release is adequate, gets stakeholder acceptance, and
meets its objectives
•  Internal validation:
–  Testing
–  Simulations
•  External validation
–  Beta testing
–  Pilot
•  Certification (in special cases)

70 Jan 2020
 3. Product Planning
3.2 Release Planning
Process in ISPMA terms Available for customers Released

All software components developed Tested

Tested

Planned in release Implemented Testing successful

Validation
Selection Selected
Release planning (release mode)

Requirements management (continuous mode)

Specified
Analysis
Into backlog if not selected
In product scope Approved
Specified; concept validated; business case

New Rejected Permanently out of scope

Elicitation Triage Requirements Inquiry Cycle

Entered in RDB Jan 2020
71
Agenda

3. Product Planning
3.1 Product Requirements Engineering
–  Role of Requirements Engineering in Software Product Management
–  Inquiry cycle with elicitation, analysis, and validation
3.2 Release Planning
–  Release Planning Process and its conflicts / Structure of Release Plan
3.3 Roadmapping
–  Product Roadmap and its elements
–  Sources of input / Usage of Roadmaps
3.4 Product Life Cycle Management
–  Phases of the Life Cycle
–  Performance Management
3.5 Impact From Development Methodologies

72 Jan 2020
3. Product Planning: 3.3 Roadmapping
Roadmap
§  Translates product strategy into series of releases
on a time axis

§  How is the product going to develop over the

strategic timeframe of up to 5 years?

§  What is a smart sequence of developing,

releasing, and evolving the solution?

Kittlaus, Fricker (2017): Software Product Management: The ISPMA-Compliant Study Guide and Handbook.

73 Jan 2020
3. Product Planning: 3.3 Roadmapping
Roadmap
§  Contents:
§  Timescale
§  Market and technology trends
§  New releases or versions and their (tentative) schedule
§  Release themes and technologies
§  Feature level as lowest level of detail
§  Target markets
§  Dependencies on other platforms, products, or technologies
§  Short term (e.g. 1-2 years): detailed and rather reliable.
§  Long-term (e.g. 5 years): less precise and subject to change
§  Assumptions
§  Legal disclaimer (for external audience)
Kittlaus, Fricker (2017): Software Product Management: The ISPMA-Compliant Study Guide and Handbook.

74 Jan 2020
3. Product Planning: 3.3 Roadmapping
Roadmap Purpose
§  Give direction
§  Communication to internal audience
§  Strategic alignment (iterative process for reaching long-term agreement on
product direction and priorities)
§  Forecasting and Budgeting
§  Motivate developers, sales, or support to work on the product
§  Communication to external audience (show subset)
§  Demonstration of product viability
§  Customers (Influence investment decisions)
§  Partners
§  Market research companies
§  Share holders / Venture capital funds (get funding)
Kittlaus, Fricker (2017): Software Product Management: The ISPMA-Compliant Study Guide and Handbook.

75 Jan 2020
3. Product Planning
3.3 Roadmapping

No universal
standard: chose and
Phaal, Farrukh, Probert (2004): „Technology Roadmapping – A Planning Framework for Evolution and Revolution“, adapt to situation.
Technological Forecasting and Social Change.

76 Jan 2020
3. Product Planning
3.3 Roadmapping: Basic Structure

Phaal, Muller (2009): An architectural framework for roadmapping: Towards visual strategy. Technological Forecasting & Social Change 76:39-49.

77 Jan 2020
3. Product Planning
3.3 Roadmapping: Examples
Product Service /
Planning Capability
Planning

Strategic Long-Range
Planning Planning

Knowledge
Asset Program
Planning Planning

Phaal et al (2003): „Technology Roadmapping – Planning Framework for Evolution and Revolution“. TFSC.

78 Jan 2020
3. Product Planning
3.3 Roadmapping: Examples

Layers Bars

Tables Graphs

Pictorial Flow
Chart

Phaal et al (2003): „Technology Roadmapping – Planning Framework for Evolution and Revolution“. TFSC.

79 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Example Confluence

80 Jan 2020
 3. Product Planning: 3.3 Roadmapping:
Example
1.2
PR1

1.3 1.4 1.5 2.0 2.1

PR2

1.0 1.1 2.0 2.1

PR3

PR4

PR5

Beta
PR6
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1
2020 2021 2022 2023
Commit Planned Tentative (External) commitment

81 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Example (external)

82 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Example Oracle Siebel (external)

83 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Quality Criteria
•  Simplicity
–  Minimal representation of final outputs from strategy and planning.
–  Dialogue- and collaboration facilitating.
–  Documentation may be supplied to enhance a roadmap.
•  Adaptation to purpose, situation, and culture (→ large variability)
–  Layers reasonably independent and consistent over time.
–  Effective for communication: influence decision-making.
•  Correctness
–  Well-founded: based on company‘s best knowledge and expertise
–  Credible: representation of stakeholder interests and intentions
•  Evolving
–  Iterative, exploratory development and adjustment.
Phaal et al (2003): „Technology Roadmapping – Planning Framework for Evolution and Revolution“. TFSC.
Phaal, Farrukh, et al (2003): „Customizing the Technology Roadmapping Approach“, Mgmt of Eng. and Techn.

84 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Meta Process

•  Form a roadmap team with key stakeholders (cross-functional, influencers), and

assign the SPM as clearly designated owner of the product roadmap

•  Create a ‘roadmap knowledge base’

–  Roadmap templates

•  Review and update product roadmaps regularly

•  Compare your resources and key capabilities with your roadmap periodically

85 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Process for Creation / Update

1.  Which parties/persons should be involved?

è Update the roadmap team
2.  Ensure up-to-date input
§  Corporate strategy and portfolio management decisions
§  Product strategy
§  Budgets and resources
§  Data from market and product analysis
§  Current development status compared to plan
§  Customer commitments

86 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Process for Creation / Update

When you do it for the first time:

3.  Choose a granularity level
§  Themes, components, product requirements, features
4.  Choose which views you want to include in your roadmap
5.  Choose a time scale

Everytime:
6.  Go into iterative process to align roadmap with corporate strategy, product
strategy, release plans, product RE

87 Jan 2020
3. Product Planning: 3.3 Roadmapping:
External Communication

1.  Manage expectations 3.  Avoid the delay of sales to future

–  ‘Plan of intent’ products
–  Limit time horizon –  Present during a vision presentation
–  No specific dates or details –  Offer “bridge” programs

2.  Beware of the risk of information leaks 4.  Prepare for the “so what?” response
–  Assume competitors will see it –  Know your market and customers
–  Use an NDA –  Use as a collaboration tool, not as a
–  Don’t leave it behind plan

88 Jan 2020
3. Product Planning: 3.3 Roadmapping:
Legal Aspects for External Audience
•  Legal disclaimer for protection: Content is confidential, plans may change
•  Non-disclosure agreement (NDA)
è Marketing value

89 Jan 2020
Agenda

3. Product Planning
3.1 Product Requirements Engineering
–  Role of Requirements Engineering in Software Product Management
–  Inquiry cycle with elicitation, analysis, and validation
3.2 Release Planning
–  Release Planning Process and its conflicts / Structure of Release Plan
3.3 Roadmapping
–  Product Roadmap and its elements
–  Sources of input / Usage of Roadmaps
3.4 Product Life Cycle Management
–  Phases of the Life Cycle
–  Performance Management
3.5 Impact From Development Methodologies

90 Jan 2020
3. Product Planning
3.4 Product Life Cycle Management
§  Holistic approach from cradle to grave
§  PLM approach (manufacturing industry) not really transferable to software

CONCEPTION AND CREATION

WITHDRAWAL
91 Jan 2020
 3. Product Planning
3.4 Product Life Cycle Management
Software product across life cycle (all versions)

Phase Focus Areas Leading Stakeholders

Conception and creation Innovation, positioning, investment Research, Development, Marketing, regulatory
bodies

Market introduction Launch, market share, investment Marketing, Sales

Growth Market share, functionality, investment Research, Development, Marketing, Sales

Maturity Cash cow, revitalization, services Sales, Services, Support

Decline Customer retention, cash cow Marketing, Sales, Support

Withdrawal Customer retention, cost reduction Marketing

92 Jan 2020
3. Product Planning
3.4 Product Life Cycle Management

93 Jan 2020
3. Product Planning
3.4 Product Life Cycle Management
Extend capabilities and
functionality to meet user needs
Software
Product: Make minor defect
one version repairs and simple
functional changes

Stop servicing, but

generate revenue as
long as possible

Withdraw system from

market and direct users
to replacements
Rajlich, Bennett (2000): A Staged Model for the Software Lifecycle. IEEE Computer.

94 Jan 2020
 3. Product Planning
3.4 Product Life Cycle Management

Software
Product:
multiple
versions

Rajlich, Bennett (2000): A Staged Model for the Software Lifecycle. IEEE Computer.

95 Jan 2020
3. Product Planning
3.4 Product Life Cycle Management

Withdrawal from Service

•  No more maintenance
•  Customers are expected to migrate
•  Vendor can try to generate revenue from
–  customer-specific support
–  license fees (depends on terms and conditions)

96 Jan 2020
3. Product Planning
3.4 Product Life Cycle Management

Closedown

•  Vendor shuts down the software

•  Vendor directs users to a replacement system
•  Residual responsibilities
–  Source code retention
–  Legal liability
•  Migrate data to a new system

Rajlich, Bennett (2000): A Staged Model for the Software Lifecycle. IEEE Computer.

97 Jan 2020
3. Product Planning
3.4 Product Life Cycle Management

Knowledge Management

•  Ensure that the knowledge required for the viability of the product continues to be
accessible and available for the company during the product life cycle
•  Special problem for legacy products
–  incentives can help

98 Jan 2020
3. Product Planning
3.4 Product Life Cycle Management

Performance Management

•  Continuous measurement required to drive timely corrective actions

–  Product profitability
–  Actual vs. planned revenue
•  New vs. existing customers
•  Product sales vs. maintenance
–  Customer satisfaction
–  Market share

99 Jan 2020
 3. Product Planning
3.4 Product Life Cycle Management
Software product across life cycle (all versions)

Phase Focus Areas Leading Stakeholders

Conception and creation Innovation, positioning, investment Research, Development, Marketing, regulatory
bodies

Market introduction Launch, market share, investment Marketing, Sales

Growth Market share, functionality, investment Research, Development, Marketing, Sales

Maturity Cash cow, revitalization, services Sales, Services, Support

Decline Customer retention, cash cow Marketing, Sales, Support

Withdrawal Customer retention, cost reduction Marketing

100 Jan 2020