Goal and scenario based domain requirements analysis environment

Abstract

Identifying and representing domain requirements among products in a product family are crucial activities for a successful software reuse. The domain requirements should be not only identified based on the business goal, which drives marketing plan, product plan, and differences among products, but also represented as familiar notations in order to support developing a particular product in the product family. Thus, our proposal is to identify the domain requirements through goals and scenarios, and represent them as variable use cases for a product family. Especially, for identification of the domain requirements, we propose four abstraction levels of requirements in a product family, and goal and scenario modeling. For representation of them, variable use case model is suggested, and also the use case transfer rules are proposed so as to bridge the gap between the identification and representation activity. The paper illustrates the application of the approach within a supporting tool using the HIS (Home Integration System) example.

Full text

Page 1

Goal and scenario based domain requirements analysis environment
Jintae Kim*, Minseong Kim, Sooyong Park
Department of Computer Science, Sogang University, Shinsu-Dong, Mapo-Gu, Seoul, 121-742, Republic of Korea
Received 6 December 2004; accepted 20 June 2005
Available online 23 January 2006
Abstract
Identifying and representing domain requirements among products in a product family are crucial activities for a successful software
reuse. The domain requirements should be not only identified based on the business goal, which drives marketing plan, product plan, and
differences among products, but also represented as familiar notations in order to support developing a particular product in the product
family. Thus, our proposal is to identify the domain requirements through goals and scenarios, and represent them as variable use cases
for a product family. Especially, for identification of the domain requirements, we propose four abstraction levels of requirements in a
product family, and goal and scenario modeling. For representation of them, variable use case model is suggested, and also the use case
transfer rules are proposed so as to bridge the gap between the identification and representation activity. The paper illustrates the appli-
cation of the approach within a supporting tool using the HIS (Home Integration System) example.
? 2005 Elsevier Inc. All rights reserved.
Keywords: Goal; Scenario; Use case; Domain requirements analysis
1. Introduction
Managing differences between products in a product
family is one of the essential matters that must be consid-
ered when building a product line. Recently, the focus is
being changed from mere commonality management to
variability management (Geyer and Becker, 2002; Jaring
and Bosch, 2002; Myllyma ¨ki, 2001).
Feature based approaches such as FODA (Kang et al.,
1990) and FeatuRSEB (Griss et al., 1998) have been widely
used in domain analysis to model mandatory and variant
(optional and alternative) requirements as a feature graph.
However, it has been recognized that the feature based
approaches do not adequately support some issues (refer
to Section 6). In brief, they do not support a well defined
process and the source of variability. Without a well
defined process, they are less applicable. Handling the rea-
son of variability makes it easy to predict when the varia-
tion happens and where the variation comes from.
Therefore, in this paper, we focus on a well defined pro-
cess for identification and representation of domain
requirements considering the source of variability. The
characteristics of our approach are (1) to provide a process
for domain requirements analysis, (2) to provide how to
represent domain requirements, and a tool supporting both
(1) and (2). Three characteristics of our approach (see
Fig. 1) contribute to the achievement of these objectives.
First, there is the identification of domain requirements
using goals and scenarios: goal and scenario modeling is an
effective way to identify requirements in requirements engi-
neering (Kim et al., 2004; Potts, 1997; Rolland et al.,
1998b; Sutcliffe, 1998). A goal provides the rationale for
requirements—a requirement exists because of some under-
lying goal which provides a base for it (Dardenne et al.,
1991; Kim et al., 2004; Sommerville and Sawyer, 1997).
Since scenarios describe real situations, they capture real
requirements (Rolland et al., 1998b). In the context of a
product line, an organization’s high-level business goals
drive marketing plans and product plans, and force
0164-1212/$ - see front matter ? 2005 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2005.06.046
*Corresponding author. Tel.: +82 16 741 2145.
E-mail addresses: canon@sogang.ac.kr (J. Kim), minskim@sogang.
ac.kr (M. Kim), sypark@sogang.ac.kr (S. Park).
www.elsevier.com/locate/jss
The Journal of Systems and Software 79 (2006) 926–938

Page 2

products in a product family to have common and variant
requirements. On the basis of the business goals, the char-
acteristics of products are determined, and the goal pro-
videstherationalefor
Consequently, goal and scenario modeling makes it possi-
ble to manage adequately the variations among products
in the product family. In addition, the domain require-
ments level is proposed to help separation of concerns in
product line requirements elicitation as follows: business,
service, interaction, and internal level. These levels are
abstraction hierarchies. Each of them has its own perspec-
tive on separation of concerns in the product line require-
ments. Goal and scenario modeling is thus to identify
and analyze the domain requirements corresponding to
each of the domain requirements level via the goal and
scenario template proposed.
The second characteristic of the approach is to represent
the domain requirements identified through goal and sce-
nario modeling as a use case diagram through the transfer
guiding rules. The guiding rules help to represent the
domain requirements including common and variant
requirements as variable use cases. Thus, the domain
requirements are expressed by the use case diagram
extended for representation of variability.
Finally, the tool supports our proposal through the
whole process and their outputs. Especially it generates
XML (extensible markup language) based use case specifi-
cation, which can be shown as a graphical diagram in
CASE tools such as Rational Rose (http://www-306.ibm.
com/software/rational/) and Together (http://www.bor-
land.com/together/). The tool consists of 4 tabs corre-
sponding to the four levels of abstraction for goal and
scenario. The tool supports goal and scenario authoring
and the use case transfer rules.
The paper is organized as follows. The next section
briefly discusses HIS (Home Integration System) used in
this paper to illustrate our approach. How the domain
requirements are identified through goal and scenario mod-
eling is described in Section 3. A use case diagram represent-
ing domain requirements is presented in Section 4. The
transfer rules helping to represent the domain requirements
thedomain requirements.
as a use case diagram are discussed in Section 5. Section 6
describes a supporting environment and related work is dis-
cussed in Section 7. The last section sums up the essential
properties of our approach and discusses future works.
2. Case description: Home Integration System
We apply our approach to a HIS. To demonstrate the
feasibility of our approach, we have chosen the example of
a HIS (Kang et al., 2002; Chastek et al., 2001, 2002). HIS
enhances comfort, safety, and security of a home. The
HIS enables homeowners to access, control, and integrate
equipment in their homes such as the ones listed below:
• climate control systems—heating and cooling;
• security systems—intrusion, fire, and flood detection
and response; and
• entertainment systems—televisions, radios, and music-
playing devices.
HIS represents a multi-billion dollar market and offers
an opportunity for an organization with strong experience
and expertise in the HIS arena to expand into a new market
(e.g., integration, networks, devices, home or office security
systems). The HIS market is relatively new and immature,
and is changing rapidly as new devices and manufacturers
continually appear. Most homeowners have no experience
with an HIS and moreover, the consumer market for HIS is
also quite varied.
3. Domain requirements analysis using goal and scenario
This section discusses goal and scenario modeling that
helps to identify and analyze the domain requirements
based on the rationale for variations, i.e., a goal. A goal
drives marketing plan, product plan, and the differentia-
tions among most of the products because an organization
makes aplan to develop products based on its business goal.
The goal means, therefore, the direction, purpose, and
objective of the organization. Otherwise scenarios show
the behavior of system. They represent how the goal can
be achieved by a set of purposeful actions. However, in
requirements engineering, it has been recognized that ana-
lyzing requirements through goal and scenario is not very
easy because it is not defined at which level goal and sce-
nario modeling should be stopped. In this paper, goal and
scenario modeling is implemented corresponding to the
domain requirements level, such as business, service, inter-
action, and internal level. These levels explain where goal
and scenario modeling ends. Details of the domain require-
ments level, the concept of goal and scenario, and goal and
scenario modeling are discussed in the following sections.
3.1. The concept of goal and scenario
A goal is defined as ‘‘something that some stakeholder
hopes to achieve in the future’’ (Plihon et al., 1998) or
Domain Requirement
Analysis
Domain Requirements
Representation
Goal and Scenario modeling
Domain Requirements levels
Goal tree
Goal tree
Transfer rules
Use Case diagram
Process
input
output
legend
Supporting Environment
Fig. 1. The characteristics of our approach.
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938
927

