Improving use case driven analysis using goal and scenario

www.elsevier.com/locate/datak

Data & Knowledge Engineering 58 (2006) 21–46

Improving use case driven analysis using goal andscenario authoring: A linguistics-based approach

Jintae Kim a,*, Sooyong Park a, Vijayan Sugumaran b

a Department of Computer Science, Sogang University, Sinsu-Dong, Mapo-gu, Seoul 121-742, Republic of Koreab Department of Decision and Information Sciences, Oakland University, Rochester, MI 48309, USA

Received 19 May 2005; accepted 19 May 2005Available online 24 June 2005

Abstract

Use case driven analysis does not facilitate effective requirements elicitation or provide rationale for thevarious artifacts that get generated during the requirements analysis phase. On the other hand, goal andscenario based approach is considered to be effective for elicitation but it does not lead to use cases. Thispaper discusses how to combine goal and scenario based requirements elicitation technique with use casedriven analysis using natural language concepts. In our proposed approach, four levels of goals, scenarioauthoring rules, and linguistic techniques have been developed to identify use cases from text based goaland scenario descriptions. The artifacts resulting from our approach could be used as input to a use casediagramming tool to automate the process of use case diagram generation.� 2005 Elsevier B.V. All rights reserved.

Keywords: Goal and scenario based requirements; Linguistic techniques; UCDA method

1. Introduction

One of the most popular analysis methods in requirements engineering is the use case drivenanalysis (UCDA) method [1]. It helps us to cope with the complexity of the requirements analysis

0169-023X/$ - see front matter � 2005 Elsevier B.V. All rights reserved.doi:10.1016/j.datak.2005.05.006

* Corresponding author.E-mail addresses: [email protected] (J. Kim), [email protected] (S. Park), [email protected] (V.

Sugumaran).

mailto:[email protected]



22 J. Kim et al. / Data & Knowledge Engineering 58 (2006) 21–46

process. By identifying and independently analyzing different use cases, we may focus on onenarrow aspect of the system usage at a time. Since the idea of UCDA is simple, and the use casedescriptions are based on concepts that can be found in the problem domain, the customers andthe end users can actively participate in requirements analysis. Consequently, developers can learnmore about the users, their actual needs, and their typical behaviors [1]. However, the lack of sup-port for a systematic requirements elicitation process is probably one of the main drawbacks ofUCDA. This lack of elicitation guidance in UCDA sometimes results in an ad hoc set of use caseswithout any underlying rationale. On the other hand, if one knows the origin of each use case, onecould capture the requirements more completely through UCDA. Our current research addressesthe issue of lack of elicitation support in UCDA by using goal and scenario modeling. Thus, theobjective of this paper is to develop an approach for use case analysis that makes use of goal andscenario authoring techniques using natural language processing concepts. Our contribution is anapproach to enhance the elicitation of requirements in the context of use case driven analysis. Ourapproach uses goal and scenario modeling, which have been recognized as important facilitatorsfor identifying system requirements [2,3].

Goal modeling is an effective way to identify requirements [2,4–7]. The main emphasis of goaldriven approaches is that the rationale for developing a system is to be found outside the systemitself in the enterprise in which the system shall function [8,9]. A goal provides a rationale forrequirements, i.e., a requirement exists because of some underlying goal, which provides the basisfor it [4,10,11]. Recently, some proposals have been made for integrating goals and scenarios. Theimpetus for this is the notion that by capturing examples and illustrations, scenarios can help peo-ple in reasoning about complex systems [12].

Cockburn [13] was the first to suggest combining use cases with other concepts. He proposedthe use of goals to structure use cases by connecting every action in a scenario to a goal. However,Cockburn�s approach is only concerned with the description of scenarios in a use case. Ralyteet al. [14] integrated scenario based techniques into existing methods. This led to some enhance-ment of use case modeling within Jacobson�s object oriented software engineering (OOSE) [15].However, Ralyte�s approach does not provide any rationale for identifying use cases, i.e., it cannotreflect where the use cases come from. Finally, these approaches do not support both require-ments elicitation and requirements analysis. Little is known about supporting the elicitation pro-cess in UCDA. In this paper, we present an approach that supports deriving use cases from goalmodeling through authoring scenarios. Especially, a linguistics-based technique for scenarioauthoring, and goal modeling with different levels is proposed to complement the elicitation pro-cess within UCDA. Our aim is to provide a supplementary elicitation process, which helps ahuman engineer to analyze the system with UCDA through goal and scenario modeling. Fig. 1depicts an overview of our approach.

Three artifacts (goal and scenario levels, scenario authoring rules, and transfer rules) and twoactivities (goal and scenario modeling and use case transfer) constitute our approach. Goal andscenario levels are refined from Rolland�s proposal [3,16]. We have derived those levels by sepa-rating the concerns in requirements elicitation related to Business, Service, Interaction, and Inter-nal aspects. Scenario authoring rules help to identify requirements through goal and scenariomodeling. These rules provide a scenario authoring template hSubject, Verb, Target, Directioni,which helps users to create scenarios in a systematic fashion. Transfer rules enable us construct ause case diagram from the artifacts created through goal and scenario modeling.

Goal and Scenario levelBusiness

ServiceInteraction

Internal

Separation of concernsGoal & Scenario modeling

ScenarioAuthoring Rules

<Subject + Verb + Target + Direction>

Systematicguideline

<Goal, Scenario>

elicit

represented

Transfer rules

<Goal, Scenario>→ <Actor, Use case>

Use case Transfer

Use case diagramSystematic guideline

elicited

:artifact :activity

Fig. 1. Overview of our approach.

J. Kim et al. / Data & Knowledge Engineering 58 (2006) 21–46 23

Our approach consists of the following two main activities: (a) goals and scenarios are gener-ated for each goal and scenario level, and (b) transfer rules are used to transform the scenariosinto a use case diagram. When scenarios achieving a goal are authored, they are generated usingscenario authoring rules outlined in this paper. Goal and scenario authoring activity is highly iter-ative that results in a successively refined set of goals and scenarios. The output of the higher levelbecomes input to the immediate lower level, thus yielding a hierarchy of goals and scenarios withvarious levels. The requirements (actually represented as goals and scenarios) elicited correspond-ing to each level is represented by a Use case diagram created using the transfer rules. Essentially,our approach bridges the gap between the goal and scenario modeling research and the traditionaluse case driven analysis within requirements engineering.

Three characteristics exemplify our approach and contribute to the objective of systematicallygenerating use case diagrams from goal and scenario modeling. First, we employ different levels ofabstraction for goal and scenario (AL). Based on [3] as well as [16], we classify hGoal, Scenarioipairs into business, service, system interaction, and system internal levels. As a result, goals andscenarios are organized in a four level abstraction hierarchy. This hierarchy-based approach helpsseparate concerns in requirements elicitation and goal refinement. Second, we utilize scenario-authoring rules. Scenarios are very familiar to users. However, scenario authoring is ambiguousto users and it is not easy to articulate requirements through scenarios because there are no rulesto author scenarios. Scenario authoring rules help to elicit requirements from goals and they arevery useful to users and developers alike. Since these rules provide a template and constraints forauthoring, even users or developers not familiar with scenario authoring can obtain the require-ments without special exercises.

