Decision Support Systems 51 (2011) 350–360

Contents lists available at ScienceDirect

Decision Support Systems

j ourna l homepage: www.e lsev ie r.com/ locate /dss

Using service responsibility tables to supplement UML in analyzing e-service systems

Xin Tan a,1, Steven Alter b,2, Keng Siau c,⁎a Fairleigh Dickinson University, 1000 River Road, H-DH2-06, Teaneck, NJ 07666, United Statesb University of San Francisco, 2130 Fulton Street, MH-314, San Francisco, CA 94117-1045, United Statesc University of Nebraska-Lincoln, 209 CBA, Department of Management, Lincoln, NE 68588-0491, United States

⁎ Corresponding author. Tel.: +1 402 472 3078; fax:E-mail addresses: xtan@fdu.edu (X. Tan), alter@usfc

(K. Siau).1 Tel.: +1 201 692 7283; fax: +1 201 692 7219.2 Tel.: +1 415 422 6383; fax: +1 415 422 2502.

0167-9236/$ – see front matter © 2011 Elsevier B.V. Adoi:10.1016/j.dss.2011.01.001

a b s t r a c t

a r t i c l e i n f o

Article history:Received 10 May 2009Received in revised form 16 January 2011Accepted 16 January 2011Available online 21 January 2011

Keywords:Systems analysis and designWork system methodService responsibility tableUnified modeling language

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

+1 402 472 5855.a.edu (S. Alter), ksiau@unl.edu

ll rights reserved.

© 2011 Elsevier B.V. All rights reserved.

1. Introduction

The advent of the Internet and other modern information andcommunication technologies (ICTs) has led businesses worldwide toembrace e-commerce and e-service. E-commerce has been widelyaccepted as a viable business model for buying and selling products/services over theWeb, leading to a new paradigm known as e-service,or electronic service, defined as the provision of service overelectronic networks [42]. Common examples of such e-service includeonline package tracking, email notification of order status, and morerecently mobile banking. The advantages of providing customers withe-service include reducing operating expenses, allowing for person-alization, and improving customer satisfaction [8,40]. Through e-service, enhanced service experience and higher levels of customersatisfaction tend to increase revenues and profitability [42]. Forcustomers, the benefits of e-service include addressing new businessneeds, saving money and time in traveling, and avoiding awkwardinterpersonal encounters [32].

Whereas e-service systems may offer many benefits to businessesand their customers, developing e-service systems is challenging [56].E-service is predominately self-service [40]. In other words, customeruse of e-service systems implies coproduction of service, frequentlyrequiring customers to engage in new behaviors [33]. There is a

general agreement on the importance of user involvement duringsystems analysis and design [10,55].

The self-service nature of e-service poses several difficulties ineffectively involving users' participation in systems analysis anddesign stages. First, ordinary customers, i.e. the intended users ofe-service systems, often have difficulty identifying and describing thecapabilities and features they want [33]. Even if the system totallyreflects what they requested, it often omits important capabilities thatthe users failed to request [34].

Second, formal requirements modeling methods, such as UnifiedModeling Language (UML), are frequently used to create require-ments representations that need users' review and approval [22].Such formal notations are difficult to understand for people with littleor no technology background [25]. Users have difficulty verifying theaccuracy and completeness of requirements models that are pre-sented in formalisms that are unfamiliar to them at best, andsometimes seem impenetrable to typical business professionals.

This paper proposes Service Responsibility Tables (SRTs) as toolsthat business professionals and service customers can use in theanalysis stage of e-service system development. The idea of SRTs camefrom service-related extensions of work system research [2,4], whichhas focused for over a decade on developing lightweight systemsanalysis tools for business professionals. The form of SRTs is based onthe structure of the service value chain framework [4,6,7]. Tan, Alter,and Siau [57] propose that the use of SRTs might alleviate difficultiesin analyzing e-service systems by helping users and analystssummarize and discuss important elements and processes involvedin service provision. In comparison with formal modeling methods,SRTs are easier to use by business professionals who typically havelittle or no knowledge of the heavyweight analytical tools. SRTs can

351X. Tan et al. / Decision Support Systems 51 (2011) 350–360

help them devote their cognitive effort to eliciting and identifyingrequirements in e-service systems, instead of making sense of thesyntax and grammar of formal modeling languages.

We are not proposing that SRTs should replace UML, which is thede facto modeling standard of the software development community[21]. Instead, we propose to use SRTs as a lightweight analytical toolfor business professionals. The resulting SRTs can be transformed torigorous UML diagrams by analysts who are able to fill in missingdetails needed to produce syntactically and substantively correct UMLdiagrams. We suggest using a set of heuristics to facilitate thetransformation from SRTs to UML diagrams.

The rest of the paper is organized as follows. The first sectionintroduces common cognitive problems that can affect requirementsmodeling, and explains why some of these problems are heightenedin e-service systems analysis. The objective is to clarify the difficultiesof applying formal modeling methods in the analysis stage. Thesecond section provides background on a flexible class of analysistools called SRTs, and explains how they can be used as lightweightanalysis tools for business professionals and analysts. The thirdsection summarizes initial heuristics for transforming SRTs into UMLdiagrams for documenting requirements. The usefulness of theheuristics is illustrated through a case. The conclusion sectiondiscusses the implications of the present study for research andpractice, and highlights the directions for future research.

2. Related literature

Eliciting and documenting users' requirements for the systembeing built are crucial activities in system development projects.Despite the general agreement on the importance of user involvementduring systems analysis and design, the level and quality of userinvolvement are often inadequate [30,31]. This section reviewsrelated literature to summarize common problems in eliciting anddocumenting users' requirements. It also surveys the literaturerelated to e-service to reveal the additional problems in using formalmodelingmethods in e-service systems analysis. It concludes with thefeatures of a novice-friendly analytical tool to supplement UML fore-service systems analysis.

2.1. Common problems in requirements determination

One of the key objectives of systems analysis and design is todetermine users' information requirements. Being able to understandusers' information requirements is vital in any software project and akey factor in any successful software implementation [11–13,17].Information requirements determination is a set of activitiesperformed by systems analysts to assess the functionality requiredin a proposed system. According to Pohl [38], requirementsdetermination involves four tasks that are often performed iterativelyin practice:

i. Requirements specification: to understand the organizationalsituation that the system under consideration aims to improveand describe the needs and constraints of the system underdevelopment.

ii. Requirements negotiation: to establish an agreement on therequirements of the system among the various stakeholdersinvolved in the process.

iii. Requirements representation: to develop a mapping of real-world needs onto a requirements model.

iv. Requirements validation: to ensure that the derived specifica-tion corresponds to the original stakeholder needs and con-forms to the internal and/or external constraints set by theenterprise and its environment.

