Requirements Elicitation Process Research Articles

Challenges in Requirements Engineering for Mobile Applications for Disabled –Autism

Autism Spectrum Disorder (ASD) is a brain development disorder caused due to abnormal functioning of brain impacting development activities. Different traditional techniques and methods have been used to communicate with ASD person. Researchers and developers have come up with different innovative ideas to aid ASD patients to communicate with others. As ASD people do not communicate properly so requirement engineers face challenges while gathering requirements from them. This paper focuses on the challenges faced during the requirement elicitation process. As challenges are discussed we have proposed a solution to overcome these problems. 

Proposal of Tasks and Techniques for a Requirements Conceptualization

The requirements elicitation process has social connotations involving different people (stakeholders), a circumstance which causes certain problems arise when carrying out this process of requirement conceptualization. In order to deal with this problem, we propose tasks and techniques for a requirements conceptualization process that are structured in two phases: (a) tasks and techniques for problem-oriented analysis, and (b) tasks and techniques for Product-Oriented Analysis. The techniques for each task in both phases are introduced.

Requirements Negotiation: Does Consensus Reduce Software Development Cost?

The requirements engineering activities within a software project are known to be critical to the successful production of a correctly functioning system. This is particularly so when considering the varying views of multiple stakeholders. One promising approach for improving the outcome is to introduce formal negotiation. Negotiation is beneficial to identify and to resolve conflicts between stakeholders. Consensus achieved through negotiation represents all key stakeholders’ perspectives and perceptions regarding the system to be developed. The aim of implementing negotiation is to minimize the possibility of introducing defects during the creation of requirements and to decrease later effort required to fix requirements’ defects. This paper answers the question of whether consensus gives positive significant impact to the software project as a whole or not. It presents an approach to estimate the savings from implementing negotiation in the requirements elicitation process. An empirical evaluation study is adopted through a role play experiment to evaluate the benefit of exercising negotiation. The net gain and the return on investment show positive values which suggest that negotiation activities are worth an investment. Based on a return on investment of 197 percent on average, this paper suggests that negotiation is a useful prevention activity to inhibit defects from occurring during the requirements creation process.

ActCPG framework to learn about information user requirements of a clinical practice guideline

A clinical practice guideline is a knowledge uptake instrument that supports evidence-based decision making by clinicians. It represents a model of a clinical process that describes the sequence of actions, decisions and their outcomes, and the interface with other processes beyond the scope of a guideline. In domains outside healthcare, the computerization of business processes via information systems follows a very rigorous design labeled as the system development life cycle. Our argument is that the computerization of a clinical practice guideline is the equivalent of building an information system for a clinical process and therefore should follow a similarly rigorous design method. One of the first and also one of the most important steps in the system development life cycle is learning about user information requirements. This paper is about a user requirements elicitation and definition process customized to clinical practice guideline. We propose the novel ActCPG conceptual framework for elicitation of basic user requirements for developing computer-interpreted guidelines. This framework relies on Activity Theory to structure and decompose information coming from a clinical practice guideline and associated narrative. We illustrate operation of the ActCPG framework with an example of a practice guideline for a management of clinically obese children enrolled in the Children's Hospital of Eastern Ontario obesity program.

System requirements engineering in complex situations

The purpose of this paper is to present an alternative systems thinking---based perspective and approach to the requirements elicitation process in complex situations. Three broad challenges associated with the requirements engineering elicitation in complex situations are explored, including the (1) role of the system observer, (2) nature of system requirements in complex situations, and (3) influence of the system environment. Authors have asserted that the expectation of unambiguous, consistent, complete, understandable, verifiable, traceable, and modifiable requirements is not consistent with complex situations. In contrast, complex situations are an emerging design reality for requirements engineering processes, marked by high levels of ambiguity, uncertainty, and emergence. This paper develops the argument that dealing with requirements for complex situations requires a change in paradigm. The elicitation of requirements for simple and technically driven systems is appropriately accomplished by proven methods. In contrast, the elicitation of requirements in complex situations (e.g., integrated multiple critical infrastructures, system-of-systems, etc.) requires more holistic thinking and can be enhanced by grounding in systems theory.

Reverse Engineering Legacy Finite Element Code

