DeepAI
Log In Sign Up

A Methodology for the Selection of Requirement Elicitation Techniques

In this paper, we present an approach to select a subset of requirement elicitation technique for an optimum result in the requirement elicitation process. Our approach consists of three steps. First, we identify various attribute in three important dimensions namely project, people and the process of software development that can influence the outcome of an elicitation process. Second, we construct three p matrix (3PM) separately for each dimension, that shows a relation between the elicitation techniques and three dimensions of a software. Third, we provide a mapping criteria and use them in the selection of a subset of elicitation techniques. We demonstrate the applicability of the proposed approach using case studies to evaluate and provide the contextual knowledge of selecting requirement elicitation technique.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

04/13/2021

Not All Requirements Prioritization Criteria Are Equal at All Times: A Quantitative Analysis

Requirement prioritization is recognized as an important decision-making...
01/06/2019

STORE: Security Threat Oriented Requirements Engineering Methodology

As we are continuously depending on information technology applications ...
03/10/2020

A Fuzzy-Based Optimization Method for Integrating Value Dependencies into Software Requirement Selection

Software requirement selection aims to find an optimal subset of the req...
08/25/2010

An Influence Diagram-Based Approach for Estimating Staff Training in Software Industry

The successful completion of a software development process depends on t...
03/06/2022

Establishing Traceability Links among Software Artefacts

Artefact management in a software development process is a difficult pro...
11/21/2017

Finding an Effective Classification Technique to Develop a Software Team Composition Model

Ineffective software team composition has become recognized as a promine...
10/13/2021

HEDP: A Method for Early Forecasting Software Defects based on Human Error Mechanisms

As the primary cause of software defects, human error is the key to unde...

I Introduction

Software requirement elicitation is a fundamental and critical part of the software development life cycle. It is generally accepted that the quality of software depends on the requirements upon which software has been developed. The success or failure of a software development effort is greatly influenced by the quality of the requirements. Therefore, we require a variety of elicitation techniques beforehand to determine the user or customer needs. Though it is difficult to gather complete requirements from the users but choosing the best elicitation technique available in context with the software characteristics might ensure the completeness of requirements. In their study, BELL et al. [1] observed that, ”The requirement for a system do not arise naturally; instead, they need to be engineered and have continuing review and revision”.

It has been found that the cost of rectifying errors in software increases exponentially as one approaches the later phases of software development. Hence, the identification of missing and incorrect requirements in the requirement elicitation process itself would help to reduce the cost of rectifying errors in the software. If one identifies all incorrect and missing requirements then, theoretically the cost of rectifying errors later would approach zero. However, simultaneously the time taken to identify all such missing and incorrect requirements is infinite and hence, undertaking such a kind of task is impossible [73]. Thus, all we can do is, optimizing the process of requirement elicitation thereby doing it better and faster.

The selection of suitable requirement elicitation techniques for a specific domain of a software project is a challenging issue. In the literature, we identified that there exist numerous techniques of requirement elicitation to gather requirements but, due to the lack of proper contextual knowledge of their use, it is difficult to choose the right technique [74]. There are a number of variables influences this selection process. Generally, the techniques are chosen by the requirement analysts for the specific project through their interest or experience. In the upcoming arena, there are numerous numbers of methods or techniques have been proposed by various authors to acquire information for the purposes of eliciting [19][21]. The motivation behind the study is to create a simple mapping platform between requirements elicitation techniques and threefold matrix consisting project, people and process attribute. The basic idea of mapping approach is taken from the astrology (Kundli) software. The process of eliciting requirement, not only helps the organization to gather the requirements, but also in the analysis of requirement.

In this paper, we propose a framework to select effective elicitation techniques i.e., Choosing a small subset of requirements elicitation techniques from the set of techniques. Moreover, we focus to identify the project, people and process attributes for any problem domain and find out the relationship between these available three p matrix (3PM) with the available techniques to provide a guidance on selecting requirement elicitation technique. So, we could improve the average analyst’s abilities to select a set of elicitation techniques, and we will most likely to improve the successfulness of software systems. Using all these matrix parameters, we applied a mapping mechanism on the framework for the evaluation and selection of requirement elicitation techniques. We have demonstrated the applicability of these matrices on the case studies and their comparison with the other elicitation based approaches. The results suggested that the matrices are capable of selecting a set of effective elicitation techniques for a software in order to effectively elicit, model, document, verify and validate requirements.

The rest of the paper is organized as follows. Section II, provides the background information about the requirement elicitation techniques. Section III, presents the data collection strategy for the matrices. Section IV, describes an overview of the proposed framework. Section V, explains our approach and framework via case studies. Section VI, presents the comparison of our approach with other RE approaches. Subsequently, discuss the applicability of the proposed approach and other related issues in Section VII. We present related work in Section VIII, and finally summarize our conclusions in Section IX.

Ii Background Overview

Ii-a Problem Description

Requirement elicitation is a process of determining the problems and needs of the customer, so that software developers can construct a system that actually resolve customer problems and address their needs [33][34]. Understanding requirements is a difficult task because it involves natural language to interact with the end-users, and end users may provide incomplete and ambiguous requirements. Requirements are volatile in nature, and they change over the period of time. There are some social issues also, that affect requirement elicitation process. The process of selecting an elicitation technique is affected by a number of other parameters also. Often requirement analysts choose a technique based on the some assumptions [11]. That are:

  • This is the only technique which are they are known.

  • Because this technique works effetely last time, so it will also work at this time.

  • The analyst intuitively understands that the technique is effective in the current circumstance.

  • The analyst is following some explicit methodology, and that methodology prescribes a particular technique at the current time.

