spm 4 requirements gathering and organization

Software Product Management Requirements gathering and organization

Lecture 4

Sjaak Brinkkemper

Garm Lucassen

10 September 2014

SPM Competence Model

Agenda

• Requirements sources

• Requirements gathering

• Requirements organization

Gathering from external sources

• Customer: Extension of product features – Specialization: new attributes, process variants

– Completion: covering the whole workflow

– Interoperability: interfacing with other products

• Market: Product positioning – Standard functionality coverage

– Market distinction: unique selling points

• Partners: Product implementation – Voice of customers

– Partner revenue generating features

– E.g. Microsoft Dynamics implementation service partners provide reqs to MS

Gathering from internal sources (1)

• Company board – Long term product vision

– Major product themes

– Influence from portfolio and lifecycle decisions

• Sales – Input from Request for Information (RfI) and Request for Proposals

(RfP)

– Short term vision

• Marketing – Sense of the market; market trends,

– Competitors, market analysis

Gathering from internal sources (2)

• Research & innovation – Functional feature innovation

– Technical platform innovation; prototypes with new devices

• Development – Refactoring of architectural problems

– Process optimization

• Services – Features that facilitate implementation: migration tools, business

modeling tools

– Voice of customer: process alternatives, simplification, UI changes

• Support – Frequently occurring problems

Communication channels

• Stakeholder input channel: Specific process for each channel

• Agenda time allocation per input channel

• Always give a response to every input of a market requirement

• Educate internal stakeholders about process obligations (sales and marketing, board, etc.)

• Do NOT allow bypassing of product management

• Careful with explicit communication of release inclusion, best in case of development completion

Agenda



– Inquiry cycle

– Gathering techniques


Requirements inquiry cycle (1)

• An informal pattern for improving a set of requirements (or any other document, actually)

• Three phases:

1. requirements documentation

2. requirements discussion

3. requirements evolution

Requirements inquiry cycle (2)

Colin Potts, Kenji Takahashi, and Annie I. Antón. Inquiry–Based Requirements Analysis. IEEE Software, 11(2):21–32, Mar. 1994.

Requirements gathering techniques

1. Brainstorming

2. Questionnaires

3. User groups

4. Lead user interviews

5. Workshops

6. Prototyping

7. Beta customers

8. Work in user setting

1. Brainstorming

• Gathering of stakeholders and the exchange of ideas in an open atmosphere where no one risks being ridiculed for their ideas and no ideas are rejected/criticized.

Involved stakeholders Advantages Disadvantages

Relevant internal and

external stakeholders

Product manager(s)

Many ideas

Simple organization

Low commitment

Too many ideas

Difficult to create a

good atmosphere

where everyone is

involved

Difficult to get good

representation of

customer base

2. Questionnaires

• Research instrument to get quantitative data from respondents


End users Lot of information

Low costs

Difficult to create

good questionnaires

3. User groups

• Groups of customers who commonly use your products and services. They provide input on product improvements, and offer feedback on their needs and desires


Members of user

groups

Product manager(s)

High-quality

outcome, focused on

actual business

problems

Improved customer

relationships

Risk of dominating

users

Risk of ‘complain

sessions’

Too much focus on

low-level

requirements

4. Lead user interviews

• Interviews with representatives of certain groups of stakeholders or key accounts

• Lead Users are users of a product that currently experience needs still unknown to the public and who also benefit greatly if they obtain a solution to these needs (von Hippel, 1986)


Lead users

Product manager(s)

High-quality outcome Time-consuming

Difficult to find

representative lead

users

5. Workshops

• Also called: Joint requirements development sessions

• Requirements are jointly identified and defined by stakeholders. Cross-functional implications that are unknown to individual stakeholders are uncovered.


Relevant internal and

external stakeholders

Product manager(s)

Uncovering cross-

functional issues

High-quality outcome

Customer buy-in

Time-consuming

Danger of ‘opinion-

leadership’

Who commits to

requirements?

6. Prototyping

• Users can experiment with the system and point out its strengths and weaknesses of the implemented requirements.


End users

Developers/designers

Product manager(s)

Visualization

stimulates new ideas

Usability issues are

also included

Interaction between

designer and end-