The development of code for finite elements-based field computation has been going on at a pace since the 1970s, yielding code that was not put through the software lifecycle – where code is developed through a sequential process of requirements elicitation from the user/client to design, analysis, implementation and testing and release and maintenance. As a result, today we have legacy code running into millions of lines, implemented without planning and not using proper state-of-the-art software design tools. It is necessary to redo this code to exploit new object oriented facilities and make corrections or run on the web with Java. Object oriented code’s principal advantage is reusability. Recent advances in software make such reverse engineering/re-engineering of this code into object oriented form possible. The purpose of this paper is to show how existing finite element code can be reverse/re-engineered to improve it. Taking sections of working finite element code, especially matrix computation for equation solution as examples, we put it through reverse engineering to arrive at the effective UML design by which development was done and then translate it to Java. This then is the starting point for analyzing the design and improving it without having to throw away any of the old code. Using auto-translators and then visually rewriting parts by the design so revealed, has no match in terms of speed and efficiency of re-engineering legacy code.

A Lightweight Forum-based Distributed Requirement Elicitation Process for Open Source Community

Nowadays, lots of open source communities adopt forum to acquire scattered stakeholders' requirements. But the requirements collection process always suffers from the unformatted description and unfocused discussions. In this paper, we establish a framework ReqForum to define the metamodel of the requirement elicitation forum. Based on it, we propose a lightweight forum-based requirements elicitation process which includes six steps: template-based requirements creation, opinions collection, requirements collection, requirements management, capability identification and the incentive mechanism. According to the proposed process, the prototype SKLSEForum is established by composing the Discuz and its existed pulg-ins. The implementation indicates that the process is feasible and the cost is economic.

The impact of analyst-induced misinformation on the requirements elicitation process

Information requirements determination (IRD) is concerned with developing accurate requirements for a proposed system, primarily by eliciting information from users and other organizational stakeholders. In this paper we build and test theory concerning a significant threat to the accuracy of information requirements, termed the misinformation effect. Misinformation is distorted, false, or other erroneous or misleading information that does not reflect the true state of the world or state of mind of the person communicating the information. The misinformation effect refers to the tendency of people to recall misleading or false information introduced to them following an event instead of original material learned or observed at the time the event occurred. During user-analyst communication in the IRD process, analysts may introduce misinformation in their discussions with users. We use the misinformation effect literature to hypothesize that in such circumstances users are likely to recall misinformation introduced by analysts rather than their true beliefs and knowledge of facts. Additionally, we use literature in social psychology to hypothesize that the misinformation effect will be stronger when misinformation is introduced using a social technique rather than a nonsocial technique. We conducted an experiment to test the misinformation effect in the requirements elicitation process. Results indicated that (1) introduction of misinformation reduces the accuracy of requirements provided by users, and (2) social techniques (interviews) are more vulnerable to the misinformation effect than nonsocial techniques (surveys). Our research contributes to the information systems literature by identifying an important reason that requirements provided by users may be inaccurate, and to IRD practice by identifying important dilemmas caused by the misinformation effect as well as potential solutions. We also contribute to the psychology literature by demonstrating the existence of the misinformation effect with users' experiential factual knowledge and beliefs in a business context, and by aiding in understanding the underlying causes of the misinformation effect. We discuss implications of our findings and directions for future research to address challenges resulting from the misinformation effect.

Defining DSL design principles for enhancing the requirements elicitation process

Requirements elicitation is concerned with learning and understanding the needs of users w.r.t. a new software development. Frequently the methods employed for requirements elicitation are adapted from areas like social sciences that do not include executable (prototype based on) feedback. As a consequence, it is relatively common to discover that the first release does not fit the requirements defined at the beginning of the project. Using domain-specific languages (DSLs) as an auxiliary tool for requirements elicitation is a commonly well accepted idea. Unfortunately, there are few works in the literature devoted to the definition of design principles for DSLs to be experienced in the frameworks for DSL developing such as ANTLR, Ruby, and Curry. We propose design principles for the DSL development (regardless of paradigm) which are sufficient to model the domain in a requirements phase. Further more we enunciate a new profile for the requirements analyst and a set of elicitation steps. The use of DSLs not only giveus an immediate feedback with the stake holders; it also allows us to produce part of the real code.

The Impact of Analyst-Induced Misinformation on The Requirements Elicitation Process

