This is a pre-publishe raft of the following paper: España, S., González, A. an Pastor, O. (2009) Communication Analysis: a Requirements Engineering metho for Information Systems. 21st International Conference on Avance Information Systems Engineering (CAiSE'09). Amsteram, The Netherlans, Springer LNCS: 530-545 Communication Analysis: a Requirements Engineering Metho for Information Systems 1 Sergio España 1, Arturo González 2, Óscar Pastor 1 1 Centro e Investigación en Métoos e Proucción e Software Universia Politécnica e Valencia {sergio.espana, opastor}@pros.upv.es 2 Departamento e Sistemas Informáticos y Computación Universia Politécnica e Valencia agelrio@sic.upv.es Abstract. Developing Information Systems (ISs) is a har task for which Requirements Engineering (RE) offers a goo starting point. ISs can be viewe as a support for organisational communication. Therefore, we argue in favour of communication-oriente RE methos. This paper presents Communication Analysis, a metho for IS evelopment an computerisation. The focus is put on requirements moelling techniques. Two novel techniques are escribe; namely, Communicative Event Diagram an Communication Structures. These are base on soun theory, they are accompanie by prescriptive guielines (such as unity criteria) an they are illustrate by means of a practical example. Keywors: Communication Analysis, requirements engineering, communication theory, enterprise information systems, requirements structure. 1. Introuction Information Systems (ISs) evelopment an computerisation is a wicke problem 2. To a large extent, this is ue to their socio-technical nature [27] an to the intervention of multiple stakeholers with often conflicting nees an worl views. To overcome conflicts an to reach agreement, stakeholers perceptions have to be place in a knowlege base that is share with IS evelopers. Requirements Engineering (RE) facilitates this process by offering techniques for the iscovery an escription of stakeholers nees. However, there exist many ifferent explanations of what a requirement is an what it is not (e.g. what vs. how [10], why [35]). The authors stance in this matter is summarise as follows (for more reasone arguments see [20]): A requirements engineering metho shoul prescribe a requirements structure that fits the problem trying to be solve, it shoul offer contingent an prescriptive methoological guiance an it shoul be illustrate with representative examples. 1 Research supporte by the Spanish Ministry of Science an Innovation (MICINN) project SESAMO (TIN2007-62894), the MICINN FPU grant (AP2006-02323), an FEDER. 2 Among other characteristics, wicke problems o not have a unique solution an their statement is not clear until they are solve (in part ue to stakeholer iscrepancies) [34].
2 Sergio España1, Arturo González2, Óscar Pastor1 Requirements specifications shoul offer an external view of the system uner evelopment. In case internal etails are inclue, the requirements structure shoul clearly ifferentiate the problem space (external) from the solution space (internal). Attening to acaemic literature an inustrial practice, various conceptions of ISs are foun. Some authors consier ISs as a mere representation of reality [40]. Uner this perspective, ISs can be escribe following an ontological approach; that is, focusing on the objects perceive in the universe of iscourse (e.g. OO-Metho [32]). Other perspectives focus on organisational intentions (e.g. Maps [35]), value object exchanges (e.g. e3-value [23]), etc. The authors view an IS as a support for organisational communications [26, 27]. Therefore, a communicational approach to ISs analysis is necessary; that is, we claim that ISs requirements engineering shoul take into account users communicational nees. We propose Communication Analysis as a metho for the evelopment an computerisation of enterprise Information Systems. This metho focuses on communicative interactions that occur between the IS an its environment. The metho stems from IS founations acaemic research [22, 31] an it evolves by means of the collaboration with inustry. Communication Analysis is currently being use by important Spanish enterprises an governmental institutions. The communicational perspective of the metho has been overviewe in a previous publication [20]. This paper presents with greater etail the moelling techniques that Communication Analysis proposes for requirements specification. The main contributions of this paper are the following: Communicative Event Diagram is presente a business process moelling technique that aopts a communicational perspective an facilitates the evelopment of an IS that will support those business processes. Communication Structures are presente a moelling technique for the specification of messages communicate with (an within) the organisation. Both moelling techniques fit well into a requirements structure, an they are both sounly foune on concepts borrowe from iverse isciplines (e.g. Systems Theory, Communication Theory, Information Systems Theory). Methoological guiance is base on soun criteria an illustrative examples are offere. The rest of the article is structure as follows. Section 2 presents an overview of the approach, highlighting the propose requirements specification structure an the metho workflow. Section 3 escribes the case that is use to illustrate the proposal. Section 4 escribes Communication Analysis moelling techniques, paying special attention to Communicative Event Diagram an Communication Structures, an illustrating them. Section 5 presents a review of relate works. Section 6 presents conclusions an future works. 2. Overview of the Approach From a systemic point of view, the kin of problem that we are confronting involves at least three systems. The Organisational System (OS) is a social system that is intereste in observing, controlling an/or influencing a portion of the worl [27]. We refer as Subject System (SS) to the portion of the worl in which the OS is intereste (a.k.a universe of iscourse). An Information System (IS) is a socio-technical system, a set of agents of ifferent nature that collaborate in orer to support communication
Communication Analysis: a Requirements Engineering Metho for Information Systems0F 3 between the OS an its environment (an also within the OS) [27]. We refer as Computerise Information System (CIS) to the part of the IS that is automate. Therefore, we argue that systemic principles nee to be applie to IS requirements engineering. Quite often, the set of requirements are organise as plain enumerate lists. We claim that a requirements structure suite to ISs evelopment is more appropriate than a list. Communication Analysis proposes a requirements structure that allows a stepwise refinements approach to ISs escription (by following systemic principles). Also, the propose metho allows tackling with static an ynamic perceptions of reality (by giving support to iscovering an escribing that uality). Figure 1 shows the first imension of the propose requirements structure an the activities that are relate to each requirements level. The structure an the metho flow of activities have been overviewe in a previous publication [20]. Fig. 1. Communication Analysis requirements levels an workflow The first imension concerns several (systemic) requirements levels. L1.System/subsystems level refers to an overall escription of the organisation an its environment (OS an SS, respectively) an also involves ecomposing the problem in orer to reuce its complexity. L2.Process level refers to business process escription both from the ynamic viewpoint (by ientifying flows of communicative interactions, a.k.a. communicative events) an the static viewpoint (by ientifying business objects). L3.Communicative interaction level refers to the etaile escription of each communicative event (e.g. the escription of its associate message) an each business object. L4.Usage environment level refers to capturing requirements relate to
4 Sergio España1, Arturo González2, Óscar Pastor1 the usage of the CIS, the esign of user interfaces, an the moelling of object classes that will support IS memory. L5.Operational environment level refers to the esign an implementation of CIS software components an architecture. Levels L1, L2 an L3 belong to the problem space, since they o not presuppose the computerisation of the IS an they aim to iscover an escribe the communicational nees of users. Levels L4 an L5 belong to the solution space, since they specify how the communicational nees are going to be supporte. This paper focuses on the problem space an it escribes in etail some of its moelling techniques. 3. Illustration Case Description In orer to exemplify the application of the metho, we use an illustration case. A photography agency manages illustrate reports (a.k.a. reports) an istributes them to publishing houses. Freelance photographers apply to work for the agency. The agency management boar ecies whether the photographer is accepte or not, an which quality level is assigne to them. Accepte photographers provie reports to the agency. Publishing houses buy reports from the agency catalogue an, sometimes, they request an exclusive report (a.k.a. exclusive) on a particular subject. Each exclusive is assigne to an intereste photographer, as long as they o not have any other pening exclusive. Reports an exclusives are sent to publishing houses through a courier company, along with a elivery note. Then the messenger returns to the agency the elivery note, signe by the publishing house. Monthly, the agency issues publishing house invoices an photographers cheques. 4. Communication Analysis Moelling Primitives an Guielines. Before escribing Communication Analysis requirements levels, it is worth enumerating three functions of communication efine by Jakobson [25]. These functions allow us to structure requirements an to unerpin the concepts unerlying the metho: Phatic: it aims to establish, maintain contact, an ensure operation of the (physical or psychological) communication channel between the aresser an the aressee. Referential: the purpose of this function is to convey con-relate information. Connative: it aims to convey commans, to (attempt to) transform reality or people, to affect the course of events or behaviour of iniviuals. 4.1. L1. System/Subsystems Level On the first requirements level, the analyst escribes the OS from the strategic point of view. On the one han, when the organisation is complex, it is avisable to ecompose the problem into subsystems or organisational areas. On the other han, the analyst elicits requirements relate to strategic-level business inicators. The photography agency case is of manageable size. Even though, three subsystems can be istinguishe: Customer Service Department (it serves publishing houses), Prouction Department (it eals with photographers an manages reports), Accounting Department. With regar to strategic business inicators, the management
Communication Analysis: a Requirements Engineering Metho for Information Systems0F 5 boar is intereste in growth inicators that serve as a scorecar; e.g. increase in the number of photographers, increase in the number of exclusives, cash flow. 4.2. L2. Process Level On this requirements level, Communication Analysis proposes escribing business processes from a communicational perspective. The aim is to iscover communicative interactions between the IS an its environment, an to escribe them taking into account their ynamic an static aspects; that is, creating the Communicative Event Diagram an the Business Objects Glossary, respectively. In the following, a series of efinitions clarify the concepts upon which the moelling techniques are built. We refer as communicative interaction to an interaction between actors with the aim of exchanging information. FRISCO report [16] presents a generic moel of ISs that consiers an IS as a support for communicative interactions. In a previous publication, the authors exten this moel in orer to eepen the communicative point of view [31]. Depening on the main irection of communication, the following types of communicative interactions can be istinguishe: Ingoing communicative interactions primarily fee the IS memory with new meaningful information. These interactions often appear in the shape of business forms. Outgoing communicative interactions primarily consult IS memory. These interactions often appear in the shape of business inicators, listings an printouts. Inustrial experience has shown us that ingoing communicative interactions entail more analytical complexity. Therefore, we avise the analyst to focus, first of all, on ingoing communicative interactions 3. A communicative event is a set of actions relate to information (acquisition, storage, processing, retrieval an/or istribution), which are carrie out in a complete an uninterrupte way, on the occasion of an external stimulus [22]. Communication Analysis offers unity criteria to allow ientifying communicative events, also facilitating the etermination of their granularity. This way, a communicative event can be seen as an ingoing communicative interaction that fulfils the unity criteria. Each unity criterion is relate to a communication function. Table 1 summarises unity criteria an their application, see [21] for etaile information. Communication Analysis proposes to specify the flow of communicative events by means of the Communicative Event Diagram (CED). The primitives of this moelling technique are shown at the bottom of Figure 2 an explaine next. 3 Communication Analysis also takes into account outgoing communicative interactions. However, when the OS nees complex inicators for performance management, techniques such as the Balance Scorecar are recommene.
6 Sergio España1, Arturo González2, Óscar Pastor1 Table 1. Unity criteria to ientify an encapsulate communicative events. Criterion (Communication function) Definition Trigger unity (Phatic function) Trigger responsibility is external. The event occurs as a response to an external interaction an, therefore, some actor triggers it. This (primary) actor is the one that provies the information that is conveye in the event. Communication unity (Referential function) Each an every event involves proviing new meaningful information. Thus, an interaction nees to provie new facts in orer to be consiere an event. Input messages are representations of something that happens in the IS environment. Reaction unity (Connative function) The event is a composition of synchronous activities; thus, these activities can communicate the information they nee from each other. Events are asynchronous among each other; thus, events nee a share IS memory to communicate. An example of their application. Accoring to the unity criteria, two communicative events are ientifie with regar to photographer subscriptions: PHO 1 an PHO 3 (see Figure 2). Both events fulfil the three unity criteria: both have an external actor that triggers them (a photographer an the management boar, respectively), both result in the provision of new meaningful information (the application an the resolution, respectively), an both are compositions of synchronous activities. Consiering them to be only one communicative event woul result in violating the trigger criteria (each has a ifferent primary actor) an the reaction criteria (they are asynchronous: PHO 1 can occur at any moment uring office hours, PHO 3 occurs Monay mornings). Each communicative event is represente as a roune rectangle an is given an ientifier an a escriptive name. The ientifier serves for traceability purposes an it is usually a coe compose of a mnemonic (relate to the system to which the event is ascribe) an a number (e.g. PHO 3). With regar to the name, we recommen to consistently use either an external nomination (primary actor + action + object + qualifier; e.g. Photographer submits an application ) or an internal nomination (support actor + action + object + qualifier; e.g. Clerk receives a photographer application ). For instance, in the illustration case we have opte for an external nomination. For each event, involve actors are ientifie. Communication Analysis istinguishes several roles (see theoretical basis in [31]): The primary actor triggers the communicative event by establishing contact with the OS an provies the conveye input information. Therefore, primary actors are moelle as seners of ingoing communicative interactions. For instance, the management boar is the primary actor of event PHO 3. The support actor is in charge of physically interacting with the IS interface in orer to encoe an eit input messages. Support actors are specifie at the bottom of the event roune rectangle. Sometimes the primary actor an the support actor are ifferent persons (e.g. photographer an clerk, respectively, in event PHO 1). Other times both roles are playe by the same person (e.g. the salesman in event PHO 2). Receiver actors are those who nee to be informe of the occurrence on an event. In orer to truly unerstan the meaning of messages in organisations, it is neces-
Communication Analysis: a Requirements Engineering Metho for Information Systems0F 7 sary to analyse these actors. They are moelle as receivers of outgoing communicative interactions (e.g. in PHO 3 the photographer is informe of the resolution). Reaction processors are those in charge of performing the IS reaction to the message. This role is not epicte in the CED. PHOTOGRAPHER APPLICATION MNGMT BOARD RESOLU- TIONS RESOLUTION REPORT PHO 1 PHOTOGRAPHER SUBMITS AN APPLICATION CLERK PHO 3 MANAGEMENT BOARD RESOLVES APPLICATIONS PHO 3.1 BOARD REJECTS CLERK PHO 4 PHOTOGRAPHER PROVIDES REPORT CLERK PHO 3.2 BOARD APPROVES PHO 2 SALESMAN ESTABLISHES RATES SALESMAN RATES SALESMAN PHO 5 PUBLISHING HOUSE REQUESTS SUBSCRIPTION SALESMAN PHO 8 PUBLISHING HOUSE REQUESTS EXCLUSIVE REPORT SALESMAN PUBLISHING HOUSE SUBS. REQ. EXCL. REQ. CHEQUE PHO 12 ACCOUNTANT ISSUES PHOTOGRAPHER RECEIPTS ACCOUNTANT PHO 6 PUBLISHING HOUSE ORDERS REPORT SALESMAN PHO 7 PUBLISHING HOUSE RETURNS SIGNED REPORT DELIVERY NOTE CLERK PHO 13 ACCOUNTANT ISSUES PUBLISHING HOUSE INVOICES ACCOUNTANT PHO 9 PHOTOGRAPHER REQUESTS ASIGNMENT OF EXCLUSIVE CLERK PHO 10 PHOTOGRAPHER COMPLETES EXCLUSIVE CLERK ACCOUNTANT ACCOUNTANT PHO 11 CHEQUE ASSIGNMENT REQUEST EXCLUSIVE REPORT LIST REPORT REQST DELIVERY NOTE PUBLISHING HOUSE RETURNS SIGNED EXCLUSIVE DELIV. NOTE CLERK INVOICE DELIV. NOTE SIG. D.N. SIG. D.N. LEGEND ACTOR COMMUNICATIVE EVENT INGOING COMMUNICATIVE INTERACTION OUTGOING COMMUNICATIVE INTERACTION PRECEDENCE RELATION SPECIALISED COMMUNICATIVE EVENT Fig. 2. Communicative Event Diagram of the photography agency 4 The messages associate to communicative events are conveye via ingoing communicative interactions an outgoing communicative interactions. In the CED, messages are given a name (by labelling communicative interactions) 5. Communicative interactions are moelle as arrows place in the horizontal axis. The vertical axis is 4 Note that the labels of Photographer actors (to the right) an Publishing house actors (to the left) are omitte for reasons of space. Also, some communicative interaction labels have been abbreviate (e.g. SIG.D.N. stans for SIGNED DELIVERY NOTE). 5 Message structure is specifie in etail in a later activity (see Section 4.3)
8 Sergio España1, Arturo González2, Óscar Pastor1 reserve for preceence relations among communicative events, which are also moelle as arrows 6. E.g. PHO 3 requires the previous occurrence of PHO 1 an PHO 2. Communicative events are specialise whenever each specialise variant leas to a ifferent temporal path (i.e. istinct preceence relations). It must be avoie specialising an event as a result of ifferent communication channels, since the message remains the same (e.g. a publishing house can orer a report in person or by telephone). This requirements level also provies a static perspective of business processes, by means of business objects. We refer as business objects to the conceptions of those entities of the Subject System in which the OS is intereste. Frequently, stakeholers escribe business objects as complex aggregates of properties. Business objects are ientifie an escribe in a Business Object Glossary. Also, users are aske to han out business forms to the analysts, who catalogue them for later form analysis. For instance, the photography agency manages the following business objects: photographer recors, publishing house recors an reports 7. Static analysis also implies eliciting business inicators that are associate to subsystems or processes. For instance, the photography agency is intereste in business inicators relate to its three subsystems: Customer Service Department requires payments an takings inicators that allow them monitoring ebts (e.g. publishing house inebteness). Prouction Department requires prouctivity an profitability inicators (e.g. elivery performance to customer, photographer prouctivity). Customer Service Department requires client-relate inicators that allow them to monitor customer loyalty (e.g. consumption rates). 4.3. L3. Communicative Interaction Level Communicative events that appear in the CED nee to be escribe in etail. Requirements associate to an event are structure by means of an Event Specification Template. The template is compose by a heaer an three categories of requirements: contact, communicational content an reaction requirements. These categories are relate to phatic, referential an connative communication functions, respectively. The heaer contains general information about the communicative event; that is, the event ientifier, its name, a narrative escription an, optionally, an explanatory iagram. The event ientifier an name come from the CED; event ientification nees to be kept consistent throughout the entire analysis an esign specification in orer to enhance requirements traceability. Since requirements specifications is meant, first of all, to facilitate problem unerstaning, a narrative escription of the event is strongly avise. Also, whenever the event is complex, an explanatory iagram illustrating its associate flow of tasks shall be inclue. Contact requirements are relate to the conitions that are necessary in orer to establish communication. For instance 8, the primary actor, possible communication channels (e.g. fax, email, in person), availability an temporal restrictions (e.g. office hours for orer reception), authentication requirements (e.g. in Spain, bureaucratic proceeings often require showing an ientity car). 6 Complex business processes may require other operators. Start an en symbols can also be use. Besies, loops appear in many business processes. 7 The escription of business objects is omitte for the sake of brevity. 8 For reasons of space, not all kins of requirements in each category are inclue.
Communication Analysis: a Requirements Engineering Metho for Information Systems0F 9 Table 2. Primitives an grammar of Communication Structures moelling technique CSs primitives EBNF grammar for Communication Structures 9 Aggregation A = < a + b + c > A is compose of fiels a an b an c. Alternative A = [ a b c ] A is either compose of fiel a or b or c, (only one of them). Iteration A = { B } A is compose of several substructures of type B. Ientification a( i ) Fiel a ientifies an object that is alreay known by the IS. communication structure = structure name, =, initial substructure; initial substructure = aggregation substructure iteration substructure; aggregation substructure = <, substructure list, > ; iteration substructure = {, substructure list, } ; specialisation structure = [, substructure list, {, substructure list }, ] ; substructure list = substructure, { +, substructure }; complex substructure = aggregation substructure iteration substructure specialisation structure; substructure = substructure name, =, complex substructure ientifier fiel fiel; Communicational content requirements specify the message conveye in an event an relate restrictions (e.g. reliability: certifying that a iploma provie by a stuent is not frauulent). With regar to the message, both metalinguistic aspects (e.g. message fiel structure, optionality of fiels) an linguistic aspects (e.g. fiel omains, example values) nee to be specifie. Communication Analysis proposes a message moelling technique. Communication Structure (CS) is a moelling technique that is base in structure an allows specifying the message associate to a communicative event. The structure of message fiels lies vertically an many other etails of the fiels can be arrange horizontally; e.g. the information acquisition operation, the fiel omain, the link with the business object, an example value provie by users. A communicative event can not be fully unerstoo until its CS is efine in etail. Specifying with precision an event CS forces an helps analysts an users to appropriately mark the event bounary an meaning. Table 2 shows the Communication Structures grammar. On left-han sie column, the primitives are informally explaine; on the right-han sie column, an EBNF grammar [24] that allows expressing CSs is presente. Reaction requirements escribe how the IS reacts to the communicative event occurrence. Typically, the IS stores new knowlege, extracts all the necessary conclusions that can be inferre from new knowlege, an makes new knowlege an conclusions available to the corresponing actors. Therefore, this category of requirements inclues business objects being registere an outgoing communicative interactions being generate by the event, among other requirements. 9 This table summarises the main syntactical rules of the grammar. The elements structure name, substructure name, ientifier fiel an fiel can be consiere character strings.
10 Sergio España1, Arturo González2, Óscar Pastor1 A simplifie Event Specification Template of event PHO 3 is shown next. PHO 3 Management boar resolves applications Goals: The IS aims to obtain a response to outstaning photographer applications. Description: Monay mornings, the management boar hols a meeting. A member of each epartment is present. A Prouction Department clerk has prepare a list of outstaning (pening) photographer applications an a résumé of each applicant. Management boar procees to evaluate an resolve each application. Depening on the ocumentation, a photographer is either accepte or rejecte. Accepte photographers are classifie into a quality level (this level will etermine their rates). After the meeting, the list of resolve applications is returne to Prouction Department. Explanatory iagram: (Not inclue) Contact requirements Primary actor: Management boar. Communication channel: In person. Temporal restrictions: This communicative event occurs Monay mornings. Frequency: Of the 10-20 monthly applications, aroun 5 are accepte. Communicational content requirements Support actor: Prouction Department clerk Communication Structure: (See some comments below) FIELD OP DOMAIN BUSINESS OBJ. EXAMPLE VALUE LEGEND PHOTOGRAPHER (ID car #)= < CSs Primitives RESOLUTIONS = { Application()= < ID car # + Name + Aress + Postcoe + City + Phone # + Equipment + Experience + Portfolio + Resol. ate + Decision + [ Accepte = < Level > ] > > i i i i ocument ate [acc rej] Decision=acc Rate<level> resol ate + ecision + level > 19.345.631-Q Sergio Pastor González Camino e Vera s/n 46022 Valencia 9638700000 ext 83534 Canon A1 w. telemacro Worke for Mangum Ph N/A (sample of work) November 21, 2008 acc 1 (highest quality level) <+> aggregation { } iteration [ ] alternative ( ) selection Information aquisition operations erivation i input Management boar resolves each application (see the iteration of applications). Note that, for each application (ientifie by the ID car #), the only fiels that constitute new information are the ecision on whether to accept or reject the photographer (Decision fiel) an, in case of acceptance (message alternative an associate conition Decision=acc), the assigne quality level (Level fiel). The rest of the fiels are erive from the IS memory (these ata is introuce by a previous event; namely, PHO 1 Photographer submits an application). The business object column links ynamic perspective (communicative interaction escription) with the static perspective (Business Object Glossary). Note that only new facts are store in the IS memory. Example values enhance user-analyst communication.
Communication Analysis: a Requirements Engineering Metho for Information Systems0F 11 Reaction requirements Business object: If the application is accepte, the photographer becomes part of the agency. The clerk creates a photographer recor that inclues photographer s personal an contact etails (See scanne form at the right-han sie). Outgoing communicative interaction: After this communicative event, a letter informing of the resolution is sent to the photographer 10. Fig. 3. Event Specification Template of communicative event PHO 3. 5. Relate Works There exist istinct orientations with regar to requirements elicitation for IS evelopment. Goal-oriente approaches inten to ientify stakeholers necessities, moelling them as goals, where a a goal is an objective the system uner consieration shoul achieve [39]. E.g. Map [35], i* [43] an KAOS [9]. Among agent-oriente approaches, which esign the system as a set of autonomous an automatable agents, Tropos inclues a goal-oriente requirements stage [6]. Usage-base approaches escribe the interaction between the user an the software system uner evelopment. E.g. Use Cases [30] an Info Cases (an extension of the former) [18]. Value-oriente approaches ientify an moel value object exchanges [41]. E.g. e3-value [23]. Aspect-oriente approaches apply the separation of concerns principle [14] to RE. E.g. Early Aspects [33] an Theme/DOC [3]. Some organisational moelling approaches propose moelling an integrating multiple views of the system [5, 36, 11]. There also exist communicational approaches. In this fiel, a wiely extene orientation is the Language Action Paraigm (LAP) [17, 42], which is mainly base on the work of Austin [1] an Searle s speech act classification [37]. Communicative Action Paraigm (CAP) is an evolution of LAP that extens the paraigm to non-verbal communication [13]. Several approaches stem from LAP, such as Action Workflow [28], SAMPO [15], Business Action Theory [19], DEMO [12] an Cronholm an Golkunhl s Communication Analysis [8]. SANP [7] aopts a similar approach, but it is base on Ballmer an Brennenstuhl s speech act classification [2]. Semiotic approaches to organisational moelling have also been propose [38]. This paper presents a communicational approach. Communication Analysis oes not consier goal moelling, but the inustrial projects in which the authors have been involve (which have contribute to consoliate the metho) i not require it. Likewise, value network moelling has not been consiere, but the metho is usually put into practice in existing organisations with well establishe businesses, not with the 10 This communicative interaction is a printout an it is not escribe in etail for the sake of brevity.
12 Sergio España1, Arturo González2, Óscar Pastor1 intention to support an innovative e-commerce iea [23]. In any case, IS evelopment is better tackle with a contingent approach, so we are open to integrating these or other perspectives with Communication Analysis (see Section 6). Some features give avantage to our proposal over other methos. The actor roles argue in Section 4.2 istinguish Communication Analysis from other approaches. Many business process moelling techniques use support actors an/or reaction processors as criteria for organising processes in swimlanes but primary actors are isregare (e.g. [11]). However, primary actors are central to our approach 11. Furthermore, most RE approaches o not specify communicational content of interactions (or message specification is mixe with system usage escription, as in Use Cases). Info Cases is an exception, since this technique proposes a structure specification of messages. However, Communication Structures have greater expressiveness (e.g. alternative, iteration, information acquisition operation) 12. With regar to communicational approaches, we share with them the communicational perspective an many founations borrowe from Communication Theory. However, Communication Analysis oes not necessarily preconceive a specific speech acts classification nor assumes conversational patterns, as LAP-base approaches o. An analyst following our approach oes not impose patterns on the organisation, but confines to iscovering the communication nees of the organisational stakeholers, sheing light on their work practice an ientifying possible improvements. Our proposal coincies with the one by Cronholm an Golkuhl in the communicational perspective. Also, both proposals consier organisational ocuments (e.g. business forms) invaluable sources of information. However, Cronholm an Golkuhl choose existing ocuments as a starting point in RE process an their moelling notation (the Document Activity Diagram) is ocument-centre; that is, communicative interactions are suborinate to ocuments. We choose communicative interactions as a starting point an the moelling notation that we propose in this paper (the Communicative Event Diagram) is communicative interaction-centre. We argue that communicative events represent pure work practice an that it is possible to iscover an escribe them inepenently of their associate ocuments. Documents are a specific technological support 13 (solution space) for a communicative event (problem space); that is, ocuments are the result of a previous IS implementation. With regar to the conceptual framework for unerstaning business processes by Melão an Pi [29], our proposal combines two of the four perspectives; namely the constructivist an mechanistic perspectives. In orer to iscover business processes, a constructivist stance is aopte: business processes are consiere a social construct that is agree among stakeholers, an the requirements engineer acts as facilitator in this agreement. In orer to escribe business processes, a mechanistic stance is aopte: the use of moels that are base on actors, events an messages allows creating a requirements specification that serves as a starting point for later software esign. 11 Organisations can replace many support agents with computer interfaces (e.g. clerks vs. webbase forms) an IS reaction processors are typically automate. Primary actors, however, are irreplaceable because they are the ultimate source of information. 12 Making an in-epth comparison of our proposal with regar to other methos (e.g. feature comparison, performance evaluations) can not be ealt with in one single paper; we are currently working on empirical valiation an results will be available as part of future works. 13 We o not necessarily refer to computer technology; paper is an ancient form of technology.
Communication Analysis: a Requirements Engineering Metho for Information Systems0F 13 Discovering requirements allows their escription an, conversely, IS escription provies feeback to iscovery by allowing new interactions with stakeholers (e.g. to formulate new questions). Both perspectives are intertwine. The combination of har (mechanistic) an soft (constructivist) approaches is not new to the ISs scene [4], but Communication Analysis contributes a requirements structure an communication-oriente moelling techniques that o not appear in previous proposals. One last remark. The propose business process moelling technique consists of a set of interrelate concepts, criteria plus other methoological guiance, an a notation. We believe that, in general, it is concepts an criteria that matter the most (not notations). We also acknowlege that some practitioners woul be more comfortable using other notations for business process moelling (e.g. BPMN, Activity Diagrams, Use Cases). There is no problem with that, as long as the notation is aapte to support the communicational perspective. In fact, this has been one before. 6. Conclusions an Future Work To sum up, Communication Analysis is an Information Systems (ISs) evelopment metho that proposes a flow of activities an a requirements structure. It is foune on Systems Theory an Communication Theory, among other scientific fiels. An overview of Communication Analysis can be foun elsewhere [20]. This paper focuses on the requirements elicitation stage an escribes in etail several communication-base moelling techniques. The Communicative Event Diagram specifies business processes from a communicational point of view. In orer to guie the analyst in ientifying an etermining the proper granularity of communicative events, unity criteria are propose. Each communicative event is later specifie by means of a template. Messages associate to communicative events are specifie by means of Communication Structures, a notation base on structure. The approach is exemplifie using an illustration case (a photography agency). Communication Analysis is currently being applie to big projects in inustrial environments; e.g. the integration of Anecoop S.Coop (a Spanish major istributor of fruit an vegetables) with its associate cooperatives (>100). We plan to escribe our inustrial experience by means case stuy reports. Laboratory experiments have been carrie out to test the benefits of the unity criteria; resulting moels correction an ata analysis is now being unertaken. Future work also involves eveloping a CASE tool that supports the metho, researching how other perspectives (e.g. goal or value orientation) may exten our approach uner certain project circumstances, an the integration of Communication Analysis an the OO-Metho, an MDA-base metho with software generation capabilities.
14 Sergio España1, Arturo González2, Óscar Pastor1 References 1. Austin, J.L.: How to o things with wors, Oxfor University Press (1962) 2. Ballmer, T.T., Brennenstuhl, W.: Speech act classification: A stuy of the lexical analysis of English speech activity verbs. Berlin, Springer (1981) 3. Baniassa, E., Clarke, S.: Theme: an approach for aspect-oriente analysis an esign. 26th International Conference on Software Engineering (ICSE 2004), IEEE Computer Society, pp. 158--167 (2004) 4. Brown, J., Cooper, C., Pi, M.: A taxing problem: the complementary use of har an soft OR in the public sector. Eur J Oper Res 172(2), pp. 666--679 (2006) 5. Bubenko, J.A., Brash, D., Stirna, J.: EKD User Guie. Dept. of Computer an Systems Science tech. report, Stockholm University (1998) 6. Castro, J., Kolp, M., Mylopoulos, J.: Towars requirements-riven information systems engineering: the Tropos project. Information Systems 27, pp. 365--389 (2002) 7. Chang, M.K., Woo, C.C.: A speech-act-base negotiation protocol: esign, implementation, an test use. ACM Trans. Inf. Syst. 12(4), pp. 360--382 (1994) 8. Cronholm, S., Golkunhl, G.: Communication Analysis as perspective an metho for requirements engineering. In: Mate, J.L., Silva, A. (es.) Requirements engineering for sociotechnical systems. Iea Group Inc., pp. 340--358 (2004) 9. Darenne, A., van Lamsweere, A, Fickas, S.: Goal-irecte requirements acquisition. Sci Comput Program 20(1-2), pp. 3--50 (1993) 10. Davis, A.M.: Software Requirements: Analysis an Specification, Prentice Hall (1990) 11. e la Vara, J.L., Sánchez, J., Pastor, O.: Business process moelling an purpose analysis for requirements analysis of information systems. 20th International Conference on Avance Information Systems Engineering (CAiSE'08). Montpellier, France, Springer (2008) 12. Dietz, J.L.G. Unerstaning an moelling business processes with DEMO. 18th International Conference on Conceptual Moeling (ER 1999). Paris, Springer, pp. 188--202 (1999) 13. Dietz, J.L.G., Golkuhl, G., Lin, M., van Reijswou, V.E.: The Communicative Action Paraigm for business moelling - a research agena. 3r International Workshop on the Language Action Perspective on Communication Moelling (LAP 1998). Jönköping International Business School (1998) 14. Dijkstra, E.W.: A iscipline of programming. Englewoo Cliffs, NJ, Prentice Hall (1976) 15. Esa, A., Lehtinen, E., Lyytinen, K.: A speech-act-base office moeling approach. ACM Trans. Inf. Syst. 6(2), pp. 126--152 (1988) 16. Falkenberg, E., Hesse, W., Lingreeen, P., Nilsson, B., Oei, J.L.H., Rollan, C., Stamper, R., Van Assche, F., Verrijn-Stuart, A., Voss, K.: FRISCO. A Framework of Information Systems Concepts. IFIP WG 8.1 Task Group Report (1998) 17. Flores, F., Lulow, J.: Doing an speaking in the office. In: Fick G., Sprague, R.H. (es.) Decision Support Systems: issues an challenges. NY, USA, Pergamon Press, pp. 95--118 (1980) 18. Fortuna, M., Werner, C., Borges, M.: Info Cases: integrating use cases an omain moels. 16th International Requirements Engineering Conference (RE'08). Barcelona, Spain, IEEE, pp. 81--84 (2008) 19. Golkuhl, G.: Generic business frameworks an action moelling. International workshop on the Language Action Perspective on Communication Moelling (LAP 1996). Tilburg, The Netherlans (1996) 20. González, A., España, S., Pastor, O.: Towars a communicational perspective for enterprise Information Systems moelling. IFIP WG 8.1 Working Conference on the Practice of Enterprise Moeling (PoEM 2008). Stockholm, Sween, Springer LNBIP (2008) 21. González, A., España, S., Pastor, O.: Unity criteria for Business Process Moelling: a theoretical argumentation for a Software Engineering recurrent problem. 3r Intl. Conf. on Research Challenges in Information Science (RCIS 09). Fes, Morocco, IEEE (2009)
Communication Analysis: a Requirements Engineering Metho for Information Systems0F 15 22. González, A.: Algunas consieraciones sobre el uso e la abstracción en el análisis e los sistemas e información e gestión. PH thesis (in Spanish). Departamento e Sistemas Informáticos y Computación. Universia Politécnica e Valencia (2004) 23. Gorijn, J., Wieringa, R.J.: A value-oriente approach to e-business process esign. 15th Conference on Avance Information Systems Engineering. Klagenfurt, Austria, Springer, pp. 390--403 (2003) 24. ISO/IEC 14977: Information technology - Syntactic metalanguage - Extene BNF (1996) 25. Jakobson, R. The speech event an the functions of language. In: Monville-Burston, M., Waugh, L.R. (es.) On language. Harvar University Press, Cambrige, pp. 69--79 (1990). 26. Langefors, B.: Theoretical analysis of Information Systems (4th e). Stuentlitteratur, Lun, Sween (1977) 27. Lockemann, P.C., Mayr H.C.: Information System Design: Techniques an Software Support. In: Kugler, H.-J. (e.) IFIP 86. North-Hollan, Amsteram (1986) 28. Meina-Mora, R., Winogra, T., Flores, R., Flores, F.: The action workflow approach to workflow management technology. ACM conference on Computer-Supporte Cooperative Work (CSCW 1992). Toronto, Ontario, Canaa, ACM, pp 281--288 (1992) 29. Melão, N., Pi, M.: A conceptual framework for unerstaning business processes an business process moelling. Inform Syst J 10(2), pp. 105--129 (2000) 30. OMG: Unifie Moeling Language: Superstructure version 2.0 http://www.omg.org/ocs/formal/05-07-04.pf Accesse 11-2008. (2005). 31. Pastor, O., González, A., España, S.: Conceptual alignment of software prouction methos. In: Krogstie, J., Opahl, A.L, Brinkkemper, S. (es.) Conceptual moelling in Information Systems engineering. Springer, Berlin, pp. 209--228 (2007) 32. Pastor, O., Molina, J.C.: Moel-Driven Architecture in practice: A Software Prouction Environment Base on Conceptual Moeling. Springer, New York (2007) 33. Rashi, A., Sawyer P., Moreira, A., Araújo, J.: Early Aspects: a moel for aspect-oriente requirements engineering. 10th Anniversary IEEE Joint International Conference on Requirements Engineering, IEEE Computer Society, pp. 199--202 (2002) 34. Rittel, H., Webber, M.: Dilemmas in a general theory of planning. Policy Sciences 4, pp. 155--169 (1973) 35. Rollan, C.: Capturing system intentionality with Maps. In: Krogstie, J., Opahl, A.L, Brinkkemper, S. (es.) Conceptual moelling in Information Systems engineering. Springer, pp. 141--158 (2007) 36. Scheer, A.-W.: ARIS - Business Process Moeling, 3r eition. New York, Springer (2000). 37. Searle, J.R., Vanerveken, D.: Founations of illocutionary logic, Cambrige University Press (1985) 38. Stamper, R. K. (1997). Organizational semiotics. In: Stowell, F.,Mingers, J. (es.) Information Systems: an emerging iscipline, Lonon, McGraw Hill, pp. 267--283 39. van Lamsweere, A.: Goal-oriente Requirements Engineering: a guie tour. 5th IEEE International Symposium on Requirements Engineering (RE 2001). Toronto, Canaa, IEEE Computer Society, pp. 249--262 (2001) 40. Wan, Y., Weber, R.: On the eep structure of information systems. Inf. Syst. J. 5, pp. 203-- 223 (1995) 41. Weigan, H., Johannesson, P., Anersson, B., Bergholtz, M., Eirisuriya, A., Ilayperuma, T.: On the notion of value object. 18th International Conference on Avance Information Systems Engineering (CAiSE 2006). Luxembourg, Belgium, Springer, pp. 321--335 (2006) 42. Winogra, T., Flores, F.: Unerstaning computers an cognition: A new founation for esign. Boston, Aison-Wesley (1987) 43. Yu, E., Mylopoulos, J.: From E-R to "A-R" - Moelling strategic actor relationships for business process reengineering. 13th International Conference on the Entity-Relationship Approach. Manchester, Springer, pp. 548--565 (1994)