SUPPORTING METHODS OF GENERATING ALTERNATIVE

SCENARIOS FROM A NORMAL SCENARIO

Atsushi Ohnishi

Department of Computer Science, Ritsumeikan University, Shiga 525-8577, Japan

Keywords: Requirements elicitation, scenario analysis, alternative scenario.

Abstract: A generation method of alternative scenarios using a normal scenario written with the scenario language

SLAF is proposed. This method includes (1) generation of alternative plans and (2) generation of alternative

scenario by a user’s selection of these plans. Our method enables to lessen the omission of the possible

alternative scenarios in the early stages of development and contributes to improve the correctness and

effectiveness of the software development.

1 INTRODUCTION

Scenarios are important in software development,

particularly in requirements engineering, by

providing concrete system description

(Weidenhaupt et al., 1998). Especially, scenarios are

useful in defining system behaviors by system

developers and validating the requirements by

customers. In many cases, scenarios are foundation

for system development. Incorrect scenarios will

have a negative impact on the overall system

development process. However scenarios are

informal and it is difficult to verify the correctness

of scenarios. The errors in incorrect scenarios may

include:

1. Vague representations,

2. Lack of necessary events,

3. Extra events,

4. Wrong sequence among events.

The author has developed a scenario language

for describing scenarios in which simple action

traces are embellished to include typed frames

based on a simple case grammar of actions and for

describing the sequence among events (Ohnishi et

al. 2001, Ohnishi et al. 2002). Since this language is

a controlled language, the vagueness of the scenario

written with this language can be reduced.

Furthermore, the scenario with this language can be

transformed into internal representation. In the

transformation, both the lack of cases and the illegal

usage of noun types can be detected, and concrete

words will be assigned to pronouns and omitted

indispensable cases (Ohnishi et al., 1996, Ohnishi et

al., 2002). As a result, the scenario with this

language can avoid the errors typed 1 previously

mentioned.

Scenarios can be classified into (1) normal

scenario, (2) alternative scenario, and (3)

exceptional scenario. A normal scenario represents

the normal and typical behavior of the target system,

while an alternative scenario represents normal but

untypical behavior of the system and an exceptional

scenario represents abnormal behavior of the system.

In order to grasp whole behaviors of the system, not

only normal scenarios, but also alternative/

exceptional scenarios should be specified. However

it is difficult to hit upon alternative scenarios and

exceptional scenarios, whereas it is easy to think of

normal scenarios.

This paper focuses on how to generate

alternative scenarios from a normal scenario. We

adopt our scenario language for writing scenarios,

because our scenario language is a control language

and it is easy to analysis scenarios with our scenario

language.

The rest of this paper is organized into 5 sections.

Section 2 introduces the outline of the scenario

language, and gives a scenario example. Section 3

describes a generation method of alternative

scenarios from a normal scenario with examples. In

section 4, evaluation of the method is briefly

described. In section 5, a discussion of related

works is presented. Finally, in section 6 we provide

some concluding remarks and point out

our future

110

Ohnishi A. (2006).

SUPPORTING METHODS OF GENERATING ALTERNATIVE SCENARIOS FROM A NORMAL SCENARIO.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 110-117

DOI: 10.5220/0002442801100117

 SciTePress

works.

2 SCENARIO LANGUAGE

2.1 Outline

The scenario language has already been introduced

(Ohnishi et al., 2001, Ohnishi et al., 2002, Zhang et

al., 2004). In this paper, a brief description of this

language will be given for convenience.

A scenario can be regarded as a sequence of

events. Events are behaviors employed by users or

the system for accomplishing their goals. We

assume that each event has just one verb, and that

each verb has its own case structure (Fillmore,

1968). The scenario language has been developed

based on this concept. Verbs and their own case

structures depend on problem domains, but the roles

of cases are independent of problem domains. The

roles include agent, object, recipient, instrument,

source, etc. (Fillmore, 1968, Ohnishi, 1996).

We provide requirements frames (Ohnishi, 1996)

in which verbs and their own case structures are

specified. The requirements frame depends on

problem domains. Each action has its case structure,

and each event can be automatically transformed

into internal representation based on the frame. In

the transformation, concrete words will be assigned

to pronouns and omitted indispensable cases. With

Requirements Frame, we can detect both the lack of

cases and the illegal usage of noun types (Ohnishi,

1996).

We assume four kinds of time sequences among

events: 1) sequence, 2) selection, 3) iteration, and 4)

parallelism. Actually most events are sequential

events.