Third, we utilize transfer rules for mapping goal and scenario to actor and use case. These rulesguide the user to identify actors and use cases. There are two key notions embodied in the transferrules. The first idea is that each goal at the interaction level is mapped to a use case because thescenarios, which achieve the goal at this level, are represented as �the interactions between the sys-tem and its agents (external entities but not the system). This definition is similar to use case�s


definition. The second idea is that each scenario achieving a goal at this level describes the flow ofevents in a use case. Therefore, this idea signifies that the rationale for use cases is founded ongoals, which are derived through scenarios. To put it more concretely, when modeling a use casediagram, analysts generally construct use cases and actors based on the raw requirements andtheir own past experience. Consequently, it is difficult to articulate why certain use cases and ac-tors have been included into the use case diagram because the whole process is mostly driven bythe analysts� prior knowledge. For example a typical ATM system has the following use cases:�Cash withdraw�, �Deposit�, �Transfer�, and �Inquiry�. Why does an ATM system need these usecases? Prior approaches cannot show why these use cases are actually needed in an ATM system.However, our approach shows why an ATM system needs these use cases because they are neededto achieve the Business goal ‘‘Provide advanced ATM services to our bank customers’’. Thus ourapproach can provide the rationale for use cases that would be useful for both the users and thedevelopers.

The remainder of the paper is structured as follows. The abstraction levels for goal and scenariomodeling are described in the next section. Goal and scenario modeling based on linguistic tech-niques is presented in Section 3. Section 4 deals with use case transfer. Section 5 illustrates ourapproach using the hotel reservation system (HRS) example. The concluding section sums upthe essential characteristics of our approach and the contributions of this paper.

2. Four abstraction levels of goal and scenario

Four abstraction levels of goal and scenarios (AL) help separate concerns in requirements elici-tation. Prior research has proved the usefulness of multiple levels of abstractions. For example,Nurcan et al. [17] have applied a multi-level approach to the ELEKTRA real world case. Theirproposal is about an approach supporting the construction of business process (BP) specifications.A BP specification takes the form of a use case comprising of information about the context of theBP, the interactions between the agents involved in the BP, the interactions of these agents with acomputerized system supporting the BP and a set of internal system requirements. They proposedthree levels for describing business processes as follows: organizational interactions level, systeminteraction level, and system internal level. We add the highest level namely business level to Nur-can�s levels. Thus in this paper, we propose a four level abstraction hierarchy, organized as busi-ness, service, interaction, and internal level. Goal modeling is accompanied by scenarioscorresponding to each of the abstraction levels. A goal is created at each level and scenariosare generated to achieve the goal. This is a convenient way to elicit requirements through goalmodeling because these levels make it possible to refine the goals [3,4]. The four abstractions levelsof goal and scenario modeling are discussed below.

2.1. Business level

The aim of the business level is to identify the ultimate purpose of a system. At this level, theoverall system goal is specified by the organization or a particular user. For example, the businessgoal �Improve the services provided to our bank customers� is an overall goal set up by the bank-ing organization.


2.2. Service level

The aim of the service level is to identify the services that a system should provide to an orga-nization and their rationale. At this level, several alternative architectures of services are postu-lated and evaluated. All of them correspond to a given business goal. Goals and scenarios inservice level are represented as a pair hG, Sci where G is a design goal and Sc is a service scenario.A design goal expresses one possible manner of fulfilling the business goal. For example, the de-sign goal �Cash withdraw� is one possible way of satisfying the business goal �Improve the servicesprovided to our bank customers�. A service scenario describes the flow of services among agents,which are necessary to fulfill the design goal. For example, the service scenario �The customerwithdraws cash from the ATM� implements the design goal �Cash withdraw�.

2.3. Interaction level

At the system interaction level the focus is on the interactions between the system and itsagents. Goals and scenarios at this level are represented as a pair hG, Sci where G is a service goaland Sc is an interaction scenario. These interactions are required to achieve the services assignedto the system at the service level. The service goal �Withdraw cash from ATM� expresses a mannerof providing a service. Interaction scenario describes the flow of interactions between the systemand agents. For example, the interaction scenario �The ATM receives the amount from user�implements the service goal.

2.4. Internal level

The internal level focuses on what the system needs to perform the interactions selected at thesystem interaction level. The �what� is expressed in terms of internal system actions that involvesystem objects but may require external objects such as other systems. At this level, goals and sce-narios are represented as a pair hG, Sci where G is an interaction goal and Sc is an internal sce-nario. For example, �Deliver cash to the user� is an interaction goal. The associated internalscenario describes the flow of interactions among the system objects to fulfill the interaction goal.

3. Goal and scenario modeling

This section discusses goal and scenario modeling specific to each abstraction level and therelated concept of goals and scenarios. Then, the scenario-authoring rules are discussed.

3.1. The concept of goal and scenario

A goal is defined as ‘‘something that some stakeholder hopes to achieve in the future’’ [3,4,9]. Ascenario is ‘‘a possible behavior limited to a set of purposeful interactions taking place among sev-eral agents’’ [18]. Clearly, a goal [19] is associated to a verb and to one or more parameters, whereeach parameter plays a different role with respect to the verb. In this paper, a goal is described as atemplate hV + Target + Directioni, where V is an active verb, Target is a conceptual or a physical


object, and Direction is either source or destination. For example, the goal, �Withdraw cash fromthe ATM� is represented as follows:

ð‘WithdrawÞVerbðCashÞ

TargetðFrom the ATMÞ

Dir’:

The scenarios capture real requirements since they describe real situations or concrete behav-iors, and goals can be achieved through the execution of scenarios. Thus, scenarios have theirgoals, and typically, goals are achieved by scenarios. In other words, just as goals can help in sce-nario discovery, scenarios can also help in goal discovery. As each individual goal is discovered, ascenario can be authored for it. Once a scenario has been authored, it can be explored to yieldfurther goals [4,8].

3.2. Scenario authoring model

As stated earlier, one can think of scenario-authoring rules as a set of guidelines that help gen-erate scenarios. They are based on linguistic techniques concepts. First, we briefly discuss the sce-nario structure and then the scenario authoring rules. Our scenario structure is an extension of[3,20].

3.2.1. The scenario structureSince a goal is intentional and a scenario is operational by nature, a goal is achieved by one or

more scenarios. A scenario is associated with one or more states, which consist of preconditionand post-condition. Precondition describes a necessary condition that is required for scenariosto be implemented. Post-condition shows the result after scenarios are implemented. Scenariostructure is a template, which enables us to describe scenarios for the goal. Fig. 2 shows thatour scenario structure is composed of several components that are analogous to parts of speech,i.e., elements of a sentence.

A scenario is associated with a subject, a verb and one or more parameters (multiplicity isshown by a black dot). It is expressed as a clause with a subject, a main verb, and several para-meters, where each parameter plays a different role with respect to the verb. There are two types of

Action

Subject Verb

Parameter

Target Direction

1

11 1

1

1+

Agent Activity Object Source

Destination

Normal Scenario Exceptional Scenario

Scenario State1

1+

Goal achieve1 1+

1+Precondition

Post condition

Fig. 2. The scenario structure.


