2009 International Conference on Advances in Recent Technologies in Communication and Computing

An Approach for Eliciting Software Requirements and its Prioritization using Analytic Hierarchy Process
Mohd. Sadiq
Computer Engineering Section, University Polytechnic Faculty of Engineering and Technology Jamia Millia Islamia (A Central University), New Delhi-110025 (India) E-mail: sadiq.jmi@gmail.com

Shabina Ghafir
Department of Computer Science, Faculty of Management Studies and Information Technology, Jamia Hamdard (Hamdard University), New Delhi-110062 (India) E-mail: sghafir@jamiahamdard.ac.in

Mohd. Shahid
M. Tech. Scholar, Department of Computer Science and Engineering, Al-Falah School of Engineering and Technology, Dhauj, Faridabad Maharshi Dayanand University, Rohtak, Haryana (India) E-mail: shahid27.jmi@gmail.com
Abstract: Most software engineering methods presume that requirements are explicitly and completely stated; however, experience shows that requirements are rarely complete and usually contain implicit requirements. The failure or success of a software system depends on the quality of the requirements. The quality of the requirements is influenced by the techniques employed during requirements elicitation. Requirements elicitation is most critical part of the software development because errors at this beginning stage propagate through the development process and the hardest to repair later. In this paper we have proposed an algorithmic approach to elicit the software requirements and its prioritization of the requirements using analytic hierarchy process (AHP).

Keywords: Elicitation, software requirements, prioritization, AHP.

I. INTRODUCTION

Elicitation is all about determining the needs of stakeholders and learning, uncovering extracting and /or discovering needs of the users and other potential stakeholders [5]. Requirement elicitation is recognized as one of the most critical knowledge intensive activities of the development of software. Studies by [14] indicate that 70% of the system errors are due to
978-0-7695-3845-7/09 $25.00 2009 IEEE $26.00 DOI 10.1109/ARTCom.2009.58 790

the inadequate system specification and 30% of the system errors are due to design issue. The analysis of secure software system based on the system requirements elicited in the form of use case and misuse case. Use cases have proven helpful for elicitation of communication about, and documentation of the function requirements. The integral development of use and misuse cases provides a systematic way for the elicitation of both the functional and non functional requirements [9]. Using an elicitation method can help in producing a consistent and complete set of security requirements. However, brainstorming and elicitation methods used for ordinary functional (end-user) requirements usually are not oriented toward security requirements and do not result in a consistent and complete set of security requirements. The resulting system is likely to have fewer security exposures when security requirements are elicited in a systematic way. The paper is organized as follows: In section 2 we present the background and related work. In section 3 we have explained all the requirements elicitation techniques. In section 4 we have proposed our approach to elicit and prioritize the requirements, and in section 5 we have explained the experimental work with the help of a Mini Software for Numerical Integration (MSNI) finally we conclude the paper in section 6.

II. BACKGROUND AND RELATED WORKS:

Researchers, scientist and academician in the field of software engineering have proposed several techniques to elicit the software requirements. In [3] authors have proposed an approach for the software requirements elicitation. They have used the several steps like training sessions to eliminate lack of user input and poor understanding, recording keywords, pictorial representation of needs and wants to reduce language barriers etc. but this approach does not have the information that how we will prioritize the requirements. In [7] the authors have provided the different elicitation technique and criteria for its selection. In [5] authors have developed a model for two knowledge Intensive Software Development Process. In [6] the authors have proposed methodology to introduce developers into the clients environment and this paper is based on elicit tacit domain knowledge from users. In the continuation of the above work we are going to propose an algorithmic approach to elicit the software requirements and its prioritization using AHP. In [2] the authors have proposed an ontology framework for the requirements elicitation and reuse. We are not going to use any ontology based approach in order to elicit the requirements.
III. REQUIREMENTS ELICITATION TECHNIQUES:

8. 9. 10. 11.

Critical discourse analysis Accelerated Requirements Method Rapid Application Development Ontology Framework(ONT)