Our scenario language defines the semantic of

verbs with their case structure. For example, data

flow verb has source, goal, agent, and instrument

cases. Since such case structure can define the

abstraction level, scenario with our scenario

language becomes the almost same level of the

abstraction.

2.2 Scenario Example

We consider a scenario of train ticket reservation of

a railway company. Figure 1 shows a scenario of

customer’s purchasing a ticket of express train at a

service center of a railway company. This scenario

is written with our scenario language based on a

video that records behaviors of both a user and a

staff at a service center of a railway company

(Railway Information System, 2001).

A title of the scenario is given at the first line of

the scenario in Fig.1. Viewpoints of the scenario are

specified at the third line. In this paper, viewpoints

mean active objects such as human, system

appearing in the scenario. There exist two

viewpoints, namely staff, and customer. The order

of the specified viewpoints means the priority. In

this example, the first prior object is staff, and the

second is customer. In such a case, the prior object

becomes the subject of an event

In this scenario, almost all events are sequential,

except for just one selective event (the 9

event).

Selection can be expressed with if-then syntax like

program languages. Actually, event number is for

reader’s convenience and not necessary.

[Title: A customer purchases a train ticket of

reservation seat]

[Viewpoints: Staff, customer]

1. A staff asks a customer about leaving station and

destination as customer’s request.

2. He sends the customer’s request to reservation

center via private line.

3. He retrieves available trains with the request.

4. He informs the customer of a list of available

trains.

5. The customer selects a train that he/she will get.

6. The staff retrieves available seats of the train.

7. He shows a list of available seats of the train.

8. The customer selects a seat of the train.

9. If (there exists a seat selected by the customer)

then the staff reserves the seat with the terminal.

10. He gets a permission to issue a ticket of the seat

from the center.

11. The customer paid for the ticket by cash.

12. He gives the ticket to the customer.

Figure 1: Scenario example.

2.3 Analysis of Events

Each of events is transformed into internal

representation. For example, the 2

event “He

sends the customer’s request to reservation center

via private line” can be transformed into internal

representation shown in Table 1.

SUPPORTING METHODS OF GENERATING ALTERNATIVE SCENARIOS FROM A NORMAL SCENARIO

111

Table 1: Internal representation of the 2

event.

Concept: Data Flow

source goal object instrument

Staff Reservation

center

Customer

’s request

Private line

In this event, the verb “send” corresponds to the

concept “data flow.” The data flow concept has its

own case structure with four cases, namely to say,

source case, goal case, object case and instrument

case. Sender corresponds to the source case and

receiver corresponds to the goal case. Data

transferred from source case to goal case

corresponds to the object case. Device for sending

data corresponds to the instrument case. In this

event, “customer’s request” corresponds to the

object case. Since the pronoun “he” in the event

should be “staff,” concrete noun “staff” is assigned

in the source case.

The internal representation is independent of

surface representation of an event. Suppose other

representations of event, “Customer’s request is

sent from staff to reservation center via private line”

and “reservation center receives customer’s request

from staff via private line.” These events are

syntactically different but semantically same as the

event. These two events can be transformed into

the same internal representations.

The advantages of SLAF as a scenario language

are as follows.

1) Since SLAF is a control language, it is

relatively easy to analyze a scenario written

with SLAF.

2) Since SLAF is a control language, verbs

and nouns are restricted. This means that

the abstraction level of scenario with SLAF

can be controlled.

3) Although expressions of events are

different, same meaning events are

transformed into same internal expressions.

4) It is easy to transform a scenario written

with SLAF into standard documents such

as sequence diagrams of UML.

3 GENERATION OF

ALTERNATIVE SCENARIOS

When a customer buys a ticket, there exist several

alternatives of payment, such as pay with cash,

credit card, personal check, banking card, money

order, and so on. When data is transmitted, there

exist several alternatives, such as sending via e-mail,

postal mail, FAX, FTP, and so on. These

alternatives arise from the diversity of methods. As

for the first case, the diversity of payment method

causes the alternatives. As for the second case, the

diversity of sending method causes the alternatives.

These alternatives appear in a certain case of the

case structure of a concept. For example, the

diversity of sending method appears in the

instrument case of the cases structure of data flow

concept. In case of payment with cash, there exist

alternatives (1) credit card, (2) personal check, (3)

banking card, and (4) money order.

We provide users with such alternatives using a

database whose contents are (a) pairs of an ordinary

method and its alternative methods and (b) event

sequences for the alternative methods as scenario

templates. We call this database “alternative