Requirements determination for information systems is a highlycommunicative, iterative, and creative activity. Holtzblatt and Beyer[28] claim that the success of information requirements determina-tion depends on how well people communicate and understand eachother. Davis [16] summarizes four sources of difficulties in informa-tion requirements determination: (1) the constraints on humans asinformation processors and problem solvers, (2) the variety andcomplexity of information requirements, (3) the complex patterns ofinteraction among users and analysts in defining requirements, and(4) the unwillingness of users to provide requirements. Valusek andFryback [59] label these difficulties as communication obstacles“within” individual users, “among” users, and “between” users andanalysts. More recently, Siau and Tan [48,49] elaborate further on thecognitive underpinnings of such communication problems in thecontext of conceptual modeling and requirements determination.

Frames of reference held by organization members are implicitguidelines that serve to organize and shape their interpretation ofevents and organizational phenomena, as well as to give meaning to it[62]. Inconsistent frames of reference among stakeholders may lead tocommunication problems in systems analysis and design. Cognitiveinefficacy during systems analysis also may lead to inaccurate orincomplete requirements. In relation to systems development anduse, Orlikowski and Gash [35] label such frames of reference astechnological frames that are vital in understanding of the variety andcomplexity of user needs. For instance, analysts must manage thesubjective nature of language to disseminate technology to users in anon-technical way. On the other hand, analysts often organize,classify, describe, and explain complex processes and concepts in ahighly technical manner.

2.2. Nature of e-service systems

Businesses and non-profit organizations have started embracinge-service to deliver service to their customers through electronicnetworks, although there is a lack of agreement on the definition ofe-service [40]. In this research, we define e-service as:

Acts or performances that are delivered through electronic devicesand networks to help people complete tasks, solve problems, orconduct transactions.

A review of e-service literature [40] identifies two inherentcharacteristics of e-service: information service and self-service.Information service refers to the assumption that information is theprimary value exchanged between the two parties in an e-servicerelationship. Further, an e-service experience is a self-serviceexperience [40], or customer coproduction of service [33]. Someresearchers claim that “selling tangible goods online is itself ane-service that substitutes for physical retailing” [27].

These characteristics lead to challenges in developing andimplementing e-service systems. First, the self-service nature ofe-service has a high demand for customer engagement and learning[33,40]. Second, because e-service is typically conceptualized asinformation service, the dimensions of information quality, as well asnon-technological features such as trust, reliability, and risk, shouldbe considered as part of comprehensive requirements for e-servicesystems.

2.3. Why UML by itself is not sufficient for e-service systems analysis

With the dominance of object-oriented paradigm in informationsystems development, object-oriented modeling is expected to playan increasingly important role in requirements engineering. Consis-tent with this trend, UML has emerged as a de facto standard forobject-oriented modeling language [21,22,29]. UML is a graphicalmodeling language for modeling system requirements, describing

Table 1Problems in solely using UML for requirements determination for e-service systems.

Requirementsdeterminationtask

Characteristics of e-service systems

Self-service/customercoproduction

Information serviceand non-functional concerns

Requirementsspecification

As a modeling language, UMLdoes not provide a soundframe of reference for serviceproviders and customers toidentify requirements ine-service context.

As a modeling language,UML does not providesufficient semantics tospecify different dimensionsof information quality,as well as certainnon-functional requirementsin an e-service context.

Requirementsnegotiation

UML models are too complexfor service providers andcustomers to understand,therefore causing difficultyin requirements negotiation.

Insufficient semantics maycause difficulties innegotiating non-functionalrequirements.

Requirementsrepresentation

The complexity of UMLmakes it difficult forservice providersand customers to participateeffectively in requirementsrepresentation.

Insufficient semanticsmay cause difficultiesrepresenting completerequirements and/or theomission of non-functionalrequirements.

Requirementsvalidation

UML models are too complexfor service providers andcustomers to understand,therefore causing difficulty invalidating requirements bye-service users

Insufficiency in representationsemantics may make itdifficult for users to validatethe requirements.

352 X. Tan et al. / Decision Support Systems 51 (2011) 350–360

design artifacts, and specifying implementation details. The currentUML specification (version 2.2) defines thirteen types of diagrams,which can be applied for specifying, visualizing, and documentingmodels of software systems in various development phases. Some ofthe diagrams, such as class diagrams, use case diagrams, and activitydiagrams, are used for capturing and analyzing an application'srequirements [9,41].

Object-oriented requirements engineering is a relatively new areain object-oriented information systems development. Relatively fewempirical studies have investigated how practitioners use UML forrequirements engineering in organizational contexts. Dawson andSwatman [18] investigate how object-oriented modeling methods areused by practicing professionals in requirements engineering. Basedon a case study, Glinz [25] identifies several deficiencies of UML as alanguage for requirements specification. In other research, Siau andLee [45] investigate the possible synergetic values and relationshipsbetween the use case and class diagrams in the context ofrequirements analysis. Dobing and Parsons [21] survey the use ofUML diagrams by practitioners.

A literature survey revealed several critical insufficiencies of UMLfor requirements determination.

i. Although UML is a languagewith rigorous grammar and syntax,it is not a development methodology [21]. Guidelines forapplying UML are inconsistent across different developmentsettings [20,23]. Without a sound methodology as the frame ofreference, the communication obstacles identified above tendto have a negative impact on the accuracy and comprehen-siveness of requirements determination.

ii. UML is a complex modeling language [44,51]. It is easy fornovice developers and analysts to be overwhelmed by thevarious graphical notations and associated object-orientedconcepts [1,46]. Business professionals and ordinary userstypically find the formal models much too complex, bothconceptually and technically [18]. These language problemspose difficulties in various parts of requirements negotiationand requirements validation.

iii. The recommended diagrams for modeling requirements sufferfrom deficiencies related to accurate representation of require-ments [50], especially non-functional requirements [25]. Suchsemantic deficiencies may lead to incomplete representation offunctional and non-functional requirements [23].

Table 1 summarizes specific problems caused by solely using UMLfor requirements determination for e-service systems.

In view of the deficiencies of UML, we propose that additionalanalytical tools should be adopted in requirements determination fore-service systems analysis and design. For better analysis outcomes,such tools should supplement UML by meeting the following needs:

First, the analytical tools should be embedded in a soundframework in e-service contexts. Such a framework would provide aframe of reference that helps service providers, customers, managers,and analysts explore different elements and processes of serviceprovision, and generate comprehensive requirements.

Second, the analytical tools should alleviate learning difficulties forbusiness professionals and customers by providing an informalspecification language. Such lightweight analytical tools should beeasy to learn and should make sense to people who are familiar withservice contexts but not necessarily technical and modeling concepts.This approach is consistent with recommendations from manypractitioners and researchers [11,18,49].

Third, the analytical tools should be flexible enough to capturenon-functional requirements related to the dimensions of informationquality and other factors such as trust and security. In this way, theanalytical tools can supplement UML to generate a comprehensivesummary of users' functional or non-functional requirements.

