A Visualization Tool for Scenario-based Software Development

Eiji Shiota and Atsushi Ohnishi

Department of Computer Science, Ritsumeikan University, Kusatsu, Japan

Keywords:

Scenario Retrieval, Differential Scnenario, Scenario-based Requirements Elicitation.

Abstract:

In a scenario-based software development, a lot of scenarios should be described in order to clarify the whole

behaviors of the target software. By reusing scenarios of similar software systems, it becomes more efﬁcient

to newly describe scenarios of the target software. A differential scenario includes the difference between

sequences of events of the two scenarios and the difference between nouns in the scenarios. If the nouns of the

two scenarios are commonly used in the two scenarios, we regard the two scenarios specify the same or similar

system. If the sequences of the events of the two scenarios are corresponding each other, we regard behavior

of the two scenarios are similar. In this paper, we derive differential information including different words

and events from two scenarios. Then, we propose a method of scenario retrieval using differential information

between two scenarios. This method enables to detect similar scenarios for a given scenario. The proposed

method and a prototype system for creating and visualizing differential scenario and a retrieval system will be

illustrated with examples.

1 INTRODUCTION

Scenarios are important in software development

(Cockburn, 2001), particularly in requirements en-

gineering by providing concrete system description

(Sutcliffe et al., 1998; Weidenhaupt et al., 1998).

Especially, scenarios are useful in deﬁning system

behaviors by system developers and validating the

requirements by customers (Alexander et al., 2004;

Mavin et al., 2003). In scenario-based software de-

velopment, incorrect scenarios will have a negative

impact on the overall system development process.

Scenarios can be classiﬁed into (1) normal scenar-

ios, (2) alternative scenarios, and (3) exceptional sce-

narios. A normal one represents the normal and typi-

cal behavior of the target system, while an alternative

one represents normal but alternative behavior of the

system and an exceptional one represents abnormal

behavior of the system. There are many normal sce-

narios for a certain system. For example, a normal

scenario represents withdrawal of a banking system,

another normal scenario represents money deposit, a

third one represents wire transfer, and so on. Each

normal scenario has several alternative scenarios and

exceptional scenarios. In order to grasp all behaviors

of the system, not only normal scenarios, but also al-

ternative/ exceptional scenarios should be speciﬁed.

However, it is difﬁcult to hit upon alternative scenar-

ios and exceptional scenarios, whereas it is easy to

think of normal scenarios. In order to improve the

productivityof scenario-based software development,

reusing of scenario is a key to solve the above prob-

lem.

This paper focuses on retrieval of scenarios in or-

der to improve the reusability of scenarios. For exam-

ple, suppose a new developmentof a train ticket reser-

vation system. In case of scenario-based develop-

ment, several normal scenarios, such as reservation,

cancellation, modiﬁcation and so on should be spec-

iﬁed. Furthermore, alternative scenarios and excep-

tional scenarios should be speciﬁed. In such a case, if

scenarios of similar system, such as ﬂight ticket reser-

vation are reusable and if developers can easily gener-

ate new scenarios of the new system, the productivity

will be improved.

If we can detect existing scenarios whose behav-

iors are similar with a scenario of a system to be de-

veloped, we may reuse the detected scenarios. Sup-

pose a new train ticket reservation system. If we ﬁnd

scenarios of similar system, such as bus ticket reser-

vation, we may use them.

Retrieval with keywords is an easy way, however,

it is difﬁcult to search for full-text scenarios. One of

the reasons of the difﬁculties is the difference of ab-

straction levels of scenarios. Suppose a scenario of

purchasing a train ticket. One scenario may consist of

293

Shiota E. and Ohnishi A..

A Visualization Tool for Scenario-based Software Development.

DOI: 10.5220/0005504702930300

In Proceedings of the 10th International Conference on Software Engineering and Applications (ICSOFT-EA-2015), pages 293-300

ISBN: 978-989-758-114-4

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

just one event of buying a train ticket. Another sce-

nario may consist of several events, such as 1) inform-

ing date, destination, and the number of passengers,

class of cars, 2) retrieving train data base, 3) issuing

a ticket, 4) charging ticket fee to a credit card, and so

on. If the abstraction levels of scenarios are different,

it is quite difﬁcult to correctly retrieve scenarios.

SCEL language for writing scenarios solves this

problem, because SCEL provides a limited actions

