Determining Interdependency Among Non-functional ...

Determining Interdependency Among Non-functional Requirements to Reduce Conflict Mirza Rehenuma Tabassum, Md. Saeed Siddik, Mohammad Shoyaib, Shah Mostafa Khaled Institute of Information Technology University of Dhaka Email: [email protected], [email protected], [email protected], [email protected]

Abstract—Dependency among non-functional requirements (NFRs) is one of the major issues to handle for delivering quality software. These dependency relations are the reasons of conflict, though there are also relations where one NFR help to ensure another NFR. Interdependence relations, not treated from the beginning of a software development, may cause requirement dismissal in the later phases of development. To solve those issues, interdependencies among NFRs have been determined. A framework has been proposed to deal with interdependent NFRs from the early stages of development project. The proposed NFR interdependency framework keeps the NFRs with the functional requirements they are associated with which helps to design the system without leaving the NFRs for later stages of development. A case study is done with the proposed framework. Dealing the interdependence relation among NFRs using the framework reduces the chance of conflict and help to design the software with better management of NFRs.

I. I NTRODUCTION Requirement engineering is a very important phase of a software development. It is becoming the key to success for a software system as complexity of industry and consumer software is increasing [1], [2]. While functional requirements define what the system will do, NFRs state how the system will do. For example, a system’s performance, security, reliability, scalability, fault-tolerance, etc [3] are known as NFRs. Beside treating functional requirements, the focus is shifting towards NFRs which are also known as quality requirements and they are considered as quality factors [4]. NFR plays a critical role in software systems [5]. Ineffectively dealing with them can lead a software product to failure [6], [7]. NFRs should be dealt from the very first phase of a software development [3], [8], [9]. NFRs are very expensive and difficult to deal with [9], [10], [11]. The nature of NFRs to conflict, contradict and interfere with themselves made them more complex [12]. Interdependency is the reason behind this nature of NFRs. Thus, understanding interdependency among NFRs is very important [2]. Interdependency causes conflict as well as cooperation among NFRs. Because of interdependency, implementing a NFR can hurt to achieve another NFRs [3], [13]. It is not always the case where interdependency raises conflict, interdependency between two NFRs can help each other too. Earlier, the NFR Framework used softgoal interdependency graph (SIG) [3], [14] to show interdependencies among NFRs. SIG is limited to two types of interdependencies, but research shows that they can be of seven types [2].

Although interdependencies are important characteristic of NFRs, they are not dealt seriously in industry. Many software company do not elicit, analyze or document interdependencies among NFRs and some other companies manage this interdependency at a later stage of design [2]. However, not dealing with interdependencies at an early stage of software development may lead to the necessity of total software redesign [13]. Despite this situation, interdependencies among NFRs have received very little attention in the literature [3]. Several researches have addressed relation between two NFRs [15], [16], [17], but no study could be found describing combinatorial interdependency among NFRs with all seven types of interdependence relations. Interdependency relation among various NFRs are one of the hurdles in developing quality software, because those relationships may create dispute in requirements. Recently two types of interdependence relation have been used to relate NFRs in software industry [31]. However it is difficult to manage all variation of relationship among NFRs. These relations cannot measure the underlying dependence of NFRs, it defines the positive and negative relation of interdependence relation. However recently six types of interdependencies have been proposed by [18], and another one type of interdependency has been introduced with previously mentioned six types in [2]. To the best of the authors’ knowledge, these seven types of interdependencies are not used to show combinatorial dependency relation among NFRs yet. This paper introduces interdependence relation among important NFRs and proposes a framework to determine interdependency among NFRs using these seven types of relation to reduce conflict. This proposed approach can reduce time of software development life cycle, cost of production, and increase chance of fulfilling all NFRs. The focus of this paper is thus two folds: firstly, determine interdependencies of important NFRs, and secondly proposing a framework to show these interdependencies. These two ideas result in several advantages situation for software development. Identification of interdependency can lead to proper design of software. It gives designer a clear view of interdependent NFRs before starting design. It is easy to understand how the NFRs are related from an interdependency graph. The proposed framework can help software designers, developers, and project managers to decide which of the NFRs

