Stakeholders Selection Model for Software Requirements Elicitation

: Requirements elicitation is the most critical phase in software requirements engineering. The process is resource intensive, as it concerns with a lot of dedicated stakeholders gathering purposefully to present and stipulate software requirements. The extent of effectiveness of the process is greatly influenced by the suitability of the stakeholders in the process of gathering the requirements. Previous studies indicate that improper stakeholder selection normally lead to unsuccessful requirements elicitation process. Such phenomena would later cause serious impacts to projects such as costly rework, overrun schedule and poor quality software. This study addresses this issue by proposing a model for selecting the suitable stakeholders during requirements elicitation process. The study adopts both the quantitative data collection and analysis. The data gathering was done through survey questionnaire among 300 project managers and analysts. The study employs the Structural Equation Modelling (SEM) to analyse the quantitative data. The results indicate that selecting stakeholders with appropriate characteristics such as stakeholders role, knowledge and communication skills have significant effects on the requirements elicitation phase. The results also reveal that requirements elicitation phase has significant influence on requirements quality. This model is useful for project managers to decide on appropriate stakeholders who are going to be chosen based on their characteristics during requirements elicitation phase.


Introduction
Requirements elicitation is acknowledged as the first stage in Requirements Engineering (RE). It involves identifying, gathering and elaborating the requirements of stakeholders for a particular software system, ranging widely from the context of requirements, goals, constraints and features. Usually, this process is carried out through investigation and exploration. Generally, it is agreed upon by experts that requirements elicitation is a very crucial part of the RE process (Davis et al., 2006) as it has a direct influence on software quality and cost (Cybulski and Sarkar, 2005). The processes of requirements elicitation consist of identifying the key stakeholders and selecting the suitable techniques to gather requirements from those stakeholders (Zowghi and Coulin, 2005). It is vital to get the right requirements but at the same time it serves as a difficult part of software development Projects (Aurum and Wohlin, 2006). Due to that respect, the correct selection of stakeholders is critical. The selection of the right people to be involved in the right subjects at the right time is undeniably a leading factor that determines project success (Robertson, 2000). It is important to select the right stakeholders as to understand the working of an organization. Through gaining a clear understanding of the organization, software can be developed based on requirement specifications of high-quality (Pacheco and Garcia, 2009). In addition, identifying the stakeholders during the requirements elicitation process is important because it is at this phase that the relationship and communication between diverse groups begin. Having unsuitable people around will restrict the contribution and in effect, the system quality may be jeopardized. The appropriate candidates who are able to take part in an active and direct manner should be selected to establish feasible communication links. Not having clear criteria when recognising and choosing the best candidates to share and gather facts is one of the factors that can thwart effective communication during elicitation (Coughlan et al., 2003). The organisation of this paper is as follows. The following section offers relevant work concerning factors, model and methods of choosing the right stakeholders. Section 3 will put forth the research model for this study. Next, section 4 explains about the methodology used. Next, section 5 will elaborate on the result. Last but not least, section 6 concludes the paper with the main findings and future work summarised.

Related Work
The aim of this section is to give a clear overview of the stakeholders selection process during the requirements elicitation phase. The requirements elicitation process consists of a group of tasks, which enables interaction, prioritization and cooperation with the related stakeholders. The typical activities of the stakeholders selection process is divisible into two fundamental parts as described next.

