1

Cost-value requirements prioritization

in Requirements Engineering

Student Audrey Sie 3862801 Student-assistant Daniel Alami Course Method Engineering Date 8 April 2016

2

Introduction In software development, stakeholders’ requirements are crucial. However, software projects are subject to time and resource or budget constraints, which challenge the implementation of all requirements (Svensson et al., 2011). How can project managers make a selection of requirements to implement ánd yield a system that meets the stakeholders’ demands? Requirements prioritization plays an important role in decision making, regarding requirements engineering (Berander et al., 2006). Although few companies already successfully prioritize requirements, Karlsson and Ryan (1997) describe a technique for tackling this dilemma, the cost-value requirements prioritization approach. Their objective is to formalize the requirements prioritization process in order for organizations to manage projects more effectively and efficiently. Requirements prioritization transpires at the very start of software development, during the requirements engineering phase (Moisiadis, 2002). The cost-value requirements prioritization approach identifies five steps:

1. Firstly, requirements engineers and the client review the requirements to check for completeness and ambiguity.

2. Next, end-users apply The Analytic Hierarchy Process (AHP) comparison method to assess the relative value of each of the candidate requirements.

3. In turn, experienced software engineers apply the AHP comparison method to assess the relative cost of implementing each candidate requirement.

4. Subsequently, a software engineer applies the AHP comparison method to calculate both the relative value and implementation cost of each candidate requirement, and plots these on a cost-value diagram.

5. Finally, the stakeholders use the cost-value diagram to analyze and discuss the candidate requirements.

Based on the outcome, the software project managers prioritize the requirements to decide which will actually be implemented. This technique is developed by Joachim Karlsson, cofounder of Focal Point AB. Karlsson founded his company based on his dissertation on requirements prioritization. Focal Point AB offers systems for decision support in product development. The used notation for the cost-value requirements prioritization technique is (natural) language. Each step of the technique requires a person to assess something, yielding a document with written words. The Analytic Hierarchy Process comparison method, on the other hand, uses mathematics. This consists of numbers (representing the eigenvalues) and letters or words (representing the requirements).

3

Related literature The cost-value approach to requirements prioritization originates from the analytic hierarchy process (AHP) comparison method (Achimugu et al., 2011; Moisiadis, 2002). As described before, the cost-value approach incorporates AHP, which basically compares candidate requirements stepwise and pairwise, and measures their contributions to the project (Saaty, 1987). Requirements prioritization is applied early in the requirements engineering (RE) phase of systems development projects (Moisiadis, 2002). Requirements engineering entails the “elicitation, analysis, specification, validation and management of requirements” (Dermeval et al., 2015). As described in the previous section, requirements implementation is subject to resource and time constraints. Thus, within the RE phase, requirements prioritization (RP) is necessary. Requirements prioritization concerns rating and/or ranking requirements based on certain criteria and different viewpoints of stakeholders (Moisiadis, 2002). A lot of techniques and methods for RP exist, such as Karlsson’s cost-value approach (Berander et al., 2006). The cost-value approach was applied in a case study by Karlsson and Ryan (1997). The study was centered around the so-called RAN project, which aimed to “identify and specify requirements for a system” (Karlsson & Ryan, 1997). The researchers identified 14 high-level requirements that covered the basics of the system and had the requirements reviewed by the project members. Then, experienced project members represented the customers’ views and prioritized the requirements through pairwise comparisons. Those comparisons were first conducted according to the requirements’ values and then according to the implementation costs. A cost-value diagram was then drafted, which provided a clear overview of the requirements that yield high value for relative low costs. Hasan, Hasan, Mahmood, and Alam (2010) state that requirements engineering and prioritization revolves around adding value. It is therefore not surprising that RP techniques tend to focus on the value that requirements yield for business (Barney, Aurum & Wohlin. 2008; Gordijn & Akkermans, 2003; Karlsson, Wohlin & Regnell, 1997). Karlsson’s cost-value approach is unique in the sense that it also takes implementation costs into account. Within the cost-value approach, other methods can be applied. This has been demonstrated by AHP earlier this section. Karlsson et al. (1997) evaluate six different methods for prioritizing software requirements: AHP, hierarchy AHP, spanning tree matrix, bubble sort, binary search tree, and priority groups. The authors concluded that the Analytic Hierarchy Process (AHP) is the most promising method. Achimigu, Selamat, Ibrahim, and Mahrin (2011) share this conclusion. The creators of the cost-value approach recognize similarities between their technique and Barry Boehm’s quality attribute requirements and conflict consultant tool (Karlsson & Ryan, 1997). However, due to having roots in AHP, the cost-value approach yields more objective and trustworthy results, since AHP checks for consistency across the requirements (Thakurta, 2012). Concluding, the cost-value requirements prioritization approach is one of many RP techniques and methods out there, but has important benefits over the others. It is unique in weighing the added value against the implementation costs, and it eliminates bias due to the mathematical foundation of AHP.