have to be implemented and how all the NFRs should be treated having their interdependence relation into account. It will help to incorporate NFRs at the early stages of software design which will reduce development time and effort. Using this framework, interdependencies of NFR can be managed easily from the first phase, it will reduce the conflict and increase the chance of achieving desired software quality. Thus proposed framework improves on the limitation of the NFR Framework’s SIG [3], [14] which does not consider seven types of interdependence [31] relation among NFRs. The rest of the paper is organized as follows: Section II presents related work and background. Section III discusses determined interdependencies among NFRs. Section IV proposes the new framework. A case study is to validate the proposed framework in section V. II. R ELATED W ORK AND BACKGROUND Managing and minimizing conflicts among NFRs have become a major concern. Several studies have been performed to manage NFRs conflict. Svensson et al. performed a study to find out the real scenario of NFRs in industrial practice [2]. They conducted an interview to study the most important quality aspects in software industry, their relation to interdependencies, and cost estimation of NFRs. They reported seven types of different interdependencies among requirements. They make managing and implementing quality requirements harder. For those interdependencies, not all the quality requirements are fulfilled in a software product and many of them dismissed from project during development. In the worst 41% quality requirements are dismissed at some stage prior to release [2]. Mairiza et al. studied conflicting NFRs and proposed a framework [12]. They claimed that understanding nature of complex relationship among NFRs and developing techniques to resolve that are the main challenges to manage conflicting NFRs. They summarized some techniques of identifying, analyzing and resolving conflicts from previous works. However, they did not mention any interdependency type or relationship among NFRs, which are important factors behind conflict. Brian A. Nixon proposed a systematic approach to manage performance requirement [19]. He proposed a Performance Requirement Framework based on the NFR Framework [20]. That framework has been used to manage performance requirements of an information system. The framework integrated knowledge of information system and performance from the perspective of software performance engineering. It is one of the most popular frameworks for NFRs to solely work on managing performance requirements. But it only works with performance requirements, not all the NFRs. Boehm et al. claimed that two measures must be taken to resolve quality requirement conflicts [21]. Finding out and negotiating quality requirements conflicts as well as trade offs is one of them. Based on the early information, quality requirements conflicts have to be diagnosed. Early information like detecting interdependency relation before implementing the requirements can reduce conflict and dismissal of NFRs.

This paper intends to provide information about conflicting NFRs at an early stage of a project. A. Interdependence Relation NFRs often depend on each other and their relation can affect software quality. NFRs tend to conflict, interfere and contradict with one another [12]. It is difficult to deal with interdependency as the way requirements are related, can be very complex [18]. Determining the set of requirements which can be implemented for most benefit is hard when they interact with one another [22]. Managing NFRs greatly depends on managing their interdependency relation. Various techniques have been developed to manage conflicts among software requirements though very few of them are solely focused on NFRs. The NFR framework [20] is the state of art for dealing with NFRs. NFR framework is based on positive and negative relationship between NFRs. There can be some other types of relation among NFRs. Those dependency relation can bring conflict and affect the design of the software system. NFRs can influence architectural pattern, implementation strategies even technological platform of developing a system [23]. Without dealing the NFR interdependencies at an early phase of developing a software system, overall design may need to be changed [13]. B. Types of Interdependencies NFRs can be interdependent in various ways. Charlshamre et al. identified six different kinds of interdependencies which are currently present in software industry based on interviews with requirement engineers [18] : 1) REQUIRES : When one requirement needs another requirement to function, it is called the REQUIRES relation. If there are requirements R1 and R2, R1 REQUIRES R2 is a relation where R2 has to be implemented for R1 to be functioning. 2) AND : If there are two requirements R1 and R2, those are dependent on each other, then it is AND relation. 3) TEMPORAL : If there are two requirements where one should be implemented before another, it is called TEMPORAL relation. For two requirements R1 and R2, either R1 has to be implemented before R2 or vice versa. 4) ICOST : It is dependency related to implementation cost. R1 ICOST R2 means R1 affects the cost of implementing R2. 5) CVALUE : This interdependence associate to value of customer. If R1 affects the value of R2, for a customer, then it is a CVALUE type interdependency. 6) OR : For two requirements R1 and R2, if implementing any of them can meet the purpose of the other, it is OR relation. Another relation is found in [2] which is named as TXOR. TXOR is a interdependency type concerned with time constraint. When there are two requirements where either one cannot be implemented due to time constraint. Any of the mentioned relation can be existed between two requirements.

