ETSN15 - Requirements Engineering

Lecture 6: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/krav

Market-Driven Requirements Engineering (MDRE)

Book chapter [MDRE] in compendium

● Market-Driven Requirements Engineering for Software Products

● Regnell, B., & Brinkkemper, S.● Engineering and Managing Software

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

RE vs. Product & Project Mgmt

Marketng Organizaton

DevelopmentOrganizaton

Product Management

Project Management

Top-level management

Business Stra

tegy

Portolio

Mgmt

RequriementsEngineering

Software Product Management

[SPM]

Software Project Management

The investment cycle

[MDRE]

Different types of products

● Generic product on the open market● The distinction is often blurred: the same

organization combines several types– e.g., generic + customized

● Sometimes products evolve from customer specific to generic

[MDRE]

Characteristics of MDRE

● Success through sales and market share – (not just customer satisfaction)

● Release Planning focus on– Time-to-market– Multiple release

● Continuous evolution – (not just maintenance)

● Inventing requirements + market analysis – (not just collecting 1-on-1)

● Stakeholders– Market segments with potential customers– Competitors (confidentiality often needed)

● Continuous inflow of requirements

[MDRE]

Bespoke RE vs MDRE

[PRIO]

Some challenges in MDRE

● Balancing market pull and technology push● Chasm between marketing and development● Requirements dependencies● Cost-value-estimation and release planning

– Over and Under● Overloaded requirements management

– Stage gates and triage

[MDRE]

Decisions outcomes in MDRE

[MDRE]

Product Quality:

Decision Quality:

Finding the golden grains despite uncertain cost-value estimates

[MDRE]

Requirements Prioritization

Book chapter [PRIO] in compendium

● Requirements prioritization● Berander, P., & Andrews, A.● 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 and low priority requirements● To implement requirements in a good order● To save time and money

[PRIO][PRIO]

Steps we need to do...

● Select prioritization apects● Select prioritization objects (e.g., features)● Structure and grouping● Do the actual prioritization

– Decide priorities for each aspect and object

● Visualize, discuss, iterate...

[PRIO][PRIO]

Prioritization challenges

● Finding a good abstraction level● Combinatorial explosion● Inter-dependencies● Not easy to predict the future● Power and politics

[PRIO][PRIO]

Prioritization aspects

● Example aspects:– Importance (e.g., financial benefit, urgency, strategic value, market share

etc.– Penalty (if requirement not included)– Cost (e.g., staff effort)– Time (e.g., lead time)– Risk (e.g., technical, market)– Volatility (instability, risk of change)

● 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 combinations, e.g., cost-benefit

[PRIO][PRIO]

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

[PRIO][PRIO]

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 e.g., about

competitors– etc...

[PRIO][PRIO]

Typical industry praxis

● Numerical assignment, e.g., 1-5– See Lauesen, chapter 7.4

● Problem:– Requirements are not confronted to each other– What should go out when new requirements

wants in?– Everything tends to be important

→ decision avoidance

[PRIO][PRIO]

Prioritization scales

[PRIO][PRIO]

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 listA>B

Prioritization techniques

● Grouping, numbering assignment (grading)● Ranking (sorting)● Top-ten (or Top-n)● Analytical Hierarchy Process (AHP)● 100$ test● Combination of techniques

[PRIO][PRIO]

Tools can help fnd inconsistencies

[PRIO][PRIO]

has more value for customer than

has more value for customer than

has more value for customer than

Image enhancement

Voice control

Adress book

???!

Release Planning

Paper [RP] in compendium

● The art and science of software release planning

● Ruhe, G., & Saliu, M. O. ● IEEE software, 22(6), 47-53. 2005

What is Release Planning?

[RP]

Release Planning involves...

● ...prioritization + scheduling under various constraints, e.g., resource and precedence constraints

[RP]

Example planning parameters

● Requirements priorities (from prioritization)● Available resources● Delivery time● Requirements interdependencies

– Precedence, Coupling, Excludes● System architecture● Dependencies to the code base

[RP]

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

[RP]

Baseline: Release Planning - on the fy

● 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 releases420 > 1.000.000.000.000 = 1012 possibilities

[RP]

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/Cost def 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 = input releases(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

Example from [PRIO]

Example from [PRIO]

Example from [PRIO]

Example from [PRIO]

Example from [RP]

Example from [RP]

WAS: weighted average satisfaction of stakeholder priorities

Example from [RP]

WAS: weighted average satisfaction of stakeholder priorities

Example (Part 2)

Requirements Engineering in Open Source Communities

Paper [OSSRE] in compendium

● Understanding Requirements for Open Source Software

● Scacchi, W.● Design Requirements Engineering: A Ten-Year

Perspective, Springer, pp. 467-494, 2009

What is open source?

● Software that provides its source code under a license with the rights to study, change, and distribute the software for anyone and for any purpose

● See OSI definition: 10 freedomshttp://opensource.org/osd-annotated

Different types of licenses

● Use of open source is governed with licenses● Difference in “freedom” of usage● Copyleft ↔ Permissive

Community surrounding the software

The RE process(es)

● (Semi-)formal● Need-to-know basis● Centralized● Collaboration based

on process-design

● Informal● Transparent● Decentralized● Collaborative

Informal requirements representation

● One requirement can have multiple representations and fragments (informalisms)

● Each representation has their own repository(compare with Bespoke RE/MDRE)

● E.g., mailing-lists, issue trackers, code- repository, IRC, wikis...

Classifcation sometimes foating

Linåker, J., Regnell, B., & Damian, D. (2018). Who are they and what do they want? - Stakeholder Identification and Influence Analysis in Open Source Software Ecosystems. In submission.

Informal requirements process

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.

Community governance

● Often meritocrazy-based +/- Benovelent dictators

● Influence on RE process gained by showing merit– E.g., contributing code,

sharing knowledge, attending “offline” events, sponsoring

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.

Evolving community of stakeholder

Linåker, J., Rempel, P., Regnell, B., & Mäder, P. (2016, March). How firms adapt and interact in open source ecosystems: analyzing stakeholder influence and collaboration patterns. In International Working Conference on Requirements Engineering: Foundation for Software Quality (pp. 63-81). Springer, Cham.

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.

Open Source used in different ways

● Direct or indirect, e.g., ● Support & subscription● Open core / open platform● Dual licensing● Complementary● Infrastructure / Tooling

Some examples

Open Source ops in companies

● Often centralized to a Open Source Program Office – oversees the 4C’s

Ibrahim Haddad, Samsung Research America, presentation at the Open Source Summit Europe 2017http://www.ibrahimatlinux.com/uploads/6/3/9/7/6397792/oss-summit-eu-2017.pdf

What should you share?

?

What you gain and loose?

Contribution strategies What & When→

Linåker, J., Munir, H., Wnuk, K., & Mols, C. E. (2018). Motivating the contributions: An Open Innovation perspective on what to share as Open Source Software. Journal of Systems and Software, 135, 17-36.

Exjobb <3 RE <3 OSS

# 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

# 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

TODO!

● Lab2– Please note: Preparations for lab2 takes significantly

more time compared to lab1 (~2-4h)

– Read [PRIO, RP]– Do [LAB2] (see compendium or course web)– Bring any preparations to lab

● Lecture 7 – Validation, inspections, Agile RE● Exercise 5 – Validation