user lead to high-

quality outcome

Time-consuming

High costs

Not all functionalities

are covered

“Is it already done?”

7. Beta customers

• Users who test the beta-version of a working product in a real production environment


Customers

Developer(s)

Account manager(s)

Product manager(s)

Clear requirements

Mutual trust and

commitment

Can also be used for

testing customer-

specific functionality

Time-consuming

Difficult to get good

representation of

customer base

8. Work in user setting

• Product manager works as an end-user to experience the current functionality


Product manager Good insight in

operational product

Improves customer

relationship

Time-consuming

Just perspective of

specific customer

Selection of techniques

Experience Product team

Experi

ence C

usto

mer

/ U

ser

low high

low

hig

h

Fuzzy problem

Teaching

Catch-up Mature

Fuzzy problem: • Brainstorming • Workshops

Teaching: • Prototypes • Beta-customers

Catch-up: • Lead user interviews • User groups • Work in user setting

Mature: • Questionnaires • Workshops • Prototypes

Agenda




– Organization techniques

– Requirements dependencies

– Linking requirements and architecture: Functional architecture framework

Requirements organization

• Requirements can be organized in many different ways, e.g.

– Per product

– Per component

– Per functional area

– Per theme

– ....

Thematic grouping (1)

• A theme groups requirements that should be implemented together.

• A release theme typically:

– Is interesting enough to be mentioned in press releases and used in advertising campaigns

– Appears in sales leaflets and product brochures

– Is negotiated as part of product roadmaps

– Is small and broad enough for evaluating alternative implementation strategies

Thematic grouping (2)

Example (Car Garage IS):

The release theme Order process management involves the use cases

– Create order

– Implement order

– Close order

– Record car

– Edit car properties

– Generate task lists

Use abstraction levels if neccessary

• The highest abstraction level is closest to company strategy

• The lowest abstraction level is closest to software design

• Requirements on the same abstraction level are comparable to each other

• Traceability across abstraction levels allows understanding of how software design contributes to implementing company strategy

• The number, naming, and meaning of abstraction levels is company‐ or product‐specific

Gorschek,T., Wohlin, C. (2006). Requirements Abstraction Model. Requirements Engineering, 11(1), 79-101.

Example 1 (2 levels)

Means-end relationship

If the means (requirements) are sufficiently achieved, the ends (goals) are considered achieved as well.

Means and ends should not be compared to each other when prioritizing.

Example 2 (4 levels)

Themes and abstraction levels Theme: lending process automation

Theme: data storage

Theme: theft protection

Requirements dependency types

Most common types:

• Combination (AND). A printer requires a driver to function, and the driver requires a printer to function.

• Implication (REQUIRES). Sending an e-mail requires a network connection, but not the opposite.

• Revenue-based (CVALUE). “Affects customer value of” A detailed on-line manual may decrease the customer value of a printed manual.

• Cost-based (ICOST). “Affects implementation costs” A requirement stating that "no response time should be longer than 1 second” will typically increase the cost of implementing many other requirements.

Carlshamre et al. (2002)

Requirements dependency types (2)

Other dependency types:

• Exclusion (OR). In a word processor, drawings can be either provided as integrated drawing model or a link of external drawing application.

• Time-related (TEMPORAL). The function Add object should be developed before Delete object.

Dealing with dependencies

• Record dependencies in requirements database

• Include in prioritization and selection process

– Not all prioritization techniques support this

• Have as little possible dependencies, as they complicate prioritization and selection

Linking requirements and architecture

• Twin Peaks Model:

Nuseibeh, B. (2001). Weaving together requirements and architecture. IEEE Computer, 34(3), 115–119.

Why the Twin Peaks Model?

• Joint refinement

– Twin Peaks explicitly allows the customer to explore the solution space early (tailor-made software)

• Integration of software products

– More and more, software development is a process of identifying and selecting desirable requirements from existing commercially available software packages. With Twin Peaks, developers can identify requirements and match architectures rapidly and incrementally.

• Rapid change

– Twin Peaks is receptive to changes as they occur

Twin peaks adapatation CBSP Intermediate Model

• Component, Bus, System, Property (CBSP) Approach (Grünbacher, Medvidovic & Egyed, 2003)