In summary, the suggested supplementary tools should facilitatelightweight analysis by users. These tools should help them thinkthrough their own views of IT-reliant work systems, and should helpthem understand the business situation and potential implications ofany proposed change regarding process flow, information usage, andaspects of software and hardware that are visible to users and theircolleagues. These tools should help users conduct lightweight analysiswith or without the help of IT professionals. These tools shouldgenerate an understanding that supports heavyweight analysis anddesign performed by systems analysts and other IT professionalswhile building software. The lightweight analysis should complementand supplement heavyweight techniques that are used for formaldocumentation of requirements and for designing and implementingIT-based solutions.

We believe that Service Responsibility Tables (SRTs) are a goodexample of an analytical tool that business professionals can use inlightweight analysis of e-service systems. The following sectionprovides background about SRTs as an analytical tool.

3. Service value chain and Service Responsibility Tables

The general goal of supporting lightweight analysis by businessprofessionals motivated development of the work system approachfor understanding and analyzing IT-reliant systems in organizations.Its basic assumption is that most systems in organizations can beviewed and analyzed as work systems rather than as businessprocesses, computer systems, or tools that are used by individuals.Additional information about work system framework and worksystem method can be found in Appendix A. In this section, we focuson the theoretical foundation of our proposed analytical tool.

The evolution of the work systemmethod has generated a numberof concepts, frameworks, and tools including the work systemframework, work system life cycle model, work system snapshot,and work system principles, all of which have been described in priorliterature [2,3,5–7]. More recently, widespread interest and concernabout services and the service economy led to extensions of the worksystem approach to incorporate issues and characteristics related to

353X. Tan et al. / Decision Support Systems 51 (2011) 350–360

services. The main products to date of those efforts are the servicevalue chain framework and Service Responsibility Tables [4,6].

3.1. Service value chain framework

Noting the increasing importance of services in the economy ingeneral and for technology companies in particular, IBM joined withother technology companies in amajor initiative to develop universitycourses of study related to service and to develop “service science”[15,54]. Motivations for this initiative included the long term need tohire employees who can succeed in a service economy and the beliefthat many practical and theoretical ideas related to service are not yetwell developed.

The effort to develop service science motivated an effort tointroduce service concepts into the work system method in a moredirect way. In an attempt to incorporate service concepts morecompletely, recent extensions of the work system approach incorpo-rated additional issues and characteristics related to services. Theservice value chain framework (Fig. 1) depicts generic activities andresponsibilities of both service providers and customers. These

Negotiate commitment(if any)

Provider’s Responsibilities

Create and improve service system

Fulfill service request

Provider setup

Provider’s internal follow -up

Handle service request

Service Delivery

Create awareness of the service

Customer -facing follow-up

Value capture

Service encounte

Fig. 1. Service value chain fram

activities and responsibilities may occur before, during, and afterdelivery of a specific service to a specific customer. The form of theservice value chain framework is based on the common observationthat services tend to be co-produced by service providers and serviceconsumers [60,61]. The service value chain framework includes alarge number of concepts related to services, such as coproduction ofvalue, value capture, service interactions, differentiation betweenback stage and front stage during the production and consumption ofservices, negotiations leading to service level agreements, providerand consumer preparation prior to instances of service delivery,negotiation of requests during specific instances of service provision,service fulfillment, and service follow-up [4,6,7].

3.2. Service Responsibility Tables

The work system approach was developed specifically to helpbusiness professionals understand, evaluate, and analyze systems inorganizations at any level of detail appropriate for their particularsituation, regardless of whether IT plays a central role. Typically theywould obtain help from IT professionals if changes in hardware and

Customer’s internal follow -up

Participatein

fulfillment

Make service request

Customer preparation

Customer’s Responsibilities

Negotiate commitment(if any)

Create and improve related systems

Become aware of the need

Value capture

Service Consumption

Provider -facing follow -up

rs

ework [6] slightly updated.

354 X. Tan et al. / Decision Support Systems 51 (2011) 350–360

software might be needed. We believe that a practical, easily learnedform of lightweight analysis for business professionals would be agood compromise between 1) assuming that they are incapable ofanalyzing anything in an organizedmanner and 2) assuming that theonly legitimate form of analysis is precise, rigorous analysis neededto produce testable computer programs and IT systems.

The two-sided format of the service value chain frameworktranslates directly into a useful and flexible analysis tool called aService Responsibility Table (SRT). SRTs strip out the terminologyabout steps in services per se, and emphasize coproduction byidentifying the (active or passive) responsibilities of both serviceproviders and service consumers throughout a service process. Table 2is an SRT corresponding to a loan application and underwritingsystem.

As shown in the first two columns of Table 2, the simplest form ofSRT resembles a two-column swimlane diagram, with one column forproviders and one for customers, and with specific provider andcustomer roles indicated clearly. The entries in the first two columnsof Table 2 are all activities, although some SRT entries can beresponsibilities, such as a patient's responsibilities during a physicalexam or a traveler's responsibilities during an airplane flight. It is easy

Table 2A Service Responsibility Table (SRT) example.

Provider activity orresponsibility

Customer activity orresponsibility

Information used orgenerated

Loan officer identifiesbusinesses thatmight need acommercial loan.

Uses a company'sfinancial profile

Loan officer contactspotential loanapplicant.

Potential loanapplicant agreesto discuss the possibilityof receiving a loan

Uses contact informationof potential applicants

Loan officer discussesloan applicant'sfinancing needs andpossible terms of theproposed loan.

Potential loanapplicant discussesfinancing needs.

Generates initial loanapplication with financialterms such as amount,terms, interest rate,collaterals, etc.

Loan officer helps loanapplicant compile aloan application

Loan applicantcompiles loanapplication.

Generates formal loanapplication with financialterms

Loan officer and seniorcredit officer meetto verify that the loanapplication has noglaring flaws.

Uses loan application

Credit analyst prepares a“loan write-up”summarizing the client'sfinancial history,providing projectionsof sources of fundsfor loan payments, etc.

Generates loan write-upwith details

Loan officer presentsthe loan write-up to asenior credit officeror loan committee.

Uses loan write-up

Senior credit officer orloan committee makesapproval decision.

Uses loan write-up andloan application

Loan officer informsloan applicant of thedecision

Loan applicantaccepts ordeclines anapproved loan.

Uses loan application

Loan administrationclerk produces loandocuments for anapproved loan thatthe client accepts

Generates loan documents

to extend a two-column SRT into a three-column SRT that adds a newcolumn for any of a number of topics that might be important foranalyzing a particular system. The third column in Table 2 identifiesinformation used or generated at each step. Many other examples oftopics for the third column are listed in Table 3.

