Towards a Systematic Service-oriented ... - Semantic Scholar

Towards a Systematic Service-oriented Requirements Engineering Process (S-SoRE) Fernando Flores1, Manuel Mora2, Francisco Álvarez3, Laura Garza2 and Héctor Durán4 1

PhD. Student, Computer Science Department, Autonomous University of Aguascalientes, Aguascalientes, Ags., México, 20131, 2 Information Systems Department, Autonomous University of Aguascalientes, Aguascalientes, Ags., México, 20131, {mmora, lg}@correo.uaa.mx 3 Computer Science Department, Autonomous University of Aguascalientes, Aguascalientes, Ags., México, 20131, [email protected] 3 Computer Science Department, University of Guadalajara, Guadalajara, México, 44130, [email protected]

Abstract. Software and System Requirements Engineering (RE) is considered a critical process for successful projects. Incomplete, ambiguous, and/or wrong requirements can be delivered for next design phase when this process is nonadequately performed. Thus, a well-defined and suitable RE process is needed. For usual computing paradigms (e.g. object-oriented and component-based schemes) several stable RE processes are available. However, under the emergent service-oriented computing paradigm, while diverse adaptations have been posed, none of them has gained yet their standardized utilization acknowledgment. Consequently, academics and practitioners are still confused on what RE process and specific techniques can be used for developing serviceoriented software systems (SoSS). In this paper, for advancing on such a problem and through a conceptual design research, we report: (i) an overview of a classic RE process and main used techniques, (ii) an analysis of emergent techniques reported in other domains but useful for SoSS RE, and (iii) an initial 30-mile view of a proposed systematic service-oriented requirements engineering (S-SoRE) process. Keywords: service-oriented requirements engineering (SoRE), service-oriented software systems (SoSS), quality function deployment (QFD), service level agreement (SLA), operational level agreement (OLA), IDEF0 diagrams, software system development lifecycle (SDLC).

1 Introduction Recently, the concepts of service-oriented computing (SOC) and by extension service-oriented software engineering (SoSE) have emerged to denote the computing model of consuming coarse-grained computational services delivered mainly, but not exclusively, over the Internet. SOC enhances the component-based computing

Paper accepted in CENTERIS 2010

functionality from single encapsulated applications (built on components) to service delivery infrastructures [19], [10]. Service-oriented computing and software engineering (SOC/SoSE) are expected to improve the development and delivery process of single and complex interorganizational software applications. For instance, Lichtenstein and colleagues in [14] mention that “in an increasingly service-oriented economy, corporate information technology (IT) management is evolving towards service-based models that offer continuous evaluation and improvement of application, communication, delivery and support services to internal and external customers”. The SOC/SoSE paradigm also refers to the set of concepts, principles, and methods for designing and deploying a Service-oriented Architecture (SOA). SOA relies in the principle of building complex software applications through re-usable, loosely-coupled, high-interoperable, platform-independent, and standard software components [17]. Hence, the SOC/SoSE paradigm can be considered of high value for being deployed in organizations. However, for this to happen, these systems must be engineered through a system development life cycle (SDLC). In this paper, we are focused on the usual first stage of each well-defined SLDC: Requirements Engineering (RE). Accordingly to Zave [26] RE “is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems”. In general, RE has been considered a complex process [13] due to transformation difficulties between high-level objectives and operational specifications, informal to formal descriptions, integration of software pieces to the full target system and its environment, and the conflicts between nonfunctional requirements of multiple stakeholders with diverse backgrounds, and their conflicts on technical and political and human-based power goals, and the need of high interrelated tasks to be conducted. While in classic RE (e.g. object-oriented and component-based schemes), there are stable RE processes and techniques, in the emergent domain of service-oriented software systems, there is not a clear stable and systematic process yet [13]. Need of service-oriented software system RE processes has been reported by diverse authors in [13], [1], [23], given the additional generated problems such as: (i) reduced utilization of service performance metrics, (ii) unclear, incomplete, negative or static service specifications, and (iii) significant and yet unexplored socio-technical issues experienced in negotiating conflicting customer and provider service requirements. Under such situation, in this paper, we claim that past accumulative knowledge on RE can be useful for designing a systematic service-oriented requirements engineering (S-SoRE) process, if it is enhanced with innovative methods and techniques reported in other domains (Systems Engineering, Industrial Quality Engineering, and IT Service Management). This design is guided through a conceptual design research approach [15]. The remainder of this paper continues as follows: in Section 2 an overview of classic RE techniques is reported. In Section 3 an analysis of the emergent techniques reported in other domains but useful for SoRE is analyzed. In section 4 the initial 30-mile view of an systematic service-oriented requirements engineering (S-SoRE) process, as its design rationale are reported. Finally, in section 5, we finish with conclusions, limitations, and future work.


