Comparison of various Elicitation Techniques and Requirement Prioritisation Techniques

Comparison of various Elicitation Techniques and Requirement Prioritisation Techniques

Comparison of various Elicitation Techniques and Requirement Prioritisation Techniques

Nilofar Mulla

Department of Information Technology, MIT Pune 38, Maharashtra, India

Sheetal Girase

Assistant Professor, Department of Information Technology, MIT Pune 38, Maharashtra, India

Abstract

Software engineering research has been, and still is criticised as being immature and unscientific due to lack of evaluation. However, software engineering community is now focusing more on empirical research. One of the major activities within the requirements engineering process is to use requirements elicitation and requirements prioritization that helps to focus on the most important requirements. Requirement elicitation is recognized as one of the most critical k nowledge intensive activities of the development of software. Requirements prioritization aims at identifying the most important requirements for a system .There are many elicitation and prioritization techniques available; still there is lack of evidence of which technique to prefer. The reasons could be the differences in contexts, measurement of variables and usage of data sets. In this paper, the area of requirements elicitation and prioritization has been systematically reviewed in order to assess what evidence regarding different techniques exist.

1. Introduction

   Software engineering does not yet have a widely recognized and wide ly appreciated set of research paradigms in the way that other parts of computer science do[4]. That is, we dont recognize what our research strategies are and how they establish their results. Shaw, in her artic le says described as a challenge to the whole of software engineering community [8]. The ma in challenge of the software engineering community is to satisfy the customer needs and possibly exceed his expectations in an economic, rapid and profitable manner. The process of Require ments engineering has the potential of fulfilling the customer needs and possibly exceeding them by using rigorous and defined methodologies. Require ments engineering can help organizations develop quality software systems with in time and budget constraints which are true reflection of customer needs [4]. One of the major activ ities within require ments engineering process is to use require ments prioritization that evaluates requirements to focus on

   the most important ones. The primary success factor of require ments elicitation is that require ments meet end user needs. This outcome is difficu lt to achieve because users often have trouble identifying and articulat ing their needs and because those needs often change as a result of system imple mentation. This difficu lty is compounded for newer technologies such as data warehouses because require ments continue to evolve over time as users become fa miliar with the systems and their needs for information change. For these technologies, system require ments are a moving target. Over time , challenges arise fro m the simultaneous evolution of the technology and of the users require ments. For these reasons, calls for effective user involvement in require ments elicitation continue. Effective require ments elicitat ion depends upon the ability of users and analysts to understand and appreciate one another's words. This represents a significant, but not insurmountable, challenge which we e xplore in this paper. Require ments elic itation is an often poorly completed aspect of systems analysis. Mistakes made in e lic itation have been shown many times to be major causes of systems failure or abandonment and this has a very large cost either in the complete loss or the expense of fixing mistakes.

2. Challenges in Requirements Elicitation

   Do main e xperts, customers, and users are essential during require ments elic itation; however, they do not necessarily understand the intricacies of software development. On the other hand, software engineers are like ly to be unfamiliar with the application domain. This creates a communications barrie r between the software engineers and the domain e xpe rts, customers, and users, which can be overcome by forma l elic itation methods. Require ments elicitation involves end users and analysts interacting to identify and 'capture' the data and processes that will ma ke up the eventual system. User-analyst communicat ion is an important part of require ments elic itation, but communication styles and techniques most readily associated with require ments elic itation – interv iews and questionnaires, for instance – arc rarely suffic ient to elicit the whole range of require ments [6]. The use of such standard 'instruments' in any user-analyst exchange introduces the potential for errors of omission that arise as a consequence of the

   analyst's difficulty in e lic iting system require ments that are outside the instrument's scope. The majority of require ments elic itation techniques fail to address the less conspicuous and often more tacit requirements, priorities, and issues that analysts do not know to ask about and those users do not or cannot readily identify and articulate. Traditional techniques are unable to fully diagnose how such contextual issues will a ffect system require ments, system development, and system evolution. Furthermore, analysts need unbias ed, systematic approaches during communication to assist users in identify ing and articulating needs. To overcome the limitations and perceptual biases of traditional require ments elic itation approaches, the concept of user-centred analysis – the process of 'capturing' require ments fro m the user's point of view – has frequently been promoted as a means to achieve a more comprehensive understanding of end user system needs.