An SRT (see Table 2) overlaps somewhat with a work systemsnapshot, a central tool in the work system method that consists of aone page summary of a work system based on six central elements ofthe work system framework (see Appendix). The preferred sequencein applying these tools is to use the work system snapshot to createagreement about the scope and outputs of the work system beingstudied, and then to use a sequence of SRTs to create a strongercustomer focus and to introduce a series of topics such as informationused or generated (as shown in Table 2), business rules at each step,important exceptions at each step, and so on.

The format of an SRT facilitates easy reuse as the analysis proceeds.For example, it is easy to generate a set of three-column SRTs byreusing the first two columns and including in each additional SRT anew column for any of a number of topics that might be important foranalyzing a particular system (see Table 2). Initial empirical evidencefrom classroom usage by MBA and EMBA students suggests that SRTsare potentially useful tools [4].

3.3. Advantages of Service Responsibility Tables

Use of an SRT early in an e-service system analysis has severaladvantages over using formal specification languages such as UML.

Table 3List of typical topics (by Step) for additional columns of an SRT.

Topics related to problems or issues(by step)

Topics related to thesystem's structureand requirements(by step)

Topics related toperformance metrics(by step)

• Issues andproblems participantor interpersonal issues

• Goals andrequirements

• Activity rate

• Information issues• Pre-conditions

• Duration(cycle time)

• Technology issues

• Triggers • Delay betweensteps

• Confusion or training issues

• Business rules

• Defect rate• Points of friction

• Business or legalconstraints • Rework rate

• Reasons for delays,errors, rework

• Post-conditions • Downtime

• Communication issues

• Special cases • Provider cost

• Conflicts with culture or policies

• Significantexceptions

• Customer cost

• Legal or regulatory issues • Alternative pathsor methods

• Customercomplaints

• External dependencies• Knowledge or skillrequirements forparticipants

• Informationaccuracy• Conflicts with other

systems

• Participantincentives

• Informationtimeliness

• Information used

• Informationavailability

• Informationgenerated

• Informationsecurity

• Technology used

• Technologyperformance

• Products andservices produced(and used in othersystems bycustomers orproviderorganizations)

• Key performancegaps for importantsteps (Gap=desiredvs. current value ofan importantmetric.)

• Possibilities forchange• Things that cannotchange• Benefits providedto customers

355X. Tan et al. / Decision Support Systems 51 (2011) 350–360

i. It clarifies scope and context of the process without requiringmastery of details that will be clarified later in the analysis byusing detailed representations of workflow and logic.

ii. It focuses attention on activities and responsibilities rather thanon details of technology and information.

iii. It identifies the job roles that are involved.iv. It brings customer responsibilities into the analysis.v. It identifies service interactions (rows with both provider and

customer responsibilities) and other steps that are not visibleto customers.

The tabular structure of SRTs is also conducive to creation ofvarious standard versions that can be defined and used throughdatabase or spreadsheet software. For example, at the beginning of itssystems analysis efforts, a particular firmmight establish the commonpractice of using SRTs with the following third columns: problems,opportunities, and issues; key errors and exceptions; constraints; andrecommended changes (if any) for each step. People in that firmwould become accustomed to discussing a two-column SRT to definethe scope of the system to be analyzed, and then using the additionalSRTs as a starting point for exploring additional topics and issues.

Many additional variations are consistent with an SRT's basicstructure. For example, if it is important to remember that certaingroups of steps occur in parallel, it is possible to number the activitiesand use simple numerical conventions to indicate activities that occurin parallel. If it is important to record non-sequential precedencerelationships in an SRT (rather than in other documentation), it ispossible to add two numeric columns, one that numbers each activityand another that identifies one or more direct predecessors of eachactivity.

These features make SRTs potentially useful analytical tools tosupplement UML in e-service systems analysis and design. SRTssatisfy the three previouslymentioned criteria for an ideal lightweightanalytical tool:

First, SRTs are derived from a sound theoretical foundation thatcombines work system ideas and the service value chain framework.In other words, SRTs are not just a specification language. Instead,SRTs are embedded in an analytical method that can be used to guidethe comprehensive analysis of e-service system.

Second, SRTs potentially alleviate learning difficulties for businessprofessionals and customers by providing an informal specificationlanguagewithout abstract symbols and obscure terminology. Businessprofessionals and customers who are familiar with a particular servicecontext can easily learn and apply the rules for constructing andunderstanding SRTs.

Third, SRTs are flexible enough to capture non-functional require-ments related to the dimensions of information quality and otherfactors such as trust and security. The mechanism is simply to addcolumns related to these topics, as shown in Table 2.

In summary, difficulties in using UML in e-service systems analysisand design can be alleviated by using SRTs as lightweight analyticaltools for business professionals. To do that, however, it is necessary tobridge the gap between lightweight analysis and heavyweightanalysis. The transformation of SRTs into UML diagrams is discussednext.

4. Transforming SRTs to UML diagrams

We propose using SRTs to supplement UML in e-service systemsanalysis, with SRTs supporting lightweight analysis by businessprofessionals and UML continuing in its role as the de facto standardlanguage for modeling in object-oriented development. Most object-oriented development methodologies, such as the Unified Process(UP), stipulate that UML diagrams constructed in systems analysisphase should be used later in the design and construction phases[19,43]. Using SRTs to supplement UML requires a way to transform

SRTs from lightweight analysis into key UML diagrams such as classdiagrams and use case diagrams that are critical for the design andconstruction efforts.

The transformation from SRTs into UML diagrams builds uponprior studies that tried to bridge the gap between informal and formalrepresentation languages [24]. We assume that the transformationwill be accomplished by systems analysts guided by heuristics forcreating initial transformations and then filling in missing details thatmight not have been articulated in the initial, lightweight analysis. Todemonstrate this approach, we present two sets of heuristics. Onetransforms SRTs into use case diagrams. The other is used to createclass diagrams.

4.1. Transforming an SRT into a use case diagram

System analysts employ use case diagrams to model informationrequirements. Each use-case describes an element of the functionalityof a software system that generates value for users. The sum of theseuse-cases defines the total functionality of the software system. Use-case diagrams are the cornerstones in the UML-based development.For example, UP is use-case centric. The following heuristics can beused to transform an SRT into a use case diagram for further analysis:

i. Identify the various types of service providers and customers inan SRT and consider them as actors in a use case diagram.

ii. Identify the various activities and responsibilities associatedwith each type of service provider and customer. Theseactivities and responsibilities can be regarded as candidatesfor use cases in a use case diagram.

iii. Based on the expected functionalities, decide which use casesshould be included in the use case diagram.

iv. Link actors with corresponding use cases; show “extends” or“includes” relationships among use cases based on the SRT.

Following these heuristics, the SRT (as shown in Table 2) can beused to generate a use case diagram. In particular, the transformationfollowed these steps:

i. Loan officer, loan applicant, credit analyst, senior loan officer,and loan administration clerk are identified in the SRT (Table 2)and these can be regarded as actors in the use case diagram.

ii. Primary activities and responsibilities in the SRT are summarizedinto

a. identify potential loan applicants,b. contact potential loan applicants,c. discuss financing needs,d. compile loan application,e. verify loan application,f. prepare loan write-up,g. make approval decision, andh. produce loan documents.

These will be treated as candidates of use cases in the usecase diagram.

iii. Considering the expected functionalities of the software systemsupporting loan approval, “identify potential loan applicants”and “contact potential loan applicants” are excluded from thelist of use cases. These activities are considered to be outsidethe scope of the software system for loan approval. As a result,six use cases are identified from the SRT.

iv. Link the identified use cases with corresponding actors basedon the descriptions in the SRT. The use case “Produce loandocuments” can be carried out only when “Make approvaldecision” is completed. Thus, there is an “extends” stereotypebetween the two use cases.

The resulting use case diagram is shown in Fig. 2.

Fig. 2. A use case diagram transformed from the SRT for a loan approval system.

356 X. Tan et al. / Decision Support Systems 51 (2011) 350–360

4.2. Transforming an SRT into a class diagram

A domain model describes the important things and conceptsassociated with a system. In UML, these things and concepts arerepresented as classes and the various kinds of relationships amongthem. The UML class diagram is used for capturing the contents ofthe domain model [43]. If we extend the SRT to contain a thirdcolumn titled “information used or generated”, that third column canbe translated into a UML class diagram by using the followingheuristics:

Fig. 3. A class diagram transformed from

i. Identify all the objects mentioned in the three columns of SRTand determine the objects about which the software systemwill track or maintain information. These will be considered asclasses.

ii. Decide the names of classes and the relationships among them.iii. Identify the attributes for each class using the contents in the

third column of the SRT.iv. Fill in missing classes, attributes, and relationships by further

analysis.

Following the above heuristics, the sample SRT (as shown inTable 2) can be used to generate a UML class diagram through severalsteps:

i. Among all the objects mentioned in the SRT, client company,loan applicant, loan application, loan write-up, loan officer,loan analyst, and senior loan officer are the objects about whichthe software system will record information. They are thecandidates for classes.

ii. Using the descriptions in the SRT, the individual classes will beconnected through associations. For instance, “loan officer”willbe associated with “loan application,” while “loan applicant”(as a person) is a part of “client company,” thus an aggregationrelationship.

iii. For each class, the attributes will be identified using thecontents in the third column in the SRT. For instance, “loanapplication” has attributes consisting of financial terms such asamount, terms, interest rate, and collateral.

iv. All classes that are a type of person will be a subclass of the“person” class. The relationships between person and itssubclasses are generalization.

The class diagram in Fig. 3 was produced from the SRT in Table 1 byusing the above heuristics.

5. Implications for research

To address some of the difficulties of using UML in e-servicesystems analysis, we propose the use of SRTs as a lightweightanalytical tool that is understandable and usable by businessprofessionals. The use of SRTs can supplement the use of UML by

the SRT for a loan approval system.

357X. Tan et al. / Decision Support Systems 51 (2011) 350–360

helping business professionals interpret a problem domain andidentify significant issues. The diagnostic qualities of the SRTsgenerate advantages that warrant future study.

i. SRTs help in focusing attention on significant issues.The quality and efficiency of systems analysis and informationrequirements determination is often reduced by the cognitivelimitations of people as information processors and problemsolvers. For instance, representativeness bias refers to an indivi-dual's tendency to generalize from samples that are too small forpopulation. Similarly, availability bias leads people to estimate thefrequency of events based on the ease with which instances arerecalled frommemory [10,59]. By focusing attention on significantissues, SRTs can help in counteracting cognitive limitations andbiases of individual business professionals.

ii. SRTs can help trigger memory and encourage deep reflection.Tendencies toward satisficing and automaticity are additionallimitations of people as information processors and problemsolvers. In satisficing, people tend to be satisfiedwith a problemsolution that is “good enough” and do not aim for an optimalsolution [52]. Automaticity refers to the difficulty experiencedby some domain experts when they attempt to describe thedetailed steps in completing a task that is so familiar to themthat they do it almost automatically [53]. SRTs encourage usersto deeply reflect on their routines, triggering memory andtherefore mitigating the impact of satisficing and automaticity.

iii. SRTs use vocabulary and syntax that are familiar to theirintended users.Topi and Ramesh [58] suggest that conceptual models used ascommunication tools between analysts and users should not beas formal and restrictive as tools for communicating betweenanalysts and developers. Siau and Tan [47] propose the use ofcognitive mapping techniques such as semantic mapping andcausal mapping as potentially effective communication toolsbetween analysts and end-users. The use of business orientedvocabulary and syntax in SRTs helps business professionalsunderstand, evaluate, and analyze systems in organizations atwhatever level of detail is appropriate for their particularsituation, regardless of whether IT plays a central role.Accordingly, this analytical tool is appropriate for the light-weight analysis conducted by business professionals.

It should be noted that the goal of this research is not to make SRTsas complex or as precise as the UML diagrams. SRTs should be as easyto use and as informal as possible. They should remain a lightweightanalysis tool that can be used easily and understood by businessprofessionals with little or no training. IT specialists would still berequired, however. Either they would develop SRTs with the businessprofessionals or they would examine the SRTs produced by businessprofessionals, identify areas of imprecision, and perform the transla-tion to the related UML diagrams. Our attempt to develop thisapproach further will strive to balance simplicity of use andcompleteness of information.

6. Conclusions

This paper reviewed the difficulties of using a formal modelinglanguage such as UML in e-service systems analysis and proposedusing SRTs as an informal language and lightweight analytical tool tosupplement UML. This tool is based on the service value chainframework and does not require technical concepts or obscureterminology. Therefore it can be adopted easily by business profes-sionals to analyze e-service systems. The paper also presents a set ofheuristics to transform SRTs to two key UML diagrams, which are used

as formal modeling techniques for systems design and implementa-tion by IT professionals.

Our research on the use of SRTs addresses the following goals:

i. Understand the benefits and practical limitations of lightweightanalysis such as the approach based on SRTs.

ii. Develop heuristics that can be used to transform SRTs into UMLdiagrams that can be used for more precise documentation andanalysis that is needed for the development of testablesoftware.

iii. Develop ways to complement and supplement UML diagramcreation by using SRTs to capture ideas, issues, and require-ments that are outside of UML's scope.

