Prioritizing Stakeholders Role in Prioritization Process

Transcription

1 Prioritizing Stakeholders Role in Prioritization Process Nasir Mehmood Minhas, Muhammad Aasem, Qaim Khan Khtatak, Sumaira Jamsheid University Institute of Information Technology (UIIT), Pir Maher Ali Shah Arid University of Arid Agriculture (PMASUAAR), Rawalpindi, Pakistan. Abstract The quality requirements of a software system have great concerns with the decisions made by stakeholders about them. Not all stakeholders have same approach toward each requirement. Even some core requirements might not be of any worth to some stakeholder. This problem can greatly reduce the quality of prioritization outputs. In this paper a technique has been presented to prioritize stakeholders roles by considering two elements i.e., Stakeholder Profile Weight (SPW) and Requirement Specific Stakeholder Weight (RSSW). The result of given technique has been discussed theoretically and assure quality improvement in software requirements prioritization. 1. INTRODUCTION Software requirements prioritization is a complex communication and negotiation process that involves the participation of many stakeholders [5]. They may have many different attributes that could make their views different from each other about a requirement. A person closer to the domain of a specific requirements set can make better decision about its priority than anyone else. Moreover, broader understanding of overall project/organization can also lead a one toward making good decision about the requirement. Due to these facts, it can be concluded that not all stakeholder have same importance for every requirement. There are many prioritization techniques that are based on stakeholders opinions to prioritize the software requirement. The techniques like Numerical Assessments, Hundred dollars test, Top Ten National Science Conference 2012, Rawalpindi Pakistan, January

2 requirements, Ranking, etc [1, 6, 7, 8, 9] are strongly based on stakeholders participation but none of them have focused their attention to analyze them. Without properly considering their role in prioritization, the resultant prioritized requirements would have much difference in actual result. Therefore, it is suggested to prioritize stakeholders in order to prioritize the requirements sufficiently in more qualitative way. In this paper, we suggest to identify and classify the role of each stakeholder according to their intensity toward the relationships with requirements. Prioritizing the different rules of stakeholders in requirement engineering have many benefits like right people can be used in the right way to take better decision about their related and most concern field of requirement. The next section presents an overview of related literature that advocate prioritizing stakeholder in prioritization process. In section 3, a brief discussion has been presented to explain the two core elements of the proposed technique. Using these two elements, section 4 presents the calculation of final value of each requirement with the help of pseudo code. Finally the whole discussion has been concluded and future direction has been set. 2. LITERATURE REVIEW The nature of software requirement is multifaceted. A set of requirement may be of less worth from one perspective highest of worth from another perspective [17]. In such a case we should not give equal weight to each view; rather they shall be given worth according to their association. These views can be further linked with different stakeholders or group of stakeholders that shall be prioritized. Giesen and Volker argue that not all stakeholders have same importance. In case of large software projects; a large number of stakeholders have similar number of different view and expectations from the underlying project. They all play their roles to make the project successful. But their different preferences and expectations have high degree of changes to conflict each others views [13]. This phenomenon reveals the fact that requirements have dependencies and correlations between underlying attributes, whose understandability is essential for successful projects. Lehtola et al [12] discussed some challenges in requirements prioritization. It is stated that some customers might not want to prioritize their requirements with the fear that only top most would be entertained by developers. Similarly, developers do not want to disclose that they are not able to