and their case structure as described in Section 2.3

and scenarios with SCEL keep a certain abstraction

level of actions.

2 SCENARIO LANGUAGE

2.1 Outline

The SCEL language has already been introduced

(Zhang et al., 2004). In this paper, a brief descrip-

tion 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 sys-

tem 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 prob-

lem domains, but the roles of cases are independent

of problem domains. The roles include agent, object,

recipient, instrument, source, etc. (Fillmore, 1968;

Ohnishi, 1996). Verbs and their case structures are

provided in a dictionary of verbs. If a scenario de-

scriber needs to use a new verb, he can use it by

adding the verb and its case structure in the dictio-

nary.

We adopt a requirements frame in which verbs and

their own case structures are speciﬁed. The require-

ments frame depends on problem domains. Each ac-

tion has its case structure, and each event can be au-

tomatically transformed into internal representation

based on the frame. In the transformation, concrete

words will be assigned to pronouns and omitted in-

dispensable cases. With Requirements Frame, we can

detect both the lack of cases and the illegal usage of

noun types (Ohnishi, 1996). Our scenario language

deﬁnes the semantic of verbs with their case structure.

For example, data ﬂow verb has source, goal, agent,

and instrument cases.

2.2 Scenario Example

Figure 1 shows a scenario of reservation of a hotel

room written with our scenario language, SCEL. A

[Title: Reservation of a hotel room]

[Viewpoints: user, reservation system]

1.A user enters his membership number and his

name to the reservation system.

2.The system validates the user with the mem-

bership number and the name.

3.The user enters retrieval information to the

system.

4.The system retrieves available hotels from the

database using the information.

5.The system shows available hotels to the user.

6.The user selects a hotel from the available ho-

tels.

7. The system shows the room rate to the user.

8.The user enters the credit card number to the

system.

9.The system asks the status of the card to a

credit card company using the card number.

10.The system shows the reservation number to

the user.

Figure 1: Scenario example.

title of the scenario is given at the ﬁrst line of the sce-

nario in Figure 1. Viewpoints of the scenario are spec-

iﬁed at the second line. In this paper,viewpoints mean

active objects such as human, system appearing in the

scenario. There exist two viewpoints, namely “user”

and “reservation system.” The order of the speciﬁed

viewpoints means the priority of the viewpoints. In

this example, the ﬁrst prior object is “user,” and the

second is “reservation system.” In such a case, the

prior object becomes a subject of an event.

In this scenario, all of the events are sequential.

Actually, event number is for reader’s convenience

and not necessary.

Each event is automatically transformed into in-

ternal representation. The details of transformation

mechanism is in (Ohnishi, 1996). For example, the

1st event “A user enters his membership number and

his name to the reservation system” can be trans-

formed into internal representation shown in Table

1. In this event, the verb “enter” corresponds to the

concept “data ﬂow.” The data ﬂow 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 re-

ceiver corresponds to the goal case. Data transferred

from source case to goal case corresponds to the ob-

ject case. Device for sending data corresponds to the

instrument case. In this event, “membership number

and name” correspond to the object case and “user”

corresponds to the source case.

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

294

Table 1: Internal representation of the 1st event.

Concept: Data Flow

source goal object instrument

user reservation membership *NOT

system no. and name speciﬁed*

3 DIFFERENTIAL SCENARIO

Systems that are designed for a similar purpose (e.g.

reservation, shopping, authentication, etc.) often have

similar behaviors. Besides, if such systems belong

to the same domain, actors and data resemble each

other. In other words, normal scenarios of a similar

purpose belonging to the same domain resemble each

other. Since our scenario language provides limited

vocabulary and limited grammar, the abstraction level

of any scenarios becomes almost the same.

For one system, there exist several normal scenar-

ios. In the case of ticket reservation, reservation can

be written as a normal scenario and cancellation can

be written as another normal scenario. For a certain

normal scenario, there are several exceptional scenar-

ios and alternative scenarios. To make a differential

scenario, we select two normal scenarios of two dif-

ferent systems. Each of the two scenarios should rep-

resent almost the same purpose, such as reservation of

some item.

The differential scenario consists of (1) a list of

not corresponding words, (2) a list of not correspond-

ing events, that is, deleted events which appear in one

scenario (say, scenario A) and do not appear in the

other (say, scenario B) and added events which do not