Analysing the Stakeholders
There are several definitions available for the concept of stakeholders. For example, Freeman (1984) defined stakeholders as any group or individual who can affect or is affected by the achievement of the organization objectives. On the other hand, the term also means those who have a stake in the change being considered, those who stand to gain from it and those who stand to lose (Macaulay, 1993).
The influence of the stakeholders on a project varies from one another and their involvement can be huge. On the contrary, it can also include the development team who extracts, designs and builds the system as well as the system users who use the system to fulfil their daily tasks. The selection process should then consider different types, roles and influences held by various stakeholders (Sommerville, 2011). To satisfy all these criteria would be close to impossible, as projects are restricted by tight schedule and limited budget. As a result, the stakeholder analysis is necessary so that the stakeholders can be selected well.
It is well known that requirements elicitation is the phase that necessitates intensive communications among users and analysts to collect appropriate requirements. It is therefore very important to lay emphasis on human factors which are brought to the process by both users and analysts during interactions. These factors can be classified into several aspects: Role (Ballejos and Montagna, 2008;Glinz and Wieringa, 2007), interest (Ballejos and Montagna, 2008), knowledge and communications skills (Pacheco and Garcia, 2012;Pacheco and Tovar, 2007). It is essential that these human aspects are identified and considered in order to select the appropriate participants to be involved in the requirements elicitation process. It is believed that selecting participants with appropriate intellectual properties together with the right attitudes may spur effective communication because this later leads to the capturing of better requirements. Another possible means of identifying stakeholders is by weighing on their roles. For instance, potential stakeholders can be ascertained by analysing their interactions (Sharp et al., 1999). To add, stakeholders can also be found by imposing the conventional theory of power, legitimacy and urgency (Power, 2010). As it turns out, the more authoritative a stakeholder is, the more his or her participation in the project would be deemed important.
Being human, stakeholders bring certain values and preferences to a project. They are various backgrounds which means that they reflect specific knowledge. They also have certain interests. In the stakeholder selection place, relevant parties must consider stakeholders' knowledge and interests (Ballejos and Montagna, 2008). In terms of knowledge, stakeholders can be classified into two major categories: Inner and outer (Wan et al., 2010). The inner includes producers, such as developers, who work on the project and deliver some products via their technical knowledge. The outer consists of stakeholders who possess the business knowledge needed by the producers and they can include sponsors, consumers and consultants. In order to identify those stakeholders that have an interest in the project, they may be selected through personality testing and group dynamic principles (Young et al., 2001). Several studies have revealed that measuring stakeholders' level of interest in the project before they get involved is helpful when their suitability is gauged (Applegate, 2003;Ballejos and Montagna, 2008). It can be seen that various elements which govern stakeholder selection for RE process such as stakeholder's roles, knowledge, interest and communication skills have been discussed in studies done previously. However, those elements were identified separately and thus, they are narrow and isolated. It is also very vague how these elements are inter-linked with one another.

Selecting the Stakeholders
Few techniques and methods in the literature discuss the selection of stakeholders during the requirements elicitation phase. For instance, Galal and Sharp (1999) introduced an approach that emphasizes stakeholder interaction as a means to discover the possible stakeholders for a specific software project development. This approach consists of a set of elements called stakeholder baselines, which refers to groups of stakeholders. Each of these stakeholders plays a specific role. This approach may require ample time to discover the stakeholders' roles and relationships. In a related study, Glinz and Wieringa (2007) argued that to identify the stakeholders and their roles effectively, the people who are directly affected by the system, whose interest in the proposed system is high, who are responsible for system building and who are affected by the system in a negative way need to be searched. Similarly, Ballejos and Montagna (2008) proposed an approach for stakeholder identification in an inter-organizational environment. The approach takes into account stakeholders' attributes such as function, knowledge abilities, geographical position, hierarchy level, roles and interests. This approach starts with identifying the types and the roles of the stakeholders, selecting the stakeholders, associating them with their roles and measuring the interest in and influence of each stakeholder on the project. The number of stakeholders identified for this approach is high because there is no grouping or clustering criteria applied. Besides that, since the requirements elicitation phase need intensive communication between the analysts and the stakeholders, this method overlooked the communication skills factor that the stakeholders needed to conduct the requirements gathering in the right way. Robertson (2000) studied the identification process through Sociology approach where the focus is more on the knowledge of stakeholders. Young et al. (2001) proposed a method for stakeholder identification called Method Engineering with Stakeholder Input and Collaboration (MEWSIC), which applies personality testing and group dynamic principles. The method begins with identifying initial stakeholders through a project initiation document to define which stakeholders can be affected by or can affect the project. It is then followed by defining the project features and relating these features to each stakeholder. This method doesn't show how to conduct the stakeholders selection and has never been applied. To date, the process of selecting stakeholders for the requirements elicitation process is unstructured and unclear. Furthermore, the lack of clear criteria for identifying and selecting ideal candidates to share and gather facts is one of the factors that obstruct effective communication during elicitation (Coughlan et al., 2003). In fact, the approaches described above are not consistent and not all of them deal with the same factors. It is thus challenging to choose the appropriate stakeholders because those approaches only define the stakeholders without determining each stakeholder's role in a specific project, nor do they examine the stakeholder relationship, or cover the human aspects of stakeholder selection.