3 implement all the requirements. In some cases, when there are very few strong stakeholders whose wishes are very hard to neglect, it would be hard to prioritize their roles. Other problems like political issues and interdependencies between requirements might also create difficulties in prioritization process for stakeholders. According to Lubars et al. [3], almost none of the companies in their study had sufficient understanding of assigning, modifying, and communicating priorities effectively to other project members. This means that they were mostly expert of one or few specific field and so were not fully capable to assess each requirement exactly. This fact also reveals that the hierarchy of users can assess a hierarchy of requirements. A simple hierarchy of functional users has been illustrated in figure 1. Users at level 1 have breadth knowledge of all requirements then level 2 and level 2 users have broader information then level 3, so on and so forth. There are also some literatures that have identified and discussed different concerns of stakeholders in software requirement engineering. Like Pacheco et al state that each software project may have different types of stakeholders and their appropriate selection has a strong impact on the quality of software requirements [14, 15]. The quality the software project is consequently affected by these requirements. Analyzing the stakeholders preferences in requirement engineering has been addressed in [13] that suggest prioritizing stakeholders in requirement engineering. Moreover, some classification schemes have also been discussed in [10, 11, 16] that can be used as parameters in prioritizing them. 3. STAKEHOLDERS WEIGHTING ELEMENTS A stakeholder may be defined as a person or organization, which influences system s requirements and/or impacted by that system [2]. The stated influence and resultant impact in the definition are the focus interests of this technique. We propose two essential elements to be included when software requirements are to be prioritized by human involvements. These two elements shall be calculated in order to calculate the final priority values of each requirement. The first element is called as Stakeholder Profile Weight (SPW) that is calculated against each stakeholder to assess each individual s weight in the overall project. Second element is Requirement Specific Stakeholder Weight (RSSW) that varies requirement to requirement.

4 A. STAKEHOLDER PROFILE WEIGHT (SPW) 1) Mapping View Parameters on Scale A stakeholder can be associated with a software project in more than one aspect. At the same time, he/she might be end-user, in-directly involved; yet has broader required knowledge to take better decisions to make it successful. But one of the phenomenon in assessing the right opinions of multiperson dependent decision is answering the question, who shall be preferred on whom? One of the best way to answer this question is to find a generalize answer that could be altered according to project requirement. Following this idea, we present multi-role illustration of each stakeholder. In this regard, we searched stakeholder s grouping from different perspectives in the literature and found some good findings. According to Martin and Roel [10], stakeholders can be assigned to a group like critical, major, and minor according to their impact on overall project. Another classification can be of End-users, managers, customers and domain experts [16]. The direct and indirect divisions of Stakeholders can also consider revealing the impact of his/her involvement. Figure 2 presents an illustration of stakeholder from different viewpoints discussed earlier. These are few viewpoints to understand the basic concept and subject to be altered to reflect the project need. Once they are identified, the next step is to map it on a scale ranges from 0 to 1 to rank the importance of each view s parameter. Here parameter is referred to a single value of a viewpoint. The mapping process would be simply an assigning process of each view s parameter to the scale values such that they influence the weight of stakeholder s opinion. In figure 3, we have mapped these parameters to form a simple example. The above mapping has been derived from figure 2 and can be express as shown in table 1. 2) Assessment of hierarchal levels A company s organograms clearly shows the hierarchy of personnel roles with respect to their relationships in rank-wise. This is also a very helpful tool in assessing the quantitative value of each employee regarding their authority. Moreover, it represents the breadth understanding of knowledge about overall organization procedure. In order to calculate the weight of each stakeholder, it is important to include their weights of authority in order to reflect the importance of their decision. The

5 greater authority value is also a factor of greater responsibility and hence more preference shall be given. The other aspect related to this hierarchy is the breadth of functional area the person is looking after. A stakeholder who is one of the last nodes of hierarchy might have narrow view as compare to upper level regarding overall organizational procedures understanding. Considering such a factor becomes important when dealing with requirements that have stakeholders from general to specific domain areas. A domain specialist can better express the value of a given requirement if it is most closed to his/her area. A generalist, on the other hand would express the value of a given requirement in the light of overall project or from organizational view point. Therefore, including this factor will improve the quality of stakeholder s judgments he/she would make about a requirement. In order to imitate the effect of stakeholders hierarchal values of both Overall Understanding and Authority level, we propose a scale shown in figure 4. It consists of two pyramids displaying mirror reflection to each other. The upper opposite pyramid shows the breadth of overall organization knowledge. The top portion of upper pyramid refers to the group of stakeholders having at-least clear abstract understanding of all procedures. They have clear picture about the project and/or about the company. Their understanding is at generic level as compared to the lower levels. The stakeholders at lower levels have comparatively narrow view about overall organization but have broader understanding about some specific domains in organization. The lower pyramid shows the organization s authority level. Stakeholders at upper level have the most limited authority as compare to the lower levels. In this illustration, the number of groups in each pyramid is same that are also subject to be changed. B. REQUIREMENT SPECIFIC STAKEHOLDERS WEIGHT (RSSW) The second essential element of this technique is the calculation of Requirement Specific Stakeholders Weight (RSSW). Its significance has been realized due to the fact: not every requirement is concerned to each stakeholder at the same intensity. Perhaps, there might be some requirements that have no worth