3. Requirements Elicitation

   Developing a large system is a comple x and difficult process. In the early days of computing, there was no particular o rganisation to this process: programmers just sat down and tried to write code that would be useful. To- day, fe w doubt that a task that can consume hundreds of person-years should be carefully planned and managed. Therefore the system \life cyc le" has been broken into a number of so called \phases," of which Require ments Engineering is the earliest phase3 that lies largely within Co mputing Sc ience. The require ments phase is typically p receded by business planning, and is forma lly in itiated by the client.

   Require ments describe goals, functions, and

   constraints of a software system. The term elic itation is preferred to capture, to avoid the suggestion that require ments are out there to be collected simp ly by asking the right questions [5]. Rather, the data collected during requirements elicitation often has to be interpreted, analyzed, mode lled, and validated. Elic itation is also referred to as acquisition in some literature.

   1. Requirements Elicitation techniques

      Following is the table (Table 1) showing various Require ments Elic itation techniques [7] a long with their advantages and disadvantages.

      There are a variety of techniques that can be emp loyed to elic it require ments. The approach taken by a require ments engineer is not limited to one particular technique. Organizational processes, application type, available resources, and individual preference all p lay a role in determining a particu lar approach. Fo r instance, applications that need early customer feedback might benefit fro m the use of prototyping combined ith group elicitation. The require ments elic itation process involves all stakeholders, which includes customers, developers, and users. Better technique selection will improve the quality of the requirements elic itation

      process and increase the success of software development projects.

4. Requirements Prioritisation

   After require ments are identified, they also need to be prioritised. Require ment priorit ization process is used to determine which candidate require ment of a software project should be included in a certain release, for this purpose different techniques are used [1]. Projects often have more require ments than time, resource, and budget allo w for. A function can always be added and the user interface enhanced. Some require ments are crit ical for the success of the software system. Hence, require ments should be prioritised so that the ones that are most like ly to achieve customer satisfaction can be selected for imp le mentation. It is essential to decide what is important before these requirements are incorporated into the software development process. By addressing the high-priority require ments before considering the low-p riority ones, one can significantly reduce both the costs and duration of a project.

   1. Requirements Prioritisation techniques Following is the table (Table 2) showing various Require ments Prioritization techniques [2] along with their advantages and disadvantages.

      Require ment Priorit izat ion is the most important step in require ment engineering process. Without assigning proper and accurate requirement to each release, it is almost impossible to complete project on time and within budget. In a review of the state of the practice in require ments engineering, Lubars found that many organizations believe that it is impo rtant to assign priorities to require ments and to make decisions about them according to rational, quantitative data. Still it appeared that no company really knew how to assign priorities or how to commun icate these priorities effectively to project me mbers. According to us all the factors listed in (Table 2) should be considered while prioritizing require ments. It is better to spend time in choosing the right require ments for releases rather than choosing the wrong ones and wasting time, budget and resources. Before starting prioritizing require ments first of all check the dependencies between require ments (Dependency Constraints). If dependencies between require ments are not taken properly it gets very difficult to select an appropriate require ment sets for the releases, because it is highly possible that you are selecting a requirement in the current release and leaving another for the next release but both require ments should be in the same release. Therefore, the first step is to check dependency constraints between require ments. It is almost impossible to imple ment all the require ments in one release. That is why some sort of prioritizat ion process is needed to imple ment the most important require ments in the first release and leave the less important ones for the future releases.