4

Example In this section, a fictional example is presented to provide a more concrete view on the cost-value prioritization appraoch. The procedure and result of this technique will become clear. In this example, an information system needs to be developed. The stakeholders are managers of a fictional company, and they need the system for collecting and querying employees’ strengths and weaknesses, in order to assign them to the right projects. The managers have drawn up a list of 10 requirements. In the first step, the requirements engineers meet up with the managers to discuss their requirements, to make sure they are all on the same page and avoid misunderstandings. Next, the managers apply the Analytic Hierarchy Process comparison method to assess the relative value of their requirements. In turn, experienced software engineers apply the AHP comparison method to assess the relative implementation costs of the requirements. The mathematical part of this method is not relevant for this example, so only the results of the assessments are shown in Table 1.

Requirements Relative values Relative costs R1 16% 5% R2 7% 13% R3 6% 18% R4 13% 4% R5 2% 7% R6 9% 9% R7 21% 18% R8 10% 7% R9 8% 10% R10 8% 9%

Table 1. Relative values and implementation costs of the requirements Then, another software engineer plots these data on a cost-value diagram, as shown in Figure 1. As can be seen in Figure 1, R1 and R4 yield relatively high value with relatively low implementation costs. R3, on the other hand, is not a lucrative requirement.

Figure 1. Cost-value diagram of the requirements

5

The managers use this diagram to discuss which requirements should be implemented and return a prioritized requirements list to the requirements engineers. This list is displayed in Table 2, and forms the deliverable for the cost-value requirements prioritization technique.

Rank Requirement 1 R1 2 R4 3 R8 4 R7 5 R6 6 R10 7 R9 8 R2 9 R5 10 R3

Table 2. Prioritization of the requirements

6

Process-Deliverable Diagram A process-deliverable diagram (PDD) is a meta-modeling technique and depicts both activities and their corresponding deliverables. On the left-hand side, activities are meta-modeled as a UML activity diagram, while on the right-hand side their deliverables are meta-modeled as a UML class diagram (Van de Weerd & Brinkkemper, 2009). As stated in the introduction, the cost-value requirements prioritization technique is modeled. This technique is part of a method, the requirements engineering (RE) method. In order to place the cost-value requirements prioritization technique into context, the RE method is modeled as well. The PDD of the cost-value requirements prioritization technique is portrayed in Figure 2. Explanation of the PDD The cost-value requirements prioritization technique consists of five main activities, two of which are broken down into sub-activities. All activities and sub-activities are performed sequentially. The first activity is ‘Discuss requirements’, for which managers and requirements engineers review the REQUIREMENTs to prevent misunderstandings. The result of this activity is a LIST OF REQUIREMENTS, which has two properties: Total value and Total cost. These properties represent the summed value and cost of all REQUIREMENTs. The second and third activity are basically the same, but yield different deliverables and are executed by different roles. Both activities involve the Analytic Hierarchy Process comparison method, which is broken down into four sub-activities. In the first sub-activity, ‘Set up matrix’, the managers and end-users create an N X N MATRIX, with n being the number of REQUIREMENTs in the LIST OF REQUIREMENTS. Then, they ‘Perform pairwise comparisons’ within the N X N MATRIX. Each comparison requires two REQUIREMENTs. Subsequently, an EIGENVALUE is estimated for each REQUIREMENT. The EIGENVALUE represents how many percent of the total value one REQUIREMENT yields. Therefore, the EIGENVALUE is linked to the Total value property of LIST OF REQUIREMENTS. Those percentages are thus the RELATIVE VALUE of each REQUIREMENT, which corresponds with the last sub-activity, ‘Assign relative values’ These four sub-activites are then repeated by software engineers, only focused on the implementation costs of each REQUIREMENT. Therefore, the last sub-activity is called ‘Assign relative costs’. The fourth main activity is ‘Create cost-value diagram’ and is also performed by the software engineer. The result is a COST-VALUE DIAGRAM, which contains the RELATIVE COST and RELATIVE VALUE of each REQUIREMENT. Finally, the managers ‘Prioritize requirements’ and set up a PRIORITIZED LIST OF REQUIREMENTS.