6 to some key stakeholders but have core importance to another group of key stakeholders. Therefore, keeping such scenarios into consideration, we recommend to include the effect of RSSW to reflect the association of each requirement with each stakeholder. A requirement can be associated with a stakeholder using two aspects i.e., Relationship and Distance. 1) Relationship The Relationship depicts the domain area association of a stakeholder with a given requirement. It has strong link with domain area of stakeholders. In order to prevent the negative effect of unconcerned stakeholders opinion, we can use followings weights: Strong: if the requirement lies exactly in the specific domain of a stakeholder. In this case highest weight shall be given in the scale. Dependent: if the requirement is not of stakeholder s specific domain but due to this requirement his/her specific domain requirement may affect. Weak: if the requirement has no concern in the specific domain of a stakeholder. In this case zero or lowest weight shall be given in the scale. 2) Distance The hierarchal nature of organization s functions might lower the role of RSSW, if we use Relationship factor without Distance factor. People at the lowest nodes of hierarchy might have strong depth knowledge compared to the upper ones. Therefore their distance shall be calculated from the specific domain. This can be calculated by just considering the grade level. 4. PRIORITIZING STAKEHOLDER BY SPW & RSSW At the point when we have assessed the weight property of stakeholder role, it is time to evaluate the weight of each stakeholder. The evaluation procedure is just mapping the stakeholders against the scales and aggregating the figures that will be the weights of each stakeholder referred as SPW. In figure 5, we have illustrated a simple example of evaluating the SPWs of three stakeholders. There are three scales used in this example i.e., Viewpoint parameters, Overall Understanding (of all requirements) and Authority level. All of these scales are in range 0 to 1. We have mapped each

7 stakeholder against each of these three scales one by one according to their related attributes. The strong relation has been referred a value more closely to 1 and 0 to represent weaker association. The aggregated value of each stakeholder i.e., SPW has been calculated by adding the association value of each mapping value (represented by arrows). This final value shall be referred by SPW and express the quantitative value of each stakeholder opinion with respect to their role. We can also use SPWs to prioritize the stakeholders in this way. But this prioritization shall be at overall project level not necessarily on each requirement level. Our proposed approach suggests to calculate the priority value of each record on both elements i.e., SPW and RSSW. Therefore, next we calculate RSSW using SPW. As discussed earlier in previous sections that not all requirements have same significance for each stakeholder and hence they shall be associated with a stakeholder using two aspects i.e., Relationship and Distance. We have also discussed their significance in detail in previous sections. Regarding their calculation toward evaluating final priority values; we propose to use a simple template like a one presented in figure 6. It contains four parts 1) Stakeholder role (can be either name or ID) along with his/her SPW value. 2) Description of each requirement that can is required to be prioritized, 3) A value column for each requirement where the stakeholder is supposed to write a value based on a given scale and 4) RSSW based fields so that we can calculate the final priority. The calculation of final priority value for can be obtained by finding the average of each requirement s suggested values regarding stakeholders opinion. Elements SPW and RSSW are added up and multiplied by the given value such that it increase its frequency. The result of this manipulation is divided by number stakeholders to find the final value. Using this value all requirements can be prioritized. For simplicity; the following pseudo-code is presented to understand and calculate of final priority values of each requirement.