There are a number of directions for future study in this line ofresearch. First, empirical studies can assess the efficacy of using theservice value chain framework and the associated SRT technique inanalyzing e-service systems. Case study or action research might beappropriate research methods for this purpose. The proposed SRTtechnique may also be applied in educational and training settings toeducate systems analysis and design students. Second, the proposedheuristics can be tested in practice and developed further. Newheuristics can be developed to guide the transformation of SRTs intootherUMLdiagrams, such as activity diagrams and sequencediagrams.Third, follow-on research might assess the semantic equivalence ofSRTs and UML diagrams. Finally, SRTs might be used in other systemsanalysis anddesign contexts, such as knowledgemanagement systemsand enterprise systems integration. In all areas, the overarching goal isto supplement formal, high precision analysis and design tools withlightweight tools that are more useable and understandable by typicalbusiness professionals. Such tools could help business professionalsunderstand e-service systems in greater depth and could help themcommunicate with IT professionals about functional and non-functional requirements for software development.

Appendix A. Work system framework and work system method

A work system is a system in which human participants and/ormachines perform work (processes and activities) using information,technology, and other resources to produce specific products and/orservices for specific internal or external customers. Typical businessorganizations contain work systems that procure materials fromsuppliers, produce products, deliver products to customers, findcustomers, create financial reports, hire employees, coordinate workacross departments, and perform many other functions.

Information systems, supply chains, and projects are all specialcases of work systems. An information system is a work systemwhoseprocesses and activities are devoted to processing information, i.e.,capturing, transmitting, storing, retrieving, manipulating, and dis-playing information. A supply chain is an interorganizational worksystem devoted to procuring materials and other inputs required toproduce a firm's economic products and services. The firm and specificsuppliers are participants in processes and activities that use specificinformation and technology to create, monitor, and fulfill orders. Aproject is a work system that is designed to produce a particular set ofproducts and services and then go out of existence.

The fact that a work system uses IT extensively does not imply thatit is an information system. The following are examples of worksystems that use IT extensively but are not information systems:fulfillment systems for physical goods, package delivery systems,highly automated manufacturing systems, medical systems thatinclude physical examination or treatment of patients, and transpor-tation systems that use IT extensively. In such cases, an informationsystem may produce intermediate products and services that aremeaningful and useful primarily in the context of a larger worksystem that involves activities beyond processing information.Alternatively, the processing of information may be so intertwined

358 X. Tan et al. / Decision Support Systems 51 (2011) 350–360

with the work system that it is barely meaningful to speak of theinformation system as a separate system.

A.1. Work system framework

Figure A-1 is the work system framework, which identifies nineelements that are part of even a rudimentary understanding of a worksystem. Four of these elements (processes and activities, participants,information, and technologies) constitute the work system. The otherfive elements fill out a basic understanding of the situation. Forexample, no analysis of a work system is complete without someunderstanding of the customer's view of whatever the systemproduces. The double-headed arrows in the work system frameworkexpress the need for alignment between the elements. The arrowsalso convey the path through which a change in one element mightaffect another element. In particular, the arrows linking processes andactivities to participants, information, and technologies say that achange in the processes and activities might call for a change in any ofthose elements, and vice versa.

The work system framework is designed to emphasize businessrather than IT concerns. In contrast to inwardly facing analysis modelsthat overemphasize producer concerns and underemphasize custom-er concerns, the work system framework places the customer at thetop because a work system's primary goal is to produce products andservices for customers. The work system framework does notpreclude the possibility that customers will perform self-servicesteps, however, because a customer can also be a participant.

As explained in [3,5], the terms included in the work systemframework reflect a number of distinctions that are sometimesoverlooked. For example, the work system framework uses processesand activities instead of business process, which is often interpretedas a highly structured set of steps. Processes and activities covers a fullrange of situations that might involve highly structured workflowsand/or “artful processes”whose sequence and content “depend on theskills, experience, and judgment of the primary actors” [26]. The termparticipants (not users) is included because important roles in a worksystem may be played by people who are not direct users of IT. The

TN

EM

NO

RI

VN

E

CUSTOM

I N F R A S T R U C

PRODUCTS &

PROCESSES & A

PARTICIPANTS INFORMA

Figure A-1. The work system fram

information in the system might include computerized databases,documents, shared knowledge, or even unrecorded discussions andcommitments. Technologies (not IT) is used because multipletechnologies may be relevant to the analysis. The analysis of a worksystem is incomplete if it does not consider the products and servicesprovided for its customers. The customers include the directbeneficiaries of whatever a work system produces, plus othercustomers whose interest and involvement are less direct. Theenvironment includes organizational culture and relevant regulations,policies and procedures, competitive issues, organizational history,and technical developments. Strategies of the firm, organization, andwork system should be aligned, although in many situations they maynot be articulated clearly.

A.2. Work system method

The work system method is a method that business professionals(and/or IT professionals) can use for understanding and analyzing awork system at whatever level of depth is appropriate for theirparticular concerns. It has evolved iteratively starting in around 1997.At each stage, the then current version was tested by evaluating theareas of success and the difficulties experienced by MBA and EMBAstudents trying to use it for a practical purpose. A version called “work-centered analysis” that was presented in the 1990s in a textbook wasused by a number of universities as part of the basic explanation ofsystems in organizations, thereby helping students focus on businessissues and helping student teams communicate. Ramiller [39] reportson using a version of the work system framework within a method for“animating” the idea of business process within an undergraduateclass. In a research setting, Petrie [37] uses the work systemframework as a basic analytical tool in a Ph.D. thesis examining 13e-commerce web sites. Petkov and Petkova [36] demonstrate theusefulness of the work system framework by comparing grades ofstudents who did and did not learn about the framework before tryingto interpret the same ERP case study.

Results from analyses of real world systems by typical employedMBA and EMBA students indicate that a systems analysis method for

ERSS

TR

AT

EG

IE

S

T U R E

SERVICES

CTIVITIES

TION TECHNOLOGIES

ework, slightly updated [3,5].

359X. Tan et al. / Decision Support Systems 51 (2011) 350–360

business professionals must be much more prescriptive than softsystem methodology [14]. While not a straitjacket, it must be at leastsomewhat procedural and must provide vocabulary and analysisconcepts while at the same time encouraging the user to perform theanalysis at whatever level of detail appropriate for the task at hand.The latest version of the work system method is organized around ageneral problem-solving outline that includes:

i. Identify the problem or opportunity.ii. Identify the work system that has that problem or opportunity

(plus relevant constraints and other considerations).iii. Use the work system framework to summarize the work

system.iv. Gather relevant data.v. Analyze using design characteristics, measures of performance,

and work system principles.vi. Identify possibilities for improvement.vii. Decide what to recommend.viii. Justify the recommendation using relevant metrics and work

system principles.

In contrast to systems analysis and design methods for ITprofessionals who need to produce a rigorous, totally consistentdefinition of a computerized system, the work system method:

i. Encourages the user to decide how deep to go.ii. Makes explicit use of the work system framework and work