Number of authors study about requirements elicitation problem [3][10][11][12][40], and they confirm that the problem is at much larger scale. Surveys revealed that one third of the projects started were never completed, and one half of them succeeded only partially. The reason behind such failure is poor requirement elicitation - more precisely, the lack of user involvement, requirement incompleteness, ambiguity in requirements, unrealistic expectations and unclear objectives [17].

Ii-B Literature review: Techniques for Requirement Elicitation

Many articles and books describe a way to perform requirement elicitation task. Most of the time practitioners are looking for a simple recipe that will solve all their elicitation problems. However, because of the nature of this problem, one elicitation technique cannot work in all situations. Therefore, the number of authors describes various requirement elicitation techniques [19][20][21][22][23][24][25].

Requirement elicitation techniques can be divided into four categories according to their nature of communication - traditional, contextual, collaborative and cognitive. The categorization of these requirement elicitation techniques refer from the Lecture of Requirement Elicitation at University of Toronto, department of computer science.

Ii-B1 Traditional Techniques

Interview is a method of identifying facts and opinions of users and other stakeholders of the system under development by face to face conversation. There are two different kinds of interviews: The closed interview, where the requirements elector has a pre-defined set of questions and is looking for their answers. The open interview, where the requirements engineer and stakeholders discuss in an open-ended way to find out their expectation from a system.

Questionnaire is a technique of eliciting requirement from a large number of people in lesser cost and time. A well designed questionnaire can be useful to elicit the actual requirements from the stakeholders.

Data gather from existing system is used when we gather data for a system to replace an existing one. It is a useful technique to collect the depth knowledge of the system.

Survey is a technique of eliciting requirement from a large number of people. It covers the entire region to collect a huge set of requirements. It is generally used for collecting requirement for general purpose software.

Ii-B2 Collaborative Techniques

Focus Group is a technique where a group of four to nine users from different backgrounds, with different skills discuss in a free form, and concerns about features of a system that will be created.

Brainstorming provides an open environment of discussion, where users are free to give their requirement and expectation of the system. The data (ideas) collected after this process is then discussed and analyzed.

JAD (joint application development) is a requirement definition and software system design methodology in which stakeholders, subject matter experts (SME), end-users, software architects and developers attend intense off-site meetings to work out a system’s detail. JAD focuses on the business problem rather than technical details.

Prototyping: A prototype of a system is an initial buildup of the system which often used to validate system requirement. There are two different types of prototypes: Throw-away prototypes help to understand difficult requirement. Evolutionary prototypes deliver a working system to the customer and often become a part of the final system.

Work shop is a collection of different types of stakeholders together to collect requirements for the project being developed. The workshop provides the complete set of requirement. It is very useful to elicit requirement for complex and large system.

Story boarding uses images, text, audio, video, animation diagram to visualize the concept to the stakeholders. This technique is allowing the stakeholders to come into common understanding of about the functionality of the system being developed.

Models include diagram such as Data flow diagram, Statechart, UML diagram to elicit requirement. The models use for the purpose to help the customer to thought the process. Models are useful for eliciting requirement and to resolve conflict between stakeholders.

Use cases/Scenarios: Use cases describe interactions between the user and the system to find user need. It specifies a sequence of interaction between a system and an external actor. Use cases represent functional requirements of the software system. Scenarios should include a description of the state of the system before entering and after completion of the scenario, what activities might be simultaneous, the normal flow of events and exceptions to the events.

Ii-B3 Cognitive Techniques

Document Analysis is the process of analyzing the documents related to the problem domain to gather the information which is flowing in the organization. It is a useful technique to find in-depth knowledge about a particular task.

Card sorting: The card sorting method is used to generate information about the associations and grouping of specific data items. Participants in a card sort are asked to organize individual, unsorted items into groups. Card sorting may be conducted as a series of individual exercises, as a concurrent activity of a small group, or as a hybrid approach where individual activity is followed by group discussion of individual differences.

Protocol analysis is a method of conducting a meeting where stakeholders and analyst discuss the requirements of the system. Protocol analysis also provides the required actions to be taken for fulfilling the user requirements by using rationale.

Laddering is a form of structured interview in which a limited set of standard questions is asked to stakeholders. The set of questions is arranged in hierarchical order. The requirement for the success of this technique is that stakeholders have the domain knowledge.

Repository grid is a technique of developing a grid of the form of a matrix store the requirements involve asking stakeholders to develop attributes and assign values to a set of domain entities. It is a good technique to provide the distinction between different information domains.

Ii-B4 Observational Techniques

Observation: Observational methods involve an investigation of user’s work and taking notes on the activities that takes place. Observation may be either direct or indirect. Observation allows the observer to view what users actually do in context, overcoming issues with stakeholders, describing idealized or oversimplified work processes.

Ethnography/Social analysis is the process of interacting with stakeholder and user of different background to find out political environment within the organization. The observers go through the in depth observation of the organization to understand working and cultural environment.

Iii Data Collection - Matrices

In this section, we present the strategy that we applied to select papers for populating the matrices. We initiated our search by identifying a query string being used to perform electronic searches, based on the 3PM. Then, we searched four electronic databases using this query string (IEEE Xplore, Springer, ACM digital Library, Science Direct). In addition, as a complement to the electronic search, we performed manual search in specific journals and conference proceedings, and also manually checked Software Engineering textbooks. We then scanned all the sources resulting from this two-stage search to select the works to be included in the review. During this step we applied inclusion/exclusion criteria to select the techniques. For each paper, we read the paper’s title and abstract to see whether it was relevant to our research topic. If the title and abstract of the paper could not help us make a decision, we further checked the paper’s full text. In order to augment our collection of primary studies, we scanned the reference lists of all the identified primary studies to identify additional papers. Furthermore, we also went through publication lists of primary studies’ authors to make sure that the most recent publications on the same or similar topics were included.