scenario DB.”

Users first specify a normal scenario, then

possible alternatives are provided to the users. By

users’ selecting alternatives, alternative event

sequence will be generated. By replacing the

original event sequence with the alternative event

sequence, an alternative scenario will be

automatically generated.

3.1 Generation Method of Alternative

Scenarios

Our generation method of alternative scenarios is

shown as follows. We assume that a normal

scenario is written with our scenario language in

advance as shown in step 0.

Step 0: Scenario writer describes a normal scenario

with our scenario language.

Step 1: The normal scenario is transformed into

internal representation. In this step each events is

transformed into internal representation based on

requirements frame. When the concept of the

internal representation is data flow and there exists

a noun corresponding to the instrument case, we

find alternatives for the instrument case. For

example, when the concept of the internal

representation is payment, we can find alternatives

for the payment methods.

Step 2: Alternative methods are automatically

generated and provided to the scenario writer.

He/she selects appropriate alternatives. The

describer can select one or more alternatives, or no

alternatives.

Step 3: Scenario templates can be derived from

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

112

alternative scenario DB in accordance with the

selected alternatives. There exist several lacks of

cases in the scenario template, but the lacked cases

are automatically compensated using the internal

representation of the event. Details of compensation

are in (Ohnishi, 1996).

Step 4: Alternative scenarios are provided to the

scenario writer. He/she can revise or customize

them.

3.2 Example of Generating Alternative

Scenario

The above 4 steps are illustrated with the example

shown in Fig. 1. In the step1, two events are

selected as alternative events. The 2

event, “ He

sends the customer’s request to reservation center

via private line” can be transformed into internal

representation shown in table 1. Since the concept

of the event is data flow, and its instrument case is

“private line,” so there exist several alternative

events. The 11

event, “The customer paid for the

ticket by cash.” Can be transformed into an internal

representation shown as Table 2. There is no noun

for the goal case in this event, but analyzer

compensates a noun, “staff” as the goal case object.

Table 2: Internal representation of the 11

event.

Concept: Payment

agent object instrument goal

customer ticket cash staff

Since the concept of the event is payment, there

exist several alternatives for this event.

In the step 2, alternatives are shown with

alternative scenario DB. In case of sending data via

private line, there exist alternatives, such as

(1) public line,

(2) FAX,

(3) e-mail,

(4) postal mail, and

(5) FTP.

A describer can

select one or more alternatives. If

he/she cannot find any appropriate alternatives,

he/she may not select any alternatives.

Here, we assume that no alternatives are selected.

In case of payment with cash, there exist

alternatives, such as

(1) credit card,

(2) personal check,

(3) banking card, and

(4) money order.

Here, we assume credit card is selected as

alternative payment.

In the step 3, a scenario template for the payment

with credit card is derived from the alternative

scenario DB. This template is shown in Figure 2.

[Title: Payment with a credit card]

[Viewpoints: (Agent), (Goal)]

1. (Agent) passes a credit card to (Goal).

2. (Goal) enters the credit card and amount of

payment with a terminal.

3. (Goal) confirms that the card is authenticated.

4. (Goal) gets receipt and bill via terminal.

5. (Agent) gets the receipt and bill from (Goal).

6. (Agent) autographs the bill.

7. (Agent) passes the bill to (Goal)

8. (Goal) passes both the card and the receipt to

(Agent).

Figure 2: Scenario template of the payment with credit

card.

In this template, the goal case and the agent case

are not specified. Since the goal case of the 11

event and the agent case of the event are “staff” and

“customer” respectively, both the goal case and the

agent case in the template will be “staff” and

“customer” respectively. By compensating these

two nouns, the scenario becomes as follows.

[Title: Payment with a credit card]

[Viewpoints: customer, staff]

1. Customer passes a credit card to staff.

2. Staff enters the credit card and amount of

payment with a terminal.

3. Staff confirms that the card is authenticated.

4. Staff gets the receipt and bill via terminal.

5. Customer gets the receipt and bill from staff.

6. Customer autographs the bill.

7. Customer passes the bill to staff.

8. Staff passes both the card and the receipt to

customer.

Figure 3: Compensated scenario template of the payment

with credit card.

In the step 4, alternative scenario shown in Figure

4 is provided to the scenario writer. The 11

event

of normal scenario in Figure 1 is expanded with the

compensated scenario template of Figure 3.

SUPPORTING METHODS OF GENERATING ALTERNATIVE SCENARIOS FROM A NORMAL SCENARIO

113