Information requirements determination (IRD) is concerned with developing accurate requirements for a proposed system, primarily by eliciting information from users and other organizational stakeholders. In this paper we build and test theory concerning a significant threat to the accuracy of information requirements, termed the misinformation effect. Misinformation is distorted, false, or other erroneous or misleading information that does not reflect the true state of the world or state of mind of the person communicating the information. The misinformation effect refers to the tendency of people to recall misleading or false information introduced to them following an event instead of original material learned or observed at the time the event occurred. During user-analyst communication in the IRD process, analysts may introduce misinformation in their discussions with users. We use the misinformation effect literature to hypothesize that in such circumstances users are likely to recall misinformation introduced by analysts rather than their true beliefs and knowledge of facts. Additionally, we use literature in social psychology to hypothesize that the misinformation effect will be stronger when misinformation is introduced using a social technique rather than a nonsocial technique. We conducted an experiment to test the misinformation effect in the requirements elicitation process. Results indicated that (1) introduction of misinformation reduces the accuracy of requirements provided by users, and (2) social techniques (interviews) are more vulnerable to the misinformation effect than nonsocial techniques (surveys). Our research contributes to the information systems literature by identifying an important reason that requirements provided by users may be inaccurate, and to IRD practice by identifying important dilemmas caused by the misinformation effect as well as potential solutions. We also contribute to the psychology literature by demonstrating the existence of the misinformation effect with users' experiential factual knowledge and beliefs in a business context, and by aiding in understanding the underlying causes of the misinformation effect. We discuss implications of our findings and directions for future research to address challenges resulting from the misinformation effect.

Designing and Rationalising a Layered-Mapping Aid for Requirements Elicitation in Air Traffic Control

The “Layered Map” is a simple, cheap and portable device used to aid the explanation of complex traffic management scenarios, between field practitioners and operators and during the process of requirements elicitation. It was developed for being adaptable to multiple semantic communities within and across different ontologies of work in air traffic control. The study identified a number of factors influencing the design of aids, namely: i) emerging knowledge coordination, ii) ontological compatibility, iii) jargon and linguistic interpretation, iv) cultural traffic management practices, v) software development, and vi) gesture-based interaction. The construction of the layered-map involves three layers of material: i) the base, ii) the modifier, and iii) the interactor. The layered-map utilises semiotics to define three different modes of knowledge coordination. The rationale used to represent these modes of coordination is the representational adaptability of the different physical layers of the layered map. Thus, a conceptual bridge is elicited as a means of generalising the mapping of: i) syntactic knowledge to the base layer, mainly for representation, ii) semantic knowledge to the modifier layer, mainly for learning, and iii) pragmatic knowledge to the interactor layer, mainly for transformation.

IThink: A Game-Based Approach Towards Improving Collaboration and Participation in Requirement Elicitation

Requirements are the heart of Information Systems development because they determine how the system will operate. There- fore, requirements elicitation is a critical activity of the information systems development life cycle. Recognizing the im- portance of collaborative work and the huge difficulty of gathering stakeholders at the same time and place, researches have been proposing web collaborative tools to elicit requirements. In this article we present a game-based collaborative tool called iThink that aims at improving the participation in a requirement elicitation process. iThink takes advantage of the associa- tion between “gamification” concepts and the six hats of thinking method for collecting both new requirements and feedback about existing ones and for presenting the requirement elicitation process in a form of a collaborative game. Two case-studies, involving several stakeholders, are also presented with the purpose of evaluating the effectiveness and acceptance of this tool.

Toward the Decision Tree for Inferring Requirements Maturation Types

Requirements are elicited step by step during the requirements engineering (RE) process. However, some types of requirements are elicited completely after the scheduled requirements elicitation process is finished. Such a situation is regarded as problematic situation. In our study, the difficulties of eliciting various kinds of requirements is observed by components. We refer to the components as observation targets (OTs) and introduce the word “Requirements maturation.” It means when and how requirements are elicited completely in the project. The requirements maturation is discussed on physical and logical OTs. OTs Viewed from a logical viewpoint are called logical OTs, e.g. quality requirements. The requirements of physical OTs, e.g., modules, components, subsystems, etc., includes functional and non-functional requirements. They are influenced by their requesters' environmental changes, as well as developers' technical changes. In order to infer the requirements maturation period of each OT, we need to know how much these factors influence the OTs' requirements maturation. According to the observation of actual past projects, we defined the PRINCE (Pre Requirements Intelligence Net Consideration and Evaluation) model. It aims to guide developers in their observation of the requirements maturation of OTs. We quantitatively analyzed the actual cases with their requirements elicitation process and extracted essential factors that influence the requirements maturation. The results of interviews of project managers are analyzed by WEKA, a data mining system, from which the decision tree was derived. This paper introduces the PRINCE model and the category of logical OTs to be observed. The decision tree that helps developers infer the maturation type of an OT is also described. We evaluate the tree through real projects and discuss its ability to infer the requirements maturation types.