2 An Overview of Classic RE: Process and Techniques A full Requirements Engineering (RE) process, when it is conducted with sufficient detail, is similar to a full software development life cycle. Traditionally, a RE process is performed in the beginning of the system development life cycle [20]. However, in large and complex systems development, the development of a stable and accurate set of requirements could demand concurrent efforts in next phases [4]. Therefore, a full RE process can be considered an incremental and iterative process, where each iteration is addressed with more detail. Sommerville in [22] suggests that before developing a software system, software engineers “must understand what the system is supposed to do and how its use can support the goals of the individuals or business that will pay for that system”. Such an understanding is so critical that author (2005, p. 16) defines a RE process as a the “structured set of activities that help to develop those understandings and that document the system specification for the stakeholders and engineers involved in the system development.” Author (2005) has also established that the RE process varies depending on the type of application to develop, the size and culture of the companies involved, and the software acquisition processes used. Thus, the correct selection of a RE process depends on several attributes such as: particular organization, particular systems engineering and software development process, and particular type of software developed, among others [21]. Nevertheless, while all of the RE processes do not fit to all organizations, a systematic and well-defined RE process is considered always useful when it includes at least the following activities [8]: • • • •

Requirements Elicitation: where the system requirements are discovered. Requirements Specification (Analysis and Negotiation): where the requirements are analyzed in detail, and they are negotiated for final stakeholders’ acceptance. Requirements Validation: where the consistency and completeness of the requirements are checked. Requirements Management: where the overall process is managed and conflicts are tried to be solved.

Space limitations preclude an extensive review of classic RE processes and techniques. Next discussion is based on Flores et al. [5], where a systematic RE process which integrates diverse core studies on RE has been reported. Accordingly to Flores et al. [5], a systematic RE process can be conducted through the following six phases: • •

Contextual Analysis. In this activity, there are considered the environmental influences (economics, political, business goals, and legal) which could affect the successful software system development. Elicitation. In this activity, the stakeholders, their information, and their willingness to provide it are elicited. A stakeholder is everyone that affects or will be affected for the new system [11].


• • •

• •

Analysis. In this activity, the structure of the requirements is identified, finding out their interrelationships. Modeling and Representation. In this activity, the requirements engineer models each requirement in an agreed and readable way in order that these requirements can be clearly understood by each stakeholder. Communication and Negotiation. In this activity, the requirement engineer shows and explains every identified requirement to each stakeholder in order to avoid mistakes or misunderstandings, and stakeholders' conflicts are negotiated. Validation and Final Specification. In this activity, every requirement is validated, and if there is not any change, the requirements engineer elaborates the final requirement specifications. Change Management. This activity is performed after each activity in order to record and track every change realized. With it, a history of the process is available for auditing and continuous improvement issues.

The authors in [5] report the rationale elaboration of this systematic process from four core sources. Similarly, several stable and standard RE techniques have been reported. Again, based on Flores et al. [5] a summary of them is reported in Figure 1.

Fig.1 Summary of Techniques and Methods of Classic RE