We are going to discuss only few techniques and to get the detailed description about the remaining techniques please refer to [5] [6] [4]. 3.1 Misuse Cases: Misuse cases apply the concept of a negative scenariothat is, a situation that the system's owner does not want to occurin a use-case context. For example, business leaders, military planners, and game players are familiar with analyzing their opponents' best moves as identifiable threats. Misuse cases are also known as abuse cases. A deeper discussion of abuse cases as an approach for identifying security requirements can be found in [9], [10], [11]. One significant characteristic of misuse cases is that they seem to lead to quality requirements, such as those for safety and security, whereas other elicitation methods are focused on end-user requirements, so their effectiveness in the identification of security requirements is unknown. Use cases describe system behavior in terms of functional (end-user) requirements. Interplay between misuse cases and use cases could improve the efficiency of eliciting all requirements in a system engineering life cycle. Misuse cases and use cases may be developed from system to subsystem levelsand lower as necessary. Lower level cases may draw attention to underlying problems not considered at higher levels and may compel system engineers to reanalyze the system design. Misuse cases are not a top-down method, but they provide opportunities to investigate and validate the security requirements necessary to accomplish the system's mission. Davis classifies the requirements as (i) Functional requirements (ii) Non-Functional requirements (iii) Performance/ Reliability (iv) Interfaces (v) Design Constraint. 3.2 JAD: A number of requirement elicitation techniques have been developed to extract requirements from a user. So JAD is a method where a software development team and clients all come together in workshop environments. It is not only used to create the ideas for new system but it also raises issues for the software development team [7]. The goal of JAD (Joint Application Development) is to involve all stakeholders in the design phase of the product via highly structured and focused meetings. Typical participants in the session include a facilitator, end users of the product, main
791

A number of requirements elicitations techniques have been developed to extract requirements from a user. The following list is a sample of methods that could be considered for eliciting security requirements. Some have been developed specifically with security in mind (e.g., misuse cases), whereas others have been used for traditional requirements engineering and could potentially be used for security requirements. In the future we may have a better understanding of how the unique aspects of security requirements elicitation drive selection of a method. The elicitation of software requirements is generally performed using an elicitation methodology or a series of techniques. There are several techniques which are used to elicit the software requirements. These techniques are: 1. 2. 3. 4. 5. 6. 7. Misuse cases Soft Systems Methodology Quality Function Deployment Controlled Requirements Expression Issue-based information systems (IBIS) Joint Application Development (JAD) Feature-oriented domain analysis

developers, and observers. In the preliminary phases of JAD, the requirements-engineering team is tasked with fact finding and information gathering. Typically, the outputs of this phase, as applied to security requirements elicitation, are security goals and artifacts. The actual JAD session is then used to validate this information by establishing an agreed-on set of security requirements for the product. If JAD has some advantages so it has also some disadvantages. The important disadvantage of JAD is that if there are too many JAD sessions while the project is progressing then user may develop a feeling that the developer are shifting their work and responsibility onto the users. 3.3 RAD: Rapid Application Development (RAD) is a technique that is used to create the screens while the developers and client discuss various fields and buttons that are needed. Like use case models, RAD adds visual clarity to scenarios and dialogue structure [6]. 3.4 Ontology Framework: Researchers in the requirements engineering community have been studying and developing a number of ontology based approaches in order to elicit system requirements unambiguously and correctly. In the multiple ontology frameworks there are four types of ontology and these are (i) top level ontology, (ii) domain ontology, (iii) task ontology, (iv) application ontology [2].
IV. PROPOSED APPROACH:

Kevin Ryan in 1997 [12, 13]. AHP is a method for decision making in situations where multiple objectives are present. This method uses a pairwise comparison matrix to calculate the relative value and costs of security requirements. By using AHP, the requirements engineer can also confirm the consistency of the result. AHP can prevent subjective judgment errors and increase the likelihood that the results are reliable. There are five steps in the AHP method: 1. 2. 3. Review candidate requirements for completeness. Apply the pair-wise comparison method to assess the relative value of the candidate requirements. Apply the pair-wise comparison method to assess the relative cost of implementing each candidate requirement. Calculate each candidate requirement's relative value and implementation cost, and plots each on a cost-value diagram. Use the cost-value diagram as a map for analyzing the candidate requirements.