appear in scenario A and appear in scenario B. We

also provide (3) a list of corresponding words and (4)

a list of corresponding events, and (5) a script to ap-

ply the above differential information for generating

scenarios.

We generally assume that one to one correspon-

dence between two nouns and one to one correspon-

dence between two events. Figure 2 shows a scenario

of reservation of meeting room for residents in a city.

We compare the scenario of Figure 1 with the sce-

nario of Figure 2 from top to bottom. First, we check

the actors speciﬁed as viewpoints of the two scenar-

ios. In the case of scenarios of Figure 1 and 2, “user”

in Figure 1 corresponds to “citizen” in Figure 2 and

“reservation system” in Figure 1 corresponds to “sys-

tem” in Figure 2. The correspondence should be con-

ﬁrmed by user.

Second, we check the action concepts of events.

If there exist events whose action concept appears

once in scenario A and B, respectively, we assume

that these two events are probably corresponding to

[Title: Reservation of a meeting room]

[Viewpoints: citizen, system]

1. A citizen enters reservation information to the

system.

2. The system retrieves available room from the

database using the information.

3. The system shows an available room to the

citizen.

4. The citizen enters his name and telephone

number to the system.

5. The system validates the citizen with the

name and the telephone number.

6. The system shows the room rate to the citi-

zen.

7. The citizen pays the rate to the system.

8. The system issues a receipt to the citizen.

9. The system shows the room number to the

citizen.

Figure 2: Normal scenario of reservation of a meeting room.

each other. For example, the concept of the 2nd event

in Figure 1 and the concept of the 5th event in Figure

2 are “validate” and there are no more events whose

concepts are “validate,” so we regard these two events

are probably corresponding to each other. Then we

provide these two events to a user and the user will

conﬁrm that these two events are corresponding to

each other by checking whether nouns of the same

cases are corresponding or not.

If there exists an event whose action concept ap-

pears once in scenario A, but there exists two or more

events of the action concept in scenario B, then we

regard that one of the events of the concept in sce-

nario B corresponds to the event in scenario A. So,

we provide these events to system user and the user

will check the corresponding events.

If there are two or more events whose concepts are

same in two scenarios respectively, these events are

candidates of corresponding events. Then we check

that nouns of the same cases are corresponding to.

Next we provide candidates to the user and he will

select the corresponding event.

The ﬁrst four events of the scenario in Figure 1

can be transformed as shown in Table 2. The internal

representations of the ﬁrst ﬁve events of the scenario

in Figure 2 are shown in Table 3. In fact, the data

ﬂow concept has four cases, that is, source, goal, ob-

ject, and instrument cases as shown in Table 1, but the

instrument cases are omitted in Table 2 and 3 for the

space limitation.

For the 2nd event in Table 2 and the 5th event in

Table 3 as shown with italic font, since the nouns of

the cases of the two events are same or corresponding

to each other, these two events are corresponding to

AVisualizationToolforScenario-basedSoftwareDevelopment

295

Table 2: The internal representation of the ﬁrst four events

of the scenario in Figure 1.

concept agent/ goal object

source

data ﬂow user reservation membership

system no. and name

validate system user membership

no. and name

data ﬂow user reservation retrieval

system information

retrieve system available hotels database

Table 3: The internal representation of the ﬁrst ﬁve events

of the scenario in Figure 2.

concept agent/ goal object

source

data ﬂow citizen system reservation

information

retrieve system available database

room

data ﬂow system citizen available rooms

data ﬂow citizen system name and

telephone no.

validate system citizen name and

telephone no.

each other. At this time we get “membership num-

ber and name” correspond to “name and telephone

number.” So, the 1st event in Figure 1 corresponds to

the 4th event in Figure 2, because concepts are same

and all of the nouns of corresponding cases are corre-

sponding to each other.

Similarly we detect corresponding events and cor-

responding nouns. Table 4 shows a list of correspond-

ing nouns. Figure 3 shows corresponding events of

the two scenarios. In Figure 3, two events connected

by an arrow are corresponding to each other. Events

without an arrow have no corresponding events. The

successive corresponding events are grouped into an

event block. The ﬁrst two events in Figure 1 are

grouped into a block named a1. The block a1 cor-

responds to a block named b2 consisting of the 4th

and the 5th events in Figure 2.

Figure 3: Corresponding events.

Table 4: A list of corresponding words between scenario A

