When Product Managers Gamble with Requirements: Attitudes to Value and Risk

  • Authors:
  • Nina D. Fogelström;Sebastian Barney;Aybüke Aurum;Anders Hederstierna

  • Affiliations:
  • School of Engeering, Blekinge Institute of Technology,;School of Engeering, Blekinge Institute of Technology,;School of Information Systems, Technology and Management, University of New South Wales,;School of Management, Blekinge Institute of Technology,

  • Venue:
  • REFSQ '09 Proceedings of the 15th International Working Conference on Requirements Engineering: Foundation for Software Quality
  • Year:
  • 2009

Quantified Score

Hi-index 0.00

Visualization

Abstract

[Context and motivation] Finding a balance between commercial (customer specific, market pull and external quality requirements) and internal quality requirements is a recognized challenge in market driven software product development (MDSPD). In order to address this challenge it is important to understand the preferences and biases influencing decision makers selecting requirements for software releases. [Question/problem] Prospect theory has been successfully applied to many disciplines. Applying it to MDSPD suggests decision makers will avoid risk when selecting between commercial requirements, take risk with internal quality requirements, and prefer commercial requirements over internal quality requirements in order to maximize their perceived value. This paper seeks to investigate this claim. [Principal ideas/results] This paper presents an experiment investigating whether the biases proposed by prospect theory can be seen operating in MDSPD requirements engineering (RE). The results indicate risk avoidance when dealing commercial requirements, while greater risk is taken when dealing with internal quality requirements. [Contribution] As this is the first paper to use prospect theory to explain requirements selection decisions, it presents opportunity to educate people in the biases they bring to the RE process, and facilitate the creation of strategies for balancing the different requirements types.