4. 5.

Now we will apply the following steps in order to elicit the software requirements and for prioritization we will use the concept of AHP. 1. 2. 3. 4. 5. 6. Collect information about user expectations. Train the Clients , Users and Managers Write the description of the user need for the proposed system Now you can apply Misuse cases, JAD, RAD, and Ontology framework Map Keywords Classify and prioritize the system requirements using AHP.

The elicitation method proposed in this paper starts by dealing with the problem of lack of user input. Before the designing of the algorithm we will first explain the concept and meaning of AHP. Once the actual requirements have been identified, prioritization can be used to categorize them for the sake of scheduling. Various techniques can be used to determine, negotiate, and develop a consensus regarding the priorities of the requirements: 1. 2. 3. 4. 5. 6. 7. Business Case Analysis/ Return on Investment (ROI) estimation Pair wise comparisons Prioritization working groups scale of 1-10 rankings voting schemes Value based software engineering Quality function Deployments (QFD).

In this paper we are going to use the AHP. AHP was developed by Thomas Saaty and applied to software engineering by Joachim Karlsson and
792

4.1 Collect information about user expectations: Software Requirement Specification is the first step in the software development which is used to capture the requirement of the client. Before the designing phase SRS team write the user manual i.e. SRS and from this SRS we collect the information about the user need and expectations. This careful compilation of information will be used in the next phase to train the clients/ user and make them aware of what they can and can not expect from the software developers. In this stage stakeholder also learn about the limitations of the computer resources and functionalities, and availability of other resources.