5. Conclusion

   Require ments engineering interacts with many technical as well as social sciences to improve the process of elic iting, analyzing, documenting and maintain ing require ments. Require ments elic itation is an often poorly completed aspect of systems analysis. Mistakes made in elicitat ion have been shown many times to be ma jor causes of systems failure o r abandonment. This has a very large impact on the cost either in terms of complete loss or the expenses on fixing mistakes. In this paper, the diffe rent require ment elicitation methods are studied, compared and discussed. Require ments prioritization is highly emphasized area within require ments engineering that helps different stakeholders decide on the final set of requirements, which will eventually make up a system. Certain techniques exist within require ments prioritizat ion with their own advantages and limitations. All these techniques could be of valuable help for organizations to decide which requirements are important and which are less important in the overall development of a project. Require ments elic itation is a crit ical step in the require ments development process. It is consequently imperative that require ments engineers apply appropriate methods to perform the process sufficiently. This paper has attempted to present meaningful insights into the feature of different types of require ments elic itation techniques.

   Table 1. Requirement Elicitation Techniques

   Method	Description	Advantages	Disadvantages
   Interviews	Analyst discusses the desired product with different groups of people and builds up an understanding of their require ments. If the interview is conducted with pre-defined agenda and questions, it is called structured interview; otherwise, it is an open- ended interview.	other usability activ ity
   Workshop, focus groups	Stakeholder representatives gather together for a short but intensely focused period to create or review high -level features of the desired products.	effective to resolve the conflicts among customers in order to bring them at one table.	needs a lot of effort as compared the other require ments engineering techniques. situation.
   Bra instorming	Stakeholder representatives gather together and rapidly develop a large and broad list of ideas. It encourages out -of-the-box thinking without norma l constraints, and involves both idea generation and idea reduction.	innovative ideas about the project to be developed.
   Scenarios, passive Storyboards	It is an interaction session to describe a sequence of actions and events for a specific case of some generic task which the system is intended to accomplish. Clarified system require ments related to procedures and data flows of a task. In a highly uncertain situation, an effective and re latively ine xpensive way to develop an initial set of require ments.	Because storyboards exist independently of the software system they describe, they have many advantages over regular prototypes. They cannot crash, are very easy to share with large groups, and do not give the false impression that the system is already developed. Additionally, feedback is easier to accommodate.	One of the biggest problems with storyboards is that they can become outdated very quickly. User interfaces origina lly defined often change over time, and that creates a maintenance burden.

   • Collecting the rich and detailed data

   • Collecting information to design a survey or

   • Getting a holistic vie w of the whole system

   • Co llect ing data fro m la rge samples or people

   • When it need to collect the data very rapidly

   • This technique is very much

   • Each and every aspect of require ments is discussed and proper suggestions are given using group work.

   • The stakeholders provide the direct re marks about the software require ments.

   • Sta keholders work in the environment.

   • Group work Provides the re markable

   • This technique

   • So met imes all the stakeholders can join at the same time as it may be possible that they may be busy in other tasks.

   • Group work is less effective in the highly politica l tense

   • Bra instorming is mostly used for the innovative sort of projects where each participant provides his or her own ideas after their personal research about the project to be started.

   • Th is technique is often sed ma ke the key dec isions about the require ments of the project.

   • It pro motes free thinking and e xpression of ideas.

   • Brainstorming provides the

   • Bra in storming is seriously affected by e xploring the critique ideas.

   • Bra instorming is not used to resolve the ma jor issues.

   Prototyping

   Prototype is a version of a product launched into market to provide the so for services to the customers. Prototyping is used to provide a version of the software and which is not final so that the customer can gain the experience and also may be able to provide other require ments that need to be imple mented in the next prototyping. The response of the user is in the form of a feedback which is recorded as like require ments of the system.

   helpful developing new systems for entire ly new applications.

   • Prototyping provides the detail informat ion by investing each and every prototype by the customer.

   • Prototypes are mostly used in conjunction with other elic itation techniques such as interviews.

   • Prototypes useful when developing human computer GUI interfaces.

   • Prototypes provide a good chance to the stakeholders an effective rule and to be involved in the requirements engineering.

   • The technique is e xtre mely

   • In many cases prototypes are e xpensive to produce in terms of time and cost.

   • A great proble m for prototyping is that the user often resists ma king changes if once they get e xperienced.

   Table 2. Requirement Prioritisation Techniques

   Method	Description	Advantages	Disadvantages
   Value- oriented prioritisation method	Priorit ises requirements based on their contribution to the core business values and their perceived risks. The first step in setting up a value-oriented prioritization process is to establish the fra me work and this frame work is used to identify the value of the business and the relative relat ionship of those values. Business values are established at the level of organization. Afte r indentifying the core values, the organization must provide some indication of importance of those values to the organization. This is accomplished by assigning weights that use a simp le ordinal scale ranging fro m 0(not important) to 10(critica l).		As priorit isations involve a small subset of stakeholders; the results are biased towards the perspective of those involved in the process.
   Pairwise comparison approach	Require ments engineers compare two require ments to determine the mo re important one, which is then entered in the corresponding cell in the matrix . The comparison is repeated for all require ments pairs such that the top half of the matrix is filled. If both require ments are equally important, then they both appear in the cell. Then, each requirement is ranked by the number of ce lls in the matrix that contain the requirement.	Pairwise comparis on is simple.	Since all unique pairs of require ments need to be compared, the effort is substantial when there are many require ments. Priorit ising n requirements needs n×(n1)/2 comparisons . Hence, a project with 100 require ments would require 4,950 co mparisons.
   Analytic	The analytic hierarchy process (AHP)	On the other hand	On the one hand AHP is a

   Hie rarchy Process (AHP)	is a decision-making method. Using AHP to priorit ize software require ments involves comparing all unique pairs of require ments to determine which of the two is of higher priority, and to what e xtent.	AHP is very trustworthy since the huge amount of redundancy in the pairwise co mparisons ma kes the process fairly insensitive to judgmental errors. Another advantage is that the resulting priorities are relative and based on a ratio scale, which a llo ws for useful assessments of require ments.	demanding method due to the dramatica lly increasing number of required pair- wise co mparisons when the number of require ments grows.
   100-point test	Each stakeholder is given 100 points that they can distribute as they desire among the require ments. Require ments that are more important to a stakeholder are given more points. Require ments are then priorit ised based on the total points allocated to them.	100-point test incorporates the concept of constraint in the stakeholders prioritisation by giving each of them a limited nu mber of points.	It can be easily manipu lated by stakeholders seeking to accomplish their own objectives . For e xa mple , stakeholders may distribute their points based on how they think others will do it. In addition, it is difficult for stakeholders to keep an overview of a large nu mber of require ments .
   Hie rarchica l cumulat ive voting (HCV)	Enables prio rit isations to be performed at different leve ls of a hierarchy. Stakeholders perform prio rit isation using 100- point test within each prioritisation block. The intermediate priorities for the requirements are calculated based on the characteristics of the require ments hierarchy. Fina l priorities are ca lculated for a ll require ments at the level of interest through normalisation. If several stakeholders have prioritised the require ments, their individual results are then weighted and combined.	The hierarchica l prioritisation in HCV ma kes it easier for the stakeholders to keep an overview of all the require ments	The prioritisations need to be interpreted in a rational way as stakeholders can easily play around with the numbers.
   Require ments triage method	In the require ments triage method, Davis proposed that stakeholders should be gathered in one location and group voting mechanisms used to prioritise require ments. One method to collect group vote is to use the show of fingers to indicate the stakeholders enthusiasm for a require ment.		A disadvantage is the relative priorities of require ments depend on the stakeholders who attended the prioritisation meeting, and dominant participants may influence the prioritisation.
   Win-win approach	In the win-win approach proposed by Boeh m, stakeholders negotiate to resolve disagreements about candidate require ments. Using this approach,	Win-win negotiations encourage stakeholders to focus on their interest	The approach is labour intensive, particularly in large projects.

   	each stakeholder ranks the require ments privately before negotiations start. They also consider the requirements they are willing to give up on. Stakeholders then work collaboratively to forge an agree ment through identifying conflicts and negotiating a solution.	rather than positions, negotiate towards achieving mutual gain, and use objective crite ria to prioritise require ments.
   Binary search tree (BST)	In BST, a require ment fro m the set of require ments is selected as the root node. Then, a binary tree is constructed by inserting less important require ments to the left and mo re important ones to the right of the tree. A prioritised list of require ments is generated by traversing the BST in order. The output is a prioritised list of require ments with the most important require ments at the start of the list, and te least important ones at the end.	This method is simp le to imp le ment	Provides only a simp le ranking of require ments as no priority values are assigned to the require ments .

