There are many challenges within the domain of software product management. The shift towards developing software as a standard product, the increasing complexity in software requirements and the ever-growing amount of stakeholders are some of these challenges (Weerd, Brinkkemper, Nieuwenhuis, Versendaal, & Bijlsma, 2006).
In this paper, one particular domain of the software development lifecycle will be discussed, namely the process of requirements selection. Requirements selection is the activity of selecting the proper requirements based on factors such as the degree of quality, technical constraints and other constraints such as available resources and costs (Sivzattian & Nueseibeh, 2001). Within the developments of requirements selection, portfolio-based reasoning has been picked up by the literature recently. This theory uses an economic-based approach for selecting the appropriate requirements. Its foundations lie within the following paper, written by Siv Sivzattian and Bashar Nuseibeh: “Linking the Selection of Requirements to Market Value: A Portfolio-Based Approach”.
Based on method engineering techniques, I will model this portfolio-based approach of requirements selection in order to gain a better and more structured understanding of this field of literature.
Method engineering is the engineering discipline to design, construct and adapt methods, techniques and tools for the development of information systems (Brinkkemper, 1996). Method engineering techniques are often used to produce generic models and methods based on a particular situation (Brinkkemper, 1996; Weerd, Versendaal, & Brinkkemper, 2006), implying that it is a functional and useful technique for providing a systematic approach to various methodologies of ICT systems development.
In economics, portfolio theory has been around for a long time, and its foundations are based on a number of theories which will be introduced briefly in this section. The theory is introduced by the early works on modern portfolio theory by the American economist Harry Markowitz. In his theories, he emphasized the significance of risk diversification by applying portfolios (1952; 1999). In essence, he argues that a portfolio consist of a collection of investments that are not perfectly correlated. Holding a portfolio may thus be regarded as risk diversification which may also be referred to as a risk-limiting strategy.
The Capital Asset Pricing Model (CAPM) is “a widely used model in the finance literature” (Sivzattian & Nueseibeh, 2001, p. 2), and pioneers of this theory include William Sharpe (1964) and John Lintner (1965). This theory, built on the works of Markowitz, is an economic model that calculates the value of an investment (such as stocks, securities and derivatives) by linking risk and expected return with each other. CAPM is based on the assumption that investors demand a risk-premium when asked to accept a certain amount of risk. Hence, the CAPM calculates that the expected return for investors is equal to a risk-free return (the interest rate that can be obtained by investing in financial instruments with no default risk) plus a risk-premium (Brealey, Myers, & Marcus, 2004). CAPM distinguishes two types of risk: market risk and specific risk. Market risk is risk that affects an entire financial market (such as a stock market crash), while specific risk is risk that comes with holding individual investments. According to CAPM, specific risk can partially be diversified away by investing in a number of investments (portfolio), while market risk cannot. The model can be represented with the following equation:
E(R_i )= R_f+ ß_im (E(R_m )- R_f ), where E(R_i ) is the expected return on an investment, R_f is the risk-free rate of interest of an investment, ß_im is the general risk of investing on a particular market and where (E(R_m )- R_f ) is the difference between the expected market rate of return and the risk-free rate of interest, also referred to as the risk-premium.
Software engineering is a broad discipline that encompasses the process, management of activities, technical methods and use of tools for the development of software products (Boehm, 1981; Pressman, 1997). In the past decades, this form of literature has become of great importance, due to the ever growing requirements of software products. Requirements engineering is a branch of software engineering, and analyses the requirements of software projects in terms of real-world goals, function and constraints (Nuseibeh & Easterbrook, 2000). The main assumption for requirement engineering is that success of a software product system depends heavily on the degree to which it is intended for, meaning that maintaining a correct representation of the requirements from a user’s perspective has to be taken into consideration as a crucial factor in the process of software development.
Taking a method engineering approach, it becomes possible to structurally analyze processes and construct formal methods of a particular theory. A special type of method engineering is situational method engineering: “an information systems development method tuned to the situation of the project at hand” (Harmsen, Brinkkemper, & Oei, 1994). This section describes the processes of the portfolio-based approach of requirements selection, using some theoretical foundations and techniques of the (situational) method engineering techniques (Weerd & Brinkkemper, 2007).
Figure 1 depicts the process-deliverable diagram of the portfolio-based method. A process-deliverable diagram is an integrated model of two meta-models: A meta-process model (shown on the left-side). This UML-based activity diagram consists of the activities, sub-activities and transitions between them (Weerd & Brinkkemper, 2007, p. 2), and a meta-deliverable model (shown on the right-side). The deliverable side of the model consists of a concept diagram (Weerd & Brinkkemper, 2007, p. 6).
In the following sections, I will elaborate on the process-deliverable diagram based on the starting point of the four main activities of portfolio-based reasoning, which include collection, assumption, execution and selection (see figure 2). All activities take place in the requirements selection sub-activity, as depicted in figure 2, and are to be performed by a decision maker. This is a person who is ultimately responsible for the selection of requirements, varying from a product manager to an engineer.
Correct representation. This assumption means that (the estimate for) a requirement’s value represents the expected return. This data is used for E(R_i ) and E(R_m ) (which are the expected returns on an investment) in the CAPM equation.
Linearity. This is about the assumption that the relationship between effort and expected return is linear, an assumption that aligns with the properties of CAPM.
Case-based rates. This statement assumes that the average risk-free rate and the average expected return are context-based. That is, they depend on the case from which the data is extracted from. This data is used for R_f (which is the risk-free rate of interest of an investment) in the CAPM equation.
These assumptions are required in order to correctly interpret CAPM. Accordingly, under these three assumptions (which are not required to be carried out in a pre-defined order), the theory states that the initial candidate requirements can be considered as securities as such.
Under the assumptions as described above, sufficient data is collected that is required for the equation of CAPM. First of all, the expected returns of the requirements are derived. Then, the corresponding betas (ß) could be calculated. By plotting the expected returns of the requirements against the betas, it becomes possible to check the accuracy of the estimates against the security market line (SML). This is the line that graphs the market risk versus the expected return at a certain time. The SML essentially graphs the results from the CAPM. Thus, it represents the real world:
Expected returns on the requirement that lie above the SML are undervalued.
Expected returns on the requirement that lie under the SML are overvalued.
In this stage, the values of the requirements are determined. Based on these values, which can be divided in an overvalued or undervalued rate, based on a comparison to the real world, there is sufficient information to conclude whether to select or not select a particular requirement.
|Collection||Collect requirements||Initial CANDIDATE REQUIREMENTS that come from the concerning case are collected. Used for transition to SECURITIES based on ASSUMPTIONS.|
|Assumption||Make correct representation assumption||Based on the ASSUMPTION of a CORRECT REPRESENTATION, meaning that the estimate for a requirement’s value represents the expected return (ER). Is input for CAPM, and indirectly for its EXPECTED RETURN data.|
|Make linearity assumption||Based on the ASSUMPTION of LINEARITY, meaning that assets may be exchanged. Is input for CAPM.|
|Make case-based rates’ assumption||Based on the ASSUMPTION of CASE-BASED RATES, CASE-BASED RATES data are input for CAPM. It means that one can assume context-based average risk-free rate and expected return on an individual security.|
|Consider requirements as securities||Taking the ASSUMPTIONS into consideration, the CANDIDATE REQUIREMENTS may be considered as SECURITIES and, subsequently serve as input for the calculation of BETAS.|
|Execution||Apply CAPM||Using the CAPM equation with ASSUMPTIONS and EXPECTED RETURNS as input, BETAS are calculated.|
|Derive expected returns (ER)||The EXPECTED RETURN (ER) data is derived from the concerning case.|
|Calculate betas||BETAS are calculated with the CAPM equation using input from ASSUMPTIONS and derived EXPEXTED RETURNS (ER).|
|Check accuracy (SML)||Combining BETAS with the EXPECTED RETURN (ER), the VALUE COMPARED TO REAL WORLD can be determined.|
|Selection||Select requirements||A selection from the initial CANDIDATE REQUIREMENTS is selected as REQUIREMENTS, based on the VALUE COMPARED TO REAL WORLD.|
|CANDIDATE REQUIREMENT||Candidate requirements are initial prioritized sources of benefits (Sivzattian & Nueseibeh, 2001).|
|SECURITY||Security (or stock) is the capital raised by a corporation through the issuance and distribution of shares (Brealey, Myers, & Marcus, 2004). In this particular study, requirements are considered as securities, based on a number of assumptions.|
|ASSUMPTION||An assumption is a premise: a statement that is assumed to be true and from which a conclusion can be drawn (Princeton University).|
|CORRECT REPRESENTATION||The assumption that the estimate for a requirement’s value represents the expected return ERi on asset-I (Sivzattian & Nueseibeh, 2001).|
|LINEARITY||The assumption that the relationship between effort and expected return is linear (Sivzattian & Nueseibeh, 2001).|
|CASE-BASED RATE||The assumption that the historic average risk-free rate and the average expected return on an individual security applies (Sivzattian & Nueseibeh, 2001).|
|CAPM||The Capital Asset Pricing Model (CAPM) is a model that comprises the theory of the relationship between risk and return, and states that the expected risk premium on any security equals its beta times the market risk premium (Brealey, Myers, & Marcus, 2004).|
|BETA||Beta (ß) measures the sensitivity of change in the return of an individual security to the change in return of the market portfolio (Sivzattian & Nueseibeh, 2001).|
|EXPECTED RETURN (ER)||The result (expected return on a capital asset) that can 1) be calculated using CAPM, or 2) used as input for CAPM (Brealey, Myers, & Marcus, 2004).|
|VALUE COMPARED TO REAL WORLD||By plotting the expected returns of the requirements against their corresponding betas, the accuracy of the estimates relative to the real world (represented by the Security Market Line) can be checked (Sivzattian & Nueseibeh, 2001).|
|SELECTED REQUIREMENT||The selected requirements as a result from the portfolio-based approach (Sivzattian & Nueseibeh, 2001).|
In this section, I will describe how the portfolio-based approach can be applied to a particular case-study that was performed by Karlsson & Ryan (1997), based on an existing and one of the most commonly cited cost-value approach, namely the Analytical Hierarchy Process (AHP). AHP is a mathematical decision making technique that allows consideration of both qualitative and quantitative aspects of decisions (Karlsson & Ryan, 1997; Sivzattian & Nueseibeh, 2001). This case study is performed at Ericsson’s Radio Access Network (RAN) project. The goal of this project is to “identify and specify requirements for a system that would give managers information about the operation of the mobile telephone system” (Karlsson & Ryan, 1997, p. 71). The authors identified 14 high-level requirements that cover the main system functionality. After that, experienced project members are asked to prioritize the requirements according to the AHP principles, using a predefined scale, first according to value and then according to implementation cost. Subsequently, AHP is again used to calculate each requirement’s relative value and implementation costs.
The portfolio-based approach requires the value distribution of these 14 requirements. Under the three assumptions (correct representation, linearity and case-based rates), and by using the CAPM equation, it becomes possible to calculate the corresponding betas.
The relationship between expected return on an individual requirement and its beta, tells the accuracy of the estimates relative to the real world. This is also referred to as the SML.
Please note the three undervalued requirements (R1, R6 and R13). Under original cost-value analysis, these requirements were considered as requirements with respectively high, medium and medium ratio of value to cost. Thus, according to portfolio analysis, these requirements are undervalued.
Boehm, B. W. (1981). Software Engineering Economics. New York, USA: Prentice Hall.
Brealey, R. A., Myers, S. C., & Marcus, A. J. (2004). Fundamentals of Corporate Finance. New York: McGraw? -Hill.
Brinkkemper, S. (1996). Method engineering: engineering of information systems development methods and tools. Information and Software Technology , 38 (4), 275-280.
Harmsen, F., Brinkkemper, S., & Oei, J. (1994). Situational method engineering for informational system project approaches. Proceedings of the IFIP WG8.1 Working Conference on Methods and Associated Tools for the IS Life Cycle, (pp. 169-194).
Karlsson, J., & Ryan, K. (1997). A Cost-Value Approach for Prioritizing Requirements. IEEE Software (September/October), 67-74.
Lintner, J. (1965). The Valuation of Risk Assets and the Selection of Risky Investments in Stock Portfolios and Capital Budgets. The Review of Economics and Statistics , 47 (1), 13-39.
Markowitz, H. (1952). Portfolio Selection. The Journal of Finance , 7 (1), 77-91.
Markowitz, H. (1999). The early history of portfolio theory: 1600-1960. Financial Analysts Journal , 55 (4), 5-16.
Nuseibeh, B., & Easterbrook, S. (2000). Requirements Engineering: A Roadmap. Proceedings of International Conference on Software Engineering (pp. 4-11). Limerick, Ireland: ACM Press.
Paulk, M. (1995). How ISO 9001 Compares with the CMM. IEEE Software , 12, 74-83.
Pressman, R. (1997). Software Engineering: A Practioner's Approach. New York: McGraw? Hill.
Sharpe, W. F. (1964). Capital Asset Prices: A Theory of Market Equilibrium under Conditions of Risk. The Journal of Finance , 19 (3), 425-442.
Sivzattian, S., & Nueseibeh, B. (2001). Linking the Selection of Requirements to Market Value: A Portfolio-based Approach. Proceedings of 7th International Workshop on Requirements Engineering: Foundation for Software Quality. Interlaken, Switzerland.
Weerd, I. v., & Brinkkemper, S. (2007). Meta-modeling for situational analysis and design methods. Submitted for publication.
Weerd, I. v., Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., & Bijlsma, L. (2006). On the Creation of a Reference Framework for Software Product Management: Validation and Tool Support. Proceedings of the 1st International Workshop on Product Management, (pp. 3-12). Minneapolis/St. Paul.
Weerd, I. v., Versendaal, J., & Brinkkemper, S. (2006). A Product Software Knowledge Infrastructure for Situational Capability Maturation: Vision and Case Studies in Product Management. Proceedings of the Twelfth Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ'06), (pp. 97-112). Luxembourg.