= Unit Operation (Functional Requirement) = Non-functiona Requirement C I R

+

Fig. 1.

= CVALUE = ICOST = REQUIRES = Negative Relation = Positive Relation Symbols used in this paper

However, more then one relation can remain between two requirements [18]. Establishing relation among NFRs with the mentioned interdependency types are not found by the authors in literature till now. It is not enough to work with only positive and negative relationship where seven new types of interdependencies are found. This research studied relation among important NFRs with new seven types of interdependence relation and performed a case study. III. D ETERMINED I NTERDEPENDENCIES A MONG NFR S Interdependency can exist between two different types of NFRs or between two same type of NFR. One performance requirement can be interdependent with another performance requirement or another usability requirement. It is difficult to generalize the interdependency relation among NFRs as they tend to show different type of interdependence relation in different software systems. This research determined interdependencies among important NFRs for general situation. Showing interdependence relation among different NFRs is very necessary as their interdependency effect all over software quality. Most of NFR interdependencies are drawn from a specific scenario [24], [25] or specific project. Generalized interdependence relation should be analyzed as it can help to take a decision easily while building a project. This study aims to find the interdependence relation among most of the NFRs which will give a view of interdependency among significant NFRs. Symbols used in this paper and their meaning are given in Fig. 1. Fig. 2 shows an interdependency graph of NFRs. Determined interdependence relations are discussed in the following points. Performance vs. Scalability: Performance and scalability are two major quality concern of a software system. Scalability of a software is a quality requirement which characterize the ability of that software to satisfy quality goals for example performance, throughput etc. while characteristics of execution environment vary over an expected range [26]. Performance of a software is interdependent with scalability of a software. In general they are negatively related. High scalability of software may significantly degrade its performance. Performance of a software not only proportional to the peak speed of the

system being used, it also depends on scalability [16]. Scaling up or scaling down a system affects it’s performance. If the system needs to be scalable with the same set of performance requirements, cost of implementing the system will increase. This type of relation is placed under the interdependency type ICOST. It can be shown as scalability ICOST performance. As two requirements may have more than one type of dependency [18], other type of interdependency may found. Performance vs. Usability : Performance and usability requirements are interdependent. Customers value this two NFRs most [2] and one of this requirement brings value for the other one. Performance and usability has CVALUE relation. Researchers found that better usability delivers the highest performance [27], [25]. Usability often measured with how many tasks can be done in a unit time which is also a criteria to measure performance [29]. It indicates that performance and usability are positively related. Scalability vs. Reliability : Reliability is the ability of a software system to behave consistently in a user acceptable manner when operating within the environment for which it was intended [3]. Maintaining reliability mostly depend on having redundant capacity [15]. It is positively related to scalability requirement. Reliability requires redundancy which requires that capacity should be deployable to keep ahead of demand, this satisfies scalability requirements [15]. Security vs. Performance : Security and performance requirements are negatively interdependent and tradeoff is needed to satisfy those two sets of requirements [17]. Security mechanisms and protocols degrade a system’s performance [17]. When there is security checking in a software system, it uses extra time and processor and ultimately degrades the performance. Usability vs. Efficiency : Efficiency is the level of performance that describes a process that uses the lowest amount of inputs to create the greatest amount of outputs [28]. Usable software helps the users to use that system efficiently. It indicates their relation as a positive relationship. Customer values usability for efficiency, which refers to CVALUE relation. Security and Accountability, Availability, Integrity : Integrity, availability and accountability are the three major concern of security. To ensure security, those three requirements have to be ensured first. They are in REQUIRES relation. IV. NFR I NTERDEPENDENCY F RAMEWORK This section proposes a framework to reduce the conflict of NFRs while implementing them. The framework deals with interdependence relation of NFRs. This NFRs Interdependency Framework (NFRIF) shows the system designer and developer how the NFRs are related. Steps of NFRs Interdependency Framework are : 1) Decomposing requirements into unit operations : Clients generally give requirements in human language where requirements are not specified as unit operations. Requirement engineers extract the requirements from user stories [30]. Decomposing those requirements into unit operation is the first step to use NFRI Framework.