Research Model and Hypotheses
On the basis of the literature review and our pervious study results (Anwar and Razali, 2015), this study was able to identify the factors affecting stakeholders selection during the requirements elicitation phase. The factors are the stakeholders' role, knowledge, interest and communication skills as shown in Fig. 1. Based on these factors, this study formulated the hypotheses that informed the development of the research model, each of which is explained in detail in the following paragraphs.

Stakeholders' Knowledge
Software engineering can be considered as a problem-solving process involving intensive knowledge. To develop software, the team members should have knowledge. Along with the knowledge about the system development, business knowledge is among the resources deemed critical to ensure successful system development (Bassellier et al., 2001). Since knowledge is among the most important resources in software projects, insufficient amount of knowledge clearly results in risks (Gemino et al., 2007;Nidumolu, 1995), maximizes uncertainty (Iacovou et al., 2009) and hinders the process of learning (Ramasubbu et al., 2008). The pursuit of common goals in projects requires stakeholders to adapt their individual-level knowledge to the collective knowledge. Hence, users' knowledge has to be evaluated, leveraged, shared and sustained to bring advantages to the project (Martinsuo and Kantolahti, 2009). The recently acknowledged service-dominant logic concept also argues that the effectiveness of value creation is reliant on the level to which the operant resources can be immersed into the service design and the development process (Stuart and Tax, 2004).
In this 'information or knowledge era', both stakeholders and requirements are interrelated concepts. More specifically, stakeholders are the main requirements source. In software projects, stakeholders should actively participate in eliciting, analysing and communicating requirements because they possess invaluable information. As such, any project should take stakeholders with a specific level of domain knowledge into consideration. There is a need to identify people whose knowledge contributes to the success of the projects. It is crucial that the analysts to understand individual stakeholders and the type of knowledge required for the project. Based on the above arguments, the following hypothesis was proposed: H1: The selection of the stakeholders possessing the needed knowledge is positively associated with the effectiveness of the requirement elicitation phase.

Stakeholders' Role
Every software project has various types of stakeholders and each has a role to play. In any group situation, stakeholders have different roles, where the nature of these roles reflects the contribution of each individual to the requirements specification. In other words, the significance of the stakeholders lies in the fact that their activities in the software engineering process largely explain the project quality. Stakeholders are determined by the type of requirements required (Christel and Kang, 1992). They hail from various levels in the organization involving managerial or operational staff or both. Every stakeholder is chosen according to who he/she is and the role that he/she plays. Every role may be related to the level of influence on the project, with respect to participation and responsibilities, among others.
The identification of relevant stakeholders' roles entails looking for individuals who (Glinz and Wieringa, 2007): • Use the system or are directly involved in the process that the system is expected to change • Manage, introduce, operate, or maintain the system following its deployment; • Are responsible for the business that the system supports • Have a financial stake in the system, they may have ordered the system, paid for the system or are responsible for its sale On a final note, stakeholders have to be selected based on their roles and should be those from whom the system requirements can be elicited and validated. Thus, the above findings lead to the following hypothesis: H2: Stakeholder's roles are positively associated with the effectiveness of the requirement elicitation phase.

Stakeholders' Interest
Stakeholders are regarded as those who take part in a project and who have a degree of interests in the software developed and they may not be the same from one project to the next. Hence, it is essential to execute an adaptation assessment of the contributions of stakeholders and their interests in the project (Pacheco and Tovar, 2007). From the perspective of software system, a stakeholder is described as an individual, team or organization that is interested in or has concerns about the system (Kulkarni, 2008). The stakeholder theory offers a basis for the identification, classification and categorization of stakeholders and the understanding of their behaviour. The primary notion behind the theory is that the organization builds up the relationships with various constituent groups and it can maintain and support these groups by making sure that their interests are in harmony (Fontaine et al., 2006;Freeman, 1984).
Being humans, stakeholders bring specific values and preferences to the project and reflect various backgrounds. In projects involving diverse stakeholders, their interests and demands should be considered for project success (Diallo and Thuillier, 2005;Olander and Landin, 2005). The selection of stakeholders should take their interests into consideration. Studies show that measuring the levels of stakeholders' interests in the project prior to their involvement is important to determine their suitability for the project (Applegate, 2003;Ballejos and Montagna, 2008). Therefore, the following hypothesis was proposed: H3: Stakeholder interest is associated positively with the effectiveness of the requirement elicitation phase.