7

Figure 2. Process-Deliverable Diagram of the cost-value requirements prioritization technique

8

As mentioned before, the cost-value approach is part of the requirements engineering method. To demonstrate its position within the larger method, the requirements engineering method is modeled globally as well. The method and specific method fragments are depicted in Figure 3. The requirements engineering method consists of five main activities: elicit, analyze, document, validate and manage requirements (Paetsch, Eberlein & Maurer, 2003). ‘Analyze requirements’ is an open activity, which means that it contains sub-activities which are relevant or known in this context (Van de Weerd & Brinkkemper, 2009). This activity consists of another open activity, ‘prioritize requirements’, which, in turn, also contains an open activity, the cost-value approach. Thus, the cost-value approach is part of the requirements analysis, which is the second step in requirements engineering.

Figure 3. Process-Deliverable Diagram of requirements engineering method-fragments

9

Activity Table Supplementary to the PDD, an activity table is provided. The activity table describes the left-hand side of the PDD (Figure 1) and composes of three columns. In the first column, all activities are listed. Potential sub-activities are included in the second column. Finally, the third column provides a short description of the (sub-)activities and their relations to the concepts. The activity table is shown in Table 3.

Activity Sub-activity Description

Discuss requirements

Requirement engineers discuss the REQUIREMENTs with the client to ensure completeness and ambiguity. This activity yields a LIST OF REQUIREMENTS which is needed in the following steps.

Calculate relative value

Set up matrix The REQUIREMENTs are inserted in the rows and columns of an N X N MATRIX.

Perform pairwise comparisons

Each REQUIREMENT is compared to another REQUIREMENT, in terms of their value in relation to each other. This is not yet the RELATIVE VALUE that is yielded by the main activity.

Estimate eigenvalues

For each REQUIREMENT an EIGENVALUE is estimated.

Assign relative value

Based on the EIGENVALUEs, each REQUIREMENT gets a RELATIVE VALUE.

Calculate relative cost

Set up matrix The REQUIREMENTs are inserted in the rows and columns of an N X N MATRIX.

Perform pairwise comparisons

Each REQUIREMENT is compared to another REQUIREMENT, in terms of their cost in relation to each other. This is not yet the RELATIVE COST that is yielded by the main activity.

Estimate eigenvalues

For each REQUIREMENT an EIGENVALUE is estimated.

Assign relative cost

Based on the EIGENVALUEs, each REQUIREMENT gets a RELATIVE COST.

Create cost-value diagram

A software engineer plots the RELATIVE VALUE against the RELATIVE COST for each REQUIREMENT. The result is a COST-VALUE DIAGRAM.

Prioritize requirements

The client uses the COST-VALUE DIAGRAM to decide which REQUIREMENTs will be implemented. This activity yields a PRIORITIZED LIST OF REQUIREMENTS,

Elicit requirements

Requirements engineers consult stakeholders to discover and capture requirements.

Analyze requirements

The requirements are checked for necessity, consistency, completeness, and feasibility.

Document requirements

This activity enables the communication of requirements between stakeholders and developers.

Validate requirements

The requirements are checked whether they represent an acceptable description for the system to be implemented.

10

Manage requirements

Requirement management entails capturing, storing, and disseminating information.

Prioritize requirements

The client lists all requirements in order of features yielding the most benefit.

Cost-value approach

This approach prioritizes the requirements based on a trade-off between requirements value and implementation cost.

Table 3. Activity table

Concept Table In addition to the activity table, a concept table is included in Table 4. This table specifies all of the concepts that are portrayed in the PDD, and presents a description of each concept.

Concept Description

REQUIREMENT A REQUIREMENT is a condition or capability that must be met or possessed by a system, system component, product, or service to satisfy an agreement, standard, specification, or other formally imposed documents (ISO 3.2506, 2010).

N X N MATRIX A MATRIX is a rectangular array of mathematical elements that can be combined to form sums and products with similar arrays, having an appropriate number of rows and columns (Merriam-Webster, n.d.). An N X N MATRIX thus has N rows and N columns. N is the number of REQUIREMENTs.