system life cycle model.iii. Makes explicit use of work system principles.iv. Makes explicit use of characteristics and metrics for the work

system and its elements.v. Views work system participants as part of the system (not just

users of the software).vi. Includes codified and non-codified information.vii. Includes IT and non-IT technologies.viii. Suggests that recommendations include work system improve-

ments that rely on IS changes, plus other work system changesthat don't rely on IS changes.

References

[1] R. Agarwal, A.P. Sinha, Object-oriented modeling with UML: a study of developers'perceptions, Communications of the ACM 46 (9) (2003) 248–256.

[2] S. Alter, 18 reasons why IT-reliant Work systems should replace the IT artifact asthe core subject matter of the is field, Communications of the AIS 12 (23) (2003)365–394.

[3] S. Alter, The Work System Method: Connecting People, Processes, and IT forBusiness Results, The Work System Press, Larkspur, CA, 2006.

[4] S. Alter, Service Responsibility Tables: A New Tool for Analyzing and DesigningSystems, Thirteenth Americas Conference on Information Systems, Association forInformation Systems, Keystone, CO, 2007.

[5] S. Alter, Defining information systems as work systems: implications for the ISfield, European Journal of Information Systems 17 (5) (2008) 448–469.

[6] S. Alter, Service system fundamentals: work system, value chain, and life cycle,IBM Systems Journal 47 (1) (2008) 71–85.

[7] S. Alter, Viewing systems as services: a fresh approach in the IS field,Communications of the AIS 26 (11) (2010) 195–224.

[8] M.J. Bitner, A.L. Ostrom, M.L. Meuter, Implementing successful self-servicetechnologies, Academy of Management Executive 16 (4) (2002) 96–108.

[9] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide,Addison-Wesley, Reading, Mass., 1999.

[10] G.J. Browne, V. Ramesh, Improving information requirements determination: acognitive perspective, Information Management 39 (8) (2002) 625–645.

[11] G.J. Browne, M.B. Rogich, An empirical investigation of user requirementselicitation: comparing the effectiveness of prompting techniques, Journal ofManagement Information Systems 17 (4) (2001) 223–249.

[12] J. Bubenko, Challenges in requirements engineering, in: second IEEE internationalsymposium on requirements engineering, York, England, 1995.

[13] T.A. Byrd, K.L. Cossick, R.W. Zmud, A synthesis of research on requirementsanalysis and knowledge acquisition techniques, MIS Quarterly 16 (1) (1992)117–138.

[14] P. Checkland, Systems Thinking, Systems Practice (includes a 30-year retrospec-tive), John Wiley & Sons, Chichester, UK, 1999.

[15] H. Chesbrough, J. Spohrer, A research manifesto for services science, Commu-nications of the ACM 49 (7) (2006) 35–40.

[16] G.B. Davis, Strategies for information requirements determination, IBM SystemsJournal 21 (1) (1982) 4–30.

[17] A.M. Davis, P. Hsia, Giving voice to requirements engineering, IEEE Software 11(2) (1994) 12–16.

[18] L. Dawson, P. Swatman, The use of object-oriented models in requirementsengineering: a field study, Twentieth International Conference on InformationSystems, Association for Information Systems, Charlotte, NC, 1999, pp. 260–273.

[19] A. Dennis, B.H. Wixom, D. Tegarden, Systems Analysis and Design : An Object-oriented Approach with UML, Wiley, New York, 2001.

[20] B. Dobing, J. Parsons, Understanding the role of use cases in UML: a review andresearch agenda, Journal of Database Management 11 (4) (2000) 28–36.

[21] B. Dobing, J. Parsons, HowUML is used, Communications of the ACM 49 (5) (2006)109–113.

[22] B. Dobing, J. Parsons, Dimensions of UML diagram use: a survey of practitioners,Journal of Database Management 19 (1) (2008) 1–18.

[23] J. Erickson, A decade and more of UML: an overview of uml semantic andstructural issues and UML field use, Journal of Database Management 19 (3)(2008) i–vii.

[24] M.D. Fraser, K. Kumar, V.K. Vasihnavi, Informal and formal requirementsspecification languages: bridging the gap, IEEE Transactions on SoftwareEngineering 17 (5) (1991) 454–466.

[25] M. Glinz, Problems and deficiencies of UML as a requirements specificationlanguage, 10th International Workshop on Software Specification and Design(IWSSD-10), Association for Information Systems, San Diego, 2000, pp. 11–22.

[26] C. Hill, R. Yates, C. Jones, S.L. Kogan, Beyond predictable workflows: enhancingproductivity in artful business processes, IBM Systems Journal 45 (4) (2006)663–682.

[27] C.F. Hofacker, R.E. Goldsmith, E. Bridges, E. Swilley, E-Services: a synthesis andresearch agenda, Journal of Value Chain Management 1 (1/2) (2007) 13–44.

[28] K. Holtzblatt, H.R. Beyer, Requirements gathering: the human factor, Commu-nications of the ACM 38 (5) (1995) 30–32.

[29] C.Kobryn,UML2001: a standardizationodyssey,Communicationsof theACM42(10)(1999) 29–37.

[30] S. Kujala, User involvement: a review of the benefits and challenges, Behaviour &Information Technology 22 (1) (2003) 1–16.

[31] M.L. Markus, J. Mao, Participation in development and implementation—updatingan old,tired concept for today's IS contexts, Journal of the Association forInformation Systems 5 (11) (2004) 514–544.

[32] M.L. Meuter, A.L. Ostrom, R.I. Roundtree, M.J. Bitner, Self-service technologies:understanding customer satisfaction with technoiogy-based service encounters,Journal of Marketing 64 (2000) 50–64.

[33] M.L. Meuter, M.J. Bitner, A.L. Ostrom, S.W. Brown, Choosing among alternativeservice delivery modes: an investigation of customer trial of self-servicetechnologies, Journal of Marketing 69 (2005) 61–83.

[34] C.J. Neill, P.A. Laplante, Requirements engineering: the state of the practice, IEEESoftware 20 (6) (2003) 40–45.

[35] W.J. Orlikowski, D.C. Gash, Technological frames: making sense of informationtechnology in organizations, ACM Transactions on Information Systems 12 (2)(1994) 174–207.

[36] D. Petkov, O. Petkova, The work system model as a tool for understanding theproblem in an introductory IS project, 23rd Information Systems EducationConference (ISECON 2006), Association for Information Systems, Dallas, TX, 2006.

[37] D.E. Petrie, Understanding the Impact of Technological Discontinuities onInformation Systems Management: The Case of Business-to-Business ElectronicCommerce, Claremont Graduate University, 2004.

[38] K. Pohl, Process-Centered Requirements Engineering, John Wiley & Sons, NewYork, 1996.

[39] N. Ramiller, Animating the concept of business process in the core course ininformation systems, Journal of Informatics Education and Research 3 (2) (2002)53–71.