In order to select an elicitation technique(s) for yielding an optimum result in the requirement elicitation process, we examine the merits of the elicitation techniques with respect to the project, process and the people of the software under development. Here, we collected the information about the stated parameters from the research papers [10-11][19][39][41-42][45][47-48][50][52][54-55][61-63][66-70][72], experience reports [36-37][40][57-59][71], white papers [38][51][58][56][65] and the project documents [44][35][46] to provide the methodological guidance about the selection of the techniques [43][49][53]. This helps us to create the matrices for all the three parameters. The research approach utilizes the extracted information about the software project to identify the set of elicitation techniques. This helps the analyst to gather quality requirements from the stakeholders that would result good quality software. Getting a subset of techniques from the larger available set of elicitation techniques will help the system analysts to concentrate only on the identified techniques, instead of, choosing the technique on the basis of personal experience of analysts. Choosing the right technique, for the right project, and at right time, leads to quality software. Since, last 60 years of experience in software development, about the success or failure of the software project. It seems that, if we collect the information about the project success, failure, methods, techniques applied, dos and don’ts etc., we would achieve a very strong knowledge database of the software. This database would be very helpful in achieving the goals in context with the software and might be, we are in the positions to minimize the error/bugs in the software development life cycle.

Iv Framework Overview

In this section, we present our proposed framework for the selection of requirement elicitation technique. This framework provides us the guidance to choose the requirement elicitation techniques in context with the affected parameters of the software i.e., people, process and the project attributes. As we know, requirement elicitation is performed in a wide variety of conditions, which include many dimensions representing various combinations of participants, problem domain, and organizational context.

Assumptions
First, let us consider the basic assumptions for successful execution of our approach.

  • A team of requirement analysts is available for performing the task, of applying the proposed approach.

  • Identifying various important attribute in three dimensions namely project, people and process of the software development by the analysts for the software project being undertaken.

The framework are in four-folds:

  1. Identify various important attribute in each of three dimensions namely project, people and process of the software development separately.

  2. We construct three p matrix (3PM) separately for each dimension of the software and their relationship with the elicitation techniques and use them in the selection of one or more elicitation technique for a given software project to be undertaken.

  3. Extract the information about the elicitation techniques on the basis of 3P parameters.

  4. Provide a mapping mechanism to choose the set of elicitation techniques, to gather the requirement on the basis of 3PM and knowledge base for analysts to make a decision regarding selection of elicitation techniques.

In order to achieve these objectives, we have developed 3P matrix and a methodology within the framework for the selection of requirement elicitation technique. The proposed framework is given in Figure 1.

file=framework.eps, height=2.3in, width=3.3in

Fig. 1: Overview of the proposed framework

Iv-a 1P: Project Matrix

In this subsection, we define a set of software project attributes for a given software product. The project attributes play an important role when it comes to the project characterization and selection of elicitation techniques. Figure 2 shows the set of project attributes used in our study for the selection of RE techniques. The purpose of this step is to understand the basic characteristics of the project and score the attributes as per the required elicitation technique. For eliciting the requirements of the user, the important issue is to incorporate the project attributes of the software project going to be developed, to choose the elicitation techniques. Here, we have developed a relation matrix between the project attributes and available elicitation techniques. This helps us in taking a decision to choose the appropriate elicitation techniques for the software project being developed. Each of these project attributes are shown in Table I in relation with the set of elicitation techniques.

file=attributes.eps, height=4.2in, width=3.5in

Fig. 2: Project attributes with their descriptions
file=project.eps, height=4.2in, width=7.2in
TABLE I: Project attributes matrix

Iv-B 2P: People Matrix

Moreover, the people involvement plays an important role in the software development process and also in the selection of elicitation techniques. The people behavior, knowledge, skill, experience and other parameters might affect the software development activity. The purpose of this step is to understand the basic characteristics of the people in accordance with the software project being undertaken. This matrix helps us to choose the elicitation technique on the basis of people attributes. In the people matrix, the ’N’ represent No and ’Y’ represent Yes. The relation between the elicitation technique and the people attributes are shown in Table II.

file=people.eps, height=4.5in, width=7.1in
TABLE II: People matrix

Iv-C 3P: Process Matrix

A set of software processes was defined in the books and research papers for effective and efficient software development. The processes involved in the software development may play an important role, when it comes to the selection of elicitation techniques. Each of these attributes of software processes are shown in Table III in relation with the set of elicitation techniques. In this process matrix, we have filled the values between 0 to 1, on the basis of required score, the corresponding technique is used for that software process. The values specified in the process matrix are based on the available knowledge from the reports, white papers, research papers etc. The reason to specify these values in number, due to the nature of software processes as they can be applied in any software irrespective of its domain. There exist two cases when analyzing the results of the process matrix i.e., Case 1: If the score of elicitation technique is less than 0.5 (Score0.5), then it is decided not to use them for that process model and Case 2: If the score of elicitation technique is greater than or equal to 0.5 (Score0.5) then, it is an effective technique to use for that process model.

file=process.eps, height=3.8in, width=7.0in
TABLE III: Software process matrix