3 Emergent Processes and Techniques for SoRE There are several concepts which can be considered as the building blocks for a service-oriented Requirements Engineering. We believe that such concepts are: (i) software as a service and service attributes, (ii) business process, workflow modeling and service-oriented design, (iii) IT service management issues, and (iv) emergent RE techniques from related domains. 3.1 Software as Service and Service Attributes Software as a service (SaaS) is a confusing term that means different things to different people. According to White [2], SaaS can be broken down into three main types of service: (i) on demand software purchasing, where individual users or organizations try, buy, download or rent a personal, workgroup, or enterprise full software across the internet; (ii) on demand IT service-oriented architecture (SOA), where an IT system and application processing is defined and developed as a set of own organizational packages of services that can interoperate and exchange information with each other; and (iii) on demand application services, where individual user or organizations pay external third-party providers for the use of packages of services for their own applications. SaaS has also core attributes [6] such as: usefulness, multi-platform, standardized access, component-oriented built, standardized task provision, customer, provider, loosely-coupled, and Internet or non-internet based delivering. 3.2 Business Process, Workflow Modeling and Service-oriented Design Conceptual modeling of business processes is deployed to facilitate various purposes. Several approaches have been posed. Business Process Re-engineering (BPR) [7] aims at radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed. Activity Based Costing (ABC) [9] is used as a basis for calculating the direct costs of products and services. Similarly, schemes like ISO 9000 and Total Quality Management (TQM) which focus on the Quality System of an organization, demands a model of the organizational structure of a business, its responsibilities, procedures, processes and resources [24]. Furthermore, modern businesses face the problem to fit or adjust their process support when new IT is deployed in the organization. Dijkman and Dumas in [3] suggest that a Service-oriented Design (SoD) process is required for implementing and executing IT-based services. SoD is needed to aid in the communication between application architects as well as between application and enterprise architects. It is also needed to verify the conformance of services to their requirements and to enable a model-driven approach to service development and composition. The authors in [3] mention that basic service requirements are: (i) high autonomy, (ii) coarse granularity, and (iii) process awareness. In particular, as services often correspond to a business functionality provided by an organizational unit, they are likely to be part of long-running interactions driven by explicit process


models. Hence, SoD should take into account the business processes as part of which services operate and interact, and in particular, the integration of services into business processes and workflows. Initial proposals on these concepts are reported by Papazoglou and Heuvel in [18]. 3.3 IT Service Management Issues Accordingly to Mora et al. [16] IT Service Management refers to the planning, design, building-transition, operation and continuous improvement of IT services in an organization. In the Software Engineering domain, a service -at most- can be a full software application, but in the IT domain, it is only considered a part of the full service, which is finally delivered for a service systems comprised of people, technology and processes [16]. Thus, this duality view introduces an additional complexity for the IT and SwE people in an organization. For this problem, initial solutions have been reported. For instance, Van Eck and Wieringa in [25] suggest that two new types of Requirements Engineering (RE) will emerge to complement the IT service movement: (i) RE for service customers (customers) and (ii) RE for service providers (providers), and Trienekens et al. in [23] point out the need for consensus between provider and customer in a Service Level Agreement (SLA) specification. Papazoglou in [19] identifies an additional problem: satisfying two conflicting kinds of business needs: (i) global business requirements, and (ii) local business requirements. In low-scale systems this is not present, but in large-scale (e.g. inter-organizational systems) such problem emerges. 3.4 Emergent Service-oriented RE Techniques Based on proposal on required techniques for three levels used in IT service management [16], and after a literature review on service-oriented domain and related areas, we identify some plausible techniques and methods that can be incorporated for a SoRE process (see Fig. 2). We classify them in three groups: strategic business, operational business, and IT operational levels.

Fig.2 Currently techniques versus service-oriented paradigm into organizational levels


These emergent techniques are: T1 (IDEF0), T2 (WBS), and T3 (QFD/HoQ) for strategic business level; T4 (BPMN), and T5 (OLA, SLA) for operational business level; and T6 (RUP Workflow) and T7 (CMMI - RD) for the IT operational level These techniques come from different knowledge domains. Work Breakdown Structure (WBS), Business Process Modeling Notation (BPMN), Workflow (RUP Workflow), and Integrated Function Modeling Method (IDEF0) from Systems Engineering; Service Level Agreement (SLA) and Operational Level Agreement (OLA) from Information Technologies Service Management (ITSM); and Capability Maturity Model Integration (CMMI), and Rational Unified Process – Software Engineering (RUP) from Software Engineering.

