Article Preview
TopIntroduction
Software Engineering (SE) research aims to enhance software development by concentrating on increasing the reusability and efficiency of the final product while at the same time reducing the time and expense of development. For several decades, there has been an evolution from structured plan-based style of development to object oriented, component based, aspect oriented and finally towards service oriented. The notion of service plays a more and more extensive role in the domain of software and information systems engineering. Service-Orientation has been received a lot of attention by shifting the perceptions of producing software to using software. A key attribute of SaaS is multi-tenant efficiency, which enables economies of scale and efficient resource utilization by sharing a cloud infrastructure across multiple clients (i.e., tenants). A tenant is an organization or company with its end users that uses SaaS application (Jumagaliyev, Whittle, & Elkhatib, 2016). SaaS offers advantage for both service providers and consumers. The supplier investment in a single hardware is used to host applications shared by multiple users (Anum, Khan, & Iftikhar, 2014). Researchers and practitioners have long identified and accepted the important value of Requirements Engineering (RE) in software systems development (Kotonya & Sommerville, 1996; Kotonya &S ommerville, 1992; Yu, 1997; Hegelstein, 1988; Mullery, 1979; Zhou,Yi&Liu, 2011; Lamsweerde, 2001; Lapouchnian, 2005). RE is concerned with interpreting and understanding goals, needs and beliefs of stakeholders. There are several RE-related challenges that can lead to inaccurate and incomplete specifications and software project cancellations. The process of requirements elicitation presents critical activities in the RE process. Getting the right specifications are considered to be an important and challenging part of software development projects (Zowghi&Coulin,2005). Despite of the importance of requirements in software development, in industry and software engineering research to date, insufficient attention has been paid to this field. Todoran and al. identify in (Todoran, Norbert, &Martin, 2013) ad hoc requirements elicitation approaches which are introduced by cloud providers in order to complement shortcomings of current approaches. Despite of the fact Cloud Computing (CC) applications and services go hand in hand, the cloud applications are not designed from a customer’s perspective. User involvement in software development has been the subject of important research and has been acknowledged intuitively and axiomatically to play an important role in the satisfaction of users, contributing to system success (Bano,2015). There is a several kinds of user’s involvement among others, past users’ feedback (Tizard, Rietz, &Blincoe, 2020) reviews, suggestions and comments from online sites. A multi-perspective approach to RE can potentially lead to specifications of requirements that are more likely to meet the needs of a variety of system stakeholders. VORD (Viewpoint-Oriented Requirement Definition) (Kotonya, & Sommerville, 1996) is an adaptation of the use of perspectives for RE that does not suggest any unique form of point of view or notation. The VORD method is proposed to elicit, analyze, and document the requirements for a Service-Oriented System (SOS) (Sommerville, &Sawyer,1998). The origins of requirements may be from stakeholders, other systems that communicate with the proposed system, or from other organizations in the proposed systems environment that may be influenced by its operation. Each requirement source is then considered to be a viewpoint. Although VORD present some points of weakness according to authors in (Kotonya, & Sommerville,1996). Goal-Oriented Requirement Engineering (GORE) is a sub-area of RE, which addresses using of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements (Lamsweerde,2009). Goal-oriented approaches offer explicit support for dealing with high-level user and stakeholders’ goals making it easier to consider design solutions and to identify criteria at an acceptable level of abstraction (Kolos, Eck, &Wieringa, 2005). During the early requirements phase, i* (Yu,1997) framework is used to model the environment of the system-to-be. It facilitates the analysis of the domain by allowing the modeler to diagrammatically represent the stakeholders of the system, their objectives, and relationships. The analyst can therefore visualize the current processes in the organization and examine the rationale behind these processes, thereby i* presents an important issue where VORD method fail in. In this context, authors propose an approach that builds on both VORD and i* models. VORD deals with the involvement of different stakeholders in Requirements Engineering of producing SaaS, and conversely i*’s strengths bridges VORD’s gaps. The rest sections are organized as follows: A section presenting the Characteristics of CC, then Requirements Engineering and SoRE, the authors present in the next the background of used concepts and models, then present the inspirational motivation to combination of VORD and i*. After that, the proposed approach is presented, followed by illustrative case study. We need to situate and analyze relevant works, of course, and we give at the end a conclusion and future work.