Iv-D Mapping Criteria

In order to apply the combination of all three p matrices for a given software project and, to identify the set of elicitation techniques, a systematic methodology is needed to ensure success. We, therefore develop a mapping function for requirement elicitation techniques selection. Let us consider the three p matrix (3PM) , and respectively where, i represents the set of elicitation technique, j represents the set of project attributes, k represents the set of people characteristics and l represents the set of software development process models.

The criteria used for selecting the subset of elicitation technique, on the basis of three P matrices are as follows.

  1. We divide the undertaken software project into the attributes of project, people and process. This is done according to the characteristics of the software, as identified by the requirement analysts during the feasibility study phase of software development (This is a very first phase before requirement elicitation process).

  2. Next, we identify the subset of techniques from each p matrix by simply analyzing them i.e., For , for each project attribute we get some set of elicitation techniques. To get the subset of elicitation technique for the matrix, we do the union of techniques identified corresponding to each attribute.

  3. Next, we do union of all the techniques determined in each p matrix. Step 1 and 2, resulted a subset of non-repeated elicitation techniques i.e., Set of Elicitation technique in Set of Elicitation technique in Set of Elicitation technique in Final subset of elicitation technique using 3PM according to the software project being undertaken.

  4. Next, we perform feasibility study from user as well as analyst (elector) points of view to determine the set of techniques that are actually applicable during the elicitation process.

V Case Studies

This section shows the applicability of the proposed approach using several case studies. We apply the approach to an IPOS [55] (Intelligent Power Optimization System) project, Online shopping mall project and Bhoomi E-governance project. First project is an intelligent power optimization system, second is a web based portal of a shopping mall and last one is a government project which provide information of about roads and lands of a state. Moreover, presented case studies have been conducted throughout the course of this research. In these case studies, we analyze the project attributes, software processes and people characteristics of each project. Next, these identified characteristics are used as an input in our framework to develop a relationship between the requirement elicitation techniques and 3P parameters corresponding to the software projects. For these case studies we make some assumptions based on our best knowledge to find the parameters of the project.

V-a IPOS Project

V-A1 Project Description

This project is a large sized project to develop an Intelligent Power Optimization System (IPOS). A set of elicitation techniques are selected by requirement analysts by applying the proposed approach. The selected techniques were considered, the most suitable techniques for the project IPOS. The following subsections give a brief description of the case study and the major findings.

V-A2 Technique Selection and their Usage in Project

First, we identify the project attributes of the IPOS project i.e., (i) Project Size: Large (between 1000 to 4000) (ii) Project Complexity: Very High (iii) Requirement Volatility: Very Low (iv) Degree of Criticalness: High (v) Time and cost constraint: Low (vi) Project of existing domain: Existing and so on. Using the project attribute matrix, we identified that Focus group, Interview, Ethnography are the recommended techniques.

Next, we identify the people attributes of the IPOS project i.e., User/Stakeholders: Novice, experience, communicative; Developer/Analyst: Novice, experience. Using the people attribute matrix, we identified that Observation, Interview, Focus group are the recommended techniques.

Similarly, for the process attributes of the IPOS project, i.e., for the agile process model, we get the following techniques: Interview, focus group, workshops, observation, ethnography, prototyping, models etc.

V-A3 Results

Finally, using the mapping criteria we suggest the small subset of elicitation techniques for the IPOS project. The recommended techniques are Interview, focus group, workshops, observation, ethnography, prototyping, models.

V-B Online shopping mall project

V-B1 Project Description

The Online Shopping Mall (OSM) web application is intended to provide complete solutions for vendors as well as customers through a single get way using the internet as the sole medium. It will enable vendors to setup online shops, customer to browse through the shop and purchase them online without having to visit the shop physically. The administration module will enable a system administrator to approve and reject requests for new shops and maintain various lists of shop category.

V-B2 Technique Selection and their Usage in Project

First, we identify the project attributes of the OSM project i.e., (i) Project Size: Medium (between 100 to 1000) (ii) Project Complexity: Medium (iii) Requirement Volatility: Medium (iv) Degree of Criticalness: Medium (v) Time and cost constraint: Low (vi) Project of existing domain: New and so on. Using the project attribute matrix, we identified that Brainstorming, Focus group, Interview, Ethnography, observations, models, questionnaire are the recommended techniques.

Next, we identify the people attributes of the OSM project i.e., User/Stakeholders: Novice, Silent; Developer/Analyst: Novice, experience. Using the people attribute matrix, we identified that Observation, Interview, Focus group, prototyping are the recommended techniques.

Similarly, for the process attributes of the OSM project, i.e., for the prototyping process model, we get the following techniques: Interview, focus group, workshops, prototyping etc.

V-B3 Results

Finally, using the mapping criteria we suggest the small subset of elicitation techniques for the OSM project. The recommended techniques are Interview, focus group, workshops, observation, ethnography, prototyping.

V-C Bhoomi E-governance project

V-C1 Project Description

The purpose of Project Bhoomi is to present a highly scalable, extendable, robust, user-friendly, easily deployed and cross-platform prototype for a software system for managing the City Land Record Management System of a State. The objective is to provide free flow of information and better governance through the use of technology (e-Governance). A person should be able to access the desired information anytime-anywhere. At the administration/governance side, the software solution should provide easier and effective editing (addition/removal/change) of records and a better control and monitoring of the land records, apart from the requirements above.

V-C2 Technique Selection and their Usage in Project

