Conference PaperPDF Available

An Exploratory Study of Topic Importance in Requirements Elicitation Interviewsnfe

Authors:

Abstract and Figures

Interviewing stakeholders is a common way to elicit information about requirements of the system-to-be and the conditions in its operating environment. One difficulty in preparing and doing interviews is how to avoid missing the in-formation that may be important to understand the requirements and environment conditions. Some information may remain implicit throughout the interview, if the interviewed stakeholder does not consider it important, and the business ana-lyst fails to mention it, or a topic it relates to. We propose the so-called Elicitation Topic Map (ETM), which is intended to help business analysts prepare elicitation interviews. ETM is a diagram that shows topics that can be discussed during re-quirements elicitation interviews, and shows how likely it is that stakeholders tend to discuss each of the topics spontaneously (as opposed to being explicitly asked questions on that topic by the business analyst). ETM was produced through a combination of theoretical and empirical research. 4
Content may be subject to copyright.
A preview of the PDF is not available
... Next, we present several papers related to requirements engineering studies. In [12], the authors identified 30 topics in requirements engineering elicitations based on interviews with five (5) systems engineers, and the importance of these topics was evaluated by 40 people in a quantitative survey. We followed the same steps of the authors of the paper [12], since we performed a qualitative study based on interviews and afterwards did a quantitative study using a survey to analyse the importance of the findings of the first study. ...
... In [12], the authors identified 30 topics in requirements engineering elicitations based on interviews with five (5) systems engineers, and the importance of these topics was evaluated by 40 people in a quantitative survey. We followed the same steps of the authors of the paper [12], since we performed a qualitative study based on interviews and afterwards did a quantitative study using a survey to analyse the importance of the findings of the first study. ...
... Criterion validity In the paper [12], which is similar to ours since it used mixed methods, the authors analysed documents of previous projects. They used semi-structured interviews in the qualitative stage and the survey with a Likert-type scale of five levels in the quantitative part. ...
Article
Full-text available
iStar is a goal-based requirements modelling language, being used in both industrial and academic projects of different domains. Often the language is extended to incorporate new constructs related to a particular application domain or to adjust it to practical situations during requirements modelling. Currently, the language is undergoing standardisation, and several studies have focused on the analysis of iStar variations to identify similarities and to define a core. This does not imply or constrain the need for iStar to continue to be extended. This paper contributes to the understanding of how iStar is extended by analysing how iStar researchers perform iStar extensions. To address this question, we followed a qualitative approach based on interviews involving 20 researchers from different research groups that proposed iStar extensions. The analysis revealed a good understanding about what extending a modelling language means and pointed out differences about how extensions are proposed. We discovered categories that impact positively on iStar extensions (such as reusing existing extensions, proposing extensions in abstract and concrete syntaxes, and creating new modelling tools), and other categories that impact negatively (such as modifying representations of the original constructs, proposing extensions in an ad hoc fashion and not carefully choosing graphical representations). We also evaluated the findings of interviews through an online survey answered by 30 iStar researchers. Finally, we proposed a set of guidelines to support the proposal for better future iStar extensions.
... It can be considered a threat to Criterion Validity. In the paper (Burnay et al., 2014), which is similar to ours since it used mixed methods, the authors analysed documents from previous projects. They used semi-structured interviews in the qualitative stage and the survey with a Likert-type scale of five levels in the quantitative part. ...
... The documental analysis of previous iStar extensions was presented in the paper of SLR (Gonçalves et al., 2017a). The qualitative study of the paper (Burnay et al., 2014) was made to confirm the findings of the documental analysis and discovered aspects not discovered in the documental analysis. Our script interview, therefore, has a broader scope once we have more general questions to confirm and does not bias the responses of the participants. ...
Article
iStar is a goal-based requirement modelling language, being used both in industrial and academic projects of different domains. Often the language is extended to incorporate new constructs related to an application domain or to adjust it to practical situations during requirements modelling. These iStar extensions have been proposed in an ad-hoc way resulting in many problems of incompleteness, inconsistency and conflicts. Recently, the language was standardised, but it continues being extended. Thus, we consider that this is an adequate moment to study how to support the proposals of the next iStar extensions. In this paper, we define PRISE, a process to support the creation of iStar extensions which is driven by model-based development concepts, reuse of existing iStar extensions and guidelines of experts. This process can be customised. We illustrate the usage of PRISE by recreating five existing iStar extensions. Finally, we evaluated PRISE with interviews and a survey with experts; and, we performed an interview to analyse the opinion about the usage of the PRISE to create a new iStar extension by a novice. The evaluation and validation indicate good results to avoid problems and increase the quality of the proposals and well receptivity by the experts and novice.
... It follows that the identification of quality Statements -as a way to detect quality RE Entities later on -is a key concern during Elicitation. There is considerable research on how to collect more Statements; various techniques and methods have been suggested to collect more systematically information about the domain and requirements [2], to avoid missing important questions during interviews [5], to detect implicit or tacit information [6,7], to collect novel / creative requirements [8] or to select the most appropriate technique to elicit some particular content [9,10]. These approaches all focus primarily on the quantity of Statements. ...
Article
Full-text available
In requirements engineering (RE), an early yet critical activity consists in eliciting the requirements from various stakeholders, who usually have different assumptions, knowledge, and intentions. The goal during elicitation is to understand what stakeholders expect from a given software, expectations which then feed the analysis, prioritization, validation, and ultimately specification activities of the RE process. Elicitation is an interactive activity. It relies on verbal communication of statements of stakeholders about their requirements, their ideas, their assumptions, the constraints they know apply in the environment of the future software, and so forth. Statements, we claim, build either on a past experience of the stakeholder or are the result of reasoning from indirect experience, i.e., they have different grounds. In this paper, we introduce the concept of “Statement Ground” during RE, contrast it with the classical perspective on requirements elicitation, and position the concept in existing RE literature. We conduct an empirical assessment of the relative qualities of statements that have different grounds. Our work results in a better understanding of the statements produced by stakeholders during requirements elicitation, of their qualities, and of the interplay between those qualities and the concept of statement ground. It also results in the definition of a series of research questions which focus on the implications of our findings on the overall requirements engineering activity.
... The elicitation and analysis of requirements are necessary for the correct and complete development of any software product and they are activities that make a huge difference on the success of the software [2]. The quality of the final product is dependent on the successful execution of these activities together with the specification and reuse of domain requirements. ...
Conference Paper
The¹ growth of social networks impacts on several areas of our society. They can be used during software development, more specifically in the requirements elicitation activity, for identifying, complementing and validating the domain requirements. In this paper, we propose an approach that shows how social networks can be used as a source for capturing domain requirements. The aim is to perform the initial modeling of the system domain, providing a systematic methodology (process) for rapidly capturing relevant features that would not be straightforwardly elicited using traditional approaches. We apply this approach to the emergency systems domain (more specifically, floods in coastal areas), extracting information from the Twitter social network. The result is a domain model whose features can be reused in several applications of that domain. The application of the approach has been evaluated for its usefulness by domain experts and replicated to verify the generation of similar results at different time periods.
... Se traduce comúnmente en malentendidos durante las entrevistas provocando especificaciones poco claras e incompletas producto del uso del lenguaje natural. Desde el lado del cliente se manifiesta en el sentido de que este último se expresa utilizando un lenguaje lleno de jergas asociadas a su dominio provocando la interpretación múltiple de los analistas (Burnay et al., 2014a), o entrega muy poca o demasiada información que se aleja de los límites de procesamiento del analista durante una entrevista. ...
Article
Requirements engineering (RE) is one of the most important phases during the software development and its proper execution greatly affects the developed product success. The overall objective of the RE is to understand accurately the problem that it is intended to solve. RE activities require a high degree of interaction and communication between all stakeholders. Multiple factors affect this process, highlighting social and emotional aspects of people, which are not commonly considered by traditional elicitation techniques. The objective of this work is to identify social and human factors that are not covered during the elicitation process and they may negatively affect the product success. The review process was carried out on bibliographic sources recognized by scientific community following three major activities described by Barbara Kitchen approach.
... Generic RE methods can be applied in service identification sessions as well. For example, Burnay et al. [29] propose the Elicitation Topic Map (ETM) to list the topics of discuss and their relative importance when preparing for an RE session. This kind of a topic list could be used as a checklist in service identification, but it should be adapted with topics important for service elicitation. ...
Article
Full-text available
Service-oriented computing has created new requirements for information systems development processes and methods. The adoption of service-oriented development requires service identification methods matching the challenge in enterprises. A wide variety of service identification methods (SIM) have been proposed, but less attention has been paid to the actual requirements of the methods. This paper provides an ethnographical look at challenges in service identification based on data from 14 service identification sessions, providing insight into the practice of service identification. The findings identified two types of service identification sessions and the results can be used for selecting the appropriate SIM based on the type of the session.
Conference Paper
Full-text available
Requirements elicitation is the activity in requirements engineering (RE) which focuses on the collection of information about requirements of the system-to-be and its environment. One important challenge is elicitation incompleteness; it occurs when information, which may have been relevant for requirements engineering, is not elicited. This may be due to various factors, such as that the requirements engineer asked no questions about it, and the stakeholders did not consider it important. To help requirements engineers reduce elicitation incompleteness, we propose the so-called Model of Elicitation Topic Relevance (METRe). METRe is a diagram that shows topics which can be discussed during requirements elicitation, and expresses the relative importance of each topic to stakeholders and engineers. The more likely it is that a stakeholder or engineer will discuss the topic spontaneously during elicitation, the more important it is for, respectively, stakeholders or engineers. METRe was made by combining our prior work on the importance of topics to stakeholders, and a new round of empirical research. The new round consisted of data collection using a survey, in which the various topics were presented to and evaluated by 50 IT-experts in Belgium. Subjects were asked to evaluate the relative importance of the topics, that is, how relevant they find these topics when eliciting information, and how pro-active they would be in collecting them.
Article
Interviewing stakeholders is a way to elicit information about requirements for a system-to-be. A difficulty when preparing such elicitation interviews is to select the topics to discuss, so as to avoid missing important information. Stakeholders may spontaneously share information on some topics, but remain silent on others, unless asked explicitly. We propose the Elicitation Topic Map (ETM) to help engineers in preparing interviews. ETM is a diagram showing topics that may be discussed during interviews, and shows how likely stakeholders discuss each of these topics spontaneously. If a topic is less likely to be discussed spontaneously, then this suggests that engineers may want to prepare questions on it, before the interview. ETM was produced through theoretical and empirical research. The theoretical part consisted of identifying topic sets based on a conceptual model of communication context, grounded in philosophy, artificial intelligence, and computer science. The empirical part involved interviews with requirements engineering professionals to identify the topic sets and topics in each set, surveys of business people in order to evaluate how likely they would spontaneously share information about topics, and evaluations of how likely students would share information about each topic, when asked about requirements for social network websites.
Conference Paper
Full-text available
[Context and motivation] Implicit requirements (ImRs) are defined as requirements of a system which are not explicitly expressed during requirements elicitation, often because they are considered so basic that developers should already know them. Many products have been rejected or users made unhappy because implicit requirements were not sufficiently addressed. [Question/Problem] Requirement management tools have not addressed the issue of managing ImRs, also despite the challenges of managing ImRs that exist in practice the issue has not received sufficient attention in the literature. [Principal Idea/results] This planned research will investigate how automated support can be provided for managing ImRs within an organizational context, which is currently lacking in practice. This work proposed an approach that is based on semantic case-based reasoning for managing ImRs. [Contribution] We present the concept of a tool which enables managing of ImRs through the analogy-based requirements reuse of previously known ImRs. This ensures the discovery, structured documentation, proper prioritization, and evolution of ImRs, which improves the overall success of software development processes.
Chapter
Full-text available
Requirements elicitation is the process of seeking, uncovering, acquiring, and elaborating requirements for computer based systems. It is generally understood that requirements are elicited rather than just captured or collected. This implies there are discovery, emergence, and development elements in the elicitation process. Requirements elicitation is a complex process involving many activities with a variety of available techniques, approaches, and tools for performing them. The relative strengths and weaknesses of these determine when each is appropriate depending on the context and situation. The objectives of this chapter are to present a comprehensive survey of important aspects of the techniques, approaches, and tools for requirements elicitation, and examine the current issues, trends, and challenges faced by researchers and practitioners in this field.
Article
When eliciting requirements, it is important to understand why some information may remain implicit, while other are shared by stakeholders. This requires knowing which variables influence if an individual shares implicit information during requirements elicitation. Based on our past experimental work on decision-making, we identify variables - Context Factors (CFs) - which influence whether implicit information is shared, and we define a procedure to validate CFs. Our contribution is that we present and define a set of CFs, we define an experimental procedure to validate CFs, and we discuss how the understanding of CFs helps identify information that can remain implicit during elicitation, and can thereby help to increase the completeness of requirements. We relate CFs to the common Requirements Problem concept, and we highlight the main limitation of our results.
Conference Paper
A software development task is performed in accordance with requirements specification. Therefore, requirements elicitation work in order to prepare requirements specification is a very important task. However, it is very difficult to elicit user requirements for software development without omissions or errors, mainly because customers are often ignorant for software development technologies, and novice SEs do not have enough knowledge of the business contents for the software development. In order to solve this problem, the authors recognize requirements elicitation work as interview techniques, and are proposing a method to navigate interview-driven software requirements elicitation work conducted by SEs to customers so that SEs are able to elicit user requirements without omissions or errors [4]. Then, the effectiveness of the proposed method was proven by conducting the experiment to compare completeness and accuracy of the elicited requirements. This paper discusses effectiveness of the proposed method from the viewpoint of efficiency of requirements elicitation work by conducting the comparative experiment in regards to the cases that the method proposed in the Reference [4] was used and not used.
Article
The specification of requirements is among the most critical activities of information system development, and yet it is very prone to errors. A number of actions are proposed here to improve the situation: (1) shifting the concern from the target system towards its environment; (2) using an expressive language close to the natural way future users of the system express their requirements; and (3) using a formal language to ensure unambiguity, and to provide the deductive capabilities that will help in validating the requirements. A requirements expression language called ERAE is presented, which is inspired by some of the knowledge representation techniques in artificial intelligence, and by the so-called ‘declarative’ conceptual modelling languages in databases. The author also illustrates how the accompanying methodology makes the best use of the language's characteristics.