EIGENVALUE An EIGENVALUE is a special set of scalars associated with a linear system of equations (i.e. matrix equation) (Weisstein, 2004).

RELATIVE VALUE

The value of a REQUIREMENT for clients and users, relative to other REQUIREMENTs (Karlsson & Ryan, 1997).

COMPARISON A COMPARISON is the act of looking at things to see how they are similar or different (Merriam-Webster, n.d.).

RELATIVE COST The cost of succesfully implementing the REQUIREMENT, relative to other REQUIREMENTs (Karlsson & Ryan, 1997).

COST-VALUE DIAGRAM

A diagram which plots the RELATIVE VALUE on the x-axis and the RELATIVE COST on the y-axis (Karlsson & Ryan, 1997).

PRIORITIZED LIST OF REQUIREMENTS

A PRIORITIZED LIST OF REQUIREMENTS is a list, containing REQUIREMENTs that are ranked in order of priority.

Table 4. Concept table

11

References Achimugu, P., Selamat, A., Ibrahim, R., Mahrin, M. (2014). A systematic literature review of software

requirements prioritization. Information and Software Technology, 56(6), 568-585. Barney, S., Aurum, A., Wohlin, C. (2008). A product management challenge: creating software product

value through requirements selection. Journal of Systems Architecture, 54(6), 576-593. Berander, P., Khan, K., Lehtola, L. (2006). Towards a research framework on requirements prioritization.

Proceedings of the 6th Conference on Software Engineering Research and Practice, Umea (pp. 39-48). Comparison [Def. 1b]. (n.d.). In Merriam Webster Online, Retrieved April 7, 2016, from

http://www.merriam-webster.com/dictionary/comparison Dermeval, D., Vilela, J., Bittencourt, I., Castro, J., Isotani, S., Brito, P., Silva, A. (2015). Applications of

ontologies in requirements engineering: a systematic review of the literature. Requirements Engineering, 1-33.

Gordijn, J., Akkermans, J. (2003). Value-based requirements engineering: exploring innovative e-commerce ideas. Requirements Engineering, 8(2), 114-134. Hasan, S., Hasan, M., Mahmood, A., Alam, M. (2010). A model for value based requirement engineering.

International Journal of Computer Science and Network Security, 10(12), 171-177. International Organization for Standardization. (2010). Systems and software engineering – vocabulary

(ISO/IEC/IEEE 24765). https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:24765:ed-1:v1:en International Organization for Standardization.

Karlsson, J. & Ryan, K. (1997). A Cost-Value Approach for Prioritizing Requirements. IEEE Software,

14(5), 67-74. Karlsson, J., Wohlin, C., Regnell, B. (1997). An evaluation of methods for prioritizing software

requirements. Information and Software Technology, 39(14-15), 939-947. Matrix [Def. 5a]. (n.d.). In Merriam Webster Online, Retrieved March 10, 2016, from

http://www.merriam-webster.com/dictionary/matrix Moisiadis, F. (2002). The fundamentals of prioritising requirements. Proceedings of the Systems Engineering, Test

& Evaluation Conference, Sydney (p. 108-119). Paetsch, F., Eberlein, A., Maurer, F. (2003). Requirements engineering and agile software development.

Proceedings of the 12th IEEE International Workshops Enabling Technologies: Infrasstructure for Collaborative Enterprices, Linz (p. 308-313).

Saaty, R. (1987). The analytic hierarchy process – what it is and how it is used. Mathematical Modelling, 9(3

5), 161-176. Svensson, R., Gorschek, T., Regnell, B., Torkar, R., Shakrokni, A., Feldt, R., Aurum, A. (2011).

12

Prioritization of quality requirements: state of practice in eleven companies. Proceedings of the 19th IEEE International Requirements Engineering Conference, Trento (pp. 69-78).

Thakurta, R. (2012). A framework for prioritization of quality requirements for inclusion in a software

project. Software Quality Journal, 21, 573-597. Weerd, van de I. & Brinkkemper, S. (2009). Meta-modeling for situational analysis and design methods. In

M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing.

Weisstein, E. W. (2004). Eigenvalue. From MathWorld–A Wolfram Web Resource.

http://mathworld.wolfram.com/Eigenvalue.html.