First, we identify the project attributes of the Bhoomi project i.e., (i) Project Size: Large (between 1000 to 4000) (ii) Project Complexity: Very High (iii) Requirement Volatility: Very Low (iv) Degree of Criticalness: High (v) Time and cost constraint: Low (vi) Project of existing domain: Existing and so on. Using the project attribute matrix, we identified that Focus group, Interview, Ethnography, Observation, Models, Survey, Introspection are the recommended techniques.

Next, we identify the people attributes of the Bhoomi project i.e., User/Stakeholders: Novice, experience, expert, communicative; Developer/Analyst: expert, experience. Using the people attribute matrix, we identified that Brainstorming, Observation, Interview, Focus group etc are the recommended techniques.

Similarly, for the process attributes of the Bhoomi project, i.e., for the waterfall process model, we get the following techniques: Brainstorming, Interview, focus group, workshops, observation, ethnography, models, questionnaire, analysis of existing domain, concept/mind mapping etc.

V-C3 Results

Finally, using the mapping criteria we suggest the small subset of elicitation techniques for the Bhoomi project. The recommended techniques are Brainstorming, Interview, focus group, workshops, observation, ethnography, models, questionnaire, analysis of existing domain, concept/mind mapping, survey.

Vi Comparison with Other Approaches

This section presents the validation of the proposed approach in comparison with other approach presented by [55][56]. Table IV shows the comparison between the techniques where ‘Y‘ represents the presence of property. In the work reported, [55] presented their experience of improving the requirements engineering process for a software project using a combination of Requirement Engineering (RE) techniques based on project attributes and characteristics of RE techniques. The case study of IPOS is conducted which shows a positive result of the application of a combination of RE techniques to a software project using only project characteristics. Similarly, we have also included a case study of IPOS to apply the proposed approach using all the three matrices. The results identified (see Section Case Studies) suggests that the populated matrices are useful for selecting the subset of requirement elicitation techniques on the basis of project, people and process attributes.

Jiang et al. [56], presented a methodology for RE process development for a given project where first, a RE Process Knowledge Base (REPKB) is established. Second, a decision support mechanism is provided during RE process development. Third, this methodology uses three components: process building blocks, standard templates of the RE process and development guidelines, to help process development. Fourth, it explicitly links project characteristics with RE process development so that the most suitable RE process can be developed. Similar, to this approach we have also generated the three matrices to acquired the knowledge about the elicitation techniques. In their approach, they had only considered the project attributes, while others are not considered.

# [55] [56] Our Approach
Project Characteristics Y Y Y
People Attributes - - Y
Process Attributes - - Y
Effective Approach Y Y Y
TABLE IV: Comparison

Vii Discussions

Identify the set of elicitation techniques for the software project to be undertaken is an important task to gather quality requirements. In this paper, we have proposed an approach where we identify some initial characteristics of the software before the process of requirement gathering begins. These initial characteristics are project attributes, people attributes and the process model involved in the software. The reasons to include all these parameters are:

  • The requirement gathering process is a human centric process. Thus, it needs to include the behavior or skills of the people that directly or indirectly involved with the software project.

  • The software project is influenced by several parameters. Therefore, it is important to include the project attributes in our study.

  • The process models involved in the development of software, needs some set of elicitation techniques according to the behavior. So, we have also included the process models as an important parameter for the study.

This information will be extracted with the help of project managers, requirement analysts to identify these above stated parameters for the software project. The obtained information and available information in the matrices database are combined with the available techniques to identify the set of elicitation techniques. Moreover, it is not mandatory to use all three matrices together for getting optimum elicitation technique. They can be used separately depending upon the type of software project being undertaken, or on the basis of industry experience. The information/values stated in the matrices might be used by researchers or industry persons to populate, for further detailed study.

The limitations of our research are influence by the scope of elicitation technique which we included and our understanding of these techniques. The state-of-the-practice in RE is still one of the major problems in software development; it is very difficult to reach to any conclusion for selecting requirement eliciting techniques. But by analyzing the domain of problem we can find some characteristics of the system, which can help us to making decision of selecting requirement eliciting techniques.

The proposed approach has some limitations. The approach presented is a heuristic because we have taken some assumptions to identify the requirement gathering techniques due to the lack of information or guidance related to requirement engineering. We have taken the help of various research papers to maintain the database and for filling the relevant information required to gather the requirement. Although, we know that the mapping function used by the approach is theoretical one, but it might be helpful to the analysts for choosing the set of best elicitation techniques.

Viii Related Work

The selection of suitable RE techniques for a specific domain of software project is a challenging issue. Number of variables influences this selection process. To overcome this challenge, several solutions have been proposed by many authors in different perspectives: Method engineering [3][4][5][6][7][8][20] provides approaches to develop or adapt existing methodologies to the new problem domain. Maiden et al. [9] proposed a framework which provides guidance to selecting technique for requirement elicitation. Hickey et al. [10][11] proposed a model that helps to understand the RE process and the selection of elicitation techniques. Bickerton et al. [12] provide a framework for the classification of elicitation techniques based on the social assumptions. Macaulay [2] proposes a list for the selection of elicitation techniques. Kotonya et al. [13] proposed characteristic attributes which can be helpful for the selection of elicitation techniques. Davis et al. [14] also proposed a process for elicitation technique selection based on four strategies of the requirements determination model and focuses on the selection of RE elicitation techniques. Browne et al. [15] also proposed guidance for the selection of elicitation technique. Lobo et al. [16] developed an approach for elicitation technique selection based on a predefined RE process model. Lausen [18] discusses several techniques, which can be used in the RE process. He also provides an idea for elicitation technique selection. After of many study and research, the problem of RE is not address properly and there is still lack of proper contextual information for selecting elicitation is available.