Page 3

‘‘high level objectives of the business, organization or sys-
tem’’ (Anto ´n, 1996) in requirements engineering. In this
paper, a goal is defined in the context of a product line,
as an objective of the business, organization or system that
some stakeholder hopes to achieve with that product line.
We propose four types of a goal corresponding to the
domain requirements level (refer to Section 3.2), which
are a business goal, a service goal, an interaction goal,
and an internal goal. Clearly, a goal (Prat, 1997) is associ-
ated to a verb and to one or more parameters, where each
parameter plays a different role with respect to the verb. In
this paper, a goal is described as a combination hV + Tar-
get + Directioni, where V is an active verb, Target is a con-
ceptual or a physical object, and Direction is either source
or destination. For example, the goal, ‘Provide Entertain-
ment System to customers’ is described as follows:
ðProvideÞVerbðEntertainmentSystemÞTargetðToCustomersÞDir
A scenario is ‘‘a possible behavior limited to a set of pur-
poseful interactions taking place among several agents’’
(Plihon et al., 1998). Potts et al. (1994) defines a scenario
as ‘‘particular cases of how the system is to be used’’ and
additionally states that, ‘‘in a broad sense, a scenario is
simply a proposed specific use of the system’’. In the con-
text of a product line, we define a scenario as a possible
behavior limited to a set of purposeful actions in order to
achieve some goals. A scenario also has three types such
as a service scenario, an interaction scenario, and an inter-
nal scenario. In this paper, a scenario is authored as a com-
bination hS + V + Target + Direction + Manneri, where S
is either agents except for the designed system or the
designed system itself, V is an active verb, Target is a con-
ceptual or a physical object, Direction is either source or
destination, and Manner is the way in which the scenario
is implemented. For example, the scenario, ‘the HIS checks
the current temperature with a temperature sensor’ is
described as follows:
ðthe HISÞSubjectðchecksÞVerbðthe current temperatureÞTarget
ðwith a temperature sensorÞManner
3.2. The relationship between goals and scenarios
in domain requirements analysis
The scenarios capture real requirements since they
describe real situations or concrete behaviors, and goals
can be achieved through the execution of scenarios. Thus,
scenarios have their goals, and typically, the goals are
achieved by the scenarios. In other words, just as goals
can help in scenario discovery, so also scenarios can help
in goal discovery. As each individual goal is discovered, a
scenario can be authored for it. Once a scenario has been
authored, it is explored to yield goals (Rolland et al.,
1998b). In a product line, since a goal provides the ratio-
nale for variations in domain requirements, it is used as a
discriminator that enables us to identify common and
variant requirements. Variant requirements (or variation
point Jacobson et al., 1997) are identified when scenarios
achieve a goal in two ways; first, alternative variation: from
a set of alternative scenarios, only one scenario can be cho-
sen to achieve a goal—defining an exclusive relationship,
which means a ‘‘1 from n choice’’. Second is optional var-
iation: optional scenarios for a goal can be integrated or
not. That means from a set of optional scenarios, any
quantity of these scenarios can be chosen, at the rank to
zero to all. Hence, the optional scenarios can be modeled
by means of an optional relationship.
Fig. 2 depicts the variation point from the relationship
between goals and scenarios. For example, a goal, ‘‘Pro-
vide entertainment service to customers’’ can be achieved
by lots of concrete ways, which are represented as scenar-
ios. Scenarios such as ‘‘the HIS provides a movie service
on TV’’, ‘‘the HIS provides electronic games on TV’’, or
‘‘the HIS provide home shopping on TV’’ can be possible
ways. In these cases, domain experts and analysts should
decide which scenario should be common, alternative, or
optional. This is determined based on the goal providing
the rationale for the variations. For example, if the sce-
nario, ‘‘the HIS provides a movie service on TV’’ has a
common type, it should be involved in all products in a
product family. If the other scenarios are either alternative
or optional, they can be involved in any products or not in
other products. Therefore, variant point comes from the
relationship between goals and scenarios.
3.3. Domain requirements level
In this paper, we reorganize domain requirements col-
lection in a four levels abstraction hierarchy, namely, busi-
ness, service, interaction, and internal level based on
Rolland et al. (1998a). This can be useful in clarifying the
concerns of requirements and help separating concerns in
requirements elicitation. Domain requirements level also
helps to stop at which level goal and scenario modeling is
processed. This was proved useful when applying the
approach to the ELEKTRA real case (Nurcan et al.,
Goal Scenario
Variant type
Common
Alternative
Optional
A goal is achieved by scenarios.
When scenarios are generated to
satisfy a goal, they are authored
with variant types such as
‘Common’, ‘Alternative’, and
‘Optional’. Variant points come
from the relationship between
goals and scenarios.
: Variation point
author
yield
Fig. 2. The relationship between goals and scenarios.
928
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938

Page 4

1998). Each level reflects its own aspect of requirements.
That is, the business level shows what the business goal
of an organization is. The service level shows which ser-
vices can achieve the business goal, and how the scope in
a product line is determined. The requirements in the prod-
uct line are identified at the perspective of interaction
between the system itself and external entities, namely
agents at the interaction level. The internal level shows
the functionality among objects of system. This is a conve-
nient way to elicit domain requirements through goal and
scenario modeling because these levels make it possible to
refine the goals (Rolland et al., 1998b) and show at which
level goal and scenario modeling should end.
• Business level. The aim of the business level is to identify
the ultimate purpose of a product family. At this level,
the goal is given by any kind of organization or persons.
The business goal is represented as a business strategy or
as a business objective. For HIS example, the business
goal ‘‘Become the best provider in HIS market within
10 years’’ is a final purpose of the organization.
• Service level. The service level addresses identifying
the product plan or marketing plan, recognizing what
kinds of products in a product line will be developed,
and deciding their characteristics. At this level, the
domain requirements at this level are represented as a
pair hG,Sci where G is a service goal and Sc is a service
scenario. All of service goals correspond to a given
business goal. For example, the service goal ‘‘Provide
high-end products to customers’’ is one possible way
of satisfying the business goal (The high-end product
contains more functions). For another example, the ser-
vice goal ‘‘Provide low-end products to customers’’ is
another possible way of corresponding the business goal
(The low-end product contains less functions than the
high-end product). Service scenarios describe the flow
of services, which are necessary to fulfill the service goal.
For example, the service scenario ‘‘customers get
entertainment services through High-end HIS’’ achieves
theservicegoal ‘‘Provide
customers’’.
• Interaction level. At the interaction level, the focus is on
the interactions between the system and its external enti-
ties. The domain requirements at this level are repre-
sented as a pair hG,Sci where G is an interaction goal
and Sc is an interaction scenario. These interactions
are required to achieve the services assigned to the sys-
tem at the service level. The interaction goal ‘‘Provide
entertainment services to our High-end product custom-
ers’’ expresses a way of providing a service. The interac-
tion scenario describes a flow of interactions between the
system and agents. For example, the interaction scenario
‘‘the High-end HIS helps customers to watch TV’’ and
‘‘customers can play a video game through High-end
HIS’’ can achieves the interaction goal.
• Internal level. The internal level focuses on what the sys-
tem should provide to satisfy the interactions selected at
high-endproducts to
the interaction level. At this level, the domain require-
ments are represented as a pair hG,Sci where G is an
internal goal and Sc is an internal scenario. For exam-
ple, ‘‘operate a video game’’ is an internal goal. The asso-
ciated internal scenario describes the flow of interactions
among the system objects to fulfill the internal goal. For
example, ‘‘the entertainment manager connects a main
game server on Internet’’ is the internal scenario.
3.4. Goal and scenario modeling process for a product line
The prior proposals (Griss et al., 1998; Kang et al.,
1990) take into account only what are to be considered in
order to identify domain requirements in products of a
product family, not how the domain requirements are to
be identified and analyzed. This section discusses how goal
and scenario modeling for a product line is implemented
when identifying the domain requirements corresponding
to the domain requirements level. The process of goal
and scenario modeling is shown by using HIS example.
3.4.1. The structure of goal and scenario modeling process
Goal and scenario modeling is conducted in each
domain requirements level. Through this modeling, the
domain requirements including common and variant
requirements are identified. Fig. 3 shows the structure of
goal and scenario modeling process.
As shown in Fig. 3, at first, the business goal is given by
the organization. In general, the business goal represents
the directional value of the organization. The business goal
is achieved by one or more service goals. The service goal
explains what the scope of the product line is, what kinds
of the characteristics are included in each product, and what
the production plan or marketing plan of the future is.
From the service level, goals have the corresponding
scenarios showing the functions of products with the vari-
ant types such as common, alternative, and optional. The
goals are yielded from the scenarios at the previous level
and they author the corresponding scenarios. This process
is done at from the service level to the internal level. During
this process, common and variant requirements are identi-
fied by goals and scenarios. The following sections explain
how our process can be implemented by using HIS example.
3.4.2. HIS example of goal and scenario modeling process
• At the business and service level
In the HIS example, let us assume that a company
‘‘ABC’’ has projected a multibillion-dollar market for
HISs. The company intends to become a major vendor
with two initial HIS products: a low-end product (LE-
HIS)—a small system with a few services, and a high-
end product (HE-HIS) with additional services. The
key marketing strategy of this company is to build
scalable products that allow budget-conscious cus-
tomers to start with a small system and then grow to a
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938
929