4.2 Train the Clients, Users, and Managers: Once we have collected the information about the user need and expectation the next step is to train the clients, users and managers. At this stage, missing user input can be supplemented. 4.3 Write the description of the user need for the proposed system: After the successful completion of the above steps, each stakeholder will write the description of his/ her needs of the system that the clients want to develop. Since the clients and customers are already educated about the computer limitations and availability of resources through the training sessions. In this stage expectations of the development process become clearer. 4.4 Elicitation Evaluation Criteria: Here we are going to discuss the elicitation evaluation criteria that may be useful in selecting an elicitation method. We evaluate the elicitation criteria on the basis of the following common terms. Adaptability: The method can be used to generate requirements in multiple environments. For example, the elicitation method works equally as well with a software product that is near completion as with a project in the planning stages. Computer-aided software engineering (CASE) tool: The method includes a CASE tool. (The Software Engineering Institute defines a CASE tool as "a computer-based product aimed at supporting one or more software engineering activities within a software development process" Stakeholder acceptance: The stakeholders are likely to agree to the elicitation method in analyzing their requirements. For example, the method isn't too invasive in a business environment. Easy implementation: The elicitation method isn't overly complex and can be properly executed easily. Graphical output: The method produces readily understandable visual artifacts. Quick implementation: The requirements engineers and stakeholders can fully execute the elicitation method in a reasonable length of time. Shallow learning curve: The requirements engineers and stakeholders can fully comprehend the

elicitation method within a reasonable length of time. High maturity: The elicitation method has experienced considerable exposure and analysis in the requirements engineering community. Scalability: The method can be used to elicit the requirements of projects of different sizes, from enterprise-level systems to small-scale applications.

In our case studies, we decided to use IBIS, ONT, and JAD on three different projects. These three methods were subjectively ranked to be the most suitable candidates for the case studies, given the time and effort constraints that we were working with. We considered not just the total score. The learning curve was an important factor, and the team attempted to select methods that were not too similar to one another, to have some variety. On the basis of the above criteria we generally choose the appropriate elicitation method. Similarly you can evaluate the elicitation criteria on the basis of your projects. 4.5 Map Keywords: From the customers and other stakeholders interview sessions we have recorded their wishes. From this a large amount of keywords are carefully analyzed, collected and organized. These keywords by themselves not explain or tell us anything. If we relate the recorded keywords with each other, at least we are in a position to define the user/s needs with the precision we need. 4.6 Classify and Prioritize the System requirement using AHP: From the above steps we are in a position to find out the requirements of the users. With the help of the following example we will explain how you will prioritize the requirements? Suppose a university wishes to buy a piece of software of certain type and has four aspects in mind which will govern its purchasing choice. (i) Expense, E (ii) Operability, O (iii) Reliability, R (iv) Adaptability for other uses or Flexibility , F. Competing manufactures of that equipment have offered three options, X, Y, and Z . The software engineers have looked at these options and decided that X is cheap and easy to operate but is very reliable and could not easily be adapted to other users. Y is somewhat more expensive, is reasonable and easy to operate, and is very reliable and not very adaptable. Finally, Z is very expensive, not easy to operate, is a little less reliable than Y but is claimed by the manufacturer to have a wide range of alternatives uses. Each of X, Y, and Z will satisfy the firms
793

requirements to differing extents so which, overall, best meets this firms needs? This is clearly an important and common class of problem and AHP have numerous applications. We first provide an initial matrix for the firms pair wise comparisons in which the principal diagonal contains entries of 1, as each factor is s important as itself. E 1 O 1 1 1 R F

V.

EXPERIMENTAL WORK:

E O R F

According to the proposed approach we have to first collect the information about user expectations. In this paper we have collected the customer needs for Mini Software for Numerical Integration (MSNI). So in order to elicit the software requirements for MSNI we have used the JAD method. After applying the JAD we have collected the number of requirements and we have summarized 5 requirements in the following table. 1 2 3 4 5 CN-F1 CN-F2 CN-Q1 CN-Q2 CN-Q3 Up to date function Ease of use Information Content Number of algorithms GUI

There is no standard way to make the pair wise comparison but let us suppose that the firm decide that O is slightly more important than cost. In the next matrix that is rated as 3 in the cell O, E and I/3 in E, O. They also decide that reliability is far more important than cost, giving 9 in R, E and 1/9 in E, R. Similarly we enter the information into the given matrix on the basis of the Saaty Rating scale. This forms the completed matrix, which we will term the Overall Preference matrix (OPM) is E 1 3 9 5 O 1/3 1 1 1 R 1/9 1 1 1/3 F 1/5 1 3 1

The overall performance matrix for given requirements for the MSNI. 1 1 1/3 9 1/5 7 2 3 1 3 1/5 5 3 1/9 1/3 1 3 1/3 4 5 5 1/3 1 1/5 5 1/7 1/5 3 5 1 Eigen Vector 0.139 0.119 0.357 0.168 0.219

E O R F

1 2 3 4 5

The eigenvector of the relative importance or value of E, O, R, and F is (0.058, 0.2620, 0,454, and 0.226). Thus R is most valuable, O and F are behind, but roughly equal and E is very much less significant. Now we multiply on the right the matrix of judgment by the eigenvector, obtaining a new vector. The calculation for the first row in the matrix is: 1*0.058+1/3*0.262+1/9*0.454+1/5*0.226=).240 and the remaining three rows gives 1.116, 1.916, and 0.928. Now we will calculate the Consistency Index (CI) for the matrix and it is 0.060. After this we calculate the Consistency ratio for this set of judgments using the CI for the corresponding value from the large sample of matrices. For the given example it is 0.060 Saaty argues that CR>0.1 indicates that the judgments are at the limit of consistency though CR>0.1. A CR as high as, say, 08 would mean that the pair wise judgments are just about and are completely untrustworthy. So on the basis of CR we can prioritize the requirements. Which requirement is more important and which one is less, could be easily determine on the basis of the above example?
794

