ETS170

Requirements Engineering

Lecture 4:Preparations for Lab 2

Market-Driven Requirements Engineering [MDRE]

Prioritization [PRIO],

Release Planning [RP]

RE for OSS [OSSRE]

Johan Linåker

Björn Regnell

http://www.cs.lth.se/ETS170

Book Chapter [MDRE] in compendium

Market-Driven Requirements

Engineering for Software ProductsB. Regnell, S. Brinkkemper

Engineering and Managing Software Requirements, Eds. A.

Aurum and C. Wohlin, Springer, ISBN 3-540-25043-3, 2005

Marketing Organization

RE versus Product & Project Management

DevelopmentOrganization

Product Management

Project Management

Top-level management

RequriementsEngineering

Software Product Management

[SPM]

Software Project Management

Different types of products

• Generic Product on Open Market

• The distinction is often blurred: the same org. often

combines several types, e.g. generic+customized

• Sometimes products evolve from customer specific to

generic.[MDRE]

The investment cycle

[MDRE]

Specific characteristics of MDRE

[MDRE pp 589-590]

• Basic goals

• Profit, margins, future revenue

• Market shares

• Inventing reqs (not just collect)

• Stakeholders

• Market segments with potential customers

• Competitors

(confidentiality often needed)

• Planning

• Time to market

• Multiple releases

• Continuous inflow of reqs

Bespoke RE vs MDRE

[PRIO, p. 79]

Some hard challenges in

MDRE

1. Balancing market pull and technology push

2. Chasm between marketing and development

3. Organizational instability and market turbulence

4. Simple tools for basic needs

5. Requirements dependencies

6. Cost-value-estimation and release planning

7. Overloaded Requirements Management

[MDRE]

Decisions outcomes in MDRE

Product Quality:

Decision Quality:

Finding the golden grains despite

uncertain estimates of value and cost

Requirements

Prioritization

[PRIO]

Paper [PRIO]

”Requirements Prioritization”,

Patrik Berander and Anneliese Andrews,

Engineering and Managing Software

Requirements,

Eds. A. Aurum and C. Wohlin, Springer,

ISBN 3-540-25043-3, 2005

Why prioritize?

To focus on the most important issues

To find high & low priority requirements

To implement requirements in a good order

To save time and money

...[PRIO]

What we need to do...

• Select prioritization aspects (criteria)

• Select prioritization objects• e.g. features at high level that can be selected or de-selected

• Structure and group• appropriate level and reasonable number

• Do the actual prioritization• decide priorities for each aspect and object

• Visualize, discuss, iterate, …

Prioritization challenges

Finding a good abstraction level

Combinatorial explosion

Inter-dependencies

Not easy to predict the future

Power and politics

Prioritization Aspects

Example aspects (also called criteria): [PRIO]

• Importance (to stakeholder(s))

E.g. financial benefit, urgency, strategic value, market share etc.

• Penalty (if req is not included)

• Cost (e.g. staff effort)

• Time (e.g. lead time)

• Risk (e.g. technical, market)

• Volatility (instability, risk of change) (ändringsbenägenhet)

Other aspects (e.g. competitors, brand fitness, competence, release theme, ...)

Combination of aspects: cost vs benefit, cost vs risk, importance vs volatility

Optimize: Minimize or maximize some combination, e.g. benefit/cost

Filtering Requirements

Karlsson, Joachim, and Kevin Ryan. "A cost-value approach for prioritizing

requirements." IEEE software 14.5 (1997): 67-74.

When to prioritize?

At decision points (toll gates), e.g.

Project start

Start of construction

Release planning

Increment planning

When big changes occur

Iteratively with lagom intervals

Who should prioritize?

Find the right competence for the right aspect

• Developers know about e.g. development

effort and engineering risk

• Support organization knows about e.g.

customer value and penalty

• Marketing organization knows about e.g.

competitors

etc.

Typical industry praxis

Numerical assignment ,e.g. 1-5

[Lauesen, chapter 7.4]

Problem:

Reqs are not confronted to each other

What should go out when new req wants in?

Everything tends to be important;

hesitation to decide

(”beslutskramp”)

Prioritization scales

Ratio scale

ex: $, h,

% (relative)

Numeric relations:

A=2*B

Categorization

e.g.: must, ambiguous,

volatile

Partition in groups

without greater-less

relations