Stakeholders' Communication Skills
The biggest threat to the success of any software project is communication failure (Schwalbe, 2010). The outcomes of system implementation can be largely gauged from the degree of cooperation among the requirements analysts and stakeholders. The requirements analysts and stakeholders relationship could directly translate into the success or failure of software projects. Thus, communication skills still ranks as a critical criterion and such skills have become increasingly significant due to the fact that the economy has transformed into a technologyenhanced and information-oriented business. Various reasons exist for software system development failures. Such failures are often attributed to issues associated with human communication factors with respect to the determination of requirements (Alvarez, 2002;Price and Cybulski, 2007). Therefore, communication skills are considered in the present study.
Project managers should acknowledge the actions that can be taken to improve the communication environment prior to selecting a project team (Chen et al., 2005). The effectiveness of the communication between analysts and stakeholders leads to system success. Thus, the following hypothesis was proposed: H4: Selecting stakeholders with good communication skills is positively associated with the effectiveness of the requirements elicitation phase.

Requirements Elicitation
Eliciting requirements is considered as the most important and significant step in software development (Davis et al., 2006). It comprises seeking, determining, learning, acquisition, discovery and elaboration of potential stakeholders' requirements (Sharmila and Umarani, 2011;Zowghi and Coulin, 2005). Requirements elicitation is basically the initial phase of the software development cycle and as such, it is a prerequisite of all other major development activities. It is through software requirements elicitation that the exact details of the end-product are accurately determined. This stage entails the suitable identification of stakeholders in order to understand the environment in which the software project will be developed and operated and to ascertain which stakeholders would play an important role for the project. These are the critical elements of acquiring quality requirement specifications, which must be suitable, complete and unambiguous. This means that all stakeholders must succumb to the fact that appropriate knowledge is vital and nonstakeholders have to be disregarded.
Effective interaction among stakeholders is important to avoid conflicts and issues of communication stemming from various viewpoints. Moreover, elicitation is considered to be the most critical and difficult phase because its outcome reflects the system's activities and success/failure. This phase directly impacts the quality and cost of the software. Ineffective elicitation process generally generates poor requirements and this leads to a lowquality system, a delay in the schedule and an increase in costs (Price and Cybulski, 2007). For a successful requirements elicitation process, active and appropriate stakeholder participation is required. Hence, the following hypothesis was proposed: H5: The effectiveness of the requirements elicitation phase is positively associated with requirements quality.

Requirements Quality
Standing as a discipline, RE was developed when the requirement quality assumes the position as a primary factor in the prevention of the causes of software failure. Measures employed at an initial stage of a project may exert great influence and as such, they are more significant than the measures adopted in the later stages (Pacheco and Tovar, 2007).
If quality requirements are not defined in an effective manner, the system's outcomes cannot be evaluated for its success or otherwise before implementation. The IEEE Standard 830 offers a summary of the properties that should be part of software requirements specification and include completeness, correctness and consistency. Any identification process that mistakenly endorses someone as a stakeholder will include requirements that do not cater to any actual need (Pacheco and Tovar, 2007). On the other hand, if there is a failure to detect the participants needed for a software project, requirement specifications will not be complete owing to the omission of significant requirements for the success of the project and may also lead to inconsistent specifications. Therefore, the failure to obtain the needed requirements can lead to risks that may influence the project.