and scenario B.

Nouns in scenario A Nouns in scenario B

user citizen

reservation system system

membership num. and name name and telephone no.

available hotels available room

retrieval information reservation information

reservation number room number

hotel room meeting room

hotels room

Table 5: Deleted events from perspective scenario A/ Added

events from perspective scenario B.

concept agent/ goal object

source

select user hotel available hotels

data ﬂow user system credit card number

data ﬂow system credit card credit card number

company

Table 6: Added events from perspective scenario A/ deleted

events from perspective scenario B.

concept agent/ goal object

source

pay citizen system room rate

data ﬂow system citizen receipt

Finally, we can get the differential scenario be-

tween hotel reservation and meeting room reserva-

tion shown in Table 4, 5, and 6 and Figure 3. Ta-

ble 5 shows events that appear in scenario A, but do

not appear in scenario B. Table 6 shows events that

do not appear in scenario A, but appear in scenario

B. Figure 4 shows a script to make a new alterna-

tive/exceptional scenario of scenario B by applying

to an alternative/exceptional scenario of scenario A.

1) change positions of block a1 and a2

2) delete events in Table 5

3) insert events in Table 6 followed by a4

4) change the corresponding nouns in Table 4

Figure 4: Script applied to alternative/exceptional scenarios

of scenario A.

4 SCENARIO RETRIEVAL USING

DIFFERENTIAL SCENARIO

In scenario-based software development, several sce-

narios should be speciﬁed. Since such scenarios may

be revised, there exist a lot of scenarios of different

revisions. When a scenario is given, it may be dif-

ﬁcult to ﬁnd similar scenarios or related scenarios to

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

296

the given scenario by hand. We propose a retrieval

method in order to get similar scenarios or related sce-

narios using the similar information of scenarios.

We assume that scenarios are analyzed based

on the requirements frame in advance. As previ-

ously mentioned in Section 2, the requirements frame

strongly depends on the problem domain. So, if case

structures of verbs are different between two scenar-

ios, we consider that these two scenarios are belong-

ing to different domains each other. If all of the case

structures are same, these scenarios can be classiﬁed

into the same domain.

We propose two factors of the similarity between

scenarios. One is related to same system. For ex-

ample, a banking system provides several functions,

withdrawal, deposit, loan, opening account, and so

on. These functions are different each other, but both

active objects, such as customer, bank clerk, ATM,

banking system and inactive objects, such as bank

card, cash, account in common appear in scenarios

specifying behaviors of these functions of the banking

system. The other factor is related to same or similar

behavior. For example, behavior of train seat reser-

vation and that of ﬂight reservation are similar each

other, although these systems are different.

4.1 Similarity of Scenarios by System

If same nouns are used in scenarios, these scenarios

probably specify behaviors of the same system. For

example, “library id,” “e-library system,” and “librar-

ian” appear in different scenarios, these scenarios can

be regarded as scenarios of the same system. On the

basis of the above discussion, we give an equation in

order to measure the similarity of system of scenarios

as below.

Similarity of system between the two scenarios =

theno. of samenounsineventsof thetwoscenarios

thetotal no. of nounsineventsof thetwoscenarios

(1)

As for scenarios in Figure 1 and 2, nouns in the

events of these scenarios are shown in Table 7.

The total number of the nouns is 19 and the same

nouns are “database”, “name” and “room rate.” So

the similarity of system between these two scenarios

becomes

4.2 Similarity of Scenarios by Behavior

If scenario titles have a same verb, these scenario

probably specify similar behaviors. For example, a

scenario whose title is “a customer reserves a train

Table 7: Nouns in the events of Figure 1 and Figure 2.

Scenario nouns

Fig.1 available hotel(s), credit card company,

(credit) card number, database,

membership number, name, (retrieval)

information, reservation number,

(reservation) system, room rate,

status of the card, user

Fig.2 available room, citizen, database, name,

receipt, (reservation) information,

room number, (room) rate,

system, telephone number

seat” and another scenario whose title is “a user re-

serves a ﬂight ticket” can be classiﬁed into similar

scenarios from a behavioral viewpoint. However, a

scenario whose title is “a customer purchases a train

ticket” can be classiﬁed into similar scenarios with

above ones. So, we think that scenarios are similar if

titles of the scenarios have same verb, but this is not

necessary.