Ordinal scale

e.g.: more expensive,

higher risk,

higher value

Ranked list

A>B

Different techniques for

requirements prioritization

Grouping, Numerical assignment (grading)

Can be done using any scale (categorical, ordinal, ratio)

Quick & easy; but a risk is that all reqs are deemed highly important as they are not challenged against each other; may be misinterpreted as ratio scale (even if ”4” not necessarily is "twice as much" as ”2” when using an ordinal scale).

100$-test

Ratio scale, quick and easy, risk of shrewd tactics (listigt taktikspel)

Ranking (sorting)

Ordinal scale, pairwise comparison, easy and rather quick

Top-ten (or Top-n)

Ordinal scale if the top list is ranked / Categorical grouping if not ranked; very quick and simple, gives a rough estimate on a limited set of req

Analytical Hierarchy Process (AHP)

Ratio scale, pairwise comparison, tool is needed, redundancy gives measure of consistency

Combination of techniques: e.g. First grouping, then sorting or top-5 depending of which group

[PRIO]

Tools can help you find inconsistent

comparisons if each requirements is

involved in more than one comparison

has more value for

customer than

has more value for

customer than

has more value for

customer than

Image enhancement

Voice control

Adress book

???!

[RP1] Release Planning

The Art and Science of Software Release Planning,

Günther Ruhe and Moshood Omolade Saliu, IEEE

Software, November/December, pp. 47-53, 2005

What is Release Planning?

[RP]

Release planning involves ...

...prioritization + scheduling

under various constraints, e.g.

resource and precedence constraints

Example planning parameters

Requirements priorities (from prioritization)

Available resources

Delivery time

Requirements interdependencies

precedes, requires (coupling), excludes

System architecture

Dependencies to the code base

...

What is a Good Release Plan?

A good release plan should

• provide maximum business value by

• offering the best possible blend of features

• in the right sequence of releases,

• satisfy the most important stakeholders involved,

• be feasible with available resources, and

• reflect existing dependencies between features.

Baseline:

Release planning “on the fly”

• Informal process

• Rationale behind decisions not always clear

• Constraints regarding e.g. resources and

stakeholders not systematically taken into account

• Already in case of 20 features and 3 releases:

420 > 1.000.000.000.000 = 1012 possibilities

Investigate with reqT why greedy is not good...

val m = Model(

Feature("a") has (Benefit(90), Cost(100)),

Feature("b") has (Benefit(85), Cost(90)),

Feature("c") has (Benefit(80), Cost(25)),

Feature("d") has (Benefit(75), Cost(23)),

Feature("e") has (Benefit(70), Cost(22)),

Feature("f") has (Benefit(65), Cost(20)),

Feature("g") has (Benefit(60), Cost(10)),

Feature("h") has (Benefit(55), Cost(30)),

Feature("i") has (Benefit(50), Cost(30)),

Feature("j") has (Benefit(45), Cost(30)),

Release("r1") has Capacity(100),

Release("r2") has Capacity(90))

def features(m: Model) = m.tip.collect{case f: Feature => f}def releases(m: Model) = m.tip.collect{case r: Release => r}def allocate(m: Model, f: Feature, r: Release) = m + (r has f)def isAllocated(m: Model, f: Feature) = releases(m).exists(r => (m/r).contains(f))def allocatedCost(m: Model, r: Release) = (m/r).entities.collect{case f => m/f/Cost}.sumdef isRoom(m: Model, f: Feature, r: Release) = m/r/Capacity >= allocatedCost(m,r) + m/f/Costdef featuresInGreedyOrder(m: Model) = features(m).sortBy(f => m/f/Benefit).reverse

def random(m: Model, r: Release) = scala.util.Random.shuffle(features(m)).filter(f => !isAllocated(m,f) && isRoom(m,f,r)).headOption

def greedy(m: Model, r: Release) =featuresInGreedyOrder(m).find(f => !isAllocated(m,f) && isRoom(m,f,r))

def plan(input: Model,pickNext: (Model,Release)=>Option[Feature]): Model = {

var result = inputreleases(input).foreach { r =>var next = pickNext(result, r)while (next.isDefined) {result = allocate(result, next.get, r)next = pickNext(result, r)

}}result

}

plan(m, random)plan(m, greedy)

Optimal vs Greedy