[Title: A customer purchases a train ticket of

reservation seat]

[Viewpoints: Staff, customer]

1. A staff asks a customer about leaving station

and destination as customer’s request.

2. He sends the customer’s request to reservation

center via private line.

3. He retrieves available trains with the request.

4. He informs the customer of a list of available

trains.

5. The customer selects a train that he/she will get.

6. The staff retrieves available seats of the train.

7. He shows a list of available seats of the train.

8. The customer selects a seat of the train.

9. If (there exists a seat selected by the customer)

then the staff reserves the seat with the terminal.

10. He gets a permission to issue a ticket of the

seat from the center.

11. Customer passes a credit card to staff.

12. Staff enters the credit card and amount of

payment with a terminal.

13. Staff confirms that the card is authenticated.

14. Staff gets the receipt and bill via terminal.

15. Customer gets the receipt and bill from staff.

16. Customer autographs the bill.

17. Customer passes the bill to staff.

18. Staff passes both the card and the receipt to

customer.

19. He gives the ticket to the customer

Figure 4: Alternative scenario for the normal scenario in

Figure 1.

Last, the scenario writer checks the alternative

scenario and revises it if needed.

3.3 Supporting Tool for Making

Alternative Scenario

We have developed a supporting tool based on our

method with VisulaBasic.NET 2003. Figure 5(a)

shows display image of the tool. The left side of

Figure 5(a) shows alternatives of payment methods.

Figure 5(b) shows the list of alternatives of payment

in English. The right side of Figure 5(a) shows a

normal scenario. Figure 5(c) shows a normal

scenario in English. Figure 5(d) shows a part of

normal scenario with XML format.

We use a transformer from scenario with SLAF

to scenario with XML format. Our system accepts a

scenario with XML format.

Figure 5(a): Original normal scenario and list of

alternatives.

 Payment with credit card

 Payment with check

 Payment with prepaid card

Figure 5(b): List of alternative methods of the payment.

1. A customer sends his order to a staff.

2. The staff sends the order to system.

3. The system displays available seats of the

train.

4. The staff selects a seat and enters the seat id

to the system.

5. A ticket of the seat is issued.

6. The staff notifies the customer of the total

amount fee.

7. The customer pays the fee with cash.

8. The staff hands out the ticket of the reserved

seat.

Figure 5(c): original normal scenario.

In the left side of Figure 6 (a), user selected the

first payment method. This method is payment

with credit card. The right side of Figure 6(a)

shows an alternative event sequence generated by

compensating scenario template with the

payment method using credit card.

Figure 6(b) shows the alternative event

sequence in English. Since Figure 3 shows

alternative events for payment with credit card,

Figure 3 and Figure 6(b) are mostly same. The

difference between them is system’s viewpoint is

included in the scenario or not. In Figure 6(b), 3

and 4

events that state system’s behavior are

included. By replacing the 7

event of Figure

5(c) with the events in Figure 6(b), an alternative

scenario can be automatically generated.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

114

<title>Reservation of seats </title>

<view>customer staff system </view>

<noun type="DATA">order</noun>

</object>

<noun type="HUMAN"> customer</noun>

</source>

<goal>

<noun type="HUMAN"> staff</noun>

</goal>

</event>

<noun type="DATA">order</noun>

</object>

<noun type="HUMAN"> staff</noun>

</source>

<goal>

<noun type="FUNC">system</noun>

</goal>

</event>

<verb crd="

DISPLAY">display</verb>

<noun type="DATA">available seats of the

train</noun>

</object>

<noun type="HUMAN">system</noun>

</source>

<goal>

<noun type="DEV">terminal</noun>

</goal>

</event>

Figure 5(d): A part of original scenario in XML.

Figure 6(a): Compensated scenario template of the

selected payment method.

[Payment with credit card]

[customer, staff, system]

1. The customer passes his credit card to the

staff.

2. The staff enters the credit card and amount of

payment with a terminal.

3. The system authenticates the card.

4. The system issues a bill and receipt.

5. The staff gets the receipt and bill via terminal.

6. The customer gets the receipt and bill from

the staff.

7. The customer autographs the bill.

8. The customer passes the bill to staff.

9. The staff passes both the card and the receipt

to customer.

Figure 6(b): Alternative events for payment with credit

card.

4 EVALUATION

In order to evaluate our method, the following

experiment was performed. We adopted a scenario

based software project of developing a bill

management system of an insurance company. In

this project, analysts wrote not only a normal

scenario for each projects, but also other scenarios,

