2010 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises
Supporting the Requirements Prioritization Process Using Social Network Analysis Techniques Ilias Κ. Savvas
Panos Fitsilis, Vassilis Gerogiannis, Leonidas Anthopoulos
Computer Science and Telecommunication Department, TEI Larissa, 41110 Greece.
[email protected]
Project Management Department, TEI Larissa, 41110 Greece {fitsilis, gerogian, lanthopo}@teilar.gr
Abstract — Requirements management and prioritization is a complex process that should take into account requirements value for customers, cost of implementation, available resources, requirements interdependencies, system architecture and dependencies to the code base. In this paper we present how Social Network Analysis can be used in order to improve software requirements management and the prioritization process. The presented model is based on meta-networks where basic entities are combined for representing requirements priorities, interdependencies, required knowledge, etc. The analysis of the model is illustrated with sample data and a number of examples. Keywords-requirements management, prioritazation, social networking
requirements are implemented correctly, to ensure the project communication is smooth and therefore requirements are well understood and defined, to secure that resources are of the appropriate level, etc. Social Network Analysis (SNA) is a powerful tool that provides the means for analyzing informal networks [4]. The key benefit of an SNA is the ability to visualize networks and manipulate these visualizations in real-time. In the context of project management, SNA can act as a diagnostic gap-analysis tool for social networks in organizations. Broadly speaking, the benefits of interventions based on SNA include: a) the determination of the optimal set of requirements to be implemented in specific releases; b) the facilitation of communication between project stakeholders and c) the improvement of software release planning.
requirements
I. INTRODUCTION Requirements management is a process of systematically eliciting, organizing, and documenting requirements for a complex system [1]. The whole process becomes even more complex in iterative and incremental software development life cycles [2, 3] since software systems today are not delivered in a monolithic fashion at the end of a long development process but in small releases that are implemented sequentially.
The main objective of this paper is to analyze the required collaboration/knowledge within the requirements and analysis project team (including clients, managers, analysts, developers etc.) in order to efficiently/effectively prioritize the requirements through the identification of the proper requirements prioritization technique. The structure of this paper is as follows: section II introduces the relevant literature background, section III presents the proposed approach though examining its application in a set of problems-cases. The results of this analysis are presented in section IV. Conclusions and extensions of the research work are addressed in section V.
The process of requirements selection to be included in a particular increment-release, is complex and difficult since it involves a number of different planning parameters such as available resources, available know-how, delivery time, dependencies between requirements and dependencies due to architecture and existing code base, marketing priorities etc. As such, the requirements management process is a core project management process that affects directly the scope, the schedule, the budget and the quality of each software process.
II.
Traditionally, software projects are analyzed, controlled and monitored by controlling respectively project scope, time, cost and quality. A large number of techniques, methods and tools are available in the literature, concerning how to control projects, identify potential risks, improve performance, etc. However, this is not sufficient, since software project management is a process that relies heavily on knowledge and teamwork. Therefore, we need to be able to provide solutions to a set of different problems such as: to make sure that the knowledge is available in the project team, and therefore the 978-0-7695-4063-4/10 $26.00 © 2010 IEEE DOI 10.1109/WETICE.2010.24
RELATED WORK
According to Leffingwell and Widrig [1] a requirement is a software capability that must be met or possessed by a system or system component to satisfy a contract, a standard, a specification, or other formally imposed documentation, while requirements management is “a systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system”. Requirements usually create hierarchies and interdependencies. Carlshamre et al. [5, 6] defined five different requirements interdependencies types. These types are structured in a network making the process of requirements 110
The pair-wise comparison method is based on the Analytical Hierarchy Process (AHP) as developed by Saaty [13]. In AHP, each element (requirement) is compared with all other elements (requirements), using a scale from one to nine, where one represents equal importance and nine represents extreme preference, for defining their relative importance. These judgments are quantified and calculated so that when synthesized, they reveal the best choice. Eigen values vectors are used to control the judgments’ consistency.
management even more difficult to handle. These six interdependencies as defined by Carlshamre et al. are: AND: r1 AND r2 implies that requirement r1 requires r2 and r2 requires r1 or all requirements should be implemented simultaneously, REQUIRES: r1 REQUIRES r2 denotes that requirement r1 requires r2, but not the opposite,
Pair-wise comparisons is a prioritization method which is a relatively simple and straight forward, however the number of comparisons increases substantially when the number of requirements increases. If there are n requirements to prioritize, the total number of comparisons to perform is equal to n(n-1)/ 2 [14]. The method is also known as Cost-Value Approach [12].
TEMPORAL: r1 TEMPORAL r2 r2,
defines that requirement r1 should be implemented before CVALUE: r1 CVALUE r2
which means that implementation of requirement r1 affects the value of r2 as perceived by end customer,
The Planning Game (PG) technique is a fundamental part of each Extreme Programming (XP) project [11]. In XP development the PG is divided into two parts: a) release planning which is focused on selection of requirements to be implemented; and b) iteration planning in which the tasks to be executed are defined, for each iteration.
ICOST: r1 ICOST r2 implementation of requirement r1 increases the cost for implementing requirement r2 OR:
r1 OR r2
In PG, the release planning process [11] consists of three phases: exploration, commitment and steering. In exploration phase, the requirements are written using story cards and an estimate on the effort required for their implementation is produced. In commitment phase, requirements are evaluated according to their business value, their potential risk and their impact on project schedule. Initially, they are prioritized according to the business value they have into three different stacks: (a) requirements mandatory for the functioning of the system (b) requirements not mandatory but delivering essential for business functionality and (c) the “nice to have” requirements. Secondly, requirements (user stories) are sorted according to the risk they exhibit for the project again in three piles, called “low”, “medium” and “high” risk. The calculation of the risk category is based on their completeness, volatility and complexity. Finally, user stories are evaluated from the development team, in order to determine the velocity, how fast user stories can be implemented. In steering phase, the release is finalized so the PG can continue with iteration planning.
at least one of the requirements r1, r2 should be implemented. Although, the above model describes requirements interdependencies in detail, not all interdependencies have the same value. For example, AND and REQUIRES interdependencies must be satisfied, otherwise the system will be dysfunctional. This is due to the fact that, AND, REQUIRES and OR describe structural constraints of the system. Similarly, the interdependency TEMPORAL describes a project constraint that should be taken into account during release planning. On the edge, it is cumbersome and in many cases difficult to define CVALUE and ICOST for all requirements pairs. In reality, it is much more practical each project stakeholder to define a priority for each requirement, instead defining CVALUE and ICOST. Dahlstedt, and Persson [7] distinguish interdependencies in those that classify structural dependencies such as “requires”, “influences”, etc. and in cost/value interdependencies such as CVALUE and ICOST. An overview of requirements interdependencies is given in [8].
MoSCoW is an acronym used to represent four priority groups for requirements [26]. Each requirement is classified either as “MUST have”, or as “SHOULD have” or as “COULD have” or as “WON'T have”.
Requirements prioritization is the decision process of defining relative priorities of the requested requirements [9]. The selection of the proper requirements based on priorities, for a software release, increases the value of software delivered to end customers/users but it does not secure the optimal resource allocation, neither satisfies budget constraints.
In the “Hundred Dollar Method”, each user is receiving one hundred dollars to be spent on purchasing requirements. Based on these user preferences, the priority of each requirement is calculated [27]. The above discussion shows that requirements prioritization takes into account: value for customers, cost of implementation, available resources and requirements interdependencies. Furthermore, it should take into account system architecture and dependencies to the code base. Additionally, this analysis should consider the required collaboration/knowledge within the requirements and analysis project team (including clients, managers, analysts, developers
A number of techniques has been developed for the optimal selection of requirements: others focused on the absolute importance of each requirement, others focused on relative importance based on user experience. Among these techniques the most known are: pairwise comparisons [10, 12], planning game [11], MoSCoW [26] and Hundred Dollar Method [27].
111
etc.) in order requirements.
to
efficiently/effectively
prioritize
represents the necessary knowledge, for implementing a specific tasks. Even though employees working in a project are as well stakeholders, deciding on which requirements to implement, we have decided to introduce the class named Employee as a different entity than Stakeholders, for representing the human resources working on a project
the
Social Network Analysis (SNA) techniques can be used for handling the problem of prioritization of the requirements, since requirements management resembles in various aspects a social network, e.g. requirements form a network of interdependencies which are changing over time, or for selecting the requirements a group of stakeholders are interacting for taking a group decision.
These classes present numerous possibilities to represent various types of relationships e.g. employees that have worked with another employees in a project or an employee that has worked on similar requirements and therefore has relevant know-how etc., which complements the requirements prioritization process.
Therefore, SNA techniques can be applied on release planning for the selection of the optimal number of requirements to be implemented in each release by applying simple SNA metrics. Furthermore, the same model can be used for a) collaboration analysis (coordination, communication and cooperation) within the project team, especially within the group responsible for requirements management [15], b) selecting team members taking into account their know-how [16, 17, 18], c) improving the resources utilization throughout the project [20], and d) managing project risks related with requirements management [19, 28, 29].
Project
Agent
Knowledge
The whole process can be facilitated by the application of SNA software, which automates the whole procedure. III.
Tasks
Requirements Release Planning Model
Stakeholder
MODELING SOFTWARE REQUIREMENTS RELEASE
Release
Requirement
Figure 1. Model Dimensions
PLANNING
In our model, we have defined seven major classes for modeling the aspects of software requirements release planning problem (see Figure1): Project, Task, Release, Requirement, Stakeholder, Agent and Knowledge. It is possible, to elaborate the model by defining more classes, more concepts for our model, but for demonstrating the proposed concept these are sufficient since they can represent sufficiently the main parameters of software release planning. In Figure 2, we present the UML class model for software requirements release planning. In this model, class Project defines the Project under study. A project includes one or more (1..*) releases and defines at least one task. In case that, there is just one release, the model represents a traditional, old-fashioned waterfalllike lifecycle. Iterative and agile projects usually implement more than one releases. Stakeholders assign priorities to requirements in order to define the mandatory, the essential and the “good to have” requirements. For each release, we select a number of requirements by using a number of prioritization criteria. Instances of class Requirement are related to each other by defining interdependencies. This is modeled with association class Interdependency, which defines a hierarchy of interdependencies (structural or cost/value type). Instances of class Stakeholder prioritize each requirement. Further, Class Task defines which tasks have to be executed for the specific project.
Figure 2. Model Dimensions
Furthermore, the above described classes provide a generic yet powerful model for the identification of various aspects of an organization, since the links between different class entities can give answers to a variety of questions. Table I, presents the different questions that can be answered by combining instances of this model. For example, the matrix having as rows and columns employees can answer to the question who has worked with whom at past projects, or the matrix of requirements can be used to define the requirements interdependencies. For empty cells, we cannot derive a useful question or a metric in the context of this study.
A number of employees/agents, representing resources, are working for implementing relevant tasks (i.e., requirements elicitation, prioritization, assignment of requirements to releases, etc.). The class Knowledge
112
TABLE I.
Employees
Employees
Stakeholders
Knowledge
Requirements
Projects
Releases
Tasks
Enterprise Network.
Business Network
Knowledge Network.
Knowledge Network.
Assignment Network.
Assignment Network.
Assignment Network.
a) Who works with whom?
Knowledge of application domain
What knowledge is available within organization?
a)
Knowledge with implementatio n of similar requirements
Who is working on which project?
Who is working on which release?
Who is working on which task?
b)
Who is implementing which requirement?
b) Defines Team Structure
Stakeholders
Knowledge
SHOWING NETWORKS OF RELATIONS CONNECTING CLASSES
What knowledge is required by application domain?
Release planning
Knowledge relationships (e.g. prerequisites)
What knowledge is needed for implementing the requirement?
What knowledge is needed for project?
What knowledge is needed for implementing release?
What knowledge is needed for executing task?
Which are the requirements’ interdependencies?
What are the project requirements?
Which are the requirements included in the release?
Which are the requirements implemented by task?
Requirements
Prioritization of requirements
Projects
Defines project cycle
Tasks
life
CPM/ PERT Dependencies between teaks
IV.
it offers data import functionalities for projects’ manually modeling or for automatic creation of the required metamatrix; it is well documented, since a large number of application cases is publicly available.
USE OF SOCIAL NETWORK ANALYSIS TECHNIQUES
In this section we demonstrate with a number of examples, illustrating the usage of SNA in the context of requirements prioritization. More specifically, we will demonstrate how requirements can be selected
In order, to analyze project information in our testing case we used the ORA (Organization Risk Analyzer), a method which was developed by K.M. Carley, at the Center for Computational Analysis of Social and Organizational Systems (CASOS), Carnegie Mellon University [19, 20].
Concerning the selection of requirements according to stakeholders priorities and requirements interdependencies, we have defined a set of twenty requirements R={R1, R2, …, R20}, and a set of five different stakeholders S={S1, S2, S3, S4, S5}. Each stakeholder has evaluated each requirement with a scale from one to three, according to the classification used in PG, where the “must have” requirement is ranked with three, the “should have” is ranked with two and the “could have” is ranked with one. When a stakeholder ranks a requirement with zero implies that the stakeholder does not have any opinion concerning this specific requirement. This relationship has been modeled in the matrix R x S.
The ORA was selected among a number of available tools (# Net, Pajek, GUESS, etc.) [24], because it is publicly available; it implements a large number of algorithms for networks measurement; it is accompanied with lots of reports;
Respectively, we represent the AND and REQUIRES interdependencies with a matrix named Req AND Req. This matrix accepts binary data. If cell Rij = true and cell Rji = true, then we have an AND dependency. If cell Rij = true and cell
a)
according to stakeholders priorities and requirements interdependencies, and
b) according to team knowledge/skills and to team members’ previous collaboration.
113
Rji = false or vice-versa then, it is a REQUIRES dependency. In Figure 3, the matrix Req x Stakeholder is presented showing the result of prioritization process.
Figure 3. Matrix representation using ORA
Figure 5. Calculation of cliques using R1 AND R2 interdependencies
With priorities in a tabular form we can easily calculate which requirements have higher priorities so that they can be implemented first. Figure 3 shows all links with priority “must have”.
The number of measures that can be applied in our analysis is extensive, deriving either from social analysis [21] or from graph theory [22, 23]. For example, we can calculate the total degree centrality of each requirement, which is the requirement related closely to other requirements. In our example, Requirement 10 has the highest centrality since it is required mostly by other requirements. In Table II, we present standard SNA measures that can be applied on requirements analysis. In this table, betweenness centrality is defined as a requirement as being in a favored position to the extent that the requirement falls on the geodesic paths between other pairs of requirements in the network. That means, the more requirements depend on it to make connections with other requirements, the more important this requirement is. Closeness centrality emphasizes on the distance of a requirement to all others in the network by focusing on the distance from each requirement to all others. TABLE II.
Figure 4. Links between stakeholders and requirements
Similarly, we can calculate the fully-connected sub-graphs of the requirements matrix. The fully-connected sub-graph defines a clique of requirements, or a n-clique. A n-clique is a clique where a requirement is a member if they are connected to every other member of the group at a distance less than n. Figure 5 presents the calculation of 3-cliques using R1 AND R2 interdependencies.
RANKING OF REQUIREMENTS USING SNA MEASURES
Rank
Betweenness centrality
Closeness centrality
In-degree centrality
1 2 3 4 5 6 7 8 9 10
R_10 R_9 R_3 R_15 R_4 R_2 R_8 R_19 R_1 R_5
R_10 R_9 R_4 R_15 R_3 R_11 R_6 R_12 R_13 R_14
R_10 R_9 R_19 R_2 R_3 R_5 R_8 R_14 R_20 R_4
Outdegree centrality R_10 R_9 R_3 R_15 R_4 R_11 R_1 R_2 R_6 R_7
Total degree centrality R_10 R_9 R_3 R_15 R_19 R_2 R_4 R_8 R_11 R_14
Similar analysis can be done with the available knowledge per employee using matrix Employee x Knowledge or knowledge required per task using the matrix Task x Knowledge, This matrix is produced by matrix multiplication: [Task x Employee] x [Employee x Knowledge] = [Task x Knowledge]. An example of calculation of knowledge centrality for employees and tasks is given in Figure 6.
114
International Workshop on requirements engineering- foundation for software quality, 2003. [8] A. Dahlstedt, and A. Persson, “An Overview of Requirements Interdependency Types,” http://www.ida.his.se/ida/~asa/ReqInterdependencies.pdf [9] K. Wiegers, Software requirements. Microsoft Press, Redmond, 1999. [10] T.L. Saaty, and L.G. Vargas, Models, methods, concepts & applications of the analytic hierarchy process. Kluwer Academic Publishers, Norwell, MA, 2001. [11] K. Beck, Extreme programming explained. Addison-Wesley, Reading, MA, 1999. [12] J. Karlsson, and K. Ryan, “Prioritizing Requirements Using a CostValue Approach,” IEEE Software: 67-74, 1999. [13] T.L. Saaty, The Analytic Hierarchy Process: Planning, Priority Setting, Resource Allocation. McGraw-Hill: Pittsburgh, 1980. [14] L. Karlsson, T. Thelin, B. Regnell, P. Berander, and C. Wohlin, “Pairwise comparisons versus planning game partitioning—experiments on requirements prioritisation techniques,” Empir. Software Eng. 12:3–33, 2007. [15] S. Pereira, and A. L. Soares, “Improving the quality of collaboration requirements for information management through social networks analysis”, Int. J. of Information Management, 27(2), 86–103, 2007. [16] H. Wi, S. Oh, J. Mun, and M. Jung, “A team formation model based on knowledge and collaboration”, Expert Systems with Applications. Vol. 36, 9121–9134, 2009. [17] H.L. Yang and J.H. Tang, “Team structure and team performance in IS development: a social network perspective”, Information & Management 41(3): 335–349, 2004. [18] R. Regans, E. Zuckerman, and B. McEvily, “How to make the team: social network demography as criteria for designing effective teams”, Administrative Science Quarterly, 49(1):101–25, 2004 [19] K.M. Carley and J. Reminga, “ORA: Organization Risk Analyzer”, Technical Report, CMU-ISRI-04-106, Carnegie Mellon University. Available at: http://www.casos.cs.cmu.edu/publications/ papers/carley_2004_oraorganizationrisk.pdf. [20] K.M. Carley, “Summary of Key Network Measures for Characterizing Organizational Architectures”, Technical Report, Carnegie Mellon University. Available at:. http://www.casos.cs.cmu.edu/ publications/papers/reminga_2003_ora.pdf [21] M.Uhl-Bien and R. Marion (eds), Complexity Leadership. Part I: Conceptual Foundations, Information Age Publishing Inc., 2008. [22] E. D. Kolaczyk, Statistical Analysis of Network Data Methods and Models, Springer Series in Statistics, 2009. [23] R. A. Hanneman and M. Riddle, Introduction to Social Network Methods, University of California, Riverside, 2005. [24] Social network analysis software. Available at http://en.wikipedia.org/wiki/Social_network_analysis_software [25] R Cross, SP Borgatti, A Parker, “Making invisible work visible: Using social network analysis to support strategic collaboration”, California Management Review, 2002. Available at: https://webapp.comm.virginia.edu/networkroundtable/portals/0/ making_invisible_work_visible.pdf [26] D. Tudor, and G. A. Walter, “Using an Agile Approach in a Large, Traditional Organisation” Proceedings of AGILE 2006 Conference (AGILE’06). pp 367 -373. 2006. [27] A. M. Davis, Just Enough Requirement Management, Where Software Development Meets Marketing Dorset House Publishing Company Incorporated New York USA, 2005. [28] P.A.Nielsen, and G.Tjørnehøj, “Social networks in software process improvement”, J. Softw. Maint. Evol.: Res. Pract. 2010; 22:33–51. [29] S. Marczak, D. Damian, U. Stege, and A. Schröter, “Information Brokers in Requirement-Dependency Social Networks”, 16th IEEE International Requirements Engineering Conference, Barcelona, Spain 2008.
Figure 6. Calculation of knowledge centrality for employees and tasks
V.
CONCLUSIONS AND FURTHER WORK
In this paper, we presented how social network analysis can be used in order to improve the process of software requirements management. The introduced model is based on meta-networks where basic entities are combined for prioritizing requirements, for defining subsets and groups of requirement whose implementation is connected and as well examples on managing the required knowledge. The analysis of the model has been illustrated briefly with sample data. However, this is practically not sufficient since the requirements are changing over time, along with their interdependencies and the required knowledge. For these reasons, we need to study further how requirements evolve over time and to determine a standard set of measures that optimally describe the characteristics and the status of requirements management process. VI.
REFERENCES
[1] D. Leffingwell and D. Widrig, Managing Software Requirements - A [2]
[3] [4] [5]
[6]
[7]
Unified Approach, Addison Wesley, 2003. P. Jalote, A. Palit, P. Kurien, V.T. Peethamber, “Timeboxing: a Process Model for Iterative Software Development”, Journal of Systems & Software, 70(1-2), 117-127. Beck, K., Extreme Programming Explained, Addison-Wesley, 2000. S. Wasserman and K. Faust, Social Network Analysis: Methods and Applications, Cambridge: UK, Cambridge University Press, 1994. P. Carlshamre, K. Sandahl, M. Lindvall, B. Regnell, J. Natt och Dag, “An Industrial Survey of Requirements Interdependencies in Software Product Release Planning”, Fifth International Symposium on Requirements Engineering, pp. 27-31, Toronto, Canada, August 2001. J. Karlsson, S. Olsson, and K. Ryan, “Improved Practical Support for Large-scale Requirements Prioritising,” Requirements Engineering Journal, 2(1):51-60, 1997. A. Dahlstedt, and A. Persson, “Requirements Interdependencies Moulding the State of Research into a Research Agenda”, 9th
115