4 S-SoRE: an Initial Systematic Service-oriented Requirements Engineering Process Given that the three-fold concept of service (e.g. as a high-level business service, an operational business service, and an IT service level [12], [16]), we support the notion of using RE methods, techniques and an integrated process which considers such views. From the business level, the requirements engineer must be aware of the business goals and the business processes of an organization. It can assure that the developed software system is aligned with those business processes and business goals that finally will support. From the IT level, the requirements engineer must translate such high-business level requirements in engineering low-level and operational specifications. Under such a design premise, a general classic RE process, and the previous emergent techniques identified, a systematic SoRE process can be defined as follows: 1. Business Process Modeling Phase. In this phase the business goals and the business processes that support those goals are identified making a high-level model of the business processes. Three tasks are posed as follows: (1.1) Business Goal Comprehension; (1.2) Business Process Detection; and (1.3) Strategic Information Detection. 2. Flow-Down Phase. This phase is concerned with each business process identified in the phase above, detecting, understanding and analyzing each activity needed to successfully execute the business process flowing it down until the business process architecture is discovered [4]. 3. Formal Requirements Specification Phase. In this phase, the requirements software needed to successfully satisfy the business process are formally established by: (3a) negotiating and elaborating Service Level Agreements (SLAs), and (3b) translating them in Operational Level Agreements (OLAs). Two specific tasks are proposed: (3.1). Requirements Elicitation, and (3.2) Requirements Specification. In Figures 3 and 4, this systematic SoRE Process is illustrated using IDEF0 diagrams.


Fig.3 Systematic SoRE Process IDEF0 Diagram

Fig. 4 Systematic SoRE Process IDEF0 Detailed Diagram

This initial systematic SoRE process identifies the incorporation of two main activities Business Process Modeling (high business view), and Flow-Down Analysis (business low level view), before to start a normal Elicitation and Specifications tasks (operational software/computing view). In SoSS, the wider scope of the system regarding to traditional systems (see Fig. 2) demands an identification of core issues in higher business levels no usually required in operational ones. This suggested activities help to the requirements engineer captures the overall and systemic view of a SoSS.


This systematic SoRE process (initial 30-mile view) was conceptually evaluated for a panel of eight PhD experts in several areas of software engineering from Mexican, North American, and European higher education institutions. An overall index (using a Likert scale from 1 (very low agreement) to 7 (very high agreement)) on the face validity of this model was of 4.1 with a standard deviation of 0.270. Given such initial results, we consider that this model is validly plausible for be refined and empirically tested.

5 Conclusions We consider that service-oriented paradigm for developing software systems implies a fundamental shift in the way that a new software system will start its development inside an organization. While in traditional paradigms the main point of view is an operative one, (concerned with the system functionality, on how to reuse code software previously developed, etc), under the new service-oriented paradigm, the business point of view must be considered at the first instance and it must lead the full development (or at least the RE process). In this new paradigm, both high-level and operational business process users are still important and their expectations must be respected due to they own the knowledge about how to do their tasks. However, given that they will be supported with IT for developing their business processes, they must also work strongly aligned to the organizational business goals. Thus, while software functionality is relevant, it is expected it clearly supports business process and goals. Hence, given the novelty of such methods and techniques, and the lack of integrated SoRE proposals, we consider that this paper contributes to: (i) present an integrated survey on the SoRE status; (ii) present an initial and plausible valid model for SoRE; and (iii) alert to SoRE research community on the need to align the business (IT Service Management and Systems Engineering) with the operational (Software Engineering) views. It is planned a further elaboration of the SoRE process reported and a proof of concept application with a demonstrative case.

References 1. Barker, D.: itSMF – ITIL Best Practice. Are we Getting the Message?, ServiceTalk – Journal of IT Service Management Forum, 66, pp. 3 (2004) 2. BeyeNETWORK, http://www.b-eye-network.com/view/2913 3. Dijkman R., Dumas M.: “Design: A Multi-viewpoint Approach”, International Journal of Cooperative Information Systems, pp. 337-368 (2004) 4. Dorfman, M., Thayer, R.H.: “Software Requirements Engineering”, CA, IEEE Computer Society Press, Los Alamitos, (1997) 5. Flores F., Mora M., Álvarez F., O’Connor R., Macias J.: Handbook of Research on Modern Systems Analysis and Design Technologies and Applications, In IGI Global (eds) Chapter VI: Requirements Engineering: A Review of Processes and Techniques, Minnesota State University; Mankato – USA, pp. 96 -111 (2008) 6. Flores, F., Mora, M., Álvarez, F., Garza, L., Ramírez, A.: El Concepto de Software como Servicio. Cuarto Congreso Estatal “La Investigación en el Posgrado”, Universidad Autónoma de Aguascalientes, México. (2008)