val optimal = Model(

Feature("a") has (Benefit(90), Cost(100)),

Feature("b") has (Benefit(85), Cost(90)),

Feature("c") has (Benefit(80), Cost(25)),

Feature("d") has (Benefit(75), Cost(23)),

Feature("e") has (Benefit(70), Cost(22)),

Feature("f") has (Benefit(65), Cost(20)),

Feature("g") has (Benefit(60), Cost(10)),

Feature("h") has (Benefit(55), Cost(30)),

Feature("i") has (Benefit(50), Cost(30)),

Feature("j") has (Benefit(45), Cost(30)),

Release("r1") has (Capacity(100), Feature("c"), Feature("d"), Feature("e"), Feature("f"), Feature("g")),

Release("r2") has (Capacity(90), Feature("h"), Feature("i"), Feature("j")))

def sumAllocatedBenefit(m: Model) =releases(m).map(r => (m/r).collect{case f: Feature => m/f/Benefit}.sum).sum

val beneftitOptimal = sumAllocatedBenefit(optimal)val benefitGreedy = sumAllocatedBenefit(plan(m,greedy))val ratio = benefitGreedy.toDouble / beneftitOptimal

[PRIO] Example

[PRIO] Example

[PRIO] Example

[PRIO] Example

[RP] Example

Example (Part 2)

WAS:

weighted

average

satisfaction

of stakeholder

priorities

[RP]

Example

output

Example (Part 2)

WAS:

weighted

average

satisfaction

of stakeholder

priorities

[RP]

Example

output

Requirements Engineering

in Open Source Software

communities

[OSSRE]

What is OSS?

Computer Software that provides its

source code under a license with

the rights to study, change, and

distribute the software to anyone

and for any purpose

OSI Definition: 10 Freedoms –

http://opensource.org/osd-

annotated

Licenses rules

Use of the OSS is governed with the

help of licenses

Difference in ”freedom” of usage

Copyleft <-> Permissive

The Community

The RE process(es)

Decentralized

Requirements

One requirements -> Multiple

representations

(artifacts/Informalisms)

E.g., Issue in an issue-tracker, mail-

threads, IRC-logs, commits…

Different levels of

formality

Ernst, Neil A., and Gail C. Murphy. "Case studies in just-in-time requirements analysis." 2012 Second IEEE

International Workshop on Empirical Requirements Engineering (EmpiRE). IEEE, 2012.

Governance

Meritocracy +/- Benevolent dictators

Power and influence by contributing

Nakakoji, Kumiyo, et al. "Evolution patterns of open-source software systems and

communities." Proceedings of the international workshop on Principles of software evolution.

ACM, 2002.

Different types of

Relationships

Dahlander, Linus, and Mats G. Magnusson. "Relationships between open source software companies and

communities: Observations from Nordic firms." Research policy 34.4 (2005): 481-493.

Commonly used

Directly and indirectly in products and

services

E.g., Sony Mobile

Android Open Source Project

Jenkins + Gerrit

Other examples

For more info…

http://amzn.github.io/

http://www.capitalone.io/

https://developers.google.com/open-source/

https://github.com/github

https://code.facebook.com/projects/

https://www.microsoft.com/en-us/openness/

https://netflix.github.io/

https://www.sandisk.com/business/datacenter/products/flas

h-software/open-source

https://github.com/walmartlabs

Why should you share?

Access to external workforce

Several (potential) benefits…

Increased innovation

Shared maintenance/increased QA

Shorter time-to-market

Control competition

…

What should you share?

How is the OSS used in your

business?

Does it bring a competitive

advantage and business profit?

OSS Business Models

Deployment Support model (Chesbrough&Appleyard, 2008)

Subscription model (Chesbrough&Appleyard, 2008)

Professional services model (Chesbrough&Appleyard, 2008)

Hybridization (Chesbrough&Appleyard, 2008)/Selling complements (West&Gallagher, 2006) Proprietary extensions model/Open core

Open Platform

Dual-licensing model

Cloud-computing/Software-as-a-Service

Time-delayed Open Source

Complements/Complementary Products Device model (Chesbrough&Appleyard, 2008)/Hardware products

Attracting donated complements (West&Gallagher, 2006)

Asymmetric value-capture

Challenges and

Consequences

Knowing what to share and where to

invest resources

Separating commodity and differentiation

Conflicting opinions and agendas

Known and unknown stakeholders

Possible competitors