-

Performance

I

C Security Scalability

R

R

Usability

R

+ Integrity

Accountability Availability

C

Efficiency Reliability

Fig. 2.

2)

3)

4)

5)

Interdependence Relation of NFRs

Each operation will indicate a single task. It can be extracted from SRS document. Identifying NFRs associated with different operations : In SRS document, NFRs are written from the perspective of the complete software system. But each NFR is associate with some other functional requirements. This step identifies which NFRs have to be implemented on which functional requirements. Checking interdependency among NFRs : This paper has presented generalized interdependency among some significant NFRs. This step finds out the interdependence relation among NFRs associated with different operation. Drawing the interdependency graph : Interdependence relations have to be shown in such a way, that the system designer can easily catch the interdependence relation before designing the system. NFR Framework mainly shows the outcome with a graph [20] and this framework also needs to draw the graph with interdependence relation among NFRs of unit operation. Finding out conflict situations : This step finds out where requirements conflict and where they cooperate. As there are seven types of interdependencies, it is not always the case that the NFRs are positively or negatively related. If there is a REQUIRES relation, one NFR must have been implemented to make the other NFR functioning. In a ICOST relation, designer should consider the implementation cost before implementing those NFRs. Implementing the NFRs considering all the interdependencies from the graph concludes the framework steps. V. C ASE S TUDY

An online ticketing system was selected to perform the case study of this research. The system sells ticket of cricket matches online. Users of the system initially have a view of the match fixture for the current season. The fixture shows the match number, teams, venues, date and time of matches. An option is provided beside the matches, enabling the user to buy ticket. If the user selects the ticket to buy then s/he will be considered as a buyer and asked for providing necessary

information. After receiving the confirmation that the money has been paid, a receipt is provided by the system. It is the overview of the system. According to the NFRs provided by the clients, they are plotted to NFRIF. 1) Decomposing requirements into unit operations: From the system scenario, requirements are decomposed into unit operations. NFRs are shown with their name only, not with the clients quantitative requirements. The operations are shown here: Add User: This operation adds users interested to buy ticket to the database. In the front end, it asks users to give their necessary information. As it interact with users, usability is a vital factor here. Performance requirements are also applicable here. Since it has some security concerns, security requirements are associated with this requirement. Number of users can fluctuate due to tournaments, matches, seasons etc. To fulfill the performance requirements in this situation, this should be scalable. Scalability is a concern for this operation. Add Ticket: This operation is performed by system admin. It adds available tickets in the system. Scalability and performance requirements are two types of NFRs here. View Fixture: Match fixtures need to be shown in the system. This is a read operation. Users get the view of this fixture in the first place. So usability requirements are present here. Every time the system starts, the view fixture operation needs to be available, therefore performance requirements are associate with this operation. Scalability requirements are also applicable here. Select Gallery: Users select their desired gallery in the cricket field with this operation. Available galleries should be updated with a very little response time, so performance requirements are associated with this operation. Good usability needs to be ensured while users select gallery. Generate Receipt: A receipt is given to the ticket buyer. This receipt must be downloaded by the ticket buyer, it cannot accessed by any other users, so security requirements are present here. Usability and performance are two other NFRs associated with receipt operation here.

View Fixture

Add User

C

C

I

I Usability

Security

Performance

Usability

Scalability

Scalability

Performance

Add Ticket

Select Gallery

I

C Performance

Scalability

Usability

Fig. 3.

Performance

Add User and Add Ticket Operation Fig. 4.