parameters, namely, Target and Direction. The main components of the scenario structure are de-scribed with an ATM example. The agent (Agent) is responsible for a given goal and implementsan activity as an active entity. An actor or the system in the sentence can be the agent: for examplein the scenario, �(The user)Agent inserts card into ATM�. The activity (Act) is the main verb. Itshows one step in the sequence of scenarios. The target (Tar) designates entities affected by theaction. Generally a target is instantiated by object (Obj). The object (Obj) is conceptual or a phys-ical entity which is changed by activities: for example, �The Customer deposits (cash)Obj to theATM�. An object has several properties such as ownership, place, status, amount, etc., whichcan be changed by activities. The direction (Dir) is an entity interacting with the agent. Thetwo types of directions, namely source (So) and destination (Dest) identify the initial and finallocation of objects to be communicated with, respectively. For example, consider the two scenar-ios given below:

�The bank customer withdraws cash from the ATM(So)�,�The ATM reports cash transactions to the Bank(Dest)�.

In the first scenario, the source of cash is the ATM, and in the second, the Bank is the desti-nation of the cash transactions.

3.2.2. Scenario authoring rulesBased on the structure of a scenario, we propose the following scenario-authoring rules. We

have developed a domain analysis approach to identify common authoring patterns and their con-straints. The formalization of these patterns results in the current set of authoring rules. In thissection, each rule is introduced using the following template hDefinition, Comment, Examplei.The definition explains the contents of the rule. The comment is expressed as items to be consideredwhen applying the rule. The example component shows a representative example (we show anexample from the ATM domain).

Scenario authoring rule 1 (S1)Definition: All scenarios should be authored using the following format.�Subject :Agent + Verb + Target :Object + Direction:(Source, Destination)�.Comment: The expected scenario prose is a description of a single course of action. This course

of action should be an illustration of fulfillment of your goal. You should describe the course ofactions you expect, not the actions that are not expected, impossible, and not relevant with regardto the problem domain.

Although these rules may be perceived to be a bit simplistic, they are sufficient to proceed withmodeling goals and scenarios. The indirect objects can be filled in the slot of Direction. Forexample, �Tom gives me a book� can be rewritten, according to our rules as, �(Tom)Agent (gives)Verb

(a book)Object (to me)Direction�.Example: (The customer)Agent (deposits)Verb (cash)Obj (to the ATM)Dest.

Scenario authoring rule 2 (S2)Definition: �Subject� should be filled with an Agent.Comment: The agent has the responsibility to fulfill a goal and it may be a human or machine,

for example, the designed system itself, an object, or a user.Example: (ATM)Agent sends a prompt for code to the user.


Scenario authoring rule 3 (S3)Definition: �Verb� should include the properties stated at requirements levels.Comment: �Verb� should express either the service at service level or the interaction at the inter-

action level as a transitive verb.Example: The customer (withdraws)Verb cash from the ATM (service scenario).The ATM (displays)Verb a prompt for amount to the user (interaction scenario).

Scenario authoring rule 4 (S4)Definition: �Target� should be an object.Comment: The object is a conceptual or physical entity. It can be changed by a �Verb�. The

change to an object may happen with one or more of its properties such as ownership, place, sta-tus, and amount.

Example: The ATM delivers (the cash)Obj to the user.

Scenario authoring rule 5 (S5)Definition: �Direction� should be either source or destination.Comment: The two types of directions, namely source and destination identify the origin and

destination objects for communication. The source is the starting point (object) of the communi-cation and the destination is the ending point of the communication (object). Sometimes, thesource has preposition such as �from�, �in�, �out of�, etc. The destination has preposition such as�to�, �toward�, �into�, etc.

Example: The bank customer withdraws cash (from the ATM)So.

Scenario authoring rule 6 (S6)Definition: The designed system and the other agents are used exclusively in instantiating the

Subject and Direction constructs.Comment: If the system is used to fill the subject slot, the other agents such as human, machine,

or an external system should be used to fill the direction slot. Thus, the other agents interactingwith the system should be treated as candidate actors.

Example: (The bank customer)Agent withdraws cash (from the ATM)So.

3.3. Goal and scenario modeling process

Goal and scenario modeling is carried out corresponding to each of the abstraction levels.Fig. 3 shows the structure of the overall goal and scenario modeling process.

As shown in Fig. 3, at first a business goal is specified by the organization. In general, a businessgoal represents the directional value of the organization. A Business goal is specified to captureone or more service goals. Service goals are implemented by service scenarios. Service scenarios,in turn, yield interaction goals. For each interaction goal, interaction scenarios are authored. Byexamining these interaction scenarios, internal goals can be generated. Again, each internal goal isaccomplished through the corresponding internal scenarios that can be authored. Thus, the pro-cess of identifying goals at each level and authoring scenarios to achieve these goals is imple-mented repeatedly from the service level to the internal level. During this process, specificrequirements are identified by goals and scenarios.

Business goal

given

Service goalService

Scenarios

refined

Interactiongoal

InteractionScenarios

yield

Internalgoal

InternalScenarios

yield

author

author

author

Fig. 3. The structure of goal and scenario modeling process.


Table 1 and Fig. 4 show goals and scenarios created for the various requirement levels and thescenario authoring model for the ATM example. A scenario consists of actions and states and theflow of actions shows the system�s behavior. The states show necessary conditions for the actionsto be fired. As shown in Table 1, the interaction goal, g1.1 has eight actions and four states. All of

Table 1ATM example of rules S1–S6

Level Goals Scenarios

Service Cash withdrawal (g1) 1. The customer withdraws cash from the ATM2. The ATM reports cash transactions to the bank

Interaction Withdraw cashfrom ATM (g1.1)

1. The ATM receives a card from the user (action)

If the card is valid, then (state)

2. ATM sends a prompt for code to the user (action)

3. The ATM receives the code from the user (action)

If the code is valid, then (state)

4. The ATM displays a prompt for amount to the user (action)

5. The ATM receives the amount from the user (action)

If the amount is valid, then (state)

6. The ATM ejects the card to the user (action)

If the user asked the ATM to supply a receipt, then (state)

7. The ATM ejects the printed receipt to the user (action)

8. The ATM delivers the cash to the user (action)

Internal Check the validity ofcard (g1.1.1)

1. The ATM engine asks the card readerto read the validity date and the card number

2. The card reader returns the card number andvalidity date to the ATM engine

3. The ATM engine transmit the card number and validity date to bank4. The ATM receives the result of card validity from bank

Fig. 4. Partial goal hierarchy with the abstraction levels for ATM example.


the actions show interactions between the designed system itself (ATM) and an agent (user). Ingeneral, a state at interaction level can become a goal at the lower level (i.e., internal level),and the scenarios corresponding to that goal describe the state in more detail. In Table 1, forexample, the state �If the card is valid� becomes the internal goal �Check the validity of Card(g1.1.1)� (as shown in Fig. 4), with corresponding scenarios. The internal behavior of the systemconcerning �If the card is valid� is described by g1.1.1 and scenarios corresponding to g1.1.1.