• Intermediate model to join RE & SA

• Goal is to aid requirements refinement

• “Looks like requirement”

• “Feels like architecture”

• End result: elicited architectural building blocks

Functional architecture framework

• Instrumentation of the Twin Peaks model

• Consider practical issues like:

– How to manage the product vision for future, subsequent releases?

– How to register incoming requirements from customers and prospects?

– How to assign work to development teams?

– How to manage large volumes of requirements in a distributed company?

Vision

• Develop a complete vision on the functional architecture of all relevant applications of your product in the business domain

the Functional Architecture Framework

• The FAF is:

– the standard positioning arrangement for all requirements

– developed together with architects, partners, customers

– used to show the product roadmap

– expressed in easy to understand models

User working scope: event manager

Example: Event Ticketing

Legal Merchandising Customer

Relationship Management

ticketing contract

event request

booking

ticket types

banking details

payee interaction

options terms of services

customer details

event details

Contract management

Ticket sales

Pay- ment

Acqui- sition

Functional architecture

On-line Event Ticketing

Information flow

Product scope

ticketing contract

event request

booking

ticket types

banking details

payee interaction


customer details

event details

Contract management

Ticket sales

Pay- ment

Acqui- sition

Module

FA on module level: Ticket sales

Sub-module Module scope

Event registration

Event reporting

templates

booking

reports

ticket types final ticket

payment details

Visitor management event details

Ticket selection

Pre-payment

arrangement

Ticket sales

Type management

package structures

ticket overview

visitor details

FA of Contract management

Contract baseline

Event administration

Options handling

contract

version

Contract management

option

details

final contract

terms of services

ticket types event details

options

Sub-module

Module scope

payee interaction

Functional Architecture for ERP product

Bussiness Planning Product Innovation

Master Planning

Production

Requirements Planning

Warehousing

Pur- chase

Sales Assembly

Product Information

Receipt & Goods

Component Manufact.

Assembly Packing & Shipping

Sales Forecast

Invoiced Sales Order

Customer Request

Packing and shipping order

Sales Order Ready for Assembly

Master Plan Material Plan

Material Plan Subcontracting

Progress

PO/ Contracts/ Inquiries

FAS Order Production Orders/ schedules

Received Goods

Picking List

Shipment order

Purchase

Picking List

BusinessPlan

Features: Event Ticketing

Acquisition Payment

Ticket Sales Contract

Mgmt

Type Management

Event Registration Contract

Baseline Options handling

Event Administration

Open basket Save basket Print ticket Remove unused baskets Monitor abuse

Select baseline

Select options

Check consistency

….

Visitor Management

Ticket Selection

….

….

….

….

….

….

….

….

Pre-payment Arrangement

….

….

Event reporting

The extension to feature modeling is part of the course Software Architecture

Technical systems

• FAs can also be provided for technical systems

• Example:

Front-end

Firefox architecture

DocShell

Document Object Model

Gecko (layout engine) JavaScript

Localization

Mac OS X Developme

nt

MathML

Networking (Necko)

Binary Plugins (including NPAPI)

MailNews

Quality Assurance

Semantic Data Interchange (RDF)

Security

Vector Graphics (SVG)

Toolkit

Cross Platform Components (XPCOM)

Exchange Language Binding (XBL)

User Interface Language (XUL)

XULRunner

Coding modules

• Modules should be coded for the requirements management processes

Module Sub-module Module code

… … …

Ticket Sales

Visitor management TiSa-VM

Ticket selection TiSa-TS

Event registration TiSa-ER

…

Contract mgmt

Contract baseline CoMa-CB

Event administration CoMa-EA

Options handling CoMa-OH

… … …

Product variability

• Products are sold in different markets with specific requirements

• Software parameterization allows for market specific applications

• Examples:

– Event ticketing tool for scientific conferences, festivals, corporate events

– Enterprise edition, Academic edition, Village edition

• Product variability: one product can be sold in distinct markets in a market-specific configuration

• Issue: How to perform requirements management for a multi-market product?

Typology

• A typology is a classification of a Application Domain based on some discriminating characteristics

• Example: Typology of Event ticketing

– Scientific conference

– Single-venue festival