Sequence of events in a scenario represents be-

haviors of users and system. If systems are differ-

ent from each other, nouns in events become differ-

ent, even if events specify similar behaviors. So, we

use corresponding events in the differential scenario.

If two scenarios are similar each other from the per-

spective of behavior,the ratio of corresponding events

becomes high.

On the basis of the above discussions, we give the

second equation in order to measure the similarity of

behaviors of scenarios as shown in below.

Similarity of behavior between the two scenarios =

thenumberof correspondingevents

thetotal numberof eventso f thetwoscenarios

(2)

As shown in Figure 3, the total number of events

is 10+ 9− 7= 12 and the number of the same events

is 7. So, the similarity of behavior between scenarios

of Figure 1 and 2 is

= 0.58 We consider that two

scenarios whose similarity of behavior is greater than

0.5 are scenarios of similar behaviors.

In order to apply the differential information to

another scenario of reservation of a hotel room, we

also provide a script for application script shown in

Figure 4. Even if there exists a delete command in

a script, event blocks will not be deleted when any

event blocks in an applied scenario do not match with

event blocks in the script. Even if there exists an in-

sertion command in the script, event blocks will not

be inserted when the following event block and the

followed event block are missing in the applied sce-

nario.

AVisualizationToolforScenario-basedSoftwareDevelopment

297

4.3 Scenario Categorization

We map classiﬁed scenarios as shown in Figure 5. In

Figure 5, there exist two axes. The horizontal axis

means the similarity of behaviors, while the vertical

axis means the similarity of systems. Scenarios of

same vertical level are scenarios of similar behaviors

and scenarios of same horizontallevelare scenarios of

same system. Overlapped scenarios mean that these

scenarios have similar behaviors and belong to same

system. The three scenarios of the left-side are cat-

egorized into scenarios of similar behavior, that is,

reservation. Scenario of modifying ﬂight ticket and

its exceptional scenario are piled up, since these two

scenarios belong to same system and have similar be-

haviors.

㻌

System

Reservation of

flight ticket

(standard

scenario)

Reservation of

train ticket

Modify flight ticket

(exceptional scenario)

Reservation of

long distance

bus ticket

Borrowing CDs

Return borrowed CD

Borrowing books

Behavior

Figure 5: Retrieval result.

5 VISUALIZATION TOOL

We have been developing a prototype system based

on the proposed method with Java on an Eclipse 3.6

Helios. This system is three man-month product and

the number of source code line is about 3,000. Figure

6 shows the outline of the visualization of differential

scenario. A user speciﬁes a normal scenario of a new

system. Our tool generates differential scenarios be-

tween the speciﬁed scenario and each scenario stored

in a scenario database. If there exist 100 scenarios in

the scenario database, 100 differential scenarios will

be generated. Out tool can visualize each differential

scenario. Another tool named scenario retriever gen-

erates scenario map with two axes, that is, the similar-

ity of behavior and the similarity of system. With this

map, the user can ﬁnd similar scenarios to the speci-

ﬁed scenario.

Figure 7 shows a differential scenario between a

scenario of reserving a ﬂight ticket and a scenario

of reserving a train ticket. The same colored events

of the two scenarios are corresponding to each other.

There exist four corresponding blocks between the

Scenario

Database

Generator/Visualizer of

Differential Scenario

user

Scenario

Retriever

Scenario A

Retrieval result of

Scenarios

Differential㻌 scenario㻌

between A and scenario in DB

Corresponding

words and events,

added/deleted events,

script

Reservation of

a hotel room

Reservation of

a meeting room

Event 1

Event 2

Event 3

Event 4

Event 5

Event 6

Event 7

Event 8

Event 9

Event 10

Event 1

Event 2

Event 3

Event 4

Event 5

Event 6

Event 7

Event 8

Event 9

deleted

and

added events

Visualized

Differential

Scenario

Figure 6: Outline of Scenario Visualization.

Flight ticket reservation Train ticket reservation

Table of corresponding nouns

The number of nouns

The ratio of corresponding nouns

The ratio of common nouns

Figure 7: Visualized Differential Scenario between ﬂight

ticket reservation and train ticket reservation.

two scnearios. In the lower area of this ﬁgure, a ta-

ble of the number of nouns in the two scenarios and a

table of corresponding nous between the two scenar-

ios are shown.

Figure 8 shows a scenario similarity map. A nor-