Enhancing security requirements engineering by organizational learning

More and more software projects today are security-related in one way or the other. Requirements engineers without expertise in security are at risk of overlooking security requirements, which often leads to security vulnerabilities that can later be exploited in practice. Identifying security-relevant requirements is labor-intensive and error-prone. In order to facilitate the security requirements elicitation process, we present an approach supporting organizational learning on security requirements by establishing company-wide experience resources and a socio-technical network to benefit from them. The approach is based on modeling the flow of requirements and related experiences. Based on those models, we enable people to exchange experiences about security-relevant requirements while they write and discuss project requirements. At the same time, the approach enables participating stakeholders to learn while they write requirements. This can increase security awareness and facilitate learning on both individual and organizational levels. As a basis for our approach, we introduce heuristic assistant tools. They support reuse of existing experiences that are relevant for security. In particular, they include Bayesian classifiers that issue a warning automatically when new requirements seem to be security-relevant. Our results indicate that this is feasible, in particular if the classifier is trained with domain-specific data and documents from previous projects. We show how the ability to identify security-relevant requirements can be improved using this approach. We illustrate our approach by providing a step-by-step example of how we improved the security requirements engineering process at the European Telecommunications Standards Institute (ETSI) and report on experiences made in this application.

Recommender Systems in Requirements Engineering

Requirements engineering in large‐scale industrial, government, and international projects can be a highly complex process involving thousands or even hundreds of thousands of potentially distributed stakeholders. The process can result in massive amounts of noisy and semistructured data that must be analyzed and distilled in order to extract useful requirements. As a result, many human‐intensive tasks in requirements elicitation, analysis, and management processes can be augmented and supported through the use of recommender system and machine‐learning techniques. In this article we describe several areas in which recommendation technologies have been applied to the requirements engineering domain, namely stakeholder identification, domain analysis, requirements elicitation, and decision support across several requirements analysis and prioritization tasks. We also highlight ongoing challenges and opportunities for applying recommender systems in the requirements engineering domain.

Eliciting user requirements using Appreciative inquiry

For decades and still today, software development projects have failed because they do not meet the needs of users, are over-budget, and abandoned. To help address this problem, the user requirements elicitation process was modified based on principles of Appreciative Inquiry. Appreciative Inquiry, commonly used in organizational development, aims to build organizations, processes, or systems based on success stories using a hopeful vision for an ideal future. In four studies, Appreciative Inquiry was evaluated for its effectiveness with eliciting user requirements in different circumstances. In the first two studies, it was compared with brainstorming, a traditional approach, with end-users (study 1) and proxy-users (study 2). The third study was a quasi-experiment comparing the use of Appreciative Inquiry in different phases in the software development cycle (study 3). The final (fourth) study combined all lessons learned using Appreciative Inquiry in a cross-case comparison study of 3 cases to gain additional understanding of the requirements gathered during various project phases. In each of the four studies, the requirements gathered, developer and user attitudes, and the Appreciative Inquiry process itself were evaluated. Requirements were evaluated for their quantity and type regardless of whether they were implemented or not. Attitudes were evaluated for commitment to the requirements and project using process feedback. The Appreciative Inquiry process was evaluated with differing groups, projects, and project phases to determine how and when it is best applied. Potentially interceding factors were also evaluated including: team effectiveness, Emotional Intelligence, and perceived stress. Appreciative Inquiry produced positive results for the participants, the requirements obtained, and the general requirements eliciting-process. Appreciative Inquiry demonstrated benefits to the requirements gathered by increasing the number of unique requirements as well as identifying more quality-based (non-functional) and forward-looking requirements. It worked best when there was time for participants to reflect on the thought-provoking questions and when the facilitator was knowledgeable of the subject-matter and had extra time to extract and translate the requirements. The participants (end-users and developers) expressed improved project understanding. End-users participated consistently with immediate buy-in and enthusiasm, especially those users who were technically-inhibited. We conclude that Appreciative Inquiry can augment existing methods by presenting a positive and future aspect for a proposed system resulting in improved user requirements.

Extracting Soft Issues during Requirements Elicitation:A Preliminary Study