Fig. 4 presents a partial goal hierarchy for the ATM example with different abstraction levels. Ithas been generated by applying the goal and scenario modeling technique discussed in [3,9]. Due tospace limitation, we have not provided all the Business Level goals for the ATM example. In Fig. 4,Goals are represented by solid rectangles. The goal with bold rectangle has more than one parentgoal. The relationships among goals can be �AND� relationship or �OR� relationship. For example,there is an �AND� relationship between g1.1 and g1.2, as they achieve �g1� together. Fig. 4 does notshow all of the goals in the ATM example; it shows only the tree concerning g1 and g2. In fact, thegoal g3 (�Transfer�) has child goals such as �Transfer amount to another account� and �Report trans-action�. Similarly, the goal g4 (�Inquiry�) also has child goals such as �Inquiry amount of account�,�Report transaction�. As shown in Fig. 4, g1.2 �Report transaction� is a child of all service goals.

4. Use case transfer

In Section 3.2, a scenario authoring model was proposed to improve the elicitation of therequirements through goals. This section describes how the elicited requirements are used tomodel use cases. It also shows a way to overcome the lack of elicitation support within UCDA.


For use case identification, we propose a relationship model in conjunction with use case conver-sion rules from goals and scenarios.

The core idea is that the goals and scenarios at the interaction level are used to help constructuse cases. A goal at the interaction level is achieved by scenarios and a use case contains the set ofpossible scenarios to achieve that goal. This is due to the fact that, in our approach, the interac-tion level focuses on the interactions between the system and its agents. The purpose of the usecase specification is to describe how the agent can interact with the system to get the serviceand achieve his/her goal. Therefore, we propose the following relationship diagram (shown inFig. 4) that captures the association between the agents, goals, scenarios and use cases. InFig. 4, an actor is derived from all the agents that interact with the system. An actor has oneor more goals, which he/she wants to achieve by interacting with the system. In the ATM exam-ple, let us assume that a user (one of the actors) desires to withdraw cash from the ATM. Thus,the user as an actor has his/her own goal, �Withdraw cash from ATM�. A goal generally representsthe high level objective in requirements. A goal is represented as an assertive sentence. When realsystems are developed, we need to determine how the goal can be achieved and implemented. Thescenarios can explain how to implement the goal by the flow of events or actions and, hence, sce-narios can achieve the goal.

In our approach, a goal is mapped to a use case. This means that a goal is transformed into ause case for a chunk of the functional requirements of the system (as stated above, the interactiongoal is used to create a use case). The use case contains the scenario achieving that goal.

After analyzing each use case, it is augmented with internal activity elements of software-to-be.In our approach, goal and scenario at the internal level represent the internal behavior of the sys-tem under consideration to achieve the goals of the interaction level. Accordingly, use cases can beperformed by achieving goals at the internal level, and completed by integration of scenarios atthat level. We also propose several guiding rules for the use case conversion using the same tem-plate as scenario authoring rules. We restrict the example to the service level goal (e.g.: g1 of theATM example).

Transfer guiding rule 1 (T1)Definition: Goals listed at the interaction level become use cases in accordance with Fig. 5.Comment: As mentioned above, goals at interaction level are mapped to use cases. The use

cases are named after the goals they correspond to.

Fig. 5. Relationships between goal and other artifacts.


Example: For the goal, g1, goals at the interaction level for ATM example are as follows:

�Withdraw cash from ATM�,�Report the transaction�.

These goals become use cases with appropriate descriptions.

Transfer guiding rule 2 (T2)Definition: Agents included in scenarios within a goal and wanting to achieve a goal become

primary actors.Comment: A goal is achieved by scenarios and several agents may be found in scenarios. As

discussed in scenario authoring rules, agents are used to instantiate either subject or direction ob-jects. Therefore, agents in subject or direction are all treated as actors except the system that iscurrently being designed.

Example: Fig. 6 shows the actors that are found in scenarios within goal g1.1 (withdraw cashfrom ATM) of the ATM example. Sc1.1 has eight actions. All agents corresponding to the direc-tion in all the actions are described as �user�. Thus, in case of Sc1.1, �user� becomes an actor.

Transfer guiding rule 3 (T3)Definition: The States contained in scenarios at the interaction level are mapped to internal

goals at the internal level.Comment: The state represents necessary conditions for actions to be fired. They can be repre-

sented as internal goals at the internal level. Thus, when specifying a use case, we can find moredetails about states in a goal and scenario at the internal level.

Example: The state, �If the card is valid�, of Sc1.1 is described in the sub goal (g1.1.1), �Check thevalidity of card� at internal level. The scenarios corresponding to g1.1.1 will also show more detailsabout the state �If the card is valid�.

Fig. 6. ATM example of finding actors through scenario structure.

Fig. 7. Use case diagram for the ATM example.


Transfer guiding rule 4 (T4)Definition: If goals at internal level have more than two parent goals, they become another use

case with the �include� relationship.Comment: Because include relationship helps us to identify commonality, a goal at internal level

with more than two parent goals becomes a use case with hincludei relationship.Example: In Fig. 4, the goal, �Check the validity of card�, has two parent goals, namely, �With-

draw cash from ATM� and �Deposit cash into ATM�. Therefore, the goal, �Check the validity ofcard �, can become a use case with hincludei relationship.

Fig. 7 shows the use case diagram for ATM application generated by applying the conversionrules T1 through T4. It contains two actors, namely, User and Bank and six use cases. The usecases associated with the user are Withdraw, Deposit, Transfer and Inquiry. These use cases in-clude the Check Validity use case, which is associated with the bank along with the Report usecase.

5. Case study: hotel reservation system (HRS)

To evaluate our approach, we applied it to some real-world projects such as automatic tellermachine (ATM), meeting reservation system (MRS) and hotel reservation system (HRS). Oneof these case studies, namely, HRS, is used to illustrate the approach below.

The hotel reservation system manages information about rooms, reservations, customers, andcustomer billing. The following are some of the typical requirements of a reservation system. Thesystem provides functionality for making reservations, check in, and check out, in addition to gen-erating reports and displays. A customer may make reservations, change, or cancel reservations.When making a reservation through a reservation clerk, a customer gives personal details, statesthe room type, number of occupants, and dates of arrival and departure. A reservation is eitherguaranteed by credit card or not guaranteed. Reservations that are not guaranteed are automat-ically cancelled at a pre-specified time, e.g. 6 PM. A no-show customer has to pay for a guaranteedreservation. A desk clerk can check in a customer (with or without a prior reservation), change thecheckout date, and check out the customer. A specific room is assigned to the customer at check-in time and a customer record is created. A customer may pay by cash, check, or credit card. A


customer billing record is created and the customer receives a check out statement. A customerwho does not check out by the checkout time is charged for an additional night. Additionally,the manager may view the hotel occupancy figures for the present or past dates, view projectedoccupancy figures for future dates, and view financial information, including room revenue infor-mation, etc.

Our approach has been applied to the HRS example and each of the steps within our approach,namely, goal and scenario modeling and use case transfer is briefly explained in the followingsections.

5.1. Goal and scenario modeling