[40] J. Rowley, An analysis of the e-service literature: towards a research agenda,Internet Research 16 (3) (2006) 339–359.

[41] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language ReferenceManual, Addison-Wesley, Reading, Mass., 1999

[42] R. Rust, P. Kannan, E-service: a new paradigm for business in the electronicenvironment, Communications of the ACM 46 (6) (2003) 36–42.

[43] K. Scott, The Unified Process Explained, Addison-Wesley, Boston, MA, 2002.[44] K. Siau, Q. Cao, Unified modeling language — a complexity analysis, Journal of

Database Management 12 (1) (2001) 26–34.[45] K. Siau, L. Lee, Are use case and class diagrams complementary in requirements

analysis? An experimental study on use case and class diagrams in UML,Requirements Engineering 9 (4) (2004) 229–237.

[46] K. Siau, P. Loo, Identifying the Learning Difficulties with Unified ModelingLanguage (UML), Information Systems Management 23 (3) (2006).

[47] K. Siau, X. Tan, Information systems requirements determination and analysis: amental modeling approach, Ninth Americas Conference on Information Systems(AMCIS'03), Association for Information Systems, Tampa, FL, 2003, pp. 1370–1379.

[48] K. Siau, X. Tan, Improving the quality of conceptual modeling using cognitivemapping techniques, Data & Knowledge Engineering 55 (3) (2005) 343–365.

[49] K. Siau, X. Tan, Using cognitive mapping techniques to supplement UML and UP ininformation requirements determination, Journal of Computer InformationSystems 47 (2006) 59–66.

[50] K. Siau, Y. Tian, A semiotics analysis of UML graphical notations, RequirementsEngineering 14 (1) (2009) 15–26.

[51] K. Siau, J. Erickson, L. Lee, Theoretical versus practical complexity: the case of UML,Journal of Database Management 16 (3) (2005) 40–57.

360 X. Tan et al. / Decision Support Systems 51 (2011) 350–360

[52] H.A. Simon, Behavioral Models of Rational Choice, in: Models of Man, Wiley, NewYork, 1957.

[53] H.A. Simon, Information processing models of cognition, Annual Review ofPsychology 30 (1979) 363–396.

[54] J. Spohrer, P.P. Maglio, J. Bailey, D. Gruhl, Steps toward a science of servicesystems, Computer 40 (1) (2007) 71–77.

[55] Standish, Extreme CHAOS, The Standish Group International, 2001, p. 12.[56] S. Swamynathan, A. Kannan, T.V. Geetha, Composite event monitoring in XML

repositories using generic rule framework for providing reactive e-services,Decision Support Systems 42 (1) (2006) 79–88.

[57] X. Tan, S. Alter, K. Siau, Integrating lightweight systems analysis into the unifiedprocess by using service responsibility tables, Fourteenth Americas Conference onInformation Systems, Association for Information Systems, Toronto, Canada, 2008.

[58] H. Topi, V. Ramesh, Human factors research on data modeling: a review of priorresearch, an extended framework and future research directions, Journal ofDatabase Management 13 (2) (2002) 3–19.

[59] J.R. Valusek, D.G. Fryback, Information requirements determination: obstacleswithin, among, and between participants, in: R. Galliers (Ed.), InformationAnalysis: Selected Readings, Addison Wesley, Reading, MA, 1987, pp. 139–151.

[60] S.L. Vargo, R.F. Lusch, Evolving to a new dominant logic for marketing, Journal ofMarketing 68 (2004) 1–17.

[61] S.L. Vargo, R.F. Lusch, Service-dominant logic: reactions, reflections and refine-ments, Marketing Theory 6 (3) (2006) 281–288.

[62] K.E. Weick, Sensemaking in Organizations, Sage Publications, Thousand Oaks, CA,1995.

Xin Tan is currently an assistant professor in Department of Information Systems andDecision Sciences at Fairleigh Dickinson University. He obtained a Ph.D. from theUniversity of Nebraska-Lincoln, and an MBA from Miami University. His currentresearch interests include information systems development, and user acceptance ofadvanced information technology and information systems. He has published papers inCommunications of the ACM, Data & Knowledge Engineering, IEEE Transactions onProfessional Communication, Information Resource Management Journal, and Journal ofComputer Information Systems.

Steven Alter is a Professor of Information Systems at the University of San Francisco. Heholds a B.S. in mathematics and Ph.D. in management science from MIT. He extendedhis 1975 Ph.D. thesis into one of the first books on decision support systems. Afterteaching at the University of Southern California, he served for eight years as co-founder and Vice President of Consilium, a manufacturing software firm that wentpublic in 1989 and was acquired by Applied Materials in 1998. His many roles atConsilium included starting departments for customer service, training, documenta-tion, technical support, and product management. Upon returning to academia, hewrote an information systems textbook whose fourth edition was published in August2001 with a new title, Information Systems: Foundation of E-business. His articles haveappeared in Harvard Business Review, Sloan Management Review, MIS Quarterly,Interfaces, Communications of the ACM, Communications of the AIS, Futures, The Futurist,and many conference transactions.

Keng Siau is the E. J. Faulkner Professor at the University of Nebraska, Lincoln (UNL). Heis the Director of the UNL-IBM Global Innovation Hub, Editor-in-Chief of the Journal ofDatabase Management, and North America Regional Editor of the RequirementsEngineering journal. He received his Ph.D. degree from the University of British Columbia(UBC). His master and bachelor degrees are in Computer and Information Sciences fromthe National University of Singapore. Professor Siau has over 250 academic publications.He has published more than 100 refereed journal articles, and these articles haveappeared (or are forthcoming) in journals such as Management Information SystemsQuarterly, Journal of the Association for Information Systems, Communications of the ACM,IEEE Computer, Information Systems Journal, Journal of Strategic Information Systems,Information Systems, ACM SIGMIS's Database, IEEE Transactions on Systems, Man, andCybernetics, IEEE Transactions on Professional Communication, IEEE Transactions onInformation Technology in Biomedicine, IEICE Transactions on Information and Systems,Data and Knowledge Engineering, Journal of Information Technology, and InternationalJournal of Human-Computer Studies. He is Co-Editor of the AMIS volume titled “SystemsAnalysis and Design: Techniques, Methodologies, Approaches, and Architectures.” Heserved as Organizing and Program Chairs of the International Conference on Evaluation ofModeling Methods in Systems Analysis and Design (EMMSAD) (1996–2005). He alsoserved on the organizing committees of AMCIS 2005, ER 2006, AMCIS 2007,EuroSIGSAND 2007, EuroSIGSAND 2008, and ICMB 2009. He received the InternationalFederation for Information Processing (IFIP) Outstanding Service Award in 2006. He isalso a recipient of the IBM Faculty Award in 2006, 2008, and 2010.