Closing the GAP Between Organizational Requirements and ... · Closing the Gap Between...

Jaelson Castro, Closing the Gap Between OrganizationalFernanda Alencar and Gilberto Cysneiros Requirements and Object Oriented Modeling

5

Closing the GAP Between OrganizationalClosing the GAP Between OrganizationalRequirements and Object OrRequirements and Object Oriiented Modelingented Modeling

Jaelson CastroUniversidade Federal dePernambuco, Centro deInformática, Recife, [email protected]

Fernanda AlencarUniversidade Federal dePernambuco, Dep. Eletrônica eSistemas, Recife, [email protected]

Gilberto CysneirosUniversidade Federal dePernambuco, Centro deInformática, Recife, [email protected]

Abstract Requirements Engineering has been considered a key activity in any Software Engineeringprocess. It is well known that a requirements specification should include not only softwarespecifications but also business models and other kinds of information describing the contextin which the intended system will function. In recent years we have observed a growing influ-ence of the object-orientation paradigm. Unfortunately, the current dominant object orientedmodeling technique, i.e. Unified Modeling Technique, is ill equipped for modeling early re-quirements which are typically informal and often focus on Organizational objectives. UML ismore suitable for later phases of requirements capture, which usually focus on completeness,consistency, and automated verification of functional requirements for the new system. In thispaper, we present some guidelines for the integration of early and late requirements specifica-tions. For the organizational modeling we use the i* framework, which focuses on the descrip-tion of organizational relationships among various organizational actors, as well as an under-standing of the rationale for the alternatives chosen. For the functional requirements specifi-cation, we rely on a precise subset of the Unified Modeling Language annotated with con-straints described in the Object Constraint Language. A small example is used to illustratehow the requirements process iterates between the early and late requirements specification.

Keywords: Requirements Engineering, Object Oriented Development, UML

1 Introduction

It is now a widely shared tenet of Software Engi-neering that a good Requirements Engineering effort isparamount to the success of any system. Often, softwaresystems fail to properly support the organizations ofwhich they are an integral part. Primary reasons for suchfailures are the lack of proper understanding of the or-ganization by the software developers of the system,also the frequency of organizational changes whichcannot be accommodated by existing software systems(or their maintainers). Hence, requirements capture hasbeen acknowledged as a critical phase of software de-velopment, precisely because it is the phase which dealsnot only with technical knowledge, but also with Or-ganizational, managerial, economic and social issues.

The emerging consensus is that a requirement specifica-tion should include not only software specifications butalso business models and other kinds of informationdescribing the context in which the intended system willfunction [1]. During requirements analysis, analystsneed to help to identify different ways in which softwaresystems ca be used to achieve Organizational objectives.Consequently, there is a need for modeling and analysisof stakeholder interests and how they might be ad-dressed, or compromised, by various system-and-environment alternative structures. Indeed, the UnifiedMethod has suggested the following archetypalworkflow for requirements capture [2]:

• List candidate requirements,

• Understand system context,

Closing the Gap Between Organizational Jaelson Castro,Requirements and Object Oriented Modeling Fernanda Alencar and Gilberto Cysneiros

6

• Capture functional requirements,

• Capture non-functional requirements.

However, the production of high quality specifica-tions is quite difficult. Usually the customers do notexactly know what they want and sometimes the re-quirements may not reflect the real needs of the custom-ers. It is common for requirements to be incompleteand/or inconsistent.

A recent work on requirements engineering has drawnan important distinction between early phase requirementscapture and late phase requirements capture [3]. Earlyphase requirements activities are typically informal andaddress Organizational or non-functional requirements. Theemphasis is on understanding the motivation and rationalethat underlie system requirements. Late phase requirementsactivities usually focus on completeness, consistency, andautomated verification of requirements.

We claim that the dominant object oriented modelingtechnique, Unified Modeling Language [4], is well suitedonly for late-phase requirements capture. We argue thatUML is ill equipped for early requirements capture becauseit can not represent how the intended system meets organ-izational goals, why the system is needed, what alternativeswere considered, what the implication of the alternatives arefor the various stakeholders, and how the stakeholders’interests and concerns might be addressed. What is requiredto capture such concerns is a framework that focuses on thedescription and evaluation of alternatives and their relation-ship to the organizational objectives behind the softwaredevelopment project [5]. We argue that the i* framework[6], is well suited for early-phase requirements capture,since it provides for the representation of alternatives, andoffers primitive modeling concepts such as those of softgoaland goal.