that is, alternative scenarios and exceptional

scenarios. We applied our method to the normal

scenarios and got alternative scenarios. Then we

compared alternative scenarios that developed at the

projects with automatically generated scenarios.

Since original normal scenarios are written with

natural language, we rewrote the normal scenarios

with our scenario language prior to the experiments.

In this project, one normal scenario, 4 alternative

scenarios, and 5 exceptional scenarios are specified.

By applying our method of generating alternative

scenarios, we could get 5 alternative scenarios. By

comparing original alternative scenarios with

generated scenarios, we found that 3 scenarios are

same respectively, 2 scenarios are newly generated

and effective, and 1 scenario is not generated. Table

6 shows the above result. The not generated

scenario is regarded as an alternative scenario at the

project, but it should be categorized into a normal

scenario, because this scenario specifies normal

behavior of the bill management system.

SUPPORTING METHODS OF GENERATING ALTERNATIVE SCENARIOS FROM A NORMAL SCENARIO

115

Table 6: Result of alternative scenarios of the project.

Total Same New Not

generated

Original 4 3 - 1

Method 5 3 2 -

5 RELATED WORKS

Ben Achour proposed guidance for correcting

scenarios, based on a set of rules (Achour, 1998).

These rules aim at the clarification, completion and

conceptualization of scenarios, and help the

scenario author to improve the scenarios until an

acceptable level in terms of the scenario models.

Ben Achour's rules can only check whether the

scenarios are well written according to the scenario

models. We propose generation methods of

exceptional scenarios and alternative scenarios from

a normal scenario.

Derek Cramp claimed the importance of

alternative scenarios. He proposed a model to create

alternative scenarios (Cramp et al., 1995). However,

his model strongly depends on a specific domain.

Our approach for generating alternative scenarios is

independent of a domain.

Ian Alexander proposed a scenario-driven search

method to find more exceptions (Alexander, 2000).

In his approach, a model answer was prepared with

knowledge of all exception cases identified by

stakeholders. For each event, related exceptions are

listed as a model answer. His model answer,

however, strongly depends on a specific domain.

Neil Maiden et al. proposed classes of

exceptions for use cases (Maiden et al, 1998).

These classes are generic exceptions,

permutations exceptions, permutation options,

and problem exceptions. With these classes,

alternative courses are generated. For

communication actions, 5 problem exceptions are

prepared, that is, human agents, machine agents,

human-machine interactions, human-human

communication, and machine-machine

communication. They proposed a generation

method of alternative paths for each normal

sequence from exception types for events and

generic requirements with abnormal patterns

(Sutcliff et al., 1998). We focus on generation of

alternative scenarios by providing more precise

model based on both case structure of actions and

actor types.

In the author’s previous work (Ohnishi, 1996),

we proposed to build software requirements from

textual requirements in Japanese, based on a

typology of concepts very similar to the semantic

roles of the case grammar (Fillmore, 1968). Another

related work is Ben Achour's use of case grammar

in scenario analysis (Achour, 1997, Achour, 1998).

Ben Achour focuses on how textual scenarios could

be integrated into different existing methods, and

proposes guidance for writing scenarios. He

provides style and content guidelines referring to

conceptual and linguistic model of scenarios, based

on the case grammar. These works demonstrate that

the case grammar is suitable to the semantic

characterization of any design models as well as the

semantic characterization of any natural language

sentence.

6 CONCLUSION

The author has proposed a generating method of

alternative scenario. We provide alternative events

and their templates with an alternative scenario DB.

By compensating the templates, we can

automatically get alternative scenarios. Our method

contributes to lessen developers’ work of making

several scenarios and to improve the quality of

scenarios.

The proposed method was demonstrated by the

example and was evaluated. The evaluation results

show that our method is valid in software

development.

The quality of the generated alternative scenario

depends on the alternative scenario DB. So, we

have a plan to derive alternative methods from

software documents. We will evaluate and improve

our method and system by applying them to several

scenario-based software system developments.

These are left as future works.

ACKNOWLEDGEMENTS

We thank to Mr. Koji Kitamoto (currently at NTT

Data co.), Dr. Hiroya Itoga, Mr. Taishi Yamamoto

and other members of Software Engineering

laboratory, Department of Computer Science,

Ritsumeikan University, Japan. This research is

partly supported by Grant-in-Aid for Scientific

Research (C)(2)(17500026), Ministry of Education,

Culture, Sports, Science and Technology, Japan.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

116

REFERENCES