Page 5

bigger one by adding additional services instead of buy-
ing new products.
The intention of the company as mentioned above
drives a business goal ‘‘Become the best provider in
HIS market within 10 years (BG: Business Goal)’’. This
business goal becomes concrete by means of the service
goals. Service goals are influenced by the marketing
strategy of the organization. The marketing strategy of
‘‘ABC’’ is to divide HIS market into a low-end product
HIS and a high-end product HIS responding to budget-
conscious customers. Due to this marketing strategy,
service goals corresponding to their business goals are
generated as follows: ‘‘Provide high-end products to cus-
tomers (Sg1: Service goal 1)’’ and ‘‘Provide low-end
products to customers (Sg2: Service goal 2)’’. The goal
Sg1 is related to the high-end products and Sg2 is
related to the low-end products, which means that the
organization can choose either Sg1 or Sg2. In the instant
developing time, if Sg1 is chosen for the marketing plan,
Sg2 is exclusive. Otherwise if Sg2 is chosen, Sg1 is exclu-
sive. Only one of two service goals must be developed.
Thus two service goals have an alternative relationship
with each other.
As shown in Figs. 2 and 3, service scenarios are gener-
ated in the same way as a goal is implemented by scenar-
ios. Because Sg1 fulfills the marketing strategy for a
high-end product, Sg1 has the following scenarios (Ss)
corresponding to high-end services (see Table 1).
Otherwise because Sg2 fulfills the marketing strategy for
a low-end product, Sg2 has fewer scenarios than Sg1. A
high-end product fulfilled by Sg1 includes Ss1 ‘‘Custom-
ers control climate through HIS remotely’’, Ss2 ‘‘Cus-
tomers secure their home through remotely’’, and Ss3
‘‘Customer enjoy an entertainment service on TV’’. A
low-end product fulfilled by g2 includes Ss1 ‘‘Customers
control climate through HIS remotely’’ and Ss2 ‘‘Cus-
tomers secure their home through remotely’’. Because
both Ss1 and Ss2 are involved in Sg1 and Sg2, all of
Ss1 and Ss2 have a common relation type. How-
ever Ss3 is just involved in Sg1, not Sg2. Thus Ss3 has
an optional relationship. Fig. 4 depicts goals and scenar-
ios at business and service level so far in the HIS
example.
• At the interaction level
Goalsattheinteractionlevelarederivedfromscenariosat
theservicelevelasillustratedinFig.3.Thescenariosyield
thuspossibleinteractiongoalsattheinteractionlevel.For
example,Ss1,Ss2,andSs3yieldgoalsatinteractionlevel:
‘‘Control climate remotely (IAg1: Interaction goal 1)’’,
‘‘Secure home remotely (IAg2: Interaction goal 2)’’,
and ‘‘Provide an entertainment service to customers
(IAg3:Interactiongoal3)’’.Thesegoalsinheritallcharac-
teristics(e.g.,varianttype)ofthescenariosattheprevious
level. Then, the domain experts and analysts choose
the interaction goals among the possible interaction
goals.
Table 1
Goals and scenarios at service level in HIS example (Ss: service scenario)
Sg1
Provide high-end products to customers
Ss1
Ss2
Ss3
Customers control climate through HIS remotely
Customers secure their home through HIS remotely
Customers enjoy an entertainment service on TV
Sg2
Provide low-end products to customers
Ss1
Ss2
Customers control climate through HIS remotely
Customers secure their home through HIS remotely
Business goal
given
Service goal
Service
Scenarios
refined
Interaction
goal
Interaction
Scenarios
yield
Internal
goal
Internal
Scenarios
yield
author
author
author
Common
Alternative
Optional
Common
Alternative
Optional
Common
Alternative
Optional
Fig. 3. The structure of goal and scenario modeling process.
930
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938