Sample and Data Collection
In order to test our proposed model, this study employed survey questionnaire with the probability sampling where representative individuals were selected from the population under consideration. In the context of the present study, the population comprises project managers and requirements analysts who are responsible for choosing the right stakeholders for requirements elicitation propose. The population is selected through a sampling procedure (Churchill, 1999). Sampling is confined to particular categories of people who can best provide the needed information, as they are the ones who possess the information or satisfy the criteria established by the researcher for the study. In the current research, 300 questionnaires were distributed among the organizations chosen as representative of the relevant population. Initially, 118 valid questionnaires were returned which accounted for a 39.3% response rate. This was thought to be sufficient for analysis as the recommended number of filled questionnaires for performing a research study on a large population, as per many experts, is 100 (Alreck and Settle, 1994). Table 1 lists the demographics of the respondents. The respondents were asked about their experience with respect to requirements elicitation, including their role, the number of years of experience had and the number of projects that they were involved in. The respondents were then asked regarding the domains and development types of those projects.

Measurements
This study included 6 main variables with a total of 23 items (see Appendix A). The variables measured included stakeholder's role, stakeholder's knowledge, stakeholder's interest, stakeholder's communication skills, requirements elicitation and requirements quality. To ensure content validity, the selected items used to define the constructs represented the concepts which were in-turn used for making generalizations. To achieve this, the constructs employed in the current work were primarily selected from prior findings of established research works and adjusted to meet the specific requirements of the present study. Table 2 lists the definitions, item numbers and associated references for each variable. This study utilized a six-point Likert scale with 1 representing "Extremely Disagree" to 6 representing "Extremely Agree". This scale was used to evaluate the perceptions of each respondent concerning statements related to the variables of the current research model. The questionnaire was structured into three sections. The first of which offered overview of the questionnaire. All respondents had to view these illustrations and confirm they were suitable to answer the subsequent questions. The second part presented the demographic questions. The third section presented the major items for measuring the variables. Before the main survey for the research was carried out, a pilot study was conducted in order to verify the effectiveness of the statistical instrument being used. One important method of analysis is validity testing which evaluates how well the selected instrument measures the specific concept it is being used to measure (Sekaran and Bougie, 2010). The test study involved five experts who were asked to give their comments regarding the length of the instrument, its format, their general understanding of the questionnaire and the wording of the scales. Their feedbacks were used to further refine the survey questionnaire and make it more effective for data acquisition. After the improvement, the finalized questionnaires for the main survey were distributed to randomly chosen individuals.

Data Analysis and Result
The software solutions used for data analysis in this study was Smart PLS version 2.0. Smart PLS enabled the researcher to obtain the causal relationships between questionnaire elements. Furthermore, the hypotheses were tested by studying the direction, the value and the significance level of the path coefficients estimated by the PLS method.

Measurement Model
The first step in PLS is to establish validity and reliability of measurement model. This study followed the validation guidelines of Urbach and Ahlemann (2010), which suggested to test the reflective measurement models for unidimensionality, internal consistency reliability, convergent validity and discriminant validity by applying standard decision rules.
Unidimensionality was assessed by evaluating the items through their loadings. Unidimensionality is usually satisfied by retaining the items whose loadings are above 0.5, indicating that they share sufficient variance with their related construct (Hair et al., 2010). A few items were excluded from the constructs in order to fulfill unidimensionality of each construct. Table 3 shows the items and their respective loading. The criterion for assessing internal consistency reliability is Composite Reliability (CR). Composite reliability takes into account that indicators have different loadings (Henseler et al., 2009). Moreover, determine the composite reliability of constructs ensures that the items of the measurement models are consistent internally. Composite reliability scores for each construct must be more than 0.7 of value (Hock and Ringle, 2010). A composite reliability score that is greater than 0.7 indicates that the variance of a given construct can justify at least 70% of the variance of the corresponding measure. Since the composite reliability of each construct in this study is above 0.7, the measures are reliable (Lewis et al., 2005). Table 3 below depicts the composite reliability value for each construct.
Convergent and discriminant validity were evaluated by way of examining the Average Variance Extracted (AVE) and the item construct correlations as produced by PLS. Convergent validity involves the degree to which individual items reflecting a construct converge are compared to items that measure different constructs. A commonly applied criterion of convergent validity is the AVE recommended by Fornell and Larcker (1981). An AVE value of at least 0.500 indicates that the latent variable is on average and thus it is able to explain more than half of the variance of its indicators. Table 4 points to the AVE value for each construct. All constructs are above 0.500, therefore, their convergent validity are met.
Meanwhile, discriminant validity refers to the degree to which the measures of different constructs vary from one another. It examines whether or not the items measure something else unintentionally. A construct should share more variance with its measures than it does with other constructs in the model.
This analysis was carried out by making comparison of the square root of the AVE with the correlations between the variables. The correlation between the variables should not be more than the square root of AVE (Chin, 1998). Table 4 below confirms that all square roots of the AVE's are higher in all cases than the correlations between the variables, thus the measurement model of this study illustrates sufficient discriminant validity.