7. Hammer, M., Champy, C.: Reengineering the Corporation: Manifesto for Business Revolution, Brealey, London (1993) 8. IEEE SwBOK: Guide to the Software Engineering Body of Knowledge. IEEE, Los Alamitos, CA, USA. (2001) 9. Kaplan, R.S., Atkinson, A.A.: Advance Management Accounting, Prentice Hall, New Jersey (1989) 10.Kontogiannis, K.., et al.: The Landscape of Service-Oriented Systems: A Research Perspective. In Proceedings of International Workshop on Systems Development in SOA Environments (SDSOA'07), pp. 1-6 (2007) 11.Kotonya, G., and Hutchinson, J.: Viewpoints for Specifying Component-Based Systems, To appear in Proceedings of the International Symposium on Component-based System (CBSE7) (2004) 12.Kotonya, G. Hutchinson, J., Bloin, B.: A Method for Formulating and Architecting Component and Service-Oriented Systems, In Service-Oriented Software System Engineering: Challenges and Practices, IGP, Hershey, pp. 155-181. (2005) 13.Lamsweerde, A. Requirements Engineering in the Year 00: A Research Perspective. In Proceedings of the ICSE 2000 Conference, Limerick, Ireland, pp. 5-19. (2000) 14.Lichtenstein, S., Nguyen, L., Hunter, A.: Issues in IT Service Oriented Requirements Engineering, AWRE’04 9th Australian Workshop on Requirements Engineering, pp. 176191. (2004) 15.Mora, M., Gelman, O., Paradice, D. & Cervantes, F.: The case for Conceptual Research in Information Systems. In: G. Grant & T. Felix (Eds), Electronic Proceedings of the 2008 International Conference on Information Resources Management (Conf-IRM), May 18-20, 2008, Niagara Falls, Ontario, Canada, pp. 1-10, (2008) 16. Mora, M., O’Connor, R. & Macias, J. : Toward an engineering and management framework for service-oriented IT organizational systems. In: P. Dembla, P. Palvia & G. Pares (Eds), Proceedings of the GITMA 2009 Conference, Mexico, DF, June 14-16, pp. 1-4, (2009). 17.Nitto, E.: International Workshop on Service Oriented Software, Iw-SOSE’06, pp. 1-5 (2006) 18. Papazoglou, M.P., van den Heuvel, W.J.: Service Oriented Arechitectures: approaches, thecnologies and research issues, The VLDB Journa, Springer Berlin, pp. 389-415 (2007) 19.Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F.: Service-oriented Computing: State of the art and Research Challenges, Computer, pp. 38-45 (2007) 20.Royce, W.W.: Managing the development of large software systems: concepts and techniques, In ICSE’87: Proceedings of the 9th international conference on Software Engineering, pp. 328-338 (1987) 21.Sommerville, I., Sawyer, P.: Requirements Engineering: A Good Practice Guide, Wiley, Chichester (1997) 22.Sommerville, I.: Integrated Requirements Engineering: A Tutorial, IEEE Software. (2005) 23.Trienekens, J.J.M., Bouman, J.J., van der Zwan, M.: Specification of Service Level Agreements: Problems, Principles and Practices, Software Quality Journal, 12(1), pp. 43-57 (2004) 24.TUDelft, http://repository.tudelft.nl/file/82937/044821 25.van Eck, P.A.T. ans Wieringa, R.j.: Requirements for Service-oriented Computing: A Position Paper, in: First International Workshop on e-Services at ICEC’03, pp. 23-28, USA (2003) 26.Zave, P.: Classification of research efforts in requirements engineering, ACM Computing Surveys, 29(4), pp. 315-321 (1997)