First of all, we must define the business goal that would be appropriate for the organization.Typically, a business goal represents the direction, purpose, and objective of the organization.In the HRS example, let us assume that the business goal, �Manage the Hotel Reservation� isthe main objective that needs to be achieved. This business goal is refined corresponding to eachlevel discussed in Section 2. Based on the requirements of HRS, the business goal has two sub-goals, which are as follows: �Handle Hotel Reservation (g1)� and �Report information (g2)�, whichare service goals at the service level. The service goal g1 shows a service associated with the coreactivities of Hotel Reservation. On the other hand, g2 describes a service associated with the op-tional activities of the system itself. This distinction is dependent on the business policies, domainexperts, or the related stakeholders. Table 2 shows the outputs generated through the goal andscenario modeling activity for the HRS example. The scenarios have been authored by applyingthe scenario authoring rules S1 through S6. At the completion of the goal and scenario modelingactivity, two service goals, seven interaction goals, and nine internal goals have been generated.These goals are achieved by their corresponding scenarios, shown in Table 2. For example, theinteraction goal (g1.1) has four scenarios that try to achieve this goal. The outputs are generatedbased on the knowledge of domain expert and goal and scenario modeling with abstraction hier-archy levels.

As indicated earlier, the goal �Manage the Hotel Reservation� was specified as the business goal.This business goal has two corresponding service goals. Each of the service goals has associatedscenarios, which are generated in order to achieve the corresponding goals based on the businessstrategy, marketing plan, and so on. The service goal �Handle Hotel Reservation (g1)� is achievedby several service scenarios as follows: �A Customer makes Hotel Room Reservation�, �A customerchanges Hotel Room Reservation�, �A customer cancels Hotel Room Reservation�, �A clerk han-dles Hotel Check-in in HRS�, and �A clerk handles Hotel Check-out in HRS�. In this example, it isassumed that these five service scenarios are sufficient to satisfy the service goal (g1). Typically, thenumber of scenarios that are generated to achieve their goal is dependent on the knowledge of thedomain expert, business strategy, and marketing plan. When generating service scenarios, sce-nario authoring rules are used. As shown in Fig. 3, Service scenarios yield interaction goals atthe next level. When each of the service scenarios becomes an interaction goal, all goals, as wellas interaction goals are described using the format of a goal template hV + Target + Directioni asindicated in Section 3.1. In Table 2, the interaction goals related to �Handle Hotel Reservation(g1)� are as follows: �Make Hotel Room Reservation (g1.1)�, �Change Hotel Room Reservation(g1.2)�, �Cancel Hotel Room Reservation (g1.3)�, �Handle Hotel Check-in in HRS (g1.4)�, and

Table 2Outputs of goal and scenario modeling in HRS example


Service Handle Hotel Reservation (g1) 1. A customer makes Hotel Room Reservation2. A customer changes Hotel Room Reservation3. A customer cancels Hotel Room Reservation4. A clerk handles Hotel Check-in in HRS5. A clerk handles Hotel Check-out in HRS

Report Information (g2) 1. Manager views the Hotel occupancy figures2. Manager views financial information

Interaction Make Hotel Room Reservation (g1.1) 1. A clerk enters customer�s personal details into HRSIf personal information is valid

2. A clerk enters customer�s reservation informationto HRSIf reservation information such as room

and date is available

3. A clerk enters credit card information into HRSIf credit card is valid

4. HRS confirms the reservation to customer and clerkChange Hotel Room Reservation (g1.2) If the customer has reservation

1. A clerk enters customer�s new room number into HRS2. HRS confirms the output of change to customer

and clerkCancel Hotel Room Reservation (g1.3) If the customer has reservation

1. A clerk asks HRS to cancel customer�s reservation2. HRS confirms the output of cancellation to clerk

Handle Hotel Check-in in HRS (g1.4) If the customer has reservation1. A clerk identifies the customer through HRS

If the customer has reservation before 6 PM

2. HRS assigns a room to customer

Handle Hotel Check-out in HRS (g1.5) If the customer checked in before1. HRS releases the room from the customer2. HRS generates the customer bill

View Hotel occupancy figure (g2.1) 1. Manager enters his or her id and password to HRSIf id and password are valid

2. Manager clicks �View occupancy figures�3. HRS displays the occupancy figures to manager

View financial information (g2.2) 1. Manager enters his or her id and password to HRS.If id and password are valid

2. Manager clicks �View financial information�3. HRS shows the financial information to manager

Internal Store the personaldetails (g1.1.1)

1. The Data Receiver gets the personal informationfrom keypad

2. The Data Receiver sends the personal informationto Reservation Controller

3. Reservation controller sends the personal informationto DBHandler

4. DBHandler inserts the personal informationinto Data base

(continued on next page)


Table 2 (continued)


Store the reservationinformation (g1.1.2)

1. The Data Receiver gets the reservationinformation such as room, arrival date,departure date from keypad

2. The Data Receiver sends the reservation informationto Reservation Controller

3. Reservation Controller sends the reservationinformation to DBHandler

4. DBHandler inserts the reservation information intoData base

Validate the creditcard (g1.1.3)

1. The Reservation Controller asks Card reader to readthe card number and the expiration date

2. The card reader returns the card number and theexpiration date to the Reservation Controller

3. The Reservation Controller asks the current dateto the clock

4. The clock transmits the current date to theReservation ControllerIf the card number is well formed and the

validity date is not expired

5. The Reservation Controller asks the Banking systemif the card number is not on the red list

6. The banking system returns to the ReservationController that the card number is (or is not)on the red listIf the card number is not on red list

The Reservation Controller returns to Screenhthe card is validi

Identify the customerthrough HRS (g1.4.1)

1. The Data Receiver gets the personal profilefrom keypad

2. The Data Receiver sends the personal informationto Reservation Controller

3. Reservation Controller returns whether customerhas a reservation or not

Manage rooms(g1.4.2)

1. Reservation Controller assigns rooms to customersIf Customer is satisfied

2. Reservation Controller sets the room to customer3. Reservation Controller sends arrival date to a

Time CounterGenerate customerbill (g1.5.1)

1. Reservation Controller asks the Time Counter todetermine the duration of stay

2. A Time Counter returns the time duration toReservation Controller

3. Reservation Controller asks the Billing system tocalculate the charge

4. The Billing System returns the Hotel charge toReservation Controller


Table 2 (continued)


Validate the id andpassword (g2.1.1)

1. The Data Receiver gets the Manager�s id andpassword from keypad

2. The Data Receiver asks the Authenticator tovalidate the inputsIf the inputs are valid

3. The Authenticator returns the�valid id and password�

Generate occupancy figures (g2.1.2) 1. Reservation Controller asks the statistics module togenerate occupancy figures

2. The Statistics module returns the occupancy figures toReservation Controller

Make financial information (g2.2.1) 1. Reservation Controller asks the statistics module togenerate financial information

2. The Statistic module returns the financial informationto Reservation Controller


�Handle Hotel Check-out in HRS (g1.5)�. Interaction scenarios, internal goals, and internal sce-narios are generated in the same way.

Fig. 8 depicts the goal hierarchy with the abstraction levels for HRS example. Especially somegoals have more than two parent goals. For example �Store personal details (g1.1.1)� achieves g1.1,g1.2, and g1.3. This means that g1.1.1 can be involved in g1.1, g1.2, and g1.3.

5.2. Use case transfer