Structural Model
Having successfully validated the measurement models, the structural model can be examined. PLS structural model shows the path coefficient and t-value of each directional relationship between constructs. Some authors point out that path coefficients should be more than 0.100 to consider a certain impact within the model (e.g., Huber et al. 2008). Furthermore, path coefficients should be significant at least at the 0.050 level. This study used 5% significance level (t-value: 1.68) as the statistical decision criterion. The structural model is presented in Fig. 2. Except for Stakeholders Interest, the relationships are highly significant. The hypotheses are tested by looking closely into the direction, the value and significance level of the path coefficients calculated by PLS. A bootstrapping resampling procedure was adopted to examine the significance of path coefficients. The results of the PLS estimates such as path coefficients and significance levels are given in Table 5. The first Hypothesis (H1) is supported and indicates that Stakeholders' Knowledge is significantly and positively associated with Requirements Elicitation (γ = 0.660; p<0.001). Hence, selecting stakeholders who have the needed knowledge improves the output of requirements elicitation phase.
The second Hypothesis (H2) is also supported. Path analysis verifies the existence of a significant relationship between Stakeholders' Role and Requirements Elicitation (γ = 0.217; p<0.001). This indicates that roles that stakeholders play positively influence requirements elicitation. The hypothesis that states Stakeholders Interest has a positive impact on the Requirements Elicitation (H3) is not supported. The path coefficients (γ = -0.059, p>0.05) indicate that there is a weak relation of Stakeholders' Interest with Requirements Elicitation and thus it is statistically not significant. The fourth Hypothesis (H4) deals with the positive relation between the Communications Skills of stakeholders with Requirements Elicitation. This hypothesis is supported (γ = 0.111; p<0.05). Indeed, the inclusion of stakeholders with good communication skills will reduce communication obstacles between stakeholders and requirements analysts during elicitation phase. The fifth hypothesis (H5) suggests a positive association between Requirements Elicitation and Requirements Quality. This hypothesis is supported (γ = 0.333; p<0.001). In other words, the effectiveness of the requirements elicitation phase has a significant impact on the requirements quality.