The Eigen vector for the MSNI is (0.139, 0.119, 0.357, 0.168, and 0.219). Thus Information content is most valuable and it has got the first priority. It means that during the software development the emphasis would be given to Information Content. GUI (graphical User interface) has the second priority. It means that the GUI of the software should be in such a way so that the end user can easily understood about the software. How many different algorithms we have used in MSNI has third priority? Like Simpsons 1/3 rule, Simpsons 3/8 rule, trapezoidal rule, etc. Similarly Up to date function and Ease of use have the fourth and fifth priority respectively. In MSNI we have collected 21 different requirements; we have shown the prioritization of these requirements in the following graph.
1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 R 1 R 3 R 5 R 7 R 9 R1 1 R3 1 R5 1 R7 1 R9 1 R1 2 Series1

VI

CONCLUSION:

5.

The poor performance could be (i) unrelated to elicitation techniques, (ii) caused by lack of effective elicitation techniques, (iii) by availability but poor use of effective elicitation techniques. In this paper we have proposed an approach to elicit the software requirements and its prioritization using AHP. From this approach we can easily rank the requirements and can implement it on the basis of the ranking. In this paper we have developed the mini software for numerical integration (MSNI) inorder to find out the software requirements. This software basically integrates the value of a given function after applying existing techniques like Simpsons 1/3 rule, Simpsons 3/8 rule, trapezoidal rule etc. ACKNOWLEDGEMENTS: The authors would like to thank Mr. Iqbal Azam, Principal, University Polytechnic, Faculty of Engineering and Technology, Jamia Millia Islamia (A Central University), New Delhi-25, India ; Professor Afsar Alam, Head, Department of Computer Science, Faculty of Management and Information Technology , Jamia Hamdard (Hamdard University), New Delhi, India and Mr. Jawad Ahmad Siddiqui, Chairman, Al-Falah School of Engineering and Technology, Dhauj, Faridabad, Haryana, India, for his valuable support , guidance and encouragement. References: 1. D. Firesmith, Prioritizing requirements, Journal of Object Technology, Volume 3, No.8, September 2004 LI Zong-yong, WANG Zhi-xue, YANG-ying, WU Yue, LIU Ying, Towards multiple ontology Framework for Requirements Elicitation and Reuse, 31st IEEE Annual International Computer Software and Application Conference, 2007. P.Rajagopal, R.Lee, Thomas Ahlswede, Chia-Chu Chiang, D. Karolak, A New Approach for Software Requirements Elicitation, Proceedings of the 6th IEEE International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/ Distributed Computing, 2005. Nancy R. Mead, Requirements Elicitation Introduction, Software Engineering Institute Carnegie Mellon University, 2008-2009.
795

6.

7.

8.

9.

10.

11.

2.

12. 13.

3.

14.

Ann M. Hickey, Alan M. Davis, Requirements Elicitation and Elicitation technique selection: A Model for Two knowledge-Intensive Software development Process, Proceedings of the 36th IEEE International Conference on System Sciences, 2002. W.R. Friedrich, J. A. Van der Poll, Towards a Methodology to Elicit Tacit Domain knowledge from Users, Interdisciplinary Journal of Information, Knowledge, and Management, Volume2, 2007. A.M. Hickey, A.M. Davis, Elicitation Technique Selection: How Do Experts Do It? Proceedings of the 11th IEEE International Requirements Engineering Conference, 2003. Gunnar Peterson, John Steven, Defining Misuse within the Development Process, IEEE Security and Privacy, 2006. J.J.Pauli, D.Xu, Misuse Case-Based design and Analysis of secure Software Architecture, Proceedings of the IEEE International Conference on Information Technology: Coding and Computing (ITCC05), 2005. J. Pauli, D. Xu, Integrating Functional and Security Requirements with Use Case Decomposition, Proceedings of the 11th IEEE International Conference on Engineering of Complex Computer System, 2006. Ian Alexander, Misuse Cases Help to Elicit Non-functional Requirements, Computing and Control Engineering 2003. T. L. Saaty, The Analytic Hierarchy process, New York, McGraw-Hill, 1980. J. Karlsson, Software Requirements Prioritizing, Proceedings of the International Conference on Requirement Engineering, 1996. Beichter F et al, SLAN-4-A Software Specification and Design Language, IEEE transaction on Software Engineering, SE- 10,2, 1994, pp 155162

4.