mal scenario of ﬂight ticket reservation is located

in the origin (left and bottom.) The horizontal axis

means the similarity of system, while the vertical axis

means the similarity of behavior. Similar scenarios to

the ﬂight ticket reservation in terms of system are dis-

played in the lower and bottom area. Similar scenar-

ios in terms of behavior are displayed in the left area.

With this map user can easily ﬁnd similar scenarios

to the speciﬁed scenario. For readers’ convenience,

the authors translated some Japanese messages of this

map into English.

6 EXPERIMENT

To evaluate our method, we compare the classiﬁ-

cation of scenarios by hands with the classiﬁcation

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

298

Figure 8: Visualized Scenario Retrieval Result.

Table 8: The scenario classiﬁcation by proposed method

and by students.

Scenario by authors (same by stu-

as by method) dents

Train ticket reservation Different system, 11/13

via internet similar behavior

Flight ticket changing Same system, 11/13

different behavior

Flight ticket changing 2 Same system 11/13

different behavior

Train ticket reservation Different System, 11/13

similar behavior

Flight ticket reservation Same system, 13/13

similar behavior

Bus ticket reservation Different System, 10/13

similar behavior

Claim for the loss Different problem 13/13

on insurance domain

Goods purchasing Different problem 12/13

domain

by the method. Thirteen graduate students at Com-

puter Science department who well know both the

scenario language and the problem domain classify

eight scenarios for a standard scenario, while the same

scenarios are also classiﬁed based on the proposed

method. The scenario of reservation of ﬂight ticket

was adopted as a standard scenario in this experiment.

Table 8 shows the comparison of the scenario classi-

ﬁcations.

In this experiment, nine scenarios are classiﬁed in

advance by the authors. The results by the authors are

regarded as correct classiﬁcations. The classiﬁcation

results by our method are much the same as the re-

sult by the authors. This fact means our method can

correctly classifyscenarios. The values of the column

“result by students” mean the ratio of correct classi-

ﬁcation by the students. We investigated the reason

why some students wrongly classiﬁed and found that

they did not recognize the difference of systems cor-

rectly. After giving additional explanation of systems,

the students adopted same classiﬁcation of scenarios

as classiﬁed by the proposed method.

Through the experiment, we found that differen-

tial scenario is useful to classify scenarios.

7 RELATED WORK

There is an obvious trend to deﬁne scenarios as tex-

tual description of the designed system behaviors.

The growing number of practitioners demanding for

more “informality” in the requirements engineering

process seems to conﬁrm this trend. Most of these

papers describe how to use scenarios for the elicita-

tion (Sutcliffe et al., 1998) or exploration (Leite et al.,

1997) of requirements. The authors believe that it is

also important to support both the generation and the

classiﬁcation of scenarios.

Brian Chance et al. give scenario types for the

classiﬁcation (Chance et al., 1999). However they do

not propose how to classify given scenarios. Our ap-

proach for retrieving scenarios gives how to retrieve

similar scenarios with a given scenario.

Colette Roland et al. give a classiﬁcation frame-

work of scenarios in CREWS project (Rolland et al.,

1996). They classify scenarios from four viewpoints.

These are contents, purpose, form and lifecycle. They

can deﬁne the content of a whole scenario. We deﬁne

contents of a scenario the sequence of actions spec-

iﬁed in events and can derive contents of a part of a

scenario. In this sense, we can detect similarities be-

tween fragments of two different scenarios.

Zhang Wei-ha et al. propose a classiﬁcation

method of scenarios, but their method depends on

hazard scenarios and classiﬁed into ﬁve types in ac-

cordance with the complexity (Zhang et al., 2008).

Gerrit Lahrmann et al. propose a classiﬁcation

method of scenarios, but their method depends on in-

formation logistics scenarios based on three types and

4 factors (Lahrmann et al., 2009). Our method clas-

siﬁes more general scenarios and enables to retrieve

similar scenarios.

Martin Glinz proposes a very lightweight require-

ments modeling language (Glinz, 2010). With this

language relations among objects including human,

system and data can be visualized. The purpose of vi-

sualizing is modeling requirements at an early stage.

In (Fill et al., 2013), a meta modeling platform named

ADOxx is proposed. This platform provides the vi-

sual representation of modeling methods from the

AVisualizationToolforScenario-basedSoftwareDevelopment

