Existing Requirements Elicitation Research Articles

Quality-of-Data Broker for Quality-of-Data-Aware Telemedicine Systems

Purpose: Telemedicine systems must provide clinical data of sufficient quality (according to medical standards) to support safe treatment guidance of outpatients. Quality of clinical data (QoD) typically varies due to unstable performance of ICT-components of these telemedicine systems. Therefore, telemedicine systems that support treatment guidance of outpatients should be QoD-aware and must be able to appropriately adapt treatment guidance to QoD variations. Only in this way, the effectiveness of treatment guidance and the safety of outpatients can be guaranteed.Methods: This paper follows a design science approach for the development of a functional architecture for QoD-aware telemedicine systems, with emphasis on one key component: the QoD Broker. Existing requirements elicitation methods were refined to deal with capturing QoD-specific requirements. Furthermore, an ontology-driven knowledge management method is proposed to enable the correct interpretation and manipulation of QoD within telemedicine systems. The functional architecture was validated using various methods, including prototype experiments and expert interviews.Result: One of the key components of the proposed functional architecture is the QoD Broker, which is a novel component that adds QoD-awareness to telemedicine systems. The QoD Broker obtains quality of service data from ICT components within a given telemedicine system and uses different computational models to compute QoD. This paper presents the QoD Broker architecture and the QoD management techniques implemented in the QoD Broker: (1) QoD dimensions, (2) QoD evaluation (i.e. computational models), (3) QoD stratification models and (4) technological recommendations.Discussion: The paper presents partial results of the validation that was performed in the context of the European MobiGuide project. The validation confirms that the proposed QoD Broker satisfies stakeholders' requirements and is considered useful to support stakeholders' goals. Both patients and medical domain experts found the role of the QoD Broker essential to guarantee the safety of patients when they are using telemedicine systems.

A Fuzzy Galois Lattices Approach to Requirements Elicitation for Cloud Services

The cloud paradigm has become increasingly attractive throughout the recent years due to its both technical and economic foreseen impact. Therefore, researchers’ and practitioners’ attention has been drawn to enhancing the technological characteristics of cloud services, such as performance, scalability or security. However, the topic of identifying and understanding cloud consumers’ real needs has largely been ignored. Existing requirements elicitation methods are not appropriate for the cloud computing domain, where consumers are highly heterogeneous and geographically distributed, have frequent change requests and expect services to be delivered at a fast pace. In this paper, we introduce a new approach to requirements elicitation for cloud services, which utilizes consumers’ advanced search queries for services to infer requirements that can lead to new cloud solutions. For this, starting from the queries, we build fuzzy Galois lattices that can be used by public cloud providers to analyze market needs and trends, as well as optimum solutions for satisfying the largest populations possible with a minimum set of features implemented. This new approach complements the existing requirements elicitation techniques in that it is a dedicated cloud method which operates with data that already exists, without entailing the active participation of consumers and requirements specialists.

A Systematic Mapping Study on Requirements Elicitation Techniques in Collaborative Application

This paper describes a mapping study to identify what are the existing requirements elicitation available for Computer-Supported Collaboration Work (CSCW) application. This study also points out type of requirements which the developers look for during requirements elicitation. Based on 14 papers that have been refined from the study, the authors look at types of domain involved in CSCW application. This paper also describes potential requirement to support social presence in collaborative application such as in E- learning as one of the domain in CSCW application.

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.

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.