Based on the outputs generated through goal and scenarios modeling in Section 5.1, a use casediagram is constructed using the use case transfer rules. Since interaction goals become use casesaccording to rule T1, the following use cases are identified: �Make Hotel Room Reservation�,�Change Hotel Room Reservation�, �Cancel Hotel Room Reservation�, �Handle Hotel Check-in�, �Handle Hotel Check-out�, �View Hotel occupancy figure�, and �View financial information�.Moreover, five additional use cases are identified based on rule T4: �Store personal details�, �Storereservation information�, �Validate credit card�, �Identify the customer�, and �Validate the id andpassword�. These use cases are involved in more than two use cases. Therefore these five use caseshave the stereo type with �Include� relationship. Actors corresponding to each use case are derivedby rule T2. Table 3 describes how actors can be derived from agents through rule T2.

In a use case diagram, the system is treated as a ‘‘black box’’. Use cases capture who (actor)does what (interaction) with the system, and for what purpose (goal), with out dealing with thesystem internals. Thus the interactions of the system are dependent on the purpose of the system.For example, in Fig. 8, there are two service goals, namely, �Handle Hotel Reservation (g1)� and�Report Information (g2)�. G1 is about Hotel Reservation service. G2 is concerned with reportingof information. The reason why g2 is strictly enforced is because the organization understandsthat it is important to report information. The goals at the interaction level such as g2.1 andg2.2 are also generated to correspond to their super goal, namely, g2. Consequently, the use casesrelated to g2.1 and g2.2 are constructed. If it is not important to report information, g2 would not

Table 3The derivation of actors from agents using rule T2

Use case name Actors Explanation

Make Hotel Room Reservation Clerk (Customer) Clerk fills the slot of �subject� as well as �Direction�.He/she also acts intentionally. Sometimes, Clerk acts asthe agent of the Customer

Change Hotel Room ReservationCancel Hotel Room ReservationHandle Hotel Check-inHandle Hotel Check-out

View Hotel occupancy figure Manager Manager fills the slots of �subject� and �Direction�View financial information

Store the personal details Keypad Keypad fills the slot of �Direction�Store the reservation informationIdentify the customerValidate the id and password

Validate the credit card Bank Bank fills the slots of �subject� and �Direction�

Fig. 8. The goal hierarchy with the abstraction levels for HRS example.


be relevant, and hence, g2.1 and g2.2 will not be generated. Thus, the use cases concerning report-ing information will not be created. Eventually goals provide the rationale for use cases becausethere is traceability between goals and use cases.

Fig. 9. Use case diagram for HRS example.


Based on the actors and the use cases identified in Table 3, the following use case diagram forHRS is constructed, as shown in Fig. 9.

Some times all of the use cases and their relationships are not generated automatically. A com-plicated use case diagram needs the domain expert�s experience and knowledge. The detailed tex-tual specification of a use case is not, for instance, generated fully by our approach. For example,there is no�extend� relationship currently included in our methodology. We will describe it inmore detail in the discussion section. This is dependant on the domain expert�s experience andknowledge. Nevertheless, our approach helps overcome the lack of support for the elicitation pro-cess in UCDA and the rationale, when initializing use case diagrams.

6. Empirical validation and discussion

In order to evaluate the applicability and usefulness of our approach, we conducted preliminaryempirical validation experiments. Graduate students in computer science at a major universityparticipated in the experiment. Two separate experiments were conducted. Each experiment con-sisted of two parts. The first half of the experiment was devoted to training the students in ourmethodology and the second half consisted of the students working on a specific case i.e.,MRS (Meeting Reservation System) assigned to them. The student training included a discussionon the overall objectives of this research, a one-hour presentation explaining the nuances of ourapproach, a demonstration of the tool, and a sample interaction session with the tool by theparticipants.