Discussion
The aim of this study was to identify and gain a better understanding of the factors of stakeholders selection that contribute to effective requirements elicitation phase and to provide insights in the relationship between requirements elicitation phase and requirements quality. Most of the findings of this study are in line with prior studies regarding stakeholders selection factors, however, a few deviations was found. The following paragraphs explain in detail the interpretation of results of this study.
Every software project has various types of stakeholders and each has a role to play. The roles that stakeholders play differ from one to another. Each role can be associated to a certain level of influence in the project. For example, the top management's role relates to decision making while in the operational level, the role relates to the tasks that stakeholders do. This study found that stakeholders' role is important quantitatively. This result supports the qualitative analysis that indicated stakeholders selection depends on the roles that the stakeholders play in the organization (Anwar and Razali, 2015). This finding confirms previous research by Ballejos and Montagna (2008) and Glinz and Wieringa (2007). Moreover, this study hypothesized that to ensure the effectiveness of requirements elicitation, the project team should select stakeholders who can contribute their knowledge, which later leads to the improvement of requirements quality.
In addition, the results indicate that stakeholders' overall knowledge has significant impacts on requirements elicitation. Thus, knowledge possessed by stakeholders need to be accessed, leveraged, shared and maintained to ensure that the project gets benefits. As mentioned before, stakeholders typically are people directly involved in a given project. For that, there is a need to consider the people whose knowledge is necessary to make it fits into the project. This finding is consistent with Robertson (2000) who concluded that there is need to look more widely at the people whose knowledge can help the project to succeed. Furthermore, recent research by Hsu et al. (2012) identified that stakeholders' knowledge is an important contributing factor for requirement gathering. For this reason, this study concludes that stakeholders' knowledge is a very significant factor for effective requirements elicitation phase based on both qualitative (Anwar and Razali, 2015) and quantitative methods. On the other hand, the hypothesised relationship between stakeholders' interest and requirements elicitation phase is found to be negative. This is explained by qualitative results when several respondents gave vary responses on the importance of stakeholders' interest (Anwar and Razali, 2015). They argued that even though some stakeholders are not interested in the project, they have to be selected because they have the knowledge about the requirements needed to build the system. This explains why the results of qualitative study reported that the stakeholders' interest is not significant. This result contradicts with earlier findings by Grünbacher and Seyff (2005), which indicated that the appropriate representatives whose interests are in the project is essential for the success of the requirements elicitation. Further research should thus focus on stakeholders' interest on requirements elicitation to better understand its influence.
The ability to interact among stakeholders in order to capture requirements and to relay ideas effectively has been acknowledged by both researchers and practitioners as a critical success factor (Davis et al., 2006). The results reveal that the stakeholders need to possess appropriate communication skills, to avoid poor communication during requirements elicitation. This finding confirms previous research, which claimed that the greatest threat to the success of any software system project is a failure to communicate (Chen et al., 2005;Hornik et al., 2003). Finally, Requirements elicitation is basically the initial phase of software development cycle and as such, it is a prerequisite of the other major development activities. This stage entails the identification of suitable stakeholders in order to understand the environment in which the software product will be developed and operated. It is a critical element for acquiring high quality requirement specifications, which are appropriate, complete and free from ambiguities. This study has found that the effectiveness of requirements elicitation phase is positively related to requirements quality. This supports the findings of previous research done by Pacheco and Garcia (2012) and Pacheco and Tovar (2007).

Conclusion
There are various methods used by software teams to explore and understand software requirements. There can be many reasons that exist for the extremely high failure rates of software projects. One major reason is to the inappropriate selection of stakeholders during requirement elicitation process. This study has introduced a model for selecting the suitable stakeholders during requirements elicitation process based on stakeholders characteristics such as stakeholders role, knowledge, interest and communication skill. The outcomes of the analyses showed that all independent variables were significant from a statistical point of view, except Stakeholders' Interest. Moreover, the results indicate that selecting stakeholders with appropriate characteristics have significant effects on the requirements elicitation phase. The results also reveal that requirements elicitation phase has significant influence on requirements quality. Finally, this model is useful for project managers to decide the appropriate stakeholders to be selected based on their characteristics during requirements elicitation phase.

Appendix A. Measurement items Construct
Abbreviation Item Stakeholder Role SR1 The users take entire responsibility to take a decision about the requirements. SR2 The users responsible for the company's policies and plans. SR3 The users are responsible about business functions. SR4 The users are responsible for the requirements definition of the system. Stakeholder Knowledge SK1 The users are knowledgeable about business functions. SK2 The users are able to interpret business problems and acquire in-depth knowledge regarding the solution. SK3 The users are familiar with IT and application. SK4 The users are familiar with the process of IS development. Stakeholder Interest SI1 The users have responsibility for system success. SI2 The users have commitment for the organization survival. SI3 The users are aware of the importance of their role in the project. Stakeholder Communication Skills SCS1 The users ability to plan and execute work in a collaborative environment. SCS2 The users have good presentation skills. SCS3 The users ability to be self-directed and proactive. SCS4 The users ability to work closely with analysts and maintain productive relationships. SCS5 The user use a clear, distinct, pleasant voice Requirements Elicitation RE1 Analysts are able to transfer what users say into system design.

RE2
Users are able to describe requirements in the way that analysts can understand it clearly.

RE3
Analysts used the way that users can understand to help them to express their needs.

RE4
Analysts and users transfer their own knowledge to each other. Requirements Quality RQ1 Consistenty of requirements. RQ2 Completeness of requirements. RQ3 Correctness of requirements.