Page 6

Next, the interaction scenarios are generated to achieve
theinteractiongoals,whichshouldreflectthecharacteris-
ticsoftheirownlevel.Fig.5showsthegoalsandtheasso-
ciated scenarios at the interaction level. When an
interactiongoalisachievedbythescenarios,thesescenar-
ios are also authored with common, optional, or alterna-
tive type. The variant type of the interaction scenarios is
determined according to the way that each interaction
scenario achieves its own interactiongoal. In Fig. 5, there
are five scenarios corresponding to IAg1. All of IAs1
(Interaction scenario 1), IAs2, and IAs4 are essential for
IAg1. However, IAs3 and IAs30have a different variant
type according to whether manually or not. On the one
hand, IAs3 supports a control climate service automati-
cally.Ontheotherhand,IAs30supports acontrol climate
servicemanually,whichmeansthatHISoperatesaninner
climate both automatically and manually. The way that
HIS operates a climate service depends on customers’
favor. If IAg1 is assigned to ‘‘Control climate remotely
economically’’, IAs30could not be generated because an
automatic climate control is generally rather expensive
than a manual climate control. Therefore, a goal decides
which variant type a scenario has.
• At the internal level
The goal and scenario modeling process is done at the
internal level in the same way that is done at the interac-
tion level. Of course internal goals and internal scenarios
are generated to correspond to the characteristics at the
internal level. At this level, internal goals are yielded
from the scenarios at the previous level in Fig. 5. The
internal goals and scenarios supplement goals and sce-
narios at the interaction and service level in more detail
from the interaction among the internal objects of view.
Fig. 6 depicts a partial example at the internal level. For
a goal INg2, it has five scenarios representing the interac-
tion flows of objects within the inner system. The objects
interacting with each other are HIS engine, Communica-
tor, and Discriminator. HIS has a role that coordinates
all objects in HIS. Communicator is responsible for com-
municating with external objects. Discriminator checks
whether connection information is valid or not.
Interaction level
Scenarios
IAg1. Control climate remotely
in various ways
ScenariosIAg2. Secure home remotely
Scenarios IAg3. Provide an entertainment
service to customers
IAs1. Customers connect HIS remotely <<common>>
IAs2. HIS checks the authentification of customers << common >>
IAs3. Customers ask HIS to control a climate manually << common >>
IAs3`. Customers ask HIS to control a climate automatically << optional >>
IAs4. HIS returns the result of control climate service << common >>
optional
author
common
common
Fig. 5. Partial example at the interaction level.
Common
Optional
Internal level
ScenariosINg1. Maintain connection with customers
ScenariosINg3. Operate a climate in a manual way
INs1. The HIS engine asks the Communicator to receive the id and password of customers <<common>>
INs2. The Communicator asks the Discriminator to identify whether id and password are reserved << common >>
INs3. The Discriminator returns the result of identification to the Communicator <<common>>
INs4. The Communicator returns the result of identification and the state of customers to the HIS engine <<common>>
INs5. The HIS engine returns the result and the state of customers’ contact to customers <<common>>
ScenariosINg4. Operate an climate in an automatic way
ScenariosINg5. Provide a result of services
Scenarios INg2. Validate the authentification of customers
Common
Common
Common
author
Fig. 6. Partial example at the internal level.
BG: Become the best provider in HIS market within 10 years
alternative
Scenarios Sg1: Provide high-end products to customers
Ss1. Customers control climate through HIS remotely <<Common>>
Ss2. Customers secure their home through remotely <<Common>>
Ss3. Customer enjoy an entertainment service on TV <<Optional>>
Scenarios Sg2: Provide low-end products to customers
Ss1. Customers control climate through HIS remotely <<Common>>
Ss2. Customers secure their home through remotely <<Common>>
alternative
At business and service level
Fig. 4. Goals and scenarios at business and service level.
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938
931

Page 7

3.5. How do goals provide the rationale of variation?
In this paper, goals are used to analyze domain require-
ments. The output from goal and scenario modeling pro-
cess is a goal tree with four levels. Since domain
requirements are analyzed in terms of goals and a goal tree,
all goals have their own relationship among themselves
such as a vertical relationship and a horizontal relation-
ship. The combination with horizontal relationship and
vertical relationship describes how goals provide the ratio-
nale of variation.
The parent goals contain customers’ needs, marketing
strategy, business plan, and so on. When a parent goal is
refined to one or more child goals, they have different var-
iation types. Their various variation come from different
ways to achieve their parent goal, various objects used to
achieve their parent goal, and different directions for
objects to move (object, direction, and ways are already
mentioned in Section 3.1). For example, in Fig. 5, it is pre-
ceded to control a climate in two ways. One is an automatic
control. The other is a manual control. These variations
come from different ways. These different ways come from
a goal ‘‘Control climate remotely in various ways’’. Thus
rationale of variations of child goals depends on their par-
ent goal. The fact that goals provide the rationale of vari-
ation makes it possible to manage variations when
requirements are modified, deleted, and added.
4. Variable use case diagram
The success of use cases to capture and communicate
functional requirements for single systems has generated
ideas to utilize use case driven approaches for product
lines. However, classical use cases are not sufficient to espe-
cially represent variability among products in a product
family (Griss et al., 1998; John and Muthig, 2002; Maßen
and Lichter, 2002). Recently, there have been some
approaches in order to extend use cases for product lines
and especially for expressing variability. If use case dia-
grams support the modeling of functional variability, they
can be used to describe common and different characteris-
tics among products in a product line. Thus, in the paper,
the variable use case diagram for a product line based on
Bertolino et al. (2002), John and Muthig (2002) and Maßen
and Lichter (2002) are used to express explicitly the domain
requirements. However, they do not support how the
domain requirements are identified, and where use cases
come from. Therefore, we suggested an approach for iden-
tifying the domain requirements and providing the ratio-
nale for them with namely, goal and scenario modeling.
After goal and scenario modeling for a product line, the
domain requirements identified are thus represented in
the variable use case diagram.
The variable use case model should be extended by two
new relationships: option and alternative. These new rela-
tionship is represented as stereo types. Fig. 7 shows vari-
able use case diagram.
All use cases have variant type marked by stereotype. A
particular product in a product line is produced by the
composite of these use cases.
5. Transfer guiding rules
In this section, we propose how the domain require-
ments can be transferred to variable use case diagram. In
order to do it, the transfer rules should be proposed. The
following subsections describe how the domain require-
ments are transferred into the variable use cases, the trans-
fer rules, and the example of them.
5.1. The core idea of the transfer rules
The core idea of this approach is that the goals and sce-
narios at the interaction level of the domain requirements
level are used to help to identify and construct use cases.
A goal at the interaction level is achieved by scenarios
and a use case contains the set of possible scenarios to
achieve the goal. This is due to the fact that, in our
approach, the interaction level focuses on the interactions
between the system and its agents, and the purpose of the
use case specification is to describe how the agent can inter-
act with the system to get the service and achieve his/her
goal. Fig. 8 shows the relationships among agents, goals,
scenarios and use cases.
In Fig. 8, an actor is derived from all agents who interact
with the system. An actor has one or more goals that he/
she wants to achieve by interacting with the system. In
the HIS example, the customer (one of the actors) desire
HIS to control a climate remote in various ways. Thus,
the customer as an actor has his/her own goal, ‘‘control a
<<variant type>>
Use case 1
Actor
Display receipt to the
Use case n
<<variant type>>
Fig. 7. Variable use case diagram.
AgentActor
Goal Use case
Scenario
derives
has
names
contains
achieves
1+
1
1
1
1
1+
11
1+
Fig. 8. The relationship between goal, scenario and use case.
932
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938

Page 8

climate remote’’. When real systems are developed, we need
to determine how the goal can be achieved and imple-
mented. The scenarios can explain how to achieve the goal
by the flow of events or actions. In our approach, a goal is
mapped to a use case. This means that the goal is trans-
formed into a use case for a chunk of the functional
requirements of the system (as stated above, the interaction
goal is used to identify and create a use case). The use case
contains the scenarios for achieving that goal.
After analyzing each use case, it is augmented with inter-
nal activity elements of software-to-be. The goals and sce-
narios at the internal level represent the internal behavior
of the system under consideration to achieve the goals of
the interaction level. Accordingly, use cases can be per-
formed by achieving the goals at the internal level, and
completed by integration of the scenarios at that level.
5.2. Transfer guiding rules
We have developed the common transfer patterns in
order to guide the transfer of the domain requirements to
the variable use cases. The formalization of these patterns
results in the current set of guiding rules. These rules are
generic in the sense that they can be applied to the transfer
of many domain requirements. In this section, each rule is
introduced via the following template hDefinition, Com-
menti. The definition describes the point of each rule.
The comment explains the things to be considered when
applying the rules.
Transfer guiding rule1 (T1)
Definition:
Goals at the interaction level become use cases.
Comment:
The key idea of this rule is that each goal at the interac-
tion level is mapped into a use case because at the inter-
action level the focus is on the interactions between the
system and its agents. This definition is similar to the def-
inition of the use case. A goal names a use case as shown
in Fig. 8, which means a goal becomes a use case. For
example, there are three interaction goals in Fig. 5. All
of three goals can become three use cases. All use cases
inherit the characteristics of the corresponding goals.
Transfer guiding rule2 (T2)
Definition:
An agent who wants the interaction goal to be achieved
can become a primary actor.
Comment:
This actor is called as a primary actor, who interacts
with a use case in the beginning. It could be a human,
a machine or the external systems.
Transfer guiding rule3 (T3)
Definition:
Scenarios become the inner specification of a textural
use case and an agent in either direction or subject of
the scenario authoring template defined in Section 3.1
can become an actor.
Comment:
In rule 3, an agent not becoming a primary actor
becomes a secondary actor. In general, actors are found
in the interaction scenarios. For example, in Fig. 5, five
scenarios corresponding to IAg1 have ‘Customers’
agents in a slot of subject and direction. Thus an actor
associated with IAg1 is ‘Customers’.
Transfer guiding rule4 (T4)
Definition:
Goals with variant requirements, at the interaction level,
become variant use cases with variant type. If a goal has
the ‘Alternative’ relationship, a use case with ?alterna-
tive? stereotype is represented in a use case diagram. If
a goal has ‘Optional’ relationship, a use case with
?optional? is represented in a use case diagram.
Comment:
The notation is based on the prior proposals such as
Bertolino et al. (2002), John and Muthig (2002) and
Maßen and Lichter (2002).
Transfer guiding rule5 (T5)
Definition:
Goals and scenarios at the internal level are described in
each textual use case specification.
Comment:
When the interaction goal becomes the use case, it has its
own specification specified by the associated internal
goals and scenarios. For example, as shown in Fig. 6,
INg2 and the associated scenarios are textually involved
in‘‘controlaclimateremote’’usecasederivedfromIAg1.
5.3. The HIS example for transfer guiding rules
This section shows how the transfer guiding rules can be
used in the HIS example. After goal and scenario modeling
process, there are three interaction goals and the corre-
sponding scenarios.
Fig. 9 partially shows a variable use case diagram show-
ing the domain requirements in the HIS example. By rule
<<common>>
Remote control for a
climate
<<optional>>
Entertainment service
<< common >>
Remote security
Customer
Police
TV station
Fig. 9. Partial variable case diagram for HIS example.
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938
933

Page 9

T1, all interaction goals can become use cases: Remote
control for a climate (from IAg1), Remote Security (from
IAg2), and Entertainment service (from IAg3). In the case
of actors, customer (from IAs1), police (among scenarios
corresponding to IAg2), and TV station (among scenarios
corresponding to IAg3) become actors by rules T2 and
T3. By rule T4, each use case had its own variant type.
For example, a use case ‘‘Remote control for a climate’’
has common variant type. By rule T5, the internal
goals and scenarios are described the textual as shown in
Fig. 10.
6. Supporting environment
This section introduces a tool supporting fully goal and
scenario modeling process and transfer guiding rules. The
input to the tool is domain requirements. The outputs from
the tool are goal lists, textual specifications of all the
use cases, and XML based use case specification, which
can be shown as a graphical diagram in CASE tools
such as Rational Rose (http://www-306.ibm.com/soft-
ware/rational/) and Together (http://www.borland.com/
together/). This tool is available at a URL (http://selab.
sogang.ac.kr/~canon/dream.zip). How to use the tool and
the characteristics of this tool are explained below.
The tool consists of 4 tabs corresponding to the four lev-
els of abstraction for requirements. The first tab shows a
process at business level and service level (see Fig. 11).
The second tab shows a process at interaction level (see
Fig. 12). The third tab shows a process at internal level.
The last tab shows use cases derived from goals and their
textual specification (see Fig. 13). The first tab and the sec-
ond tab have a possible goal list at upper right side, not
business goal description.
At the business and service level, we firstly describe a
business goal at
. A service goal is described according
to goal template at
. After ‘Goal Generate’ button is
clicked, a service goal appear at
achieving its service goal is authored according to scenario
template at
. After ‘Scenario Generate’ button is clicked,
a service scenario appear at
finished at business and service level, it is required to click
‘next’ button for continuous goal and scenario modeling
process at
.
. A service scenario
. After the whole process is
1. Usecase Name : Remote control for a climate
2. Brief description :
1 Customers connect HIS remotely <<common>>
2 HIS checks the authentification of customers <<common>>
2.1 The HIS engine asks the communicator to receive the id
and password of customers <<common>>
2.2 The Communicator asks the discriminator to identify
whether id and password are reserved <<common>>
2.3 The Discriminator returns the result of identification to the
communicator <<common>>
2.4 The communicator returns the result of identification and
the state of customers to HIS engine <<common>>
2.5 The HIS engine returns the result and the state of customers'
contact to customers <<common>>
3 Customers ask HIS to control a climate manually <<common>>
4 Customers ask HIS to control a climate automatically <<optional>>
5 HIS returns the result of control climate service <<common>>
3. Variant Type : Common
4. Candidate Actors : 1) Customer
Fig. 10. The textual specification of a use case: remote control for a
climate.
Fig. 11. The first tab supporting a process at business and service level.
934
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938

Page 10

At the interaction level, most of the second tab is similar
to the first tab. However the second tab has a candidate
goal list instead of business goal description (see
Fig. 12). A candidate goal list has six columns: candidate
goal id, number, scenario, C&V, relationship, and select.
Candidate goal id is a sequential number of a candidate
goal. Number is an id of scenario at previous level. Sce-
in
nario is a scenario name combined with each element of
scenario template. C&V is a variant type which a candidate
goal has. Relationship is a special relation which is worth
referring. Select plays a role in choosing whether a candi-
date goal is used at lower level or not. The third tab is
similar to the second tab at the point of functions of the
tool.
Fig. 12. The second tab supporting a process interaction level.
Fig. 13. The last tab: textual use case specification.
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938
935

Page 11

In the third tab, candidate use cases are generated after
‘next’ button is clicked. The last tab shows candidate use
cases and their textual specification.
Candidate use cases are listed at
list consists of use case name, description, variant type,
actors, and select. Use case name is the name derived from
an internal goal. Description is a textural specification of
each use case, which is described at
Actors are feasible actors related to their own use cases.
Select plays a role in choosing whether a candidate use case
is used in a real project or not.
After the whole process, the XML based use case spec-
ification is generated as shown in Fig. 14.
XML based use case specification can be easily imported
and used in other CASE tools for supporting specific prod-
uct development in a product line.
. A candidate use case
in more detail.
7. Related work
This section surveys related work in domain analysis
especially commonality andvariability (C&V) analysis from
theperspectiveofsoftwareproductlines.Inordertoanalyze
commonality and variability among products in a product
line, feature base approaches like Griss et al. (1998), Kang
et al. (2002) and Vici and Argentieri (1998) have been used
widely in industry and academia since the FODA method
(Kang et al., 1990) was introduced in 1990 by the Software
Engineering Institute. They attempt to analyze commonal-
ity and variability in terms of features. Feature models that
illustrate a structural view on a system are concentrated on
the representation of common and variant requirements.
However, the feature based approaches do not provide a
well defined process to identify features and C&V, which
makes it ambiguous to analyze domain requirements.
A feature model do not explain where common and var-
iant requirements come from, what brings about variation
points, and what kinds of common and variant require-
ments are generated particularly in an immature domain
or an envisioned market (Park et al., 2004). Kang et al.
(2002) tries to deal with the rationale for common and var-
iant requirements. However, his approach does not provide
formal mechanism to discover systematically the origin of
common and variant requirements. While a marketing
and product plan is proposed as a key driver for product
line asset development in (Kang et al., 2002), the paper just
describes largely what is considered, not how they are
implemented. His approach has thus a little difficulty in
handling variations based on the origin of variation itself
in a product family in practice.
Additionally, inmany
approaches have been widely used, which are useful to cap-
ture and communicate functional requirements for single
systems (Jacobson et al., 1999). Nevertheless, feature based
approaches, like FODA provide little practical relationship
between the feature models and use case models. Therefore
the practical use of FODA can be constrained in industry
(Myllyma ¨ki, 2001; Speck et al., 2002). On the other hand,
both FeatuRSEB (Griss et al., 1998) and FODAcom (Vici
and Argentieri, 1998) have used use-case models with fea-
ture models for C&V analysis. Product Line Analysis
(PLA) (Chastek et al., 2001) combines traditional object-
based analysis with FODA for a product line analysis.
However, unlike our approach, the prior methods have
not provided a systematic and concrete mechanism for
identifying common and variant requirements as well as
the rationale for them.
There are some approaches in order to extend use cases
for product lines. Reuse-Driven Software Engineering
Business (RSEB) (Jacobson et al., 1997) introduces ‘‘varia-
tion points’’ into use case diagrams and also uses variation
points in textual use cases. It does not say anything about
how variant or generic use cases can be identified and
projects use casedriven
<?xml version="1.0" standalone="yes" ?>
- <XMI xmi.version="1.1" xmlns:UML="omg.org/UML/1.4">
- <XMI.header>
- <XMI.documentation>
<XMI.exporter>kr.re.elly.model.impl.UMLRepositoryImplXMIWriter</XMI.exporter>
</XMI.documentation>
</XMI.header>
- <XMI.content>
- <UML:Package xmi.id="a0" isRoot="false" isLeaf="false" isAbstract="false" isSpecification="false">
- <UML:Namespace.ownedElement>
<UML:UseCase xmi.id="a1" isRoot="false" isLeaf="false" isAbstract="false" name="Remote control for a climate"
isSpecification="false" stereotype="a2" />
<UML:Actor xmi.id="a7" isRoot="false" isLeaf="false"
isSpecification="false" />
- <UML:UMLAssociation xmi.id="a8" isRoot="false" isLeaf="false" isAbstract="false" isSpecification="false">
- <UML:UMLAssociation.connection>
<UML:AssociationEnd xmi.id="a9" isNavigable="true" participant="a1" isSpecification="false" />
<UML:AssociationEnd xmi.id="a10" isNavigable="false" participant="a7" isSpecification="false" />
</UML:UMLAssociation.connection>
</UML:UMLAssociation>
<UML:Stereotype xmi.id="a2" isRoot="false" isLeaf="false"
isSpecification="false" />
</UML:Namespace.ownedElement>
</UML:Package>
</XMI.content>
</XMI>
isAbstract="false" name="Customers"
Abstract="false" name="Common"
is
Fig. 14. XML based use case specification of remote control for a climate.
936
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938

Page 12

instantiated. FODAcom, FeatuRSEB and PLA mentioned
previously do not provide how C&V should be integrated
and described in use case diagrams and textual use case
descriptions. In Maßen and Lichter (2002), to model
explicitly the types of variability, the use case meta-model
extended by two new relationships, in other words,
optional and alternative are introduced. And, in John
and Muthig (2002), to utilize use cases for product line
modeling, they are extended with a variability mechanism.
However, in comparison with our approach, the two
approaches (John and Muthig, 2002; Maßen and Lichter,
2002) focus on only modeling use cases for product lines
and representing variability. Consequently, the approaches
given above have no proposal to systematically identify
commonality and variability as well as use cases for prod-
uct lines, and provide the rationale for them. Moreover, as
has been pointed out, the results of C&V analysis should
satisfy an organization’s high-level business goals. There-
fore, C&V and use cases must be identified to satisfy these
goals and the rationale for those must be provided. Yet, the
approaches do not clearly take into account both of them.
8. Conclusion
The domain requirements (C&V requirements) should
be identified and represented based on the business goals
of an organization, which drive all differences among prod-
ucts in a product family. This paper proposed the system-
aticapproach toidentify
founded on the business goal, and represent them by the
variable use cases. In particular, first, goal and scenario
modeling for a product line was proposed, which enables
one to identify the variant requirements with the rationale
for them by the requirements traceability links. It is very
meaningful to provide the rationale for the variations
among products since the rationale makes it possible to
handle the variant requirements on the basis of the goals.
Second, the variable use cases with the transfer guiding
rules, which represent the domain requirements for the
product family, were suggested. The transfer rules help to
representunambiguously
Finally, we introduced the supporting tool. It helps to ana-
lyze domain requirements and to generate variable use case
diagram semi-automatically. The final output from the tool
is a variable use case diagram in a format of XML. Thus
this tool can support use case driven approach in the aspect
of the representation and analysis of the domain require-
ments, and also be extended for developing a particular
product within a product line.
Due to the three characteristics mentioned above, this
proposal is original in comparison with other approaches
which did not provide the systematic process identifying
the domain requirements. Now we are studying more com-
plicated goal and scenario modeling and transfer guiding
rules. An empirical validation of the approach is planned
for the near future.
thevariantrequirements
thedomainrequirements.
Acknowledgements
We would like to thank the guest editor, Professor Bae
for considering our paper to be included as part of the
Journal of Systems and Software special issue. This work
was supported by University IT Research Center Project
(ITRC) in Korea.
References
Anto ´n, A.I., 1996. Goal-based requirements analysis. In: Proceedings of
the second International Conference on Requirements Engineering,
Colorado Springs, CO, pp. 136–144.
Bertolino, A., Fantechi, A., Gnesi, S., Lami, G., Maccari, A., 2002. Use
case description of requirements for product lines. In: Proceedings
REPL’02, pp. 12–18.
Chastek, G. et al., 2001. Product line analysis: a practical introduction.
Techical report CMU/SEI-2001-TR-001, Software Eng. Inst., Carne-
gie Mellon University, Pittsburgh.
Chastek, G. et al., 2002. Product line production planning for the home
integration system example. Techical note CMU/SEI-2002-TN-029,
Software Eng. Inst., Carnegie Mellon University, Pittsburgh.
Dardenne, A., Fickas, S., van Lamsweerde, A., 1991. Goal-directed
concept acquisition in requirements elicitation. In: Proc. IWSSD-6—
Sixth Int’l Workshop Software Specification and Design, Como, Italy,
pp. 14–21.
Geyer, L., Becker, M., 2002. On the Influence of Variabilities on the
Application-Engineering Process of a Product Family. In: Chastek, G.
(Eds.), Proc. 2nd Software Product Line Conf., LNCS 2379, Heidel-
berg, Germany, 1–14.
Griss, M.L. et al., 1998. Integrating feature modeling with the RSEB. In:
Proc. 5th Int. Conf. on Software Reuse (ICSR’98), Victoria, BC,
Canada, pp. 76–85.
Jacobson, I. et al., 1997. Software Reuse-Architecture, Process and
Organization for Business Success. Addison-Wesley.
Jacobson, I., Booch, G., Rumbaugh, J., 1999. The Unified Software
Development Process. Addison Wesley.
Jaring, M., Bosch, J., 2002. Representing variability in software product
lines: a case study. In: Chastek, G. (Ed.), Proc. 2nd Software Product
Line Conf., LNCS 2379, Heidelberg, Germany, pp. 15–36.
John, I., Muthig, D., 2002. Tailoring use cases for product line modeling.
In: Proceedings REPL’02, pp. 26–32.
Kang, K.C. et al. 1990. Feature-oriented domain analysis (FODA)
feasibility study. Technical Report, CMU/SEI-90-TR-21, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh.
Kang, K.C. et al., 2002. Feature-oriented product line engineering. IEEE
Software 9 (4), 58–65.
Kim, J.W., Kim, J.T., Park, S.Y., Sugumaran, V., 2004. A Multi view
approach for Requirements analysis using goal and scenario. Ind.
Manage. Data Syst. J. 104 (9), 702–711.
Maßen, T., Lichter, H., 2002. Modeling variability by UML use case
diagrams. In: Proceedings REPL’02, pp. 19–25.
Myllyma ¨ki, T., 2001. Variability management in software product lines.
Archimedes Technical report.
Nurcan, S., Grosz, G., Souveyet, C., 1998. Describing business processes
with a use case driven approach. In: Pernici, B., Thanos, C. (Eds.),
Proc. 10th Int’l Conf. CAiSE ’98, Lecture Notes in Computer Science,
1413. Springer, Pisa, Italy.
Park, S.Y., Kim, M.S., Sugumaran, V., 2004. A scenario, goal and feature
oriented domain analysis approach for developing software product
lines. Ind. Manage. Data Syst. (IMDS) J. 104 (4), 296–308.
Plihon, V., Ralyte ´, J., Benjamen, A., Maiden, N., Sutcliffe, A., Dubois, E.,
Heymans, P., 1998. A reuse-oriented approach for the construction of
scenario based methods. In: Proc. Int’l Software Process Assoc. Fifth
Int’l Conf. Software Process (ICSP ’98), Chicago, pp. 14–17.
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938
937

Page 13

Potts, C., 1997. Fitness for use: the system quality that matters most. In:
Proc. Third Int’l Workshop Requirements Eng.: Foundations of
Software Quality REFSQ ’97, Barcelona, pp. 15–28.
Potts, C. et al., 1994. Inquiry-based requirements analysis. IEEE Software
11 (2), 21–32.
Prat, N., 1997. Goal formalisation and classification for requirements
engineering. In: Proc. Third Int’l Workshop Requirements Eng.:
Foundations of Software Quality REFSQ ’97, Barcelona, pp. 145–156.
Rolland, C., Achour, C., Cauvet, C., Ralyte ´, J., Sutcliffe, A., Maiden, N.,
Jarke, M., Haumer, P., Pohl, K., Dubois, Heymans, P., 1998a. A
proposal for a scenario classification framework. Requirements Eng.
J. 3 (1), 23–47.
Rolland, C., Souveyet, C., Achour, C., 1998b. Guiding goal modeling
using scenarios. IEEE Trans. Software Eng. 24 (12), 1055–1071.
Sommerville, I., Sawyer, P., 1997. Requirements Engineering: A Good
Practice Guide. Wiley.
Speck, A., Clauss, M., Franczyk, B., 2002. Concerns of variability in
bottom-up product-lines. In: Proceedings of the Workshop on Aspect-
Oriented Software Development.
Sutcliffe, A., 1998. Scenario based requirement analysis. Requirements
Eng. J., 48–65.
Vici, A.D., Argentieri, N., 1998. FODAcom: an experience with domain
analysis in the Italian telecom industry. In: Proc. 5th Int. Conf. on
Software Reuse (ICSR’98), Victoria, BC, Canada, pp. 166–175.
Jintae Kim is a Ph.D. candidate in the Department of Computer Science
and Engineering at Sogang University. He is going to receive the Ph.D.
degree in Computer science in 2005. He received his B.S. degree from
Sogang University in 2000. From 2000 to 2001, he worked for Dacom
System Technologies as a software engineer. In 2003, he received the Best
Paper Award in Korea Conference on Software Engineering. His current
research interests are Software variability management, Adaptive soft-
ware, and Requirements Engineering. He is a member of the Korea
Information Science Society and IEEE Society.
Minseong Kim received his B.S. degree in computer science from Sogang
University, Korea, in 2001. From January 2001, he was a teaching assis-
tant at Department of Computer Science and Engineering at Sogang
University, until he received the M.S. degree in 2003. In 2002, he received
the Paper Award from Korea Information Science Society. He is currently
a Ph.D. candidate and his research interests include software product
lines, requirements engineering, and self-managed systems.
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 University, in
1988, and the Ph.D. in Information Technology with major in Software
Engineering from George Mason University, in 1995. In 1994, he received
an American Institute of Aeronautics and Astronautics (AIAA) Software
Engineering Award. He served as a Senior Software Engineer at TRW ISC
during 1996–1998. His research interests include requirements engineering,
embedded and adaptive software development, software architecture.
938
J. Kim et al. / The Journal of Systems and Software 79 (2006) 926–938