Viviane et al., [26] proposed an collaborative approach for requirement elicitation process. There approach consists of a knowledge model based on the stories about the system and a tool to support interaction. Suranjan et al., [27] describe an approach to provide a guidance for the process of requirement engineering. Their study collaborates based on the four states and identifies important factors that tends to trigger from one state to another state. Ruben et al., [28] provides a framework based on the need of modeling primitives and it supported by the mean of theoretical and modeling foundation of a social science framework. Yan Tang et al., [29] proposed a framework to provide the guidance for the selection of requirement elicitation technique. Bee Bee et al., [30] proposed guidance for understanding the use of elicitation approach for effective requirement gathering. Sumaria et al., [31] introduces a way and the guidance for selecting requirement elicitation techniques. They analyzed different elicitation techniques in the context of different project settings. Zhying [32] provides a comparison of different requirement elicitation techniques and concludes his findings.

Ganesh et al., [60] presented literature study and the experimental case study on analyzing and compare different methods for requirement gathering process, this provides the flexibility to requirement engineers to know the characteristics and effectiveness of every method. All these information might be useful to select the particular elicitation method depends on the type of application and the situation. On the other hand, due to lack of guidance on which techniques are suitable for a certain project context it is difficult to choose the set of elicitation technique. Thus, Jiang et al., [64] proposed a methodology for Requirements Engineering Techniques Selection (MRETS) as an approach that helps requirements engineers select suitable RE techniques for the project at hand.

In this paper, we focus our effort to identify the characteristics of any problem domain in the context of project attributes, people and process of software development and then try to find the relationship between characteristics and available techniques to provide a guidance of selecting requirement elicitation technique. Then, we would be able to improve the average analysts abilities to select proper elicitation technique.

Ix Conclusions and Future Work

This paper has attempted to present meaningful insights into the feature of different types of requirements elicitation techniques. As discussed above that RE process is highly influence by three parameters namely people characteristics, involved processes and the project attributes. Each elicitation technique has a predefine set of specific and unique characteristics and their context of application. In this paper, we present an approach to select a subset of requirement elicitation technique for an optimum result in requirement elicitation process. The proposed approach first, identifies the attributes in three dimensions namely project, people and process of the software development, that can influence the outcome of an elicitation technique. Second, we construct three p matrix (3PM) separately which shows a relation between elicitation techniques and three dimensions of a software. Finally, we provide a mapping criteria and use them in the selection of elicitation techniques.

We aim to extend this work by incorporating the industries data in 3P matrices and subsequently, analyze these matrices by applying the organization specific case study for the selection of elicitation techniques.