8 Stakeholder={S 1,S 2,..,S m } Requirement={R 1,R 2,..,R n } for r=1 to n for s=1 to m W= W + Requirement[r][s].Value (Stakeholder[s].SPW + Requirement[r][s].RSSW) * Requirement[r][s].Value AvgPriority[r]= W/m 5. CONCLUSION AND FUTURE WORK In this paper we highlighted the significance of prioritizing stakeholder roles in software requirement prioritization. Different aspects of a stakeholder have been discussed and their impact has been discussed on final priority values. Two main elements were identified to prioritize software requirements based on stakeholders i.e., Stakeholder Profile Weight (SPW) and Requirement Specific Stakeholder Weight (RSSW). SPW is used to calculate the overall weight of each individual while RSSW is calculated for each requirement using SPW. REFERENCES [1] A. Aurm, Engineering and maangeing software requirements. Springer. [2] IEEE Std , Standard Glossary of Software Engineering Terminology, IEEE Press, [3] Lubars, M., Potts, C., Richter, C.: A review of the state of the practice in requirements modelling. In: Proceedings of IEEE Symposium on Requirements Engineering (RE 93), IEEE Computer Society Press (1993) [4] Karlsson, J., Ryan, K.: A cost-value approach for prioritizing requirements. IEEE Software 14 (1997) [5] Aurum, A., Wohlin, C.: The fundamental nature of requirements engineering activities as a decisionmaking process. Information and Software Technology 45 (2003) [6] J. Karlsson, "Software Requirements Prioritizing", Proceedings of the 2nd International Conference on Requirements Engineering (ICRE'96), 1996, pp

9 [7] A. Ahl, "An Experimental Comparison of Five Prioritization Techniques - Investigating Ease of Use,Accuracy, and Scalability", Master Thesis No. MSE , BTH, [8] S. Jenny, Early Requirements Prioritization Technique (best practice white paper).version 1, December 2008 [9] L. Lehtola and K. Marjo. Suitability of requirements prioritization methods for market-driven software product development, John Wiley & Sons, Ltd.2006 [10] G. Martin and W. J. Roel, Guest Editors' Introduction: Stakeholders in Requirements Engineering, IEEE Software, March 2007,v.24 n.2, p [11] Davis, A., M. The Art of Requirements Triage, IEEE Computer, 2003, 36(3), pp [12] Lehtola, L., Kauppinen, M., and Kujala, S. (2004): Requirements Prioritization Challenges in Practice'. Proceedings of 5th International Conference on Product Focused Software Process Improvement, pp [13] Giesen J. and Volker A. Requirements Interdependencies and Stakeholders Preferences, Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE 02) [14] Pacheco, Carla Garcia, Ivan, Effectiveness of Stakeholder Identification Methods in Requirements Elicitation: Experimental Results Derived from a Methodical Review. Eight IEEE/ACIS International Conference on Computer and Information Science 2009 [15] Pacheco, Carla & Garcia, Ivan. Stakeholder Identification Methods in Software Requirements: Empirical Findings Derived from a Systematic Review [16] Kotonya, G. and Sommerville, I. (1998) Requirements Engineering: processes and techniques. John Wiley. [17] Aasem, M, Ramzan M, Jaffar, I, Multi Faceted Requirements Classifications for Prioritization.

10 Figures and Tables Figure 1. Hierarchy of functional users Figure 2. Different concerns of a stakeholder in a project Internal External Direct user Indirect user Involved in Development Not Involved in Development Decision makers Domain Experts Managers End-Users Customers Baseline Satellite Supplier Critical Major Minor

11 Figure 3. A mapping example of SPW Table 1. Tabular illustration of SPW Viewpoint Parameter Scale value Viewpoint 1 Decision makers 0.9 Domain Experts 0.8 Managers 0.7 End-Users 0.4 Customers 0.2 Viewpoint 2 Viewpoint 3 Direct user 0.5 Indirect user 0.3 Internal 0.5 External 0.3 Viewpoint Involved in Development

12 Figure 4. The levels of hierarchy mapped on scales

13 Figure 6. Assessment Of Requirements Specific Stakeholder Weight (RSSW)