Diminished impact on feature selection

and product planning

Evolving Stakeholder

Population in Community

Need for Stakeholder

Identification and Analysis

Can help to give input to how a firm should structure their contribution strategy

E.g., when a firm wants to...

understand which parts of current and future internal functionality, knowledge and resources that are to be considered differentiating in relation to ecosystem. [Value Understanding]

know how to increase one’s long-term influence on what features that get implemented, prioritized and released. [Governance Adaption]

know how to best adapt one’s own processes to those of the ecosystem, both on a strategic level (product strategy <-> OSS roadmap) and on an operational level (development, test, release mgmt.).[Process Adaption]

scan for potential partnerships to develop certain functionality or to draw traction to a certain direction.[Partnerships]

identify competitors, both on general and modular levels. [Competition]

Contribution strategy

Contribution Acceptance

Process (CAP) Model

Examples of Revealing

strategies

Opening parts - waving control of commodity layer(s) of the platform, while retaining full control of other layers that presumably provide greater opportunities for differentiation. (West, 2003), See Selective Revealing (Henkel, 2006/2014)

Partly open - disclosing technology under such restrictions that it provides value to customers while making it difficult for it to be directly employed by competitors. (West, 2003)

Completely open – Disclosing everything

CAP Model

Determined by a series of questions

Need for cross-functional view

Drivers:

Maintenance and patch-mountains

Time-to-market

Need of Control

Acceptance process:

OSS governance board

Contribution sizes

Exjobb <3 OSS <3 RE

* Company Involvement in the Linux, OpenStack and WebKit Communities

# Requirements Engineering, Open Source, Social Network Analysis, Data Mining,

R/Python

* Feature Clustering and Collaboration Recommendations in Open Source Issue

Trackers

# Requirements Engineering, Open Source, Social Network Analysis, Data Mining,

Machine Learning, R/Python

* Web-application for ReqT - Open Source Requirements Modeling Tool

# Requirements Engineering, Scala, Javascript, Front-end

* Requirements Engineering Practices in Open Source Companies/Startups

# Requirements Engineering, Open Source, Survey/Interviews, Literature Review,

Statistics

* Open Source Licences and Requirements Engineering

# Requirements Engineering, Open Source Licences, Intellectual Property, Interviews,

Literature Review

* Open Source Business Models and Requirements Engineering

# Requirements Engineering, Open Source Business Models, Survey/Interviews,

Literature Review, Statistics

ub

INVITED TALK

Thursday, W4

Hampus Jakobsson

Entreprenör och grundare av bl.a.

TAT och Brisk.io.

Preparations for Lab 1 this week:

Requirements Modeling

Do the preparation part of [LAB1] in compendium

(Preparations will probably take less than 1h)

Bring all solutions to preparations [LAB1, p 2] and

make sure you can access the text file you

produce in the preparations feat.txt on the Linux

computers in E-huset.

Check how to run reqT on Linux computers in E-

huset here: http://cs.lth.se/ets170/reqt/

Preparations for Lab 2 in W5:

Prioritization & Release Planning

Please note: The preparations for lab2 takes

significantly more time compared to lab1, ~2-4h

Read [MDRE, PRIO, RP]

Do [LAB2] (in compendium, also on course web)

Bring all solutions to preparations [LAB2, pp 3-14]

and make sure you can access the text files you

produce in the preparations req.scala and

prio100.scala on the Linux computers in E-huset.

Lab registration:

http://cs.lth.se/ets170/lab-sessions/

To do…

Read [MDRE] [PRIO] [RP] [OSSRE]

[PRIO] [RP] are part of the preparations for lab 2

LAB 1 this week W3; LAB 2 in W5:

Mandatory lab preparations – will be checked at beginning of lab.

Sign up for a 2h lab time slot via course web:

http://cs.lth.se/ets170/lab-sessions/

Bring lab instructions in compendium to the lab

Exercise E3: Functional Requirements

Lecture 5 on Monday W4:

Specification 3, Quality Req., Lifecycle

Work in the project:

Context diagram etc.

Elicitation: try to get out in the "real world"

Deadline release R1 -> supervisor: Monday W4 at 0900

All hand-ins to your supervisor via email – check confirmation reply

Hand in exam problem proposals (see bonus instructions lecture L2) latest by W4

Wednesday midnight to aim for a chance to get a bonus