Requirements Engineering (RE) is a critical process in Software Engineering (SE) activities. RE helps stakeholders to manage requirements appropriately before dedicated requirements are used to design and implement software. The first stage in RE process is known as requirements elicitation whereby during elicitation, stakeholders will perform a set of activities to permit understanding in problem domain for respected scenario and hence proposing a set of established requirements in developing software. In elicitation, stakeholders need to collaborate and communicate in order to produce unambiguous requirements and create mutual agreement for software design and development. This can produce desired solution for all stakeholders. Soft issue is one of non-technical requirements that can associate with social presence, social interaction elements such as comfort, connectedness and motivation. This requirements need to be emphasized during RE process especially for a system that is categorized in Computer- Supported Collaboration Working (CSCW) domain. Users need CSCW domain system to carry out virtual communication, knowledge sharing via system's features. The aim of this paper is to carry out a preliminary study on RE process and requirements elicitation activities by identifying whether soft issues have been engaged in existing requirements elicitation process. Another aim is to compare stakeholders' roles based on selected articles. The method to investigate requirements elicitation process is done by identifying existing elicitation processes as well as involvement of stakeholders' collaboration during elicitation. According to the study, the comparison of existing requirements elicitation processes and comparison of job roles have been produced as a result in this paper.

A Survey of Communication Content in Software Requirements Elicitation involving Customer and Developer

At the heart of software requirements elicitation lies the communication between customer and developer. There are several valuable components of communication such as medium, sender, receiver, and messages, which relates to the input and output from both parties. Most of these messages are delivered through incompletely, inconsistently or inaccurately defined communication medium. This study has been done to look into the communication content of the current communication practices between developer and customer in Malaysia. The results of this study revealed some important notes on the practices of communication content during software requirements elicitation process in Malaysia.

Eliciting requirements for an inter‐company cooperative information system

PurposeThe requirements engineering (RE) process constitutes the earliest phase of the information system development life cycle. Requirements elicitation is considered as one of the most critical activities of this phase. Moreover, requirements elicitation is still a challenge, especially in the distributed environment of so‐called inter‐company cooperative information systems (ICISs). The purpose of this paper is to propose a methodology to elicit requirements for an ICIS.Design/methodology/approachAn analytical research approach was conducted. The current RE approaches, which are based either on goal, scenario or viewpoint were evaluated. Then the role of the elicitation technique selection step within the requirements elicitation process was examined. Finally the factors that affect this step in a distributed environment were studied. An example from the textile industry is used to illustrate the applicability of the proposed methodology.FindingsThough existing requirements elicitation approaches based either on goal, scenario or viewpoint are effective techniques, they do not fit exactly to a cooperative distributed environment: more issues are created by inadequate communication, time difference between sites, cultural, language and characteristics diversity of stakeholders which affect the elicitation technique selection step and thus the requirements elicitation process. In order to tackle these issues, this paper presents a methodology called MAMIE (from Macro‐ to Micro‐level requirements Elicitation) to elicit requirements for an ICIS. A prototype tool has been developed to support the operation of the methodology.Research limitations/implicationsThe major limitation of the paper is that has not yet been tested in an existing organization.Practical implicationsTo provide the analyst with well‐defined steps in order to elicit requirements of an ICIS. To understand the role of the elicitation technique selection step within the requirements elicitation process and identifying the factors which have an impact on this step. To select an appropriate elicitation technique according to these factors.Originality/valueMAMIE integrates the three notions of goal, scenario and viewpoint to elicit requirements for an ICIS. The paper argues that these concepts may be used simultaneously and in a complementary way to improve the requirements elicitation process. Moreover, in order to increase the quality of the elicited requirements and thus the quality of the system‐to‐be, selecting an elicitation technique in MAMIE is not based on personal preferences but on situation assessment.

A framework to improve communication during the requirements elicitation process in GSD projects

Achieving a shared understanding of requirements is difficult in any situation, even more so in global software development projects. In such environments, people must deal not only with the lack of face to face communication, but also with other issues such as time difference, cultural diversity and a large amount of information originating from different sources throughout the world. Obtaining the right requirements therefore implies extra effort. In order to minimize such problems, we propose a framework that focuses on analyzing the factors that may be problematic in global software development and which suggests a set of strategies to improve the requirements elicitation process in such environments. In this paper, we describe the different phases of our framework and present the results of an experiment that test part of this framework. The results indicate that applying some of the strategies proposed in the framework seems to positively affect the stakeholders’ satisfaction with regard to communication. Moreover, the quality of the written software requirements specifications seems to be better as well when using those strategies.