References

  • [1] T. E. Bell and T. A. Thayer ”software requirements: are they really a problem” Proceedings of the 2nd international conference on Software engineering p 61-68 IEEE Computer Society Press, 1976.
  • [2] Macaulay, L.A”Requirements engineering” Requirements Engineering Macaulay, L.A., Springer-Verlag, Berlin, Heidelberg, New York p 206, 1996.
  • [3] Kumar, K., Welke, and R.J ”Methodology engineering: a proposal for situation specific methodology construction” in Challenges and strategies for research in systems development p 257-269, 1992.
  • [4] Brinkkemper, S ”Method engineering: engineering the information systems development methods and tools” Information and Software Technology Method Engineering and Meta-Modelling vol 38, Issue 4, 1996, p275-280, 1996.
  • [5] Rossi, M., Tolvanen, J.P ”Using reusable frameworks in development of a method support environment” Proceedings in the WITS RTWH, Aachen ,vol. 95, no. 15, p 240-249, 1995.
  • [6] Lyytinen, K., Welke, R ”Meta modeling and method engineering” Special issue on Meta modeling and method engineering. Information System International Journal vol 24, no. 3, 1999.
  • [7] Tolvanen, J.P ”Incremental method engineering with modeling tools: theoretical principles and empirical evidence”, PhD thesis, Computer Science, University of Jyv skyl , 1998.
  • [8] Saeki, M ”Software specification, design methods and method engineering” International Journal on Software Eng. Knowledge Eng, Citeseer, 1994.
  • [9] Maiden, N., Rugg, G. ”ACRE: selecting methods for Requirements acquisition” software engineering journal vol 3, no. 11, may 1996.
  • [10] Hickey, A.M., Davis, A.M ”Requirements elicitation and elicitation technique selection: a model for two knowledge-intensive software development processes”. Proceedings of the 36th Annual Hawaii International Conference on System Sciences, p 96-105, Jan 2003.
  • [11] Hickey, A.M., Davis, A.M ”Elicitation technique Selection: how do experts do it?” Proceedings of the 11th IEEE International Requirements Engineering Conference, P169 - 178, 2003.
  • [12] Bickerton, J.M., Siddiqi, J ”The classification of requirements engineering methods” Proceedings of IEEE International Symposium on Requirements Engineering p182-186. San Diego, CA, USA, Jan, 1993.
  • [13] Kotonya, G., Sommerville, I.”RE, Processes and Techniques” John Wiley and Sons Ltd, New York, 1998.
  • [14] Davis, G.B ”Strategies for information requirements determination” IBM System Journal vol 21, no.1, p4-31, 1982.
  • [15] Browne, G.J., Ramesh, V ”Improving information requirements determination: a cognitive perspective” Information and Management vol 39, No. 8, p625-645, Sep, 2002.
  • [16] Lobo, L.O., Arthur, J.D ”An objectives-driven process for selecting methods to support requirements engineering activities” In 29th Annual IEEE-NASA Software Engineering Workshop, p118-130, April, 2005.
  • [17] Standish Group. CHAOS Demographics and Project Resolution, 2004.
  • [18] Lauesen, S ”Software Requirements: Styles and Techniques” Addison Wesley, New York, 2002.
  • [19] Goguen, J.A.; Linde, C. ”Techniques for requirements elicitation” Proceedings of IEEE International Symposium on Requirements Engineering, p152-164, Jan 1993.
  • [20] Brinkkemper, S., Lyytinen, K., Welke, R ”Method Engineering, Principles of Method Construction and Tool Support”, Chapman and Hall, London, 1996.
  • [21] Kotonya, G. and Sommerville, I. ”Requirements Engineering: Processes and Techniques” John Wiley and Sons, 1998.
  • [22] Leffingwell, D. and Widrig, D. ”Managing Software Requirements - A User Case Approach” 2nd Edition Addison- Wesley, 2003.
  • [23] Maiden, N.A.M. and Rugg, G. ACRE ”Selecting Methods for Requirements Acquisition” Software Engineering Journal, vol. 11 No. 3 p183 - 192,1996.
  • [24] Nuseibeh, B. and Easterbrook, S. ”Requirements engineering: a roadmap” Proceedings of the Conference on The Future of Software Engineering, ACM Press, p35 - 46, 2000.
  • [25] Rugg, G. and McGeorge, P ”The concept sorting techniques” The Encyclopedia of Library and Information Science, vol. 65 No. 28, p43 - 7, 1999.
  • [26] Viviane Laporti, Marcos R.S. Borges and Vanessa Braganholo, ”Athena: A collaborative approach to requirements elicitation” Computers in Industry 60 Page 367 380, 2009.
  • [27] Suranjan Chakraborty, Saonee Sarker and Suprateek Sarker, ”An Exploration into the Process of Requirements Elicitation: A Grounded Approach”, Journal of the association for information systems, Volume 11, Issue 4, pp. 212-249, April 2010.
  • [28] Rub n Fuentes-Fern ndez, Jorge J. G mez-Sanz, and Juan Pav n, ”Requirements Elicitation and Analysis of Multiagent Systems Using Activity Theory”, IEEE Transactions on systems, man, and cybernetics Part A: Systems and Humans, Vol. 39, No. 2, March 2009.
  • [29]

    Yan Tang, Kunwu Feng, Kendra Cooper and Jo o Cangussu, ”Requirement Engineering Techniques Selection and Modeling An Expert System Based Approach”, International Conference on Machine Learning and Applications, 2009.

  • [30] Bee Bee Chua, Danilo Valeros Bernardo and June Verner, ”Understanding the use of Elicitation Approaches for Effective Requirements Gathering”, Fifth International Conference on Software Engineering Advances, 2012.
  • [31] Sumaira Kausar, Saima Tariq, Saba Riaz and Aasia Khanum, ”Guidelines for the Selection of Elicitation Techniques”, 6th International Conference on Emerging Technologies, 2010.
  • [32] Zheying Zhang, ”Effective Requirements Development- A Comparison of Requirements Elicitation techniques”, SQM 2007.
  • [33] Ian Sommerville, Software Engineering, Eight Edition, Addison-Wesley, 2006.
  • [34] Shari Lawrence Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, Fourth Edition, Pearson, 2011.
  • [35] Shams-ul-arif,Qadeem Khan, S. A. K. Gahyyur, Requirements Engineering processes, tools/technologies and methodologies, International Journal of Reviews in Computing, IJRIC ISSN: 2076-3328, E-ISSN: 2076-3336, 2010.
  • [36] Markus Mannio, Uolevi Nikula, Requirements Elicitation Using a Combination of Prototypes and Scenarios, Telecom Business Research Center Lappeenranta, Research report, 2001.
  • [37] Ian Sommerville, Pete Sawyer and Stephen Viller, Viewpoints for Requirements Elicitation: a Practical Approach, Cooperative Systems Engineering Group Technical Report Ref: CSEG/16/1997, 1997.
  • [38] Dan Hong, Dickson K.W. Chiu and Vincent Y. Shen, Requirements Elicitation for the Design of Context-aware Applications in a Ubiquitous Environment, ICEC Xi an, China, ACM 2005.
  • [39] Zheying Zhang, Effective Requirements Development - A Comparison of Requirements Elicitation techniques, SQM 2007.
  • [40] Michael G. Christel and Kyo C. Kang, Issues in Requirements Elicitation, Technical Report CMU/SEI-92-TR-012 ESC-TR-92-012, 1992.
  • [41] A M Sen and K. Hemachandran, Elicitation of Requirements in Goal Oriented Requirement Engineering, Assam University, Journal of Science and Technology: Physical Sciences and Technology Vol. 5 Number II 64-72, 2010.
  • [42] Yuqin Lee and Wenyun Zhao, Domain Requirements Elicitation and Analysis - An Ontology-Based Approach, ICCS 2006, Part IV, LNCS 3994, pp. 805 813, 2006.
  • [43] A M Sen and K. Hemachandran, Goal Oriented Requirement Engineering: A Literature Survey, Assam University Journal of Science and Technology: Physical Sciences and Technology Vol. 6 Number II 16-25, 2010.
  • [44] E. Kazmierczak, Requirements Engineering, Course-work Masters, The University of Melbourne First Semester, Page 433-641, 2003.
  • [45] Haruhiko Kaiya and Motoshi Saeki, Using Domain Ontology as Domain Knowledge for Requirements Elicitation, IEEE-RE, 2006.
  • [46] Alistair Sutcliffe, A Technique Combination Approach to Requirements Engineering, IEEE, 1997.
  • [47] Kazuya Oshiro, Kenji Watahiki and Motoshi Saeki, Goal-Oriented Idea Generation Method for Requirements Elicitation, IEEE-RE, 2003.
  • [48] Julio Cesar Sampaio do Prado Leite and Ana Paula Pinho Gilvaz, Requirements Elicitation Driven by Interviews: The Use of Viewpoints, IWSSD-8, IEEE, 1996.
  • [49] Toshihiko Tsumaki and Tetsuo Tamai, A Framework for Matching Requirements Engineering Techniques to Project Characteristics and Situation Changes, Proceedings of SREP 05, Paris, France, August 29 30, 2005.
  • [50] Prasad Rajagopal, Roger Lee, Thomas Ahlswede, Chia-Chu Chiang, Dale Karolak, A New Approach for Software Requirements Elicitation, SNPD/SAWN 05, IEEE, 2005.
  • [51] zlem Albayrak, Duygu Albayrak and Tuna Kili , Are Software Engineers Responses to Incomplete Requirements Related to Project Characteristics?, IEEE, 2009.
  • [52] Alan Davis, Oscar Dieste,Ann Hickey, Natalia Juristo, Ana M. Moreno, Effectiveness of Requirements Elicitation Techniques: Empirical Results Derived from a Systematic Review, IEEE-RE, 2006.
  • [53] Axel van Lamsweerde, Requirements Engineering in the Year 00: A Research Perspective, Limerick, Ireland, ICSE 2000.
  • [54] Axel van Lamsweerde, Goal-Oriented Requirements Engineering: A Guided Tour, IEEE 2001.
  • [55] Li Jiang, Armin Eberlein and Behrouz H. Far, Combining Requirements Engineering Techniques Theory and Case Study, 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS), 2005.
  • [56] Li Jiang, Armin Eberlein and Behrouz Homayoun Far, A Methodology for Requirements Engineering Process Development, 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS), 2005.
  • [57] L. Jiang, A. Eberlein and B. H. Far, A RE process Template for Aiding RE process development, Technical Reports, August, 30, Dept. of Electrical and Engineering, University of Calgary, 2003.
  • [58] L. Jiang, A. Eberlein, B. H. Far, M. Majid, A Requirement Engineering Technique Selection Methodology, Technical Reports, August, 30, Dept. of Electrical and Engineering, University of Calgary, 2003.
  • [59] William foddy, Constructing questions for interviews and questionaires, theory and practice in social research, Cambridge university press, 1993.
  • [60] Sai Ganesh. Gunda, Requirement Engineering: Elicitation Techniques, masters thesis, university west, software engineering, 2008.
  • [61] Bill Davey and Chris Cope, Requirements Elicitation What s Missing?, Issues in Informing Science and Information Technology Volume 5, 2008.
  • [62] Ann M. Hickey and Alan M. Davis, A Unified Model of Requirements Elicitation, Journal of Management Information Systems / Spring 2004, Vol. 20, No. 4, pp. 65 84, 2004.
  • [63] Wesley James Lloyd, Mary Beth Rosson, James D. Arthur, Effectiveness of Elicitation Techniques in Distributed Requirements Engineering, Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE 02), 2002.
  • [64] Li Jiang, Armin Eberlein, Behrouz H. Far, Majid Mousavi, A methodology for the selection of requirements engineering techniques, Springer-Verlag 2007.
  • [65] Capt Hilliard Holbrook, A Scenario-based methodology for conducting requirements elicitation, ACM SIGSOFT software engineering notes, Vol 15, no I, Page 95, 1990.
  • [66] Shamal Faily and Ivan Fl echais, Eliciting Usable Security Requirements with Misusability Cases, IEEE-RE Conference 2011.
  • [67] Inah Omoronyia, Guttorm Sindre, Tor St lhane, Stefan Biffl , Thomas Moser, and Wikan Sunindyo, A Domain Ontology Building Process for Guiding Requirements Elicitation, REFSQ 2010, Springer LNCS, Pages 188-202, 2010.
  • [68] Nancy R. Mead, Requirements Elicitation Case Studies Using IBIS, JAD, and ARM, Software Engineering Institute, Carnegie Mellon University, 2008.
  • [69] Eva Hudlicka, Requirements Elicitation with Indirect Knowledge Elicitation Techniques: Comparison of Three Methods, ICRE, IEEE, 1996.
  • [70] Deepti Mishra, Alok Mishra, Ali Yazici, Successful Requirement Elicitation by Combining Requirement Engineering Techniques, IEEE, 2008.
  • [71] Linda Westfall, Software Requirements Engineering: What, Why, Who, When, and How, The Westfall Team, 2006.
  • [72] A. Dur n Toro, B. Bern rdez Jim nez, A. Ruiz Cort s, and M. Toro Bonilla, A Requirements Elicitation Approach Based in Templates and Patterns, Workshop em Engenharia de Requisitos, pages 17-29, 1999.
  • [73] Eric S. K. Yu, Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering, In Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE ’97). IEEE Computer Society, Washington, DC, USA, 226-235, 1997.
  • [74] Glenn J. Browne and Michael B. Rogich, An Empirical Investigation of User Requirements Elicitation: Comparing the Effectiveness of Prompting Techniques. J. Manage. Inf. Syst. 17, 4, 223-249, March 2001.