Achour, C. B., 1997: Linguistic Instruments for the

Integration of Scenarios in Requirements Engineering,

Proc. of the Third International Workshop on

Requirements Engineering: Foundation for Software

Quality (REFSQ'97), Barcelona, Spain, pp. 93-106.

Achour, C. B., 1998: Guiding Scenario Authoring, Proc. of

the Eight European-Japanese Conference on

Information Modeling and Knowledge Bases, Vamala,

Finland, May 25-29, pp.181-200.

Alexander, I., 2000: Scenario-Driven Search Finds More

Exceptions, Proc. 11

International Workshop on

Database and Expert Systems Applications, London,

U.K., Sep. 4-8, pp.991-994.

Cockburn, A., 2001: Writing Effective Use Cases,

Addison-Wesley, USA.

Cramp, D.G., Carson E.R., 1995: Assessing Health Policy

Strategies: A Model-Based Approach to Decision

Support, Proc. International Conference on System,

Man and Cybernetics, Vol.3, pp.69-73.

Fillmore, C.J., 1968: The Case for Case, in Universals in

Linguistic Theory, Bach and Harms, Chicago, Eds

Holt, Rinehart and Winston.

Jackson, M., 1995: Problems and requirements, Proc. 2nd

International Symposium on Requirements

Engineering (RE’95), IEEE Computer Soc., York,

England, March 27-29, pp.2-8.

Leite, J.C.S.P., Rossi, G., Balaguer, F., Maiorana, V.,

Kaplan, G., Hadad, G., Oloveros, A., 1997: Enhancing

a requirements Baseline with Scenarios, Proc. of the

3rd IEEE International Symposium on Requirements

Engineering (RE’97), Annapolis, U.S.A., Jan. 6-10,

pp.44-53.

Maiden, N.A.M., Manning’ M.K., Ryan M., 1998:

CREWS-SAVRE: Systematic Scenarios Generation

and Use, Proc. 3

International Conference on

Requirements Engineering (ICRE’98), Colorado

Springs, U.S.A., April 6-10, pp.148-155.

Maiden, N.A.M., Hare, M., 1998: Problem Domain

Categories in Requirements Engineering, International

Journal of Human-Computer Studies, 49, pp.281-304.

Ohnishi, A., 1996: Software Requirements Specification

Database Based on Requirements Frame Model, Proc.

of the IEEE second International Conference on

Requirements Engineering (ICRE'96), Colorado

Springs, U.S.A., April 15-18, pp.221-228.

Ohnishi, A., Potts, C., 2001: Grounding Scenarios in

Frame-Based Action Semantics, Proc. of 7th

International Workshop on Requirements Engineering:

Foundation for Software Quality (REFSQ’01),

Interlaken, Switzerland, June 4-5, pp.177-182.

Ohnishi, A., Zhang, H., Fujimoto, and H., 2002:

Transformation and Integration Method of Scenarios,

Proc. of 26th Annual International Computer Software

& Applications Conference (compsac02), Oxford,

England, pp.224-229.

Railway Information System Co., Ltd., 2001: JR System,

http://www.jrs.co.jp/keiki/en/index_main.html.

Ridao, M., Doorn, J., Leite, J.C.S.P., 2001: Domain

Independent Regularities in Scenarios, Proc. of the

Fifth IEEE International Symposium on Requirements

Engineering (RE’01), Toronto, Canada, August 27-31,

pp.120-127.

Sutcliffe, A.G., Ryan, M., 1998: Experience with SCRAM,

a Scenario Requirements Analysis Method, Proc. of

the 3rd International Conference on Requirements

Engineering (ICRE’98), Colorado Springs, U.S.A.,

April 6-10, pp.164-171.

Sutcliffe, A. G., Maiden, N. A. M., Minocha S., Manuel D.,

1998: Supporting Scenario-Based Requirements

Engineering, IEEE Trans. Software Engineering,

Vol.24, No.12, pp.1072-1088.

Weidenhaupt, K., Pohl, K., Jarke, M., Haumer, P., 1998:

Scenarios in System Development: Current Practice,

IEEE Software, March, pp.34-45.

Zhang, H., Ohnishi, A., 2004: Transformation Method of

Scenarios from Different Viewpoints, Proc. of the 11th

Asia Pacific Software Engineering Conference

(APSEC2004), Busan, Korea, Nov. 30-Dec. 3, pp.492-

501.

SUPPORTING METHODS OF GENERATING ALTERNATIVE SCENARIOS FROM A NORMAL SCENARIO

117