299

area of requirements engineering. The purposes are

both meta modeling and modeling a software. In

case of our method, the purpose of visualizing is to

improve the understandability of differential scenario

and retrieval result of similar scenarios.

In authors’ previous works, generation methods of

exceptional scenarios and alternative scenarios with a

normal scenario have been established. By retrieving

a similar normal scenario using our proposed method

and by applying the generation methods, we can eas-

ily get alternative/exceptional scenarios (Makino et

al., 2012).

8 CONCLUSION AND FUTURE

WORK

We have developed a frame base scenario language

and a method of generating and visualizing differ-

ential scenario between two scenarios. We have es-

tablished a retrieval method of similar scenarios with

system/behavior for a given scenario using the differ-

ential scenario and a generation method of alterna-

tive/exceptional scenarios for a given scenario using

the differential scenario. We have also developed vi-

sualization tools of differential scenario and retreival

result of similar scenarios. The effectiveness of the

differential scenarios is validated through the experi-

ment.

In order to retrieve more efﬁciently similar sce-

narios with differential scenario, using pre-conditions

and post-conditions just like the selection of rules

applicable to verify the correctness of scenarios

(Toyama et al., 2005) is left as our future work.

REFERENCES

Alexander, I. and Maiden, N. A. M. Scenarios, Stories, Use

Cases, Through the Systems Development Life-Cycle.

John Wiley & Sons, Ltd., 2004, pp.161-177.

Chance, B. D. and Belhart, B. E., A Taxonomy for Scenario

Use in Requirements Elicitation and Analysis of Soft-

ware Systems. Proc. IEEE ECBS’99, 1999, pp.232-

238.

Cockburn, A., Writing Effective Use Cases. Addison-

Wesley, USA, 2001

Fill, H. G. and Karagiannis, D., On the Conceptualisa-

tion of Modelling Methods Using the ADOxx Meta

Modelling Platform. International Journal of Enter-

prise Modelling and Information Systems Architec-

tures, Vol.8, No.1, 2013, pp.4-25.

Fillmore, C. J., The Case for Case, in Universals in Lin-

guistic Theory. Holt, Rinehart and Winston, 1968.

Glinz, M., Very Lightweight Requirements Modeling.

Proc. 18th RE10, pp.385-386, 2010.

Lahrmann, G. and Stroh, F., Towards a Classiﬁcation of In-

formation Logistics Scenarios - An Exploratory Anal-

ysis. Proc. IEEE 42nd Hawaii International Confer-

ence on System Sciences, 2009, pp.1-10.

Leite, J. C. S. P. et.al., Enhancing a Requirements Baseline

with Scenarios. Proc. 3rd RE, 1997, pp.44-53.

Makino M. and A. Ohnishi, A., Scenario Generation Using

Differentail Acenario Information. IEICE Trans. Inf.

& Syst., Vol.E95-D, No.4, 2012, pp.1044-1051.

Mavin A. and Maiden, N. A. M., Determining socio-

technical systems requirements, experiences with gen-

erating and walking through scenarios. Proc. 11th

IEEE RE, 2003, pp.213-222.

Ohnishi, A., Software Requirements Speciﬁcation Database

on Requirements Frame Model. Proc. IEEE 2nd

ICRE, 1996, pp.221-228.

Rolland, C. et al. A Proposal for a Scenario Classiﬁcation

Framework. CREWS Report 96-01, 1996.

Sutcliffe, A. G. and Ryan, M., Experience with SCRAM, a

SCenario Requirements Analysis Method. Proc. 3rd

ICRE, 1998, pp.164-171.

Toyama, T. and Ohnishi, A., Rule-based Veriﬁcation of Sce-

narios with Pre-conditions and Post-conditions. Proc.

13th IEEE RE2005, 2005, pp.319-328.

Weidenhaupt, K. et al., Scenarios in System Development,

Current Practice. IEEE Software, March, 1998, pp.34-

45.

Zhang, H. and Ohnishi, A., Transformation between Sce-

narios from Different Viewpoints. IEICE Trans. Inf,

& Syst., Vol.E87-D, No.4, 2004, pp.801-810.

Zhang, W. et al.: Classiﬁcation of Hazard Scenario and

SDG Qualitative Identiﬁcation Method. Proc. the 7th

ICSC2008, 2008, pp.1223-1227.

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

300