استفاده از جداول مسئولیت سرویس به عنوان مکمل UML در تحلیل سیستم های الکترونیکی خدمات

This paper proposes using Service Responsibility Tables (SRTs) as a tool in analyzing e-service systems. First it discusses difficulties and deficiencies of using formal modeling languages such as UML in analyzing e-service systems. It proposes using SRTs as an informal language and lightweight analytical tool to be used by business professionals in analyzing e-service systems. SRTs are based on a service value chain framework but do not rely on abstract concepts and constructs, and therefore can be used by business professionals to supplement UML. We suggest a set of heuristics for transforming SRTs into two key UML diagrams, thereby illustrating how SRTs can be used as a bridge from relatively informal modeling by business professionals to formal modeling techniques for systems design and implementation by IT professionals.

The advent of the Internet and other modern information and communication technologies (ICTs) has led businesses worldwide to embrace e-commerce and e-service. E-commerce has been widely accepted as a viable business model for buying and selling products/services over the Web, leading to a new paradigm known as e-service, or electronic service, defined as the provision of service over electronic networks [42]. Common examples of such e-service include online package tracking, email notification of order status, and more recently mobile banking. The advantages of providing customers with e-service include reducing operating expenses, allowing for personalization, and improving customer satisfaction [8] and [40]. Through e-service, enhanced service experience and higher levels of customer satisfaction tend to increase revenues and profitability [42]. For customers, the benefits of e-service include addressing new business needs, saving money and time in traveling, and avoiding awkward interpersonal encounters [32]. Whereas e-service systems may offer many benefits to businesses and their customers, developing e-service systems is challenging [56]. E-service is predominately self-service [40]. In other words, customer use of e-service systems implies coproduction of service, frequently requiring customers to engage in new behaviors [33]. There is a general agreement on the importance of user involvement during systems analysis and design [10] and [55]. The self-service nature of e-service poses several difficulties in effectively involving users' participation in systems analysis and design stages. First, ordinary customers, i.e. the intended users of e-service systems, often have difficulty identifying and describing the capabilities and features they want [33]. Even if the system totally reflects what they requested, it often omits important capabilities that the users failed to request [34]. Second, formal requirements modeling methods, such as Unified Modeling Language (UML), are frequently used to create requirements representations that need users' review and approval [22]. Such formal notations are difficult to understand for people with little or no technology background [25]. Users have difficulty verifying the accuracy and completeness of requirements models that are presented in formalisms that are unfamiliar to them at best, and sometimes seem impenetrable to typical business professionals. This paper proposes Service Responsibility Tables (SRTs) as tools that business professionals and service customers can use in the analysis stage of e-service system development. The idea of SRTs came from service-related extensions of work system research [2] and [4], which has focused for over a decade on developing lightweight systems analysis tools for business professionals. The form of SRTs is based on the structure of the service value chain framework [4], [6] and [7]. Tan, Alter, and Siau [57] propose that the use of SRTs might alleviate difficulties in analyzing e-service systems by helping users and analysts summarize and discuss important elements and processes involved in service provision. In comparison with formal modeling methods, SRTs are easier to use by business professionals who typically have little or no knowledge of the heavyweight analytical tools. SRTs can help them devote their cognitive effort to eliciting and identifying requirements in e-service systems, instead of making sense of the syntax and grammar of formal modeling languages. We are not proposing that SRTs should replace UML, which is the de facto modeling standard of the software development community [21]. Instead, we propose to use SRTs as a lightweight analytical tool for business professionals. The resulting SRTs can be transformed to rigorous UML diagrams by analysts who are able to fill in missing details needed to produce syntactically and substantively correct UML diagrams. We suggest using a set of heuristics to facilitate the transformation from SRTs to UML diagrams. The rest of the paper is organized as follows. The first section introduces common cognitive problems that can affect requirements modeling, and explains why some of these problems are heightened in e-service systems analysis. The objective is to clarify the difficulties of applying formal modeling methods in the analysis stage. The second section provides background on a flexible class of analysis tools called SRTs, and explains how they can be used as lightweight analysis tools for business professionals and analysts. The third section summarizes initial heuristics for transforming SRTs into UML diagrams for documenting requirements. The usefulness of the heuristics is illustrated through a case. The conclusion section discusses the implications of the present study for research and practice, and highlights the directions for future research.

This paper reviewed the difficulties of using a formal modeling language such as UML in e-service systems analysis and proposed using SRTs as an informal language and lightweight analytical tool to supplement UML. This tool is based on the service value chain framework and does not require technical concepts or obscure terminology. Therefore it can be adopted easily by business professionals to analyze e-service systems. The paper also presents a set of heuristics to transform SRTs to two key UML diagrams, which are used as formal modeling techniques for systems design and implementation by IT professionals. Our research on the use of SRTs addresses the following goals: i. Understand the benefits and practical limitations of lightweight analysis such as the approach based on SRTs. ii. Develop heuristics that can be used to transform SRTs into UML diagrams that can be used for more precise documentation and analysis that is needed for the development of testable software. iii. Develop ways to complement and supplement UML diagram creation by using SRTs to capture ideas, issues, and requirements that are outside of UML's scope. There are a number of directions for future study in this line of research. First, empirical studies can assess the efficacy of using the service value chain framework and the associated SRT technique in analyzing e-service systems. Case study or action research might be appropriate research methods for this purpose. The proposed SRT technique may also be applied in educational and training settings to educate systems analysis and design students. Second, the proposed heuristics can be tested in practice and developed further. New heuristics can be developed to guide the transformation of SRTs into other UML diagrams, such as activity diagrams and sequence diagrams. Third, follow-on research might assess the semantic equivalence of SRTs and UML diagrams. Finally, SRTs might be used in other systems analysis and design contexts, such as knowledge management systems and enterprise systems integration. In all areas, the overarching goal is to supplement formal, high precision analysis and design tools with lightweight tools that are more useable and understandable by typical business professionals. Such tools could help business professionals understand e-service systems in greater depth and could help them communicate with IT professionals about functional and non-functional requirements for software development.