Linking the Selection of Requirements to Market Value: A Portfolio-Based Approach Siv Sivzattian Bashar Nuseibeh Department of Computing Computing Department Imperial College The Open University 180 Queen’s Gate Walton Hall London SW7 2BZ, U.K. Milton Keynes MK7 6AA, U.K. Email: svs@doc.ic.ac.uk Email: B.A.Nuseibeh@open.ac.uk ABSTRACT Determining which requirements are selected for implementation of software applications is crucial to the satisfaction of customers. In a commercial setting, the value assigned by markets to a publicly held company is the ultimate measure of the degree to which the company meets its business goals -- satisfies its customers. We argue that portfolio theory provides a market driven, systematic, and more objective approach to selecting requirements and also accounts for uncertainty and incomplete knowledge in the real world. We illustrate through two examples, that the economic dimension is an important factor of software engineering decision-making because it facilitates the calibration of our estimates of limited resources. The underlying point is that the success or otherwise of software systems in commercial settings can be better ascertained by making the connection to market-assigned value explicit. Our particular application of portfolio-based reasoning is a step in contributing towards this objective. Keywords Requirements prioritisation, portfolio-based reasoning, CAPM 1 INTRODUCTION The value assigned by markets to a publicly held company is the ultimate and most objective measure of the degree to which the company meets its business goals -- that is, satisfies its customers. From a commercial perspective, the goal of all internal investment and resource allocation decisions should therefore be to align with financial market valuations. The resources deployed by the company to achieve this goal include the functionality of the computer systems that support the processes that deliver customer satisfaction with the applications [12]. It is generally accepted that the choice of requirements selected for implementation significantly determines customer satisfaction [5; 13; 15; 21; 24]. The need to select prioritised requirements is an important issue that stems from the obvious necessity to fit within an allocated project resource pool and to resolve conflicts in stated functional and non-functional requirements. Moisiadis [14] highlights the strengths and weaknesses of the two approaches most commonly cited to prioritise requirements in practice, namely, Quality Function Deployment (QFD) [23] and the Analytical Hierarchy Process (AHP) [9; 11; 20]. Except for the Distributed Collaboration and Prioritisation Tool (DCPT) [16], these and other prioritisation approaches (e.g., [3; 8]) fail to explicitly account for uncertainty and incomplete knowledge in the real world. Software engineers tend to be concerned with achieving high quality software under technical and other constraints. However, factors such as flexibility, time to market, cost and risk reduction often have a higher impact on value creation [1]. Therefore, accounting for risk is of the essence. However rigorous prioritisation approaches may be, they still depend on the subjective judgements of the stakeholders who participate in the task. Given the diversity of their backgrounds, skills, and personal agendas, it is unrealistic to expect that the various rankings and cost- value estimates that they produce is consistent and objective over time. Therefore, there is a critical need to calibrate the inputs to all the prioritisation approaches. This will then ensure a more accurate assessment of customer satisfaction that results from the implementation of the selected requirements. In this paper we propose a market driven, systematic, and more objective approach to supplement the selection of requirements, which also accounts for uncertainty and incomplete knowledge in the real world. We argue that portfolio-based reasoning is well suited to drive software engineering decisions because it makes the connection to market value explicit [1].