6. REFERENCES

1. Joachim Karlson, Claes Wholin, Bjorn Regnell An evaluation of methods for prioritizing software requirements.

2. Aaqib Iqbal, Farhan M , Khan, Shahbaz. A. Khan A Critical Analysis of Techniques for Requirement Prioritization and Open Research Issues. International Journal of Reviews in Computing 2009 IJRIC

3. Goguen, J. and Linde, C. (1993), Techniques for requirements elicitation, Requirements Engineering, IEEE, 152-164.

4. Kotonya, G. and Sommerville, I. (1998), Requirements Engineering: Processes and Techniques, John Wiley, 1998.

5. Knowledge Elicitation Techniques: Comparison of Three M ethods, Proceedings of the Second International Conference on Requirements Engineering (ICRE96),

   Colorado Springs. CO, April 15-18, 1996. pp. 4-11

6. Davis, C. J., Fuller, R. M ., Tremblay, M . C., & Berndt, D.

   J. (2006). Communication challenges in requirements elicitation and the use of the repertory grid technique. Journal of Computer Information Systems, 78.

7. Pitts, M . G., & Browne, G. J. (2007). Improving requirements elicitation: An empirical investigation of procedural prompts. Information Systems Journal, 17, 89- 110.

8. Shaw, M . (2001) The coming of age of software architecture research Proceedings of the 23rd International Conference on Software Engineering (ICSE01), pp: 657-664

International Journal of Engineering Research & Technology (IJERT)

ISSN: 2278-0181

Vol. 1 Issue 3, May – 2012