– Multi-venue festival

– Corporate event

ticketing contract

event request

booking

ticket types

banking details

payee interaction


customer details

event details

Contract management

Ticket sales

Pay- ment

Acqui- sition

Components: modules & typologies

Ticket Sales • Visitor management • Ticket selection • Event registration • Type management • Pre-payment arrangmt • Event reporting Contract management • Event administration • Contract baseline • Options handling

• ……

Typology of Event Ticketing:

• Scientific conference

•Single-venue festival

•Multi-venue festival

•Corporate event

Functional component

• The FAF consists of Functional Components

• A Functional Component is a virtual (sub-)module specific for one particular type

• Examples: – Ticket selection in Multi-venue festival type

– Event reporting in Conference type

– Options handling in Corporate event type

• Product Requirements are linked to: – one Functional Component, or

– groups of Functional Components

Linking requirements to the FAF

PR146: Requirement for Corporate Event Type: Visitor records are to be uploaded from the HR files

FC: Visitor management in

Corporate Event Type

FC: Visitor Management in

Conference Type

PR283: Requirement for Conference Type: The records of visitors should be kept for future years

Functional Components

for Visitor Management

Coding functional components

Module Sub-module Typology Functional Component

… … … …

Ticket Sales

Visitor Management

Conference 111

Single-venue 112

Multi-venue 113

Corporate 114

Ticket Selection

Conference 121

Single-venue 122

Multi-venue 123

Corporate 124

Contract Management

Contract Baseline

Conference 211

Single-venue 212

Multi-venue 213

Corporate 214

… … … …

Coding functional components

Module Sub-module Typology Functional Component

… … … …

Ticket Sales

Visitor Management

Conference TiSa-VM-CO

Single-venue TiSa-VM-SV

Multi-venue TiSa-VM-MV

Corporate TiSa-VM-CE

Ticket Selection

Conference TiSa-TS-CO

Single-venue TiSa-TS-SV

Multi-venue TiSa-TS-MV

Corporate TiSa-TS-CE

Contract Management

Contract Baseline

Conference CM-Bas-CO

Single-venue CM-Bas-SV

Multi-venue CM-Bas-MV

Corporate CM-Bas-CE

… … … …

Usage

• The Functional Architecture Framework provides an ordering scheme for all functional requirements

• Adaptable for the future markets:

– Functional Architecture can be adapted:

• Addition of a (sub-)module

• Rearrangements of the modules

– Product variability

• Adaptation of typology for different markets

– Components can be added

Case studies

Selected three companies based on differences

1. Local vendor, single country

2. Medium sized multinational vendor

3. Very large globally operating vendor

Cases conducted as semi-structured interviews, interviewees were responsible for relating requirements to the architecture

Collected documentation and experiences were the basis of the FAF

Case studies

Isah Exact Infor/Baan

Market specifity High, specific Low, wide Very low

Development team Single team Multiple teams Distributed

Requirements volume Low Medium High

Product variability None Simple Complex

FAF implementation Only basic No variability Full FAF

Lessons learned from cases (1)

• Informal development processes can still benefit from a strong structure in requirements management

• Implementing the full FAF allows a very high volume of requirements to be managed efficiently

• The data provided by the FAF decreases dependency on an individual product manager or architect to know how the application is structured

Lessons learned from cases (2)

• Mappings in the FAF made it possible to involve the right architects

– This made it possible to scope the impact of requirements on the architecture early in the definition of a release

• The relation between functional architecture and system architecture makes the impact of changes on the architecture visible earlier in the process

• Providing extra benefits from the FAF to all stakeholders proved vital to the acceptance and effectiveness of the FAF

Some RM figures for BaanERP (2001)

• 250 modules; 10.000 components; 4.5 MLOC

• Per release (9-12 mo. duration)

– 100 Conceptual Solutions

– 100 Functional Designs (Team)

• About 9000 Market Requirements

• 2500 Product requirements in RDB

• 117 Product requirements in the 5.2 release

• 4830 SW eng days for release

• Average 41 days per requirement

We welcome more recent data from case studies!

RDB Functional Components

RDB PR to FAF mapping

Questions?

spm 4 requirements gathering and organization

Education