The tool that supports our methodology has been developed based on the Java Virtual Machine1.4. The input to the tool is the text based goal and scenario description. The output from the toolis XML (extensible markup language) based use case specification, which can be shown as agraphical diagram in CASE tools such as Rational Rose (http://www-306.ibm.com/software/rational/) and Together (http://www.borland.com/together/). The tool consists of 4 tabs corre-sponding to the four levels of abstraction for goal and scenario. The tool supports scenarioauthoring rules and the use case transfer rules.

During the training phase, the automatic teller machine (ATM) and the hotel reservation sys-tem (HRS) cases were used and the students tried out the tool with these examples to gain anunderstanding of our methodology and how the tool functions. In the second half of the exper-iment, students were assigned the MRS case to solve.

The meeting reservation system is a system for the allocation of resources (e.g. rooms andequipment) within specified time-slots and requesting participants for meetings or other similaractivities. Resources are defined as being any kind of asset with a set of properties related to it.Persons invited to the meeting should be automatically notified and requested for response.

Students were asked to apply our methodology and eventually generate a use case diagram forMRS. The time taken by the participants to complete the MRS example was recorded. The outputgenerated from the experiment, namely, the use case diagram for the MRS case was then gradedfor correctness and completeness. At the end of the experiment, the participants were asked to fillout a questionnaire to provide feedback on our approach. The results extracted from these ques-tionnaires are summed up in Figs. 10 and 11. Participants were asked to grade the usefulness ofour linguistics-based approach on a scale of 0–6 (0: Strongly disagree, 1: Moderately disagree, 2:Somewhat disagree, 3: Neutral, 4: Somewhat agree, 5: Moderately agree, 6: Strongly agree). Theoverall score is presented in Fig. 10. It shows a quite high level of user satisfaction, which isencouraging. Fig. 11 shows how much our approach helps improve the understanding of require-ments. Especially goal and scenario abstraction level has proven to help understand the require-ments through goal and scenario modeling. This means that the abstraction levels are helpful toguide the requirements elicitation process, where other modeling approaches are quite weak. Usecase transfer rules also provide a high level of understanding of the requirements, which meansthat these transfer rules are very helpful in identifying and constructing use cases.

Goal and scenarioauthoring rules

Abstraction level Use case tranferrules

overall usefulness

usefulness

Fig. 10. Average grading of the usefulness.

http://www-306.ibm.com/software/rational/

http://www-306.ibm.com/software/rational/

http://www.borland.com/together/

Goal and scenarioauthoring rules

Abstraction level Use case tranfer rules

Understanding

Fig. 11. Understanding of requirements.


The participants indicated that they have 85% confidence in the correctness of use cases theygenerated. This means that when the participants created use cases and their specifications, theyare 85% confident that they have created a complete and correct set of use cases to satisfy the ori-ginal requirements of the users. Based on their experience in real world projects, when using ourapproach, they also estimated that it will take only 74% of the normal time that would take toanalyze requirements. In other words, the same project using our approach, will take only 74%of the analysis time compared to the project without our approach. For example, supposing thata particular project takes 100 days to analyze requirements of users, our approach will help ana-lyze the requirements within 74 days.

Positive statements were made regarding the contribution of our approach in transferring theoutputs of goal and scenario modeling to use case diagram. The linguistic technique for analysis,disambiguation and completion were found applicable to most of real situations where it is nec-essary to support the transformation of an informal scenario description written in full prose intoan unambiguous, complete, and well structured text. The predefinition of the four levels, namely,business, service, interaction, and internal was found useful in goal and scenario modeling. Final-ly, our approach was also found to be useful in requirements configuration management becausethe rationale for use cases have been identified previously through goal and scenario modeling.

The participants pointed out that the question of the �extend� relationship remained unset-tled. While this is a limitation, we are expanding our current approach to be able to incorporatethe�extend� relationship. Since our original scope was to help construct an initial version of theuse case diagram, it is reasonable to assume that our approach does not support the �extend�relationship automatically. We intended to handle the �extend� relationship initially throughthe textual specification of the use case.

7. Related works

Our approach is based on linguistic techniques. ORM [21] and Case grammar [22] aresomewhat similar to the techniques used in our approach. This section discusses ORM and Case


grammar briefly and the difference between our linguistic approach and them. We also compareour work to that of Fantechi et al. [26] which also uses linguistic techniques for use case analysis.

7.1. Object-role modeling (ORM)

Object-role modeling (ORM) is primarily a method for modeling and querying an informationsystem at the conceptual level. In Europe, this method is often referred to as natural languageinformation analysis method (NIAM) [21]. Since information systems are typically implementedwith a database backend that is based on a logical data model (e.g. relational, object-relational),ORM includes procedures for mapping between conceptual and logical levels. Although variousORM extensions have been proposed for process and event modeling, the focus of ORM is ondata modeling, since the data perspective is the most stable and it provides a formal foundationon which operations can be defined.

For correctness, clarity and adaptability, information systems are best specified first at the con-ceptual level, using concepts and language that people can readily understand. Analysis and de-sign involves building a formal model of the application area or universe of discourse (UoD). Todo this properly requires a good understanding of the UoD and a means of specifying this under-standing in a clear, unambiguous way. Object-role modeling simplifies this process by using nat-ural language, as well as intuitive diagrams that can be populated with examples, and byexpressing the information in terms of elementary relationships.

ORM pictures the world in terms of objects (entities or values) that play roles (parts in relation-ships). For example, you are now playing the role of reading, and this paper is playing the role ofbeing read. In contrast to other modeling techniques such as entity–relationship (ER) and object-oriented (OO) approaches, ORM makes no explicit use of attributes. For example, instead ofusing countryBorn as an attribute of Person, we use the relationship type Person was born inCountry. This has many important advantages. Firstly, ORM models and queries are more stable(attributes may evolve into entities or relationships). For example, if we decide to later record thepopulation of a country, then our countryBorn attribute needs to be reformulated as a relation-ship. Secondly, ORM models may be conveniently populated with multiple instances (attributesmake this too awkward). Thirdly, ORM is more uniform.

In our approach, we have proposed scenario authoring rules and use case transfer rules in orderto construct use case diagrams. As shown in Fig. 5, the relationship between all objects such asagent, actor, use case, scenario, and goal is constructed based on the concept of ORM, becauseORM represents the world in terms of objects that play roles in relationships. These relationshipsare the basis for use case transfer rules. While ORM is geared towards data modeling, the naturallanguage techniques used in our approach focus on the elicitation of requirements in terms of usecase.

7.2. Case grammar

Case grammar (case frames, case relations, or case theory) [22] describes the relationshipbetween a verb and the other components (typically nouns) of a single proposition. The basic ideaof case grammar is that each verb has a set of named slots that can be filled by other items, typi-cally nouns. Each slot describes the semantic role of its filler with respect to the verb. Verbs can be


characterized largely by the slots that they support and selection restrictions on what can fill them.Historically, Minsky�s original idea of frames was inspired by case theory [23]. Parunak has devel-oped a general-purpose frame language that makes full use of case theory [24].

Our approach of scenario authoring uses natural language. As shown in Section 3, the scenariostructure focuses on the notion of action. However, in textual scenarios, actions are expressedinformally. Thus, there is a need to fill the gap between the textual representation of actionsand their formal counterpart in the scenario structure. The use of free form natural languagein requirements engineering raises difficult problems. For example ambiguous and implicit state-ments requiring contextual or domain knowledge are especially dangerous in the framework ofrequirements engineering, where a small misunderstanding may have dreadful consequences[25]. In order to avoid such problems, we restrict the language of scenario expression by scenarioauthoring rules. We establish the scenario authoring rules on the basis of case grammar in orderto help to enhance goal and scenario modeling.

Our approach differs from case grammar in that we justify the cases with additional artifactssuch as agent, object, target, direction, and so on, and these cases are used to elicit actors anduse cases. Although our case grammar is not universal, it has proven to be useful in requirementsengineering.

Fantechi et al. [26] discuss the application of linguistic techniques for use case analysis, whichhas a little bit of similarity with our approach. However the aim of our work is somewhat differentfrom theirs. They have examined the various interpretation problems that exist related to the lin-guistic aspects of use cases. Their focus has been the application of methods and tools for the anal-ysis of natural language requirements documents in order to easily detect linguistic inaccuracies inuse cases, dealing in particular with problems related to the expressiveness of a document. To thisend, they define a set of metrics that can be used to evaluate the quality of requirements docu-ments, based on use cases, according to the categories listed in [26]. They are not concerned withanalyzing and modeling requirements in terms of actors and use cases. After use cases are mod-eled, they focus on the quality of evaluation of requirements documents, namely, the specificationof use cases. On the other hand, we focus on constructing use case diagrams using goal and sce-nario modeling with each semi-formal authoring template, which is based on linguistic technique.It is widely accepted in the software engineering community that constructing good use case dia-grams is a non-trivial task. Hence, we have attempted to provide a method for deriving use casediagrams from goal and scenario modeling. Especially, we use the linguistic technique to modelgoal & scenario and to generate a use case diagram by applying our transfer rules.

8. Conclusion and discussion

Our proposed approach overcomes the lack of support for the elicitation process in UCDA andthe underlying rationale. It builds on the following two principles: (a) both goal modeling and sce-nario authoring help to cope with the elicitation process in UCDA, and (b) use case conversionguidelines help us generate use case diagrams from the output of goal and scenario modeling.There have been some approaches to create use case diagrams from requirements using some nat-ural language processing techniques [14]. However, due to the varying degrees of details in therequirements text, in many cases, the resulting use case diagrams were found to be practically


unusable. In contrast, our proposed approach produces goal descriptions with the same level ofspecificity, and can be used as adequate input for deriving use case diagrams (potentially auto-mated using a diagramming tool). This promotes customer communication in defining systemrequirements. We have developed a tool that supports our methodology. It takes text based goaland scenario descriptions as input and generates XML based use case specification, which can berendered as a use case diagram in CASE tools. We have conducted preliminary empirical valida-tion of our methodology and the results are very encouraging.

Although our method may be simplistic, it promotes customer communication in defining sys-tem requirements. Since it facilitates the generation of a reasonable set of goals and scenarios tocreate use cases, our approach can save time and money as indicated by the subjects who partic-ipated in our pilot test. One limitation of our approach is the fact that it does not support non-functional requirements analysis. Until now, we have primarily concentrated on Use case drivenanalysis. Use cases generally represent the functional requirements of the system. Therefore wehave focused on the functionality and on how to construct use case diagram. Of course, a goalcan represent both functional and non-functional requirements. In our future work, we will con-sider how to tackle the non-functional requirements in constructing a use case diagram. Our fu-ture work also includes further refinement of the scenario structure as well as the authoring andconversion rules, improving the tool with new features, and conducting additional validation indifferent domains.

Acknowledgment

This work was supported by University IT Research Center Project (ITRC) in Korea and Oak-land University, USA.

References

[1] B. Regnell, K. Kimbler, A. Wesslen, Improving the use case driven approach to requirements engineering, in: Proc.Second IEEE International Symposium on Requirements Engineering (RE�95), York, 1995, pp. 1–8.

[2] C. Potts, Fitness for use: the system quality that matters most, in: Proc. Third Int�l Workshop Requirements Eng.:Foundations of Software Quality REFSQ�97, Barcelona, 1997, pp. 15–28.

[3] C. Rolland, C. Souveyet, C.B. Achour, Guiding goal modeling using scenarios, IEEE Transaction on SoftwareEngineering 24 (12) (1998) 1055–1071.

[4] J. Kim, J. Kim, S. Park, V. Sugumaran, A multiview approach for requirements analysis using goal and scenario,Industrial Management and Data Systems 104 (9) (2004) 702–711.

[5] A. van Lamsweerde, Goal-oriented requirements engineering: a guided tour, in: Proc. Fifth IEEE InternationalSymposium, Toronto, 2001, pp. 249–262.

[6] K. Park, J. Kim, S. Park, Goal based agent-oriented software modeling, in: Proc. Seventh Asia-Pacific SoftwareEngineering Conference (APSEC 2000), Singapore, 2000, pp. 320–324.

[7] R.D. Landtsheer, E. Letier, A. van Lamsweerde, Deriving tabular event-based specifications from goal-orientedrequirements models, Requirements Engineering Journal 9 (2) (2004) 104–120.

[8] J. Bubenko, C. Rolland, P. Loucopoulos, V. De Antonnellis, Facilitating ‘‘fuzzy to formal’’ requirementsmodelling, in: Proc. Int. Conf. on Requirements Engineering (ICRE), Colorado, 1994, pp. 154–157.


[9] A.I. Anton, Goal-based requirements analysis, in: Proc. 2nd International Conference on RequirementsEngineering, Colorado, 1996, pp. 136–144.

[10] A. Dardenne, S. Fickas, A. van Lamsweerde, Goal-directed concept acquisition in requirements elicitation, in:Proc. IWSSD-6—Sixth Int�l Workshop Software Specification and Design, Como, 1991, pp. 14–21.

[11] I. Sommerville, P. Sawyer, Requirements Engineering: A Good Practice Guide, Wiley, US, 1997.[12] C. Potts, K. Takahashi, A.I. Anton, Inquiry-based requirements analysis, IEEE Software 11 (2) (1994) 21–32.[13] A. Cockburn, Writing Effective Use Cases, Addison-Wesley, US, 2001.[14] J. Ralyte, C. Rolland, V. Plihon, Method enhancement with scenario based techniques, in: Proc. CAiSE �99,

Lecture Notes in Computer Science, vol. 1626, Springer, Berlin, 1999, pp. 103–118.[15] I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard, Object-Oriented Software Engineering: A Use Case Driven

Approach, Addison-Wesley, US, 1992.[16] C. Rolland, C.B. Achour, C. Cauvet, J. Ralyte, A. Sutcliffe, N.A.M. Maiden, M. Jarke, P. Haumer, K. Pohl, R.

Dubois, P. Heymans, A proposal for a scenario classification framework, Requirements Engineering Journal 3 (1)(1998) 23–47.

[17] S. Nurcan, G. Grosz, C. Souveyet, Describing business processes with a use case driven approach, in: Proc.CAiSE�98, Lecture Notes in Computer Science, vol. 1413, Springer, Berlin, 1998, pp. 339–362.

[18] V. Plihon, J. Ralyte, A. Benjamen, N.A.M. Maiden, A. Sutcliffe, E. Dubois, P. Heymans, A reuse-orientedapproach for the construction of scenario based methods, in: Proc. ICSP�98, Chicago, 1998, pp. 14–17.

[19] N. Prat, Goal formalization and classification for requirements engineering, in: Proc. Third Int�l WorkshopRequirements Eng.: Foundations of Software Quality REFSQ�97, Barcelona, 1997, pp. 145–156.

[20] J.C.S.P. Leite, J.H. Doorn, G.D.S. Hadad, G.N. Kaplan, Scenario inspections, Requirements Engineering Journal10 (1) (2004) 1–21.

[21] P. Van Bommell, Implementation selection for object-role models, in: Proc. First International Conference onObject-Role Modeling (ORM-1), Australia, 1994, pp. 103–112.

[22] W.A. Cook, Case Grammar: Development of the Matrix Model, Georgetown University Press, Washington, US,1979.

[23] M. Minsky, A Framework for Representing Knowledge, The Psychology of Computer Vision, New York, US,1981, pp. 211–277.

[24] H.V.D. Parunak, A linguistic approach to the problem of slot semantics, in: Proc. the 11th Annual Conference ofthe Cognitive Science Society, Ann Arbor, 1989, pp. 797–804.

[25] K. Ryan, The role of natural language in requirements engineering, in: Proc. Int. Symposium on RE, San Diego,1993, pp. 240–242.

[26] A. Fantechi, S. Gnesi, G. Lami, A. Maccari, Applications of linguistic techniques for use case analysis,Requirements Engineering 8 (3) (2003) 161–170.

Jintae Kim is a Ph.D. candidate in the Department of Computer Science and Engineering atSogang University. He received his B.S. degree from Sogang University in 2000. From 2000 to2001, he worked for Dacom System Technologies as a software engineer. In 2003, he received theBest Paper Award in Korea Conference on Software Engineering. His current research interestsare Software variability management, Adaptive software, and Requirements Engineering. Kim isa member of the Korea Information Science Society and IEEE Society.


Sooyong Park is an Associate Professor of Computer Science Department at Sogang University.He received his Bachelor of Engineering degree in Computer Science from Sogang University,Seoul, in 1986, the Master of Science degree in Computer Science from the Florida State Uni-versity, in 1988, and the Ph.D. in Information Technology with major in Software Engineeringfrom George Mason University, in 1995. In 1994, he received an American Institute of Aero-nautics and Astronautics (AIAA) Software Engineering Award. He served as a Senior SoftwareEngineer at TRW ISC during 1996–1998. His research interests include requirements engineering,embedded and adaptive software development, software architecture.

Vijayan Sugumaran is an Associate Professor of Management Information Systems in thedepartment of Decision and Information Sciences at Oakland University, Rochester, Michigan,USA. His research interests are in the areas of Ontologies and Semantic Web, Intelligent Agentand Multi-Agent Systems, Component Based Software Development, Knowledge-Based Systems,and Data and Information Modeling. His most recent publications have appeared in Commu-nications of the ACM, Healthcare Management Science, Data and Knowledge Engineering, TheDATABASE for Advances in Information Systems, Information Systems Journal, Journal ofInformation Systems and E-Business Management, Expert Systems with Applications, andLogistics Information Management. Dr. Sugumaran is the editor-in-chief of the InternationalJournal of Intelligent Information Technologies and also serves on the editorial board of seven

other journals. He is the chair of Intelligent Information Systems track for the Information Resources Management
Association International Conference (IRMA 2001, 2002, 2005, 2006) and the Intelligent Agent and Multi-AgentSystems in Business mini-track for Americas Conference on Information Systems (AMCIS 1999–2005). He also servedas the chair of E-Commerce track for Decision Science Institute�s Annual Conference, 2004.

Documents

Improving use case driven analysis using goal and scenario