Option for Ticket: This operation shows the user options for ticket. Users can choose different types of available gallery and seats. Performance and usability are two types of NFRs associate with “option for Ticket”operation. 2) Identifying NFRs associated with different operations : NFRs associated with different operations are identified. NFRs are found from the SRS document. NFRs associated with different functional requirements are identified. Table I shows the unit operations and their associated NFRs. 3) Check interdependency among NFRs : Interdependence relation of the mentioned NFRs are checked from interdependency among NFRs described in this scenario. 4) Draw the interdependency graph : NFRs with their corresponding unit operations with interdependence relation are drawn. Fig. 3, Fig. 4 and Fig. 5 are showing the interdependency graphs. The case study shows that, designing the software after having the graph helps the designer to take decision about tradeoff between NFRs and design efficiently without cut off the NFRs. When software designers proposing a design, they need to check the graphs to find out implementation priority, conflicting and cooperating NFRs etc. Developers can easily develop the system by ensuring NFRs along with functional requirements. VI. C ONCLUSION This paper presents the interdependence relation among significant NFRs and proposed a framework to manage interdependency. A case study has been done where the software system used NFRIFs. Interdependence relation among NFRs are one of the difficulties in developing quality software. Not treating all types of NFR interdependencies from the first phase of a software system development may lead to requirements dismissal in

View Fixture and Select Gallery Operation

Receipt

-

C Usability

Security

Performance

Option for Ticket C Performance

Fig. 5.

Usability

Generated Receipt and Option for Ticket Operation

later phases of development. Thus, the software should be designed keeping the interdependence relation of NFRs in mind. Interdependence relation shown in pairs indicates the dependency of one NFR to another. It describes the relation from the perspective of new types of interdependencies [2],[18]. It generalizes the relationship among NFRs without being specific to a scenario. Interdependency graph gives the designers a clear view about NFRs dependency relations. The NFRIF proposed in this paper maps the functional requirements with their corresponding NFRs, which enable the designer to take decision about interdependent NFRs before implementation. The application modules can than be designed keeping in view NFRs as they are associated with the functional requirements

TABLE I U NIT O PERATIONS AND A SSOCIATED NFR S Unit Operations Add User Add Ticket View Fixture Select Gallery Generated Receipt Option for Ticket

Associate NFRs Usability, Performance, Security, Scalability Performance, Scalability Usability, Performance, Scalability Usability, Performance Usability, Performance, Security Performance, Usability

in the interdependency graph. The case study presented here shows a practical example of the proposed framework. This interdependence graph will have more NFRs as nodes in future if a dependence relation is found among them. However, it is not obvious that all the NFRs will be interdependent, some of them can work independently without conflicting or helping others. The framework will reduce conflict and help implementing NFRs to build quality software. ACKNOWLEDGMENT This work is supported by Ministry of ICT, Bangladesh. Special thanks to Dr. Han-Gyun Woo, of UNIST, Korea for his help and support. This research is conducted in collaboration with IIT DU Optimization Group (https://sites.google.com/site/iitduoptimization/). R EFERENCES [1] S. Konrad and M. Gall, “Requirements engineering in the development of large-scale systems,” in International Requirements Engineering, 2008. RE’08. 16th IEEE. IEEE, 2008, pp. 217–222. [2] R. Berntsson Svensson, T. Gorschek, B. Regnell, R. Torkar, A. Shahrokni, and R. Feldt, “Quality requirements in industrial practicean extended interview study at eleven companies,” Software Engineering, IEEE Transactions on, vol. 38, no. 4, pp. 923–935, 2012. [3] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, “Non-functional requirements,” Software Engineering, 2000. [4] M. Hneif and S. P. Lee, “Using guidelines to improve quality in software nonfunctional attributes,” IEEE Software, vol. 28, no. 6, pp. 72–77, 2011. [5] H.-W. Jung, S.-G. Kim, and C.-S. Chung, “Measuring software product quality: A survey of iso/iec 9126,” IEEE software, vol. 21, no. 5, pp. 88–92, 2004. [6] K. K. Breitman, J. C. S. Leite, and A. Finkelstein, “The world sa stage: a survey on requirements engineering using a real-life case study,” Journal of the Brazilian Computer Society, vol. 6, no. 1, pp. 13–37, 1999. [7] D. R. Lindstrom, “Five ways to destroy a development project (software development),” IEEE Software, vol. 10, no. 5, pp. 55–58, 1993. [8] L. Chung and B. A. Nixon, “Dealing with non-functional requirements: three experimental studies of a process-oriented approach,” in Software Engineering, 1995. ICSE 1995. 17th International Conference on. IEEE, 1995, pp. 25–25. [9] L. M. Cysneiros and J. C. Sampaio do Prado Leite, “Nonfunctional requirements: From elicitation to conceptual models,” Software Engineering, IEEE Transactions on, vol. 30, no. 5, pp. 328–350, 2004. [10] L. M. Cysneiros and J. Sampaio do Prado Leite, “Integrating nonfunctional requirements into data modeling,” in Requirements Engineering, 1999. Proceedings. IEEE International Symposium on. IEEE, 1999, pp. 162–171. [11] A. M. Davis, Software requirements: objects, functions, and states. Prentice-Hall, Inc., 1993. [12] M. Dewi, Z. Didar, and N. Nur, “Managing conflicts among nonfunctional requirements,” University of Technology, Sydney, 2009.

[13] C. Ebert, “Putting requirement management into praxis: dealing with nonfunctional requirements,” Information and Software technology, vol. 40, no. 3, pp. 175–185, 1998. [14] J. Cleland-Huang, R. Settimi, O. BenKhadra, E. Berezhanskaya, and S. Christina, “Goal-centric traceability for managing non-functional requirements,” in Proceedings of the 27th international conference on Software engineering. ACM, 2005, pp. 362–371. [15] M. Davis. (2013, May) The complementary relationship between reliability and scalability. [Online]. Available: http://www.futurehosting.com/blog/the-complementary-relationshipbetween-reliability-and-scalability/ [16] D. M. Pressel, “Scalability vs. performance,” DTIC Document, Tech. Rep., 2001. [17] V. Zorkadis, “Security versus performance requirements in data communication systems,” in Computer Security ESORICS 94. Springer, 1994, pp. 19–30. [18] P. Carlshamre, K. Sandahl, M. Lindvall, B. Regnell, and J. N. O. Dag, “An industrial survey of requirements interdependencies in software product release planning,” in Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on. IEEE, 2001, pp. 84–91. [19] B. A. Nixon, “Management of performance requirements for information systems,” Software Engineering, IEEE Transactions on, vol. 26, no. 12, pp. 1122–1146, 2000. [20] E. Y. J. M. L. Chung, B.A. Nixon, “Non-functional requirements in software engineering,” Software Engineering, International Series in, vol. 5, p. 476, 1999. [21] B. Boehm and H. In, “Identifying quality-requirement conflicts,” IEEE software, vol. 13, no. 2, pp. 25–35, 1996. [22] M. S. Feather, S. L. Cornford, and M. Gibbel, “Scalable mechanisms for requirements interaction management,” in Requirements engineering, 2000. Proceedings. 4th International Conference on. IEEE, 2000, pp. 119–129. [23] D. Ameller, C. Ayala, J. Cabot, and X. Franch, “Non-functional requirements in architectural decision making,” IEEE Software, vol. 30, no. 2, pp. 61–67, 2013. [24] M. Walraed-Sullivan, K. Marzullo, and A. Vahdat, “Scalability vs. fault tolerance in aspen trees,” Technical Report MSR-TR-2013-21, Microsoft Research, Tech. Rep., 2013. [25] M. Aljukhadar and S. Senecal, “How the website usability elements impact performance,” in Value Creation in E-Business Management. Springer, 2009, pp. 113–130. [26] D. S. Rosenblum, “Software system scalability: concepts and techniques,” in Proceedings of the 2nd India software engineering conference. ACM, 2009, pp. 1–2. [27] Y. Lee and K. A. Kozar, “Investigating the effect of website quality on ebusiness success: an analytic hierarchy process (ahp) approach,” Decision support systems, vol. 42, no. 3, pp. 1383–1401, 2006. [28] (2014) Efficiency [Online]. Available: www.investopedia.com/terms/e/efficiency.asp [29] J. Nielsen and J. Levy, “Measuring usability: preference vs. performance,” Communications of the ACM, vol. 37, no. 4, pp. 66–75, 1994. [30] N. Maiden, “Exactly how are requirements written?” IEEE software, vol. 29, no. 1, 2012. [31] L. Chung, J.C.S. do Prado Leite “On non-functional requirements in software engineering” Springer, pp. 363–379, 2009.