We advocate that UML alone is not adequate to dealwith all different types of analysis and reasoning that arerequired during the requirements capture phases. Instead,we advocate the use of two complementary modeling tech-niques, i* and UML. To model and understand issues of theapplication and business domain (the enterprise) a devel-oper can use the i* framework which allows a better de-scription of the organizational relationships among thevarious agents of a system as well as an understanding ofthe rationale of the decisions taken. For the functional re-quirements specification, the developer can rely on UML,or if formality is required, the precise Unified ModelingLanguage (pUML) [7], annotated with constraints describedin OCL [8].

In this work we present the transition from early (in-formal) descriptions in i* to late (precise) requirementsin pUML. This constitutes a conceptualization activitywithin which a developer might make use of domain

knowledge partly expressed in descriptions of the or-ganization, and partly in existing requirements specifi-cations.

This paper is organized as follows. Section 2 intro-duces the language used for the early requirements de-scription, namely the i* technique. In section 3, weprovide some means for transforming the i* models intoprecise specifications in pUML/OCL. Late requirementsspecification is described in Section 4. Section 5 reviewssome related work, while Section 6 concludes the paperwith a summary of its contributions. Throughout thepaper, a small CD store example is used to illustratehow the requirements process iterates between the earlyand late requirements specification. The example ispedagogical and is meant to be suggestive of the muchmore complex sets of issues typically found in actualsituations

2 The i* Modeling Framework forEarly Requirements Capture

When developing systems, we usually need to have abroad understanding of the organizational environmentand goals. The i* technique [3] provides understandingof the “why” by modeling organizational relationshipsthat underlie systems requirements. i* offers a modelingframework that focuses on strategic actor relationships.Usually, when we try to understand an organization, theinformation captured by standard modeling techniques(DFD, ER, Statechart, etc.) focuses on entities, func-tions, data flows, states and the like. They are not capa-ble of expressing the reasons (the “why’s”) of the proc-ess (motivations, intentions and rationales). The ontol-ogy of i* [9] caters to some of these more advancedconcepts. It can be used for: (i) obtaining a better under-standing of the organizational relationships among thevarious organizational agents; (ii) understanding therationale of the decisions taken; and (iii) illustrating thevarious characteristics found in the early phases of re-quirements specification. The participants of the organ-izational setting are actors with intentional properties,such as, goals, beliefs, abilities and compromises. Theseactors depend upon each other in order to fulfil theirobjectives and have their tasks performed. The i* tech-nique offers two models: The Strategic Dependency(SD) model, and the Strategic Rationale (SR) model.

2.1 The Strategic Dependency Model

This model focuses on the intentional relationshipsamong organizational actors. It consists of a set of nodesand links connecting them, where nodes represent actors


7

and each link indicates a dependency between two ac-tors. The depending actor is called depender, and theactor who is depended upon is called the dependee.Hence, an SD model consists of a network of depend-ency relationships among various actors, capturing themotivation and the rationale of activities. i* distin-guishes four types of dependencies. Three of these re-lated to existing intentions – goal dependency, resourcedependency and task dependency, while the fourth isassociated with the notion of non-functional require-ments, the so called softgoal dependency. In a goal de-pendency, an agent depends on another to fulfil a goal,without worrying how this goal will be achieved. In aresource dependency, an agent depends on another agentto provide a physical resource or information. In a task

dependency, an agent depends on another to carry out atask. A softgoal dependency is similar to a goal depend-ency, except that a softgoal is not precisely defined. Ini* we can also model different degrees of dependencycommitment on the part of the relevant actors (open,committed, or critical). We can also classify actors intoagents, roles and positions. An agent is an actor withconcrete physical manifestations (a person or a system).A role is an abstract characterization of the behaviour ofa social actor within some specialized context, domainor endeavor. A position is a set of roles typically playedby one agent. Finally, i* supports the analysis of oppor-tunities and vulnerabilities for different actors [6].

Figure 1: Strategic Dependency Model


8

Suppose a situation in which a Client wishes to buyCDs and goes to a specialized store because its servicesare of good quality and it claims to have most (if not all)available titles on stock. If a client cannot find his/herspreferred title, the shop can happily place an order for itand notify the client upon its arrival. The shop has de-cided to improve its services by commissioning a newsoftware system (SmartCD) to handle orders as well asproviding an online catalogue (it would be so conven-ient!). In Figure 1, we have the Strategic Dependency(SD) model of the CD store case study.

At this early stage of requirements capture we haveidentified three actors: Client, Store and SmartCD. Thislast actor indeed corresponds to the system to be devel-oped, handling orders, notifications of CD arrivals andproviding the online catalogue. The dependencies be-tween the Client and the Store actor can be find in Fig-ure 1. The Client depends on the Store for getting theCD (resource dependency). However, he/she wishes theservices to be of good quality (softgoal Qual-ity[Service]) and the store to maintain a good stock ofCDs (softgoal Good variety). Of course these goals arenot yet precisely defined at this early stage, hence theuse of softgoals. Turning to the relationship betweenactors Client and SmartCD, we notice that one of thegoals for introducing the online system is to enablebrowsing facilities (goal dependency Browse Cata-logue). In fact, the store may stock thousands of CDs,making it difficult (or even impossible) for a customerto manually search all of them. In the (unlikely) situa-tion that a CD is not on stock, the SmartCD actor will beable to handle orders online (the system will informwhat and how it should be done, hence task dependencyOrder new CD). This feature is much awaited, sincefilling orders manually (through a sales person) is timeconsuming. Of course, when the (ordered) CD arrives,the Client will be notified as soon as possible (actuallythere is a pre-defined procedure for dealing with it,hence the task dependency Notify CD Arrival). TheClient expects the access to software system to be fast(softgoal Fast[Access]) and to use it to keep the stockupdated (task Update Stock). Last but not least, the Storeactor also has some expectations on the commissionedSmartCD system. It relies on the software system toprocess internet orders (goal Process Internet Orders)and to controls its stock (task Update Stock).

2.2 The Strategic Rational Model

The Strategic Rationale Model (SR) provides a moredetailed level of modeling by looking “inside” actors tomodel internal intentional relationships. It is used to: (i)

describe the interests, concerns and motivations of par-ticipants process; (ii) enable the assessment of the possi-ble alternatives in the definition of the process; and (iii)research in more detail the existing reasons behind thedependencies between the various actors. Nodes andlinks also compose this model. It includes the previousfour types of nodes (present in the SD model): goal,task, resource and soft-goal. However, two new types ofrelationship are incorporated: means-end that suggeststhat there could be other means of achieving the objec-tive (alternatives) and task-decomposition that describeswhat should be done in order to perform a certain task.

In Figure 2 we use the SR notation to detail the Storeagent. Due to space limitation we now only commentsome aspects. An interested reader can find a fullerdescription of the approach in [10]. The store is inter-ested in attracting (new and old) clients (expressed bytask node To Attract Customers). Several strategic deci-sions were taken in consideration and as a result the taskwas decomposed into five aspects (expressed by a task-decomposition link):

• The need to offer reasonable prices (captured bysoftware goal Good Prices). Two alternativesare considered for meeting this objective: to of-fer discount on selected items (softgoal Discount

Price) or obtaining good deals by buying largequantities of popular CDs (softgoal Volume Pur-

chase[Highs]),

• To need to establish a courteous relationshipbetween the store staff and its clients (repre-sented by softgoal Friendly Staff). This is con-sidered to be a way of meeting the quality ofservice expected by the client.

• To define standard procedures for delivering CD(expressed by sub-task Delivery),

• To be able to maintain a good stock of CDs(captured by sub-task Maintain Stock). This willalso require the updating of the online informa-tion system. Hence the task dependency Update

Stock between the Store and SmartCD actors.

• To handle internet sales (captured by sub-taskSales by Web), which depends on the adequatesoftware system, hence the goal dependencyProcess Internet Orders between the Store andSmartCD actors.


9

Figure 2: Strategic Rational Model

After some considerations, it has been agreed that thetask of maintaining the stock needs to be further decom-posed:

• The overall objective is to have all available titleson stock (captured by goal Have all titles). Ifthis is met, certainly the client will be verypleased (see the softgoal Good Variety betweenClient and Store actors),

• Buying new titles (expressed by a sub-task Buy

new releases),

• Making sure that popular CDs are re-stocked (ex-pressed by a sub-task ‘Replenish’).

At this point, we may stop the process of modelingthe strategic dependencies of the CD store. We are al-ready capable of understanding some issues of the appli-cation domain (the enterprise). We can then move toprovide a detailed system specification.

3 From Organizational Requirementsto Object Oriented Models

We have shown that i* provides an early under-standing of the organizational relationships in a businessdomain. As we progress in the development we need tofocus on the functional and non-functional requirementsof a system-to-be, which will support the chosen alter-native among those considered during early require-ments. To specify the late requirements, we adoptpUML (precise UML) [7] which provides a precise de-notational semantics for core UML elements, such as:relationship, classifier, association, and generalization.The interested reader can visit the pUML site [11] for acomplete description of the approach.

Note that pUML diagrams alone are not sufficientfor late requirement capture because it does not providefor the specification of constraints, such as invariants,preconditions and the like. For this task, we haveadopted the Object Constraint Language (OCL) [8].OCL is a textual language, also part of the Object Man-


10

agement standard, that can precisely describe constraintsfor object oriented models.

In the sequel we suggest six heuristics for trans-forming i* based early requirements models topUML/OCL based late requirements:

• Guideline G1: Related to actors;

• Guideline G2: Related to tasks;

• Guideline G3: Related to resources;

• Guideline G4: Related to goals and soft-goals;

• Guideline G5: Related to tasks decomposition;

• Guideline G6: Related to means ends links.

Guideline G1:

Actors in the i* framework, can be mapped to classesin pUML. OCL constraints can be attached to the actor-generated classes.

In our case study (see Figure 1) there were three ac-tors: Store, Client and SmartCD. These actors can bemapped to the three classes shown in Figure 3.

Guideline G1.1:

Actor composition in i* corresponds to class aggre-gation in pUML.

In our CD Store case study (see Figure 1), the Strate-gic Dependency contained three actors: Store, Client andSmartCD. In pUML (see Figure 3), CD Store class is theaggregate of three composite classes.

Guideline G2:

Tasks in i*, are mapped to class operations in pUML.

Guideline G2.1:

A task dependency, between a depender and a de-pendee actor in the SD model, corresponds to a publicoperation in the dependee pUML class.

In our case study (see Figure 1), the Store Actor de-pends on the SmartCD Actor for updating its stock (taskUpdate Stock). Similarly, the Client actor depends onthe SmartCD Actor for two tasks: ordering CDs (Ordernew CD) and receiving notification of goods arrival(task Notify CD arrivals). Hence, in Figure 3 you canobserve that the SmartCD pUML class will be responsi-ble for supporting the three (public) operations (UpdateStock, Notify CD Arrival, Order New CD) .

Guideline G2.2:

A task in the SR model is mapped to a local opera-tion in the corresponding pUML class.

In our case study, see Figure 2, a key task for the

Store actor was to be able to Attract Customers. Thisconsists of three subtasks: to handle internet orders(Sales By Web), to Maintain Stock and to deliver theCDs (Delivery). Maintaining stock included obtainingthe new releases (Buy new releases) and renewing items(Replenish). Therefore the corresponding Store class hasfive (local) corresponding operations (see Figure 3).

Guideline G3:

Resources in i* are mapped as classes in pUML. Apublic attribute of the type Boolean, indicates the avail-ability of resource.

In our example, see Figure 1, Client actor dependson the Store Actor, to obtain a CD resource. In Figure 3,we can observe that the CD class has been introduced torepresent the resource. A boolean attribute (availability)indicates if is the resource is at hand.

Guideline G4:

Strategic goals and soft goals will be mapped to at-tributes of the type boolean and enumerated type, re-spectively, in pUML classes.

Goals are well defined, hence it is always possible toestablish if one has been fulfilled or not. On the otherhand, softgoals are not well defined. They can only be“satisfied” to some degree [16]. Hence, an enumeratedtype is better suited for their representation inpUML/OCL, whose values represent different degrees ofsoftgoal fulfillment.

Guideline G4.1:

Goals and soft goals dependencies in Strategic De-pendency Models (SD) models are mapped to publicboolean and enumerated attributes, respectively, of thedependee pUML class.

In our case study (see Figure 1), the Client Actor ex-pects that the Store Actor could have a good stock(Good variety softgoal) and provide a good service(Quality[Service] softgoal). Therefore, in the corre-sponding Store class, two enumerated public attributesare added (see Figure 3).

Guideline G4.2:

Goals and soft goals dependencies in Strategic Ra-tionale Models (SR), are mapped to local boolean andenumerated pUML class attributes, respectively.

For example, in Figure 2, we have that the Store ac-tor has a well defined goal (to Have all titles), and fourill defined objectives or softgoals: to offer Good Price,to have Volume Purchase [High], to give DiscountPrice, and to have a Friendly staff. In Figure 3 we ob-serve that these extra attributes have been included to


11

Store Class.

The next guideline deals with task. Operations inpUML can be used to describe tasks performed by anactor. If we need to provide a more precise account ofthe operation, we can rely on OCL to specify its pre and

post conditions. However, observe that in the i* frame-work tasks can also be decomposed into sub-task, sub-goal, sub-softgoal and sub-resource.

Figure 3: Context Class Diagram of the CD Store

Guideline G5:

Task decomposition is represented by pre and pos-conditions (expressed in OCL) of the correspondingpUML operation.

The pre-condition is the conjunction (AND OCLconnector) of sub-tasks pre-conditions.

The post-condition is the conjunction (AND OCLconnector) of all: (i) sub tasks post-conditions; (ii) re-source Boolean attributes; (iii) goal Boolean attributes(iv) soft-goal enumerated attributes.

Consider for example, the task To Attract Customers(Figure 2). It is decomposed into three sub-tasks (Deliv-ery, Maintain Stock and Sales By Web) and two sub-goals (Good Price and Friendly staff). Let us use theOCL assertions pre-Subtask and pos-Subtask to indicategeneric pre and post-conditions of a sub-task. Moreover,assume that the OCL assertion value indicates one of thepossible values of the enumerated type (posit, negat,undef,) associated to a soft goal. Figure 4 shows thecorresponding OCL description.

Figure 4: Task decomposition in OCL

When we work with the later requirements we canrefine the pre and post conditions of the three opera-tions: Delivery, Maintain Stock and Sales by Web. This

activity is typical of later phase of the developmentprocess. Hence, we can suggest some conditions forthese operations as you can see in the Figure 5.

CD Store

Store

+ Quality[Service] : enum + Good variety : enum - Good Price : enum - Volume Purchase[High] : enum - Discount Price : enum - Friendly staff : enum - Have all titles : bool

- To Attract Customers - Sales By Web - Maintain Stock - Buy new releases - Replenish - Delivery

Client SmartCD

+ Update Stock + Notify CD Arrival + Order New CD + Browse Catalogue

+ Process Internet Order + Fast [Access] + Security [Access]

CD

+ availability

Depender

Resource

Resource

Dependee

Store:: To Attract Customerspre: pre-Delivery and pre-Maintain Stock and pre-Sales By Webpost: GoodPrice = ‘value’ and Friendly staff = ‘value’ and post-Delivery and post-MaintainStock and post-Sales By Web


12

Figure 5: Some Pre and Post Conditions

The SR models also provides for several types ormeans-end link. The “end” can be a goal, task, resource,or softgoal, whereas the “means” is usually a task (GT,TT, RT and ST links). Sometimes it is also useful tohave means-end hierarchy of softgoals or goals (SS andGG links).

Guideline G6:

Means end-analysis is represented by OCL disjunc-tions of all possible means achieving the end.

Guideline G6.1(SS and GG Links):

If the end is a (soft) goal and the means are (soft)goals than the disjunction of the means values impliesthe end value.

In our case study (see Figure 2), there are two meansof offering reasonable prices Negotiating discountsbased on high volume purchase (softgoal Volume Pur-chase[High]) or by promoting sales (softgoal DiscountPrice). Either way the end goal (softgoal Good Price) isachieved. In Figure 6 the corresponding OCL represen-tation is presented.

Figure 6: Means-end analysis

Guideline G6.2 (GT, RT and ST Links):

If the end is either a goal, resource or softgoal andthe means is a task than the post-condition of the meanstask implies the value of end goal (boolean) attribute,resource (boolean) attribute or softgoal (enumerated)attribute.

In our case study these means-end links did not oc-cur.

Guideline G6.3 (TT Link):

If the end is a task and the means are tasks then thedisjunction of the post-condition of the means task implythe pos-conditions of the end task.

In our case study this means-end link did not occur.

Of course not all concepts captured in the early re-quirements phase will correspond to software systemmodels. The models do not have a one-one relationship;many elements of the organisational model are not part

of the software model, since not all of the organisationaltasks require a software system. Many tasks containactivities that are performed manually outside the soft-ware system, and so do not become part of the softwaresystem model. Likewise, many elements in the softwaremodel comprise detailed technical software solutionsand constructs that are not part of the organisationalmodel. Nonetheless, as we shall see, pUML/OCL alsocan be used to represent this information.

So far we have been able to identify a context classdiagram for problem at hand. Now we can proceed togive some more details of the software system to bedeveloped.

4 Some Late Requirements

Late requirements analysis results in a requirementsspecification document which describes all functional

Store:: To Deliverypre: delivery address and paymentpost: delivered CD

Store:: To Maintain Stockpre: quantity >= “value”post: CD in stock

Store:: To Sales By Webpre: site on linepost: increaseded sales volume

StoreVolume Purchase [High]=’value’ or Discount Price = ‘value’

implies Good Price = ‘value’


13

and non-functional requirements of the system-to-be. Inour case study, the SmartCD actor represents the infor-mation system that will help the store to accomplishsome of its tasks strategic objective, namely to attractcustomers (see Figure 2). The system can be structuredinto various modules or sub-actors including: inventory,financial and the internet sales module.

Due to space limitation we will concentrate on somelate requirements for the Internet Sales Module, since itis related to the Sales By Web task, shown in the strate-gic rationale model of Figure 2. It is part of the systemresponsible for the process of sales through the Internet.We will consider the context class diagram of Figure 3as the starting point of our discussion, which by nomeans should be considered exhaustive. On the contrary,it is meant to be suggestive of the much more complexsets of issues typically found in actual situations. As amatter of fact, methods such as Catalysis [13] alreadymake some of these issues very clear.

The Internet Sales sub-system provides a web-site toenable customers to remotely access the Store. This siteallows the visitors to search for CDs, see informationabout pop stars and news about the musical events.

There are two ways for a client to search for a CD:the fast and super search. In the fast mode the visitorinforms the name of the album, of the artist, or of themusic. In the super search the objective is to help thosethat still do not know which title to buy. For that supersearch type the following options are available: name ofthe album or of the music, the styles (Pop, Rock, Rap,Reggae, Jazz, etc.), the recording, the repertoire (na-tional or international) and the release time.

Assistance can be provided upon request by e-mailor through a FAQ page. The FAQs (Frequentely Askedand Questions) contains answers for the most commonquestions. If the visitor does not find the appropriateanswer he/she can fill in a form (including the subject,name, number of the purchase request) and submit it.Upon receipt, an on-line sales assistant will answer thequestion.

A visitor (if not already a client) would have to reg-ister in order to use the system. The register operation isavailable through a page where the customer supplies itspersonal data (complete name, identification no., gen-der, birthday), an access name (login), a password, anote (to help to recollect the password), its completeaddress (street, number, neighborhood, city, state andzip code), residential and commercial telephone, e-mail,the address for delivery (street, number, neighborhood,city, state, zip code, telephone for contact) and the pay-ment form. In particular we are conceiving two forms of

payment: credit card or direct debit in checking account.For the payment by credit card it is necessary the title-holder's name, the type of the credit card, the number ofthe card and validity of the card. For the direct debit inchecking account it is necessary the title-holder's name,the name of the bank, the number of the agency and thenumber of the checking account. If necessary the clientcan later revise his/her personal information. For reasonsof security the customer can choose to fax or e-mail thepersonal information.

The site offers to its clients special services, for ex-ample: security in the transactions and personalizedattendance. For the sake of total security the customers’data are stored in a safe and isolated server (not con-nected to the Internet), with restricted access to author-ized employees. SmartCD will use a safe communica-tion protocol (SSL - Secure Sockets Layer). Client pro-file can also be provided. It consists of client's prefer-ences such as musical styles (Pop/Rock, Blues/Jazz,Infantile, Samba/Pop,...), artists or favorite groups andthe desire or not of receiving information on promo-tions, releases, and so on.

Based on these late requirements a revised pUMLclass diagram can be drawn (see Figure 7). It is inter-esting to note that the security[Acess] softgoal betweenthe Client and SmartCD actors of Figure 2 is the reasonfor the choice of the use of a secure protocol (SSL) forcredit and debit operation of Payment Form Class.

5 Related Work

The area of Requirements Engineering [14] has de-veloped several novel techniques for early requirementscapture [15,16]. Bubenko emphasizes the need to modelorganizations and their actors, motivations and reasons[16]. In his work, enterprise modeling and requirementsspecification are based on the notion that a requirementsspecification process, from a documentation point ofview, implies populating (instantiating) five interrelatedsub-model, representing areas of knowledge of the or-ganization, which include an Objectives Model, an Ac-tivities & Usage Model, an Actors Model, a ConceptsModel, and an Information Systems RequirementsModel. Since the models are informal, or at best semi-formal, only some verification can be performed auto-matically, such as syntactical correctness and connect-edness.


14

Figure 7: Revised Class Diagram (Internet Sales Sub-System)

In the KAOS framework [16] goals are explicitlymodeled and simplified (reduced) through means-endreasoning until it reaches the agent level of responsibili-ties. KAOS provides a multi-paradigm specificationlanguage and a goal-directed elaboration method. Thelanguage combines semantic nets for conceptual mod-eling of goals, requirements, assumptions, agents, ob-jects and operations in the system; temporal logic for thespecification of goals, requirements, assumptions andobjects; and state-based specifications for the specifica-tion of operations. Goals are reduced through means-ends reasoning to arrive at responsibilities for agents.The modeling of agents is specificational and prescrip-tive. Since agents are assumed to conform to prescribedbehavior, one cannot easily analyze dependencies foropportunities and vulnerabilities. On the other hand, i*

models offer a number of levels of analysis, in terms ofability, workability, viability and believability. Theseare detailed in [3].

The TROPOS project [17,18] is developing a meth-odology for agent-oriented systems which is require-ments-driven. It adopts the i* concepts and uses it allalong the life-cycle as a foundation to model late re-quirements, architectural, detailed design and imple-mentation. That allows dealing with intention-basedsoftware units at the right phase and not freeze themearlier in the process.

Another related work is the requirements modelingframework for manufacturing systems (MS) presented in[19]. It relies on two major ideas: a multi-formalismapproach, combining several languages into a coherent

CD

codealbumTitlestyle….

newCD...

Music

songTitleartistaudioletter....

Order

statusdateOrderdateDeliveryaddress

Payment Form

Credit Card

nametypenumbervalidate

Checking Count

namebankaccountNumber

Client

Attendance

subjectorderNumbere-mailmessage

namesexloginpasswordaddress...

registerverifiyPasswordalterDatafastSearchsuperSearchorderCD...

creditdebitSSL

Inventory

reportremoveCDinsertCD...

Sales

report....

notifyCDArrival


15

formalism, and a component-based modeling approach.The modeling framework proposed combines the AlbertII, i* and CIMOSA languages. The combination isachieved through meta-modeling and the definition of aset of mapping rules that establish a correspondenceamong some of the concepts of the three formalisms.

Another important issue related to early phase re-quirements capture is the representation of qualitiesattributes, such as accuracy, performance, security,modifiability, etc. In [12] a comprehensive approach fordealing with non-functional requirements - NFR is pre-sented. Structured graphical facilities are offered forstating NFRs and managing them by refining and inter-relating NFRs, justifying decisions, and determiningtheir impact. A current research topic is the extension oftraditional Object-Oriented Analysis to explore the al-ternatives offered by the non-functional goal-orientedanalysis, which systematizes the search for a solutionwhich characterizes early phases or requirements analy-sis, rationalizes the choice of a particular solution, arelates design decisions to their origins in organisationaland technical objectives.

Although UML has been used mainly for modelingsoftware, recent proposals have used it for describingenterprise and business modeling. For example, [1]claims that UML is a suitable language for describingboth the structural aspects of business (such as the or-ganization, goal hierarchies, or the structure of the re-sources), the behavioral aspect of a business (such as theprocesses), and the business rules that affect structureand behaviour. In [20] UML is used, from a businessperspective, to describe the four key elements of anenterprise model: purpose, processes, entities and or-ganization. The challenge is to transfer the informationavailable in the (early) business models to the (late)software requirements models.

6 Conclusion

In this paper, we have suggested that requirementscapture has to be done at different levels of abstraction(ranging from the early phase to the late phase require-ments). Furthermore, we argue that UML alone is notadequate to deal with all different types of analysis andreasoning that are required during the requirementscapture phases. Instead, we advocate the use of twocomplementary modelling techniques, i* and a precisesubset of UML.

To model and understand issues of the applicationand business domain (the enterprise) a developer can usethe i* framework which allows a better description of

the organisational relationships among the variousagents of a system as well as an understanding of therationale of the decisions taken. For later requirementscapture we suggest the use of pUML, a subset of UMLwhich has a well defined semantics. Annotations in OCLcan also be deployed for describing constraints on themodels.

We believe that each language has its own merits forsupporting requirements capture. But as long as differenttechniques are used, then a key issue is the developmentof an integrated framework to support and guide theinterplay of requirement captures activities at the vari-ous levels, and to support traceability and change man-agement. Indeed, the guidelines presented in the paperare important steps in this direction. They can help tomap the descriptive, early requirements model of the i*technique into a prescriptive, late requirements modelexpressed in pUML/OCL.

Of course not all concepts captured in the early re-quirements phase will correspond to software systemmodels. The models do not have a one-one relationship;many elements of the organisational model are not partof the software model, since not all of the organisationaltasks require a software system. Many tasks containactivities that are performed manually outside the soft-ware system, and so do not become part of the softwaresystem model. Likewise, many elements in the softwaremodel comprise detailed technical software solutionsand constructs that are not part of the organisationalmodel. Nonetheless, pUML/OCL also can be used torepresent this information.

Further research is still required to handle somestructuring concepts found in the i* framework, such asagent, role and position. Some real industrial case stud-ies are also expected. Work is underway to providesome tool support (Multiview+) for the mapping. Thetool will import organizational requirements specifica-tion produced by the i* toolset (OME) and generate thecorresponding pUML business model.

Acknowledgements

The authors are grateful to John Mylopoulos whoseinsights helped us focus our research on intentional andsocial aspects. He provided valuable comments on ear-lier drafts of this paper. We would like also to thank theanonymous referees for their helpful comments to thiswork.


16

References

[1] H. Erikson, M. Penker. Business Modeling withUML: Business Patterns at Work, John Wileys& Sons, Inc., USA, 2000.

[2] I. Jacobson, G. Booch, J. Rumbaugh. UnifiedSoftware Development Process, Rational Soft-ware Corporation. Addison-Wesley ObjectTechnology Series, 1999.

[3] E. Yu. Towards Modelling and Reasoning Sup-port for Early-Phase Requirements Engineering.In Proc of IEEE International Symposium onRequirements Engineering - RE97, pages 226-235, 1997.

[4] G. Booch, I. Jacobson, J. Rumbaugh. UnifiedModeling Language User Guide. Rational Soft-ware Corporation. Addison-Wesley ObjectTechnology Series, 1999.

[5] J. Mylopoulos, L. Chung, E. Yu. From Object-Oriented to Goal-Oriented RequirementsAnalysis. Communications of the ACM, 42(1):31-37, 1999.

[6] E. Yu, J. Mylopoulos. Understanding 'Why' inSoftware Process Modeling, Analysis and De-sign. In Proc. Sixteenth International Confer-ence on Software Engineering, Sorrento,Italy, 1994.

[7] A. Evans, S. Kent. Core Meta-Modelling Se-mantics of UML: The pUML Approach.UML’99 – The Unified Modeling Language.Proc. of <<UML>>’99 The Unified ModelingLanguage: Beyond the Standard - The SecondInternational Conference. Eds. Robert Franceand Bernhard Rumpe. Fort Collins, CO, USA,pages 140-15, 1999.

[8] J. B. Warmer, A. G. Kleppe. The Object Con-straint Language: Precise Modeling with UML.Addison-Wesley Object Technology Series,1999.

[9] E. Yu. Why Agent-Oriented RequirementsEngineering. In Proc. of the 4th InternationalWorkshop on Requirements Engineering: Foun-dations of Software Quality, Pisa, Italy. E. Du-bois, A.L. Opdahl, K. Pohl, eds. PressesUniversitaires de Namur, pages 15-22, 1998

[10] F. M. R. Alencar. Mapping OrganizationalModeling into Precise Specification. Ph.D.Thesis (In Portuguese). Centro de Informática,

Universidade Federal de Pernambuco, Recife,Brazil, Dec., 1999.

[11] Precise UML Group, pUML:http/www.cs.york.ac.uk/puml, Out. 2000.

[12] L. K. Chung, B. A. Nixon, E. Yu, J. Mylo-poulos. Non-Functional Requirements in Soft-ware Engineering, Kluwer Publishing, 2000.

[13] D. F. D’Souza, A. C. Wills. Objects, Compo-nents, and Frameworks with UML: The CA-TALYSIS Approach. Addison-Wesley ObjectTechnology Series, 1999.

[14] A. van Lamsweerde. Requirements Engineeringin the year 00: A Research Perspective. Invitedpaper to ICSE’2000. In Proc. 22nd InternationalConference on Software Engineering, Limerick,2000.

[15] M. Boman, J. Bubenko, P. Johannesson, B.Wangler. Conceptual Modeling. Prentice HallSeries in Computer Science, 1997.

[16] A. van Lamsweerde, R. Darimont, E. Letier.Managing Conflicts in Goal-Drivel Require-ments Engineering. IEEE Transaction on Soft-ware Engineering, Special Issue on Inconsis-tency Management in Software Development,1998.

[17] J. Castro, M. Kolp, J. Mylopoulos. DevelopingAgent-Oriented Information Systems for theEnterprise. In Proc of the Second InternationalConference On Enterprise Information Systems(ICEIS00), Stafford, UK, 2000.

[18] J. Mylopoulos, J. F. B. Castro. Tropos: AFramework for Requirements-Driven SoftwareDevelopment. Brinkkemper, J. and Solvberg, A.(eds.), Information Systems Engineering: Stateof the Art and Research Themes, Springer-Verlag, pages 261-273, 2000.

[19] M. Petit. Formal Requirements Engineering ofManufacturing Systems: A Multi-Formalismand Component-Based Approach. Ph.D. Thesis,Computer Science Departament University ofNamur, Namur, Belgium, 1999.

[20] C. Marshal. Enterprise Modeling with UML:Designing Successful Software through Busi-ness Analysis. Addison-Wesley Object Tech-nology Series, 2000.

Closing the GAP Between Organizational Requirements and ... · Closing the Gap Between...

Documents

Transcript of Closing the GAP Between Organizational Requirements and ... · Closing the Gap Between...