Hernán Casalánguida and Juan Eduardo Durán
Facultad de Matemática, Astronomía y Física, Universidad Nacional de Córdoba, Medina Allende s/n, Córdoba, Argentina
Keywords: Web engineering, Requirements engineering, Product line engineering.
Abstract: Application families (AF) are usually developed to reduce time to market and development costs of applica-
tions. Therefore, it is attractive to investigate the development of web AF (WAF) and to have an adequate
requirements engineering (RE) method for WAF. A problem little studied is how to classify use cases (UC)
for rich internet applications (RIA); to give better guidance to the developer we define a taxonomy for RIA
UCs. UCs are described using UML activity diagrams (AD) in some web methods, but the taxonomies for
actions proposed in them can be improved, because there are not enough action classes or they are too
monolithic; for this reason we define a new action classification for RIA ADs. Studying the AD variability
notations, we found a set of requirements for them; we define a notation for ADs satisfying these require-
ments and fulfilling some of them in a better way than in the literature. Non-functional requirements (NFR)
for WAF must be documented. There are some goal-based approaches with variabilities; but they do not
consider the modeling of NFRs and only consider examples for hard goals. We extend the NFR framework
for the description of NFRs adding to it modeling elements for expressing variabilities.
In general, AFs when well implemented help enor-
mously reduce time to market and decrease develop-
ment costs of applications. For several business
areas there are many web applications that are
similar, in terms of the functionality they offer; in
addition, a software company could develop several
web applications for a specific business area.
Therefore it is interesting to investigate the
development of WAF. As a first step we consider it
is important to have an adequate RE process for
WAF. To the best of our knowledge the field of
RIA RE has not been properly exploited and we did
not find a paper about RE of RIA families; for this
reason these are topics of study in this work.
A problem little studied is how to classify UC for
RIAs; only WebRE+ (Luna et al., 2010) considers a
stereotype <<RIA specification>> for RIA behav-
iors; and we think that more than one stereotype
should be used for different kinds of RIA behavior.
We have decided to base UC variability modeling on
(Bragança, 2007) and to define a UML profile in
order to have a taxonomy for RIA UCs.
The presence of asynchronous events and
asynchronous requests in a RIA UC introduces
concurrent behaviors in UCs which can lead to too
much scenarios and describing all of them can be
costly; for this reason we think it is more convenient
to describe a RIA UC using a notation with
constructs for concurrency. UML AD notation has
modeling elements for concurrency and was used in
some web approaches that consider RE: UWE (Koch
et al., 2008), OOWS (Valderas, 2004), WebRE+
(Luna et al., 2010). The taxonomies for actions
proposed in these approaches can be improved,
because there are not enough action classes or they
are too monolithic.
There exist some approaches for defining AD
with variabilities (Riebisch et al., 2000, Robak et al.,
2002, Reuys et al., 2006, Bragança, 2007, Korherr
and List, 2007; Schnieders and Weske, 2007,
Razavian and Khosravi, 2008, Heuer et al., 2010),
studying them in depth we found the following
requirements for AD notations with variabilities:
R1: Describe variation points inside an AD.
R2: Avoid the use of stereotypes for variant
R3: Use cardinality or interval notation for defining
variation points in AD.
R4: Avoid the use of AD elements to represent vari-
Casalánguida H. and Durán J..
DOI: 10.5220/0003348704180425
In Proceedings of the 7th International Conference on Web Information Systems and Technologies (WEBIST-2011), pages 418-425
ISBN: 978-989-8425-51-5
2011 SCITEPRESS (Science and Technology Publications, Lda.)
abilities, and do not clutter AD modeling elements
with variability information.
R5: Provide well-defined and simple specialization
semantics for ADs with variabilities.
R6: Describe dependencies between variants inside
the AD.
R7: Consider data flow variability.
Another problem is the appropriate documenta-tion
of NFRs for WAF. Feature models (FM) - see
(Schobbens et al., 2006) - do not take into account
several aspects in the area of NFR like: the impact of
non-functional qualities on the functional part of a
system, contributions of softgoals to some other
softgoals, correlations between quality goals, argu-
mentations, goal prioritization, evaluation pro-
cedures. The use of aspect-oriented FMs (Kulesza et
al., 2005) improves the situation, because it allows
expressing how a feature for a non-functional quality
affects other features; but the other aspects men-
tioned are not contemplated. Goal-based approaches
with variabilities recently have arisen (Semmak et
al., 2008; António et al., 2009); but they do not deal
with NFRs modeling and only consider case studies
for hard goals.
The objectives of this paper are: to define an AD
notation for capturing variabilities considering
(possibly in a better way) the above requirements; to
define a more detailed taxonomy of actions to give
better guidance to the developer; and the definition
of a NFR notation with variabilities that considers
the facilities in the field of NFR.
We define in Subsect. 2.1 a profile that extends
the UC model for RIAs and in Subsect. 2.2 an action
taxonomy to be used for RIA UCs description. In
Subsect. 2.2 we present an AD with variabilities
notation fulfilling requirements R1 to R7 (some of
them in a better way than in the literature – see Sect.
4). In Sect. 3 we extend the NFR framework (Chung
et al., 2000) adding to it some modeling elements for
variability expression.
2.1 A Use Case Model for WAF
To maintain the original UML 2.0 UCMs, we only
use from (Bragança, 2007) the additions to UML 2.0
UCMs to model variabilities. A variability annota-
tion is represented as a note to be linked to include
or extend relationships and represents a variability
point with a name, a minimum and a maximum
cardinality and the respective options. The family
UC metamodel presents two new elements used to
annotate variability: Extend-Variability and Include-
Variability (see Fig. 1).
Figure 1: Variability Notation for UC Models.
In addition to use well known UC classes for
Web applications it is necessary to find other classes
of UC that contemplate typical RIA features like
(some of them found in (Wright and Dietrich 2008)):
run-time interface update, auto-suggest, real-time
form validation, hover detail for items of
A job is an execution of one or more operations
(i.e. input validation, information modification, or a
calculation) by the system without user intervention.
A Job support step (JSS) consists of the collection of
inputs, the use of them for the execution of a job,
and the possible presentation to the user of the result
of the job. A content visualization step (CVS) is a
presentation of content (possibly as a consequence to
user inputs and/or search of information).
We consider the following four classes of UC:
1. «Task»: A task consists of a sequence of JSS. A
«task» UC is a UC whose instances are tasks (i.e.
each UC execution performs a task).
2. «Navigation»: A navigation consists of a se-
quence of CVS, possibly decided by a user. A
«navigation» UC is a UC whose instances are
navigations performed by a user (i.e. each UC
execution consists of a navigation).
3. «RIA Navigation»: A RIA navigation involves
one or more CVS taking into account specific RIA
interface features or the execution of asyn-chronous
search (i.e. a search request is made and the system
continues with its execution in-stead of waiting for
the end of the search to continue); in addition some
content visualize-tion steps can be concurrently
4. «RIA Task»: A RIA task involves one or more
JSS that take into account specific RIA interface
features or the execution of asynchronous jobs (i.e. a
job execution request is made and the sys-tem
continues with its execution instead of wait-ing for
the end of the job to continue); the JSSs can be
concurrently performed. A «RIA task» UC is a UC
whose instances are RIA tasks.
The first two UC stereotypes are taken from
(Casalánguida and Durán, 2009).
Fig. 2 shows a UCM for an AF of libraries.
There is an includeVariability element saying that
the «task» UC reserveItem is optional. There is an
extendVariability element expressing that the
developer has to choose one between registerLoan
with credits and registerLoan with payment. The UC
findBooks is of stereotype «RIA navigation» because
we decided it will consider autosuggestion and live
search. The UC loanItem is of stereotype «RIA task»
because it uses real time form validation.
Figure 2: UC Model for a Family of Online Libraries.
2.2 Describing Use Cases
We consider the following stereotypes for actions:
«Search» Actions: they represent database
queries (i.e. relational, object-oriented, XML) or
information retrieval. They could have an input pin
for the parameters needed to make the query and an
output pin for the result of the query.
Actions: they are call behavior actions,
whose activity performs a job. They could have
input pins for the parameters of the job and an
output pin for the result of the job.
Actions: they represent the provision of
an input by an human actor. They could have as
output pins the values provided by the user.
«Output Request» Actions: they represent the
request by the system for the provision by a human
actor of some inputs.
«Output Content» Actions: they represent the
system displaying content (for instance, the result of
a job, the result of queries). They could have as
input pins the values to show.
If an action needs to be executed as a transaction,
the stereotype «transaction» must be used. For the
execution of «transaction» actions, the ACID
properties are valid.
To consider control flow variability, we need to
be able to express that a sequence of actions inside
an AD is optional or variant; for this purpose we use
UML activity groups. An ActivityGroup is an
abstract class for defining sets of nodes and edges in
an activity. A VariabilityActivityGroup (VAG) is an
ActivityGroup where grouped nodes and edges
represent the execution of a sequence of actions
inside an activity; in addition, there exists at most
one node in the VAG (which is not a connector
node) that is the destination of an activity edge
which originated outside the VAG. A VAG is
denoted by a dotted line rectangle with a name in the
upper part and the grouped nodes and edges inside.
An ActivityEdge can be optional or variant with
the meaning that the action pointed by the Activity-
Edge will be chosen if the ActivityEdge is chosen.
For data flow variability we need to be able to
express that a data item is optional or variant; for
this purpose, we use from UML 2.0 ObjectNode and
its specializations InputPin and OutputPin.
We propose the use of variability comments that
are assigned to activity edges, to VAGs, and to
object nodes. For this purpose, we add a metaclass
called Variability which is described in Fig. 3. A
control flow variability is a variability that takes into
account activity edges (not leading to final nodes)
and VAGs and a data flow variability is a variability
that considers object nodes. A control flow vari-
ability with interval a..b (min to max), optionsAE
AE and optionsAG AG has the meaning: choose n
arcs in AE and m activity groups in AG where a n
+ m b.
Figure 3: Variability Metaclass.
In a variability element there is at least one
option to be chosen.
If a variability involves more than one variant,
then such variants must be preceded by a fork node.
If a variability element has as variants all the
nodes/VAGs following a fork node, we use an
interval near the fork node and not a variability
WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies
Elements ActivityEdge, VAG and objectNode
not included in variability objects are mandatory.
Fig. 4 shows an AD for a part of a purchase UC
of an electronic commerce AF; this AD contains the
optional VAG called add discount; inside this VAG
there is a variability saying that exactly one of the
actions below the fork must be chosen.
Figure 4: AD for part of Purchase UC.
Fig. 5 shows an example of data flow variability
for the Payment UC.
Figure 5: Data flow variability in Payment UC
Another kind of variability not explained in vari-
ability approaches for AD is business rule vari-
ability: sometimes for a job to be executed a busi-
ness rule must be valid; such a business rule can be
variable among different WAF members. This fact is
expressed with a decision node whose branches
point to the same action and a variability with
cardinality [1..1] is related to all the branches.
Fig. 6 shows an example of business rule vari-
ability in addMember (to a library) UC. There is a
decision node with all conditions leading to the Add
member action, and there is a variability saying that
only one of these conditions must be chosen.
Figure 6: Business Rules in addMember UC.
In Fig. 7 metaclasses for dependency constraints
(DC) are presented. A variant consists of a vari-
ability name and of either an objectNode or an Ac-
tivityEdge or a VAG or a UC. A DC can be of type
excludes (denoted with a left-right arrow) or
requires (denoted with a left arrow) and has a name.
We have two kinds of DCs:
DC involving variants of an AD: Such DCs have
a dependent, which can be a control flow vari-ant or
an ObjectNode. The dependent depends on a non-
empty set of variants inside the AD (obtained by
navigating the roles in and depend-ence on of the
corresponding metaassociations)
DC involving an AD variant and a UC variant:
Such DC has a dependent that is a control flow
variant. The dependent depends on a UC variant
(obtained through navigating the roles in and
dependence on of the corresponding meta-
asociations). For instance: an AD for the UC
loanBook contains an optional action called Check
for Reserved Item and there is a DC of type requires
between the action Check for Reserve Item and the
UC reserveItem.
In Fig. 4 there is an example of a DC called A of
type requires between calculate bonus points action
and send mail with bonus details action.
Fig. 5 provides an example of two DC of type
requires: one called B between outputPin debit card
data and action check debit card data, and the other
called A between outputPin credit card data and
action check credit card data.
Now we describe a specialization algorithm for
ADs. Assume that decisions of variants according to
compile time variabilities have been taken and DCs
are respected; the specialization of an AD is another
AD obtained by applying the following rules:
Figure 7: Metaclasses for DC Modeling.
1. If a variability involves only one variant, then the
variant is deleted from the AD if this variant has not
been chosen. Next, remove the variability.
2. If a control flow variability takes into account
more than one variant, then each variant that has not
been chosen is deleted from the AD. After that,
delete nodes fork and join of the variability if only
one activity edge points to the join node of the
variability. Next, remove the variability.
3. If a data flow variability considers more than one
variant, then each variant that has not been chosen is
deleted from the AD. Next, remove the variability.
4. For a business rule variability each activityEdge
variant that has not been chosen is deleted from the
AD. Next, remove the variability.
By space reasons, it is not explained in detail how to
delete a variant. The idea is to remove the variant
element in case of being a VAG or an object node,
and to remove both the variant element and the
action pointed by it in case of being an
ActivityEdge. In addition, it may be necessary to
remove some arcs leading to or going out of the
variant element in case of being a VAG or an object
node). In several cases it is necessary to replace the
elements deleted by an activityEdge.
In case of nesting of some control flow vari-
abilities, rule 3 is systematically applied from outer
to inner levels of nesting.
Within a UC description actions with stereotype
«include» are activity behavior actions that represent
the execution of an included UC. The name of an
«include» action is a name of an included UC,
whose description is externally made to the
including UC with an AD.
Each extension UC is described with an AD. For
each extension UC, extension rules are defined
which consist of the following parts:
Base UC: name of the extended UC.
Condition: condition that must hold for the in-
sertion of the extension UC.
Extension Points: this is a list of extension point
descriptions, specifying the places in the UC’s AD
where the UC extension execution is inserted; a
place can be before or after a specific action
occurrence. An extension point descript-tion has the
following syntax: (after | before) (action name |
extension point name). An action name is used if the
action occurs only once in the base UC’s AD;
otherwise an extension point name is used.
Each extension point name is added as the value of a
tagged value named extension point name, which is
assigned to the arrow leading to the desired activity
occurrence in the base UC’s AD.
In an AF all the extension point names should be
unique (i.e. the same extension point name cannot be
used in different UCs or in different action occur-
rences within a base UC’s AD).
The NFR framework (Chung et al., 2000) presents
softgoals and their relationships inside softgoal
interdependency graphs (SIG). The modeling el-
ements of a SIG are softgoals - that can be: NFR
softgoals, operatinalizing softgoals (OS), or claims -
and contributions - that can be: AND-decomposi-
tion, OR-decomposition, degree of contribution -
MAKE (++), HELP (+), HURT (-), BREAK (--).
To be able to describe SIGs of an AF that will be
specialized to application SIGs respecting the NFR
framework, we define a metamodel called NFRV
(see Fig. 8) that extends the NFR framework to take
into account variabilities.
A OS or a NFR softgoal may participate in one
or more variabilities. A Variability element has a
name and a cardinality given by two integers called
min and max.
We define the following variability constraints:
A NFR-softgoal or OS cannot have two variabilities
with the same name. If two softgoals (NFR or OS)
have a common variability, then they are offspring
of the same father.
It is not possible to define a variability for a
subset of softgoals of an AND/OR decomposition,
WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies
because all possible softgoals of an AND or OR
decomposition must be present on any family
member to satisfy the decomposition; if we allow to
choose a proper subset of the decomposition’s
softgoals for a product line member, then the
semantics of AND/OR decompositions is not
respected. For this reason, we define new kinds of
decompositions for supporting variabilities:
ANDVariability: One or more variabilities com-
prise the components of the decomposition and all
the softgoals chosen according to such variabilities
are necessary to achieve the father of the
ORVariability: One or more variabilities com-
prise the components of the decomposition and at
least one of the softgoals chosen according to such
variabilities is necessary to achieve the father of the
Figure 8: NFRV Metamodel.
A variability is represented with a UML annota-
tion for variant softgoals. An ANDVariability el-
ement is represented in the same way as an AND
decomposition. An OrVariability element is repre-
sented in the same way as an OR decomposition. If
in a variability V with cardinality [0..1] participates
only one softgoal that participates only in V, then
this softgoal is called optional and is represented
putting a question mark inside the softgoal cloud. If
there is one variability with cardinality a..b
comprising all the members of an ANDVariability or
ORVariability, then omit the variability annotation
and instead put “[a..b]” near the decomposition.
The graph formed by a softgoal S and its de-
scendants (contributions and softgoals) in the SIG is
denoted by DG(S). The set obtained by removing
from DG(S) all the DG(T) such that T is a
descendant of S and T contributes to a softgoal
outside of DG(S) is denoted by DGO(S). Assume
that decisions of variants according to variabilities
have been taken. The specialization of a SIG NFRV
is a SIG obtained by applying the following rules:
If a softgoal S is optional, and S has not been
chosen, then the relations of S with its parents and
DGO(S) are deleted.
If an ANDVariability with father F contains a
variability V, then remove V and for each vari-ant M
of V that has not been chosen delete the relation
between F and M and DGO(M). The selected
variants are offspring of F and are related to it via an
AND decomposition.
If an ORVariability with father F contains a
variability V, then remove V and for each vari-ant M
of V that has not been chosen delete the relation
between F and M and
DGO(M). The selected
variants are offspring of F and are related to it via an
OR decomposition.
If V is a variability with its variants contributing
in some degree to a father softgoal F, then remove V
and for each variant M of V that has not been
chosen delete the relation between F and M and
Fig. 9 Shows a SIG NFRV for usability. This
softgoal is decomposed using an AND-Variability
into Errors, Efficiency and Learnability using a vari-
ability of cardinality 2..3 (i.e. at least two of the
three softgoals must be chosen in specialization
time). The OS Show related data and Use site maps
are optional, and can be selected or not when
Efficiency is chosen. The mandatory OS Use help is
decomposed using an ORVariability into OS Help
general index, Help tips and Help Agent. Help tips
and Help agent is a group of variant softgoals with
cardinality 1..1 (i.e. one of them will be chosen in
specialization time). The optional OS Suggest fields
also contribute to Use help.
WebRE+ (Luna et al. 2010) uses the stereotypes
«Search» (for querying contents), «Browse» (for
navigation), «UIAction» (for actions performed by
the user in a «UIElement») and «userTransaction»
(for actions involving a transaction operation). In
contrast with our approach, WebRE+ activities
performed by the user are not separated from activ-
ities performed by the system (for instance «Search»
and «UserTransaction» activities need the involve-
ment of both the user and of the system); in addition
a «userTransaction» activity may be very complex
and could be decomposed into smaller ones.
Figure 9: SIG with Variabilities for Usability.
In OOWS (Valderas 2004) the stereotypes
«search» (for actions performing information
«function» (for actions executing function-
ality), «output» (for output interaction points), and
«input» (for input interaction points) are considered.
Table 1 shows the stereotypes for AD provided
by our work and related approaches. Our approach
permits to express WebRE+ stereotypes for content
visualization steps (CVS) and «User Transaction»
by using some distinct stereotyped actions.
Table 1: Stereotypes for ADs in Web Methods.
Objective WebRE+ OOWS Our work
Browse Input,
Output content,
Output request
CVS with
Search Input,
Input, Search,
Output content,
Output request
with a
Output Content,
Output request,
Search, Job,
Input UIAction Input Input
- output output request
- output Output content
transaction - - Transaction
In WebRE+ (Luna et al. 2010) a UC can be of
stereotypes «Navigation», «WebProcess» or «RIA
Specification» (for a behavior involving RIA specif-
ic features). The first two stereotypes are covered in
our work by the «Navigation» and «Task» stereo-
types and the third is contemplated by our «RIA
navigation» and «RIA task» stereotypes.
Table 2 provides a comparison of AD notations
for variability management w.r.t. the requirements
from R3 to R7 (presented in the introduction).
Below we justify the results in detail.
Table 2: comparison of AD with variabilities notations.
R3 R4 R5 R6 R7
Bragança. no no no no no
Heuer et al. good reg+ good good no
reg no no no good
and List
no no reg no no
and Weske
no no no no good
Robak et al. no no no no no
Our work very
R3: full use of cardinalities for variabilities: only in
(Heuer et al., 2010) and our work. In contrast to our
work in (Heuer et al., 2010) this information is
captured by Boolean expressions outside the AD.
R4: do not use AD elements to represent vari-
abilities: only in (Riebisch et al., 2000; Heuer et al.,
2010) and our work. From these approaches only our
work does not put variability information in AD
R5: presentation of some specialization rules: in
(Schnieders and Weske, 2007; Heuer et al., 2010)
and our work. For an exhaustive specialization
algorithm we only found (Heuer et al., 2010) and our
work. Do not use other notations in the special-
ization algorithm: only in our work ((Heuer et al.,
2010) uses Petri nets).
R6: use of DCs: in (Heuer et al., 2010) and our
work. In contrast to our work (Heuer et al., 2010) is
more restricted in the kind of DC that can be
expressed (variants represent sets of actions) and
DCs are defined outside the AD by means of
Boolean expressions.
R7: Use of data flow variability: only in (Razavian
and Khosravi, 2008; Schnieders and Weske, 2007)
and our work. Use of cardinalities in data flow
variabilities and do not use stereotypes in data flow
variabilities: only in our work.
WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies
In this paper we presented a RE method for WAF
considering both RIA and Web 1.0 applications.
UML tools can be used for drawing ADs and
UCMs for WAFs, because our extensive use of
variability annotations.
Our notation for AD variability management
satisfies all the requirements stated in the introduc-
tion and permits to express both data flow and
control flow variabilities.
We proposed the documentation of business rule
variability in ADs; we did not find papers consider-
ing this for ADs. In addition, we considered a more
complete treatment of DCs in ADs than in the
literature. Furthermore, because of the use of
annotations to model variabilities the documentation
of data flow variabilities is simpler than in the
approaches found in the literature.
Our method has been tested by considering parts
of an electronic commerce WAF and of an online
library WAF. Such examples are representative of
data intensive Web 1.0 or RIA WAFs.
We defined the specialization algorithms taking
preservation of syntactic correctness into account. In
the future we plan to check for the AD specialization
algorithm the preservation of behavioral correctness.
In addition we plan to continue validating our RE
process with other interesting RIA families.
António, S., Araújo, J., Silva C., 2009. Adapting the i*
Framework for Software Product Lines. In: ER’09.
LNCS 5833, pp. 286-295, Springer-Verlag.
Bragança, A., 2007. Methodological Approaches and
Techniques for Model Driven Development of Soft-
ware Product Lines. PHD-Thesis, Universidade do
Minho, Escola de Engenharia.
Casalánguida, H., Durán, J., 2009. Modelado Orientado a
Aspectos de Navegación para Aplicaciones Web
basado en UML. In IEEE Latin America Transactions,
Vol. 7, N° 1, pp 92—100.
Chung, L., Nixon, B., Yu, E., Mylopoulos, J., 2000. Non
functional Requirements in Software Engineering.
Kluwer Academic Publisher, Boston.
Heuer, A., Budnik, Ch., Konrad, S., Lauenroth, K., Pohl,
K., 2010. Formal Definition of Syntax and Semantics
for Documenting Variability in Activity Diagrams. In
SPLC’10. LNCS 6287, pp 62--76.
Koch, N., Knapp, A., Zhang, G. Baumeister, H., 2008.
UML-Based Web Engineering. An Approach Based
on Standards. In Web Engineering: Modelling and
Implementing Web Applications, Human Computer
Interaction Series, Springer, pp. 157--191.
Korherr, B., List, B., 2007. A UML 2 Profile for
Variability Models and their Dependency to Business
Processes. In DEXA´07, pp 829--834.
Kulesza, U. García, A., Bleasby, F., Lucena, C., 2005.
Instantiating and Customizing Product Line
Architectures using Aspects and Crosscutting Feature
Models. In EA’05, Workshop on Early Aspects.
Luna, E., R., Escalona, M., J., Rossi, G., 2010. A
Requirements Metamodel for Rich Internet
Applications. In ICSOFT 2010.
Razavian, M., Khosravi, R., 2008. Modeling Variability in
Business Process Models Using UML. In 5
Conf. on Inf. Technology: New Generations, pp 82-87.
Riebisch, M., Böllert, K., Streitferdt, D., Franczyk, B.,
2000. Extending the UML to Model System Families.
In IDPT 2000, Integrated Design and Process
Technology. Society for Design and Process Science.
Robak, S., Franczyk, B., Politowicz, K., 2002. Extending
the UML for Modelling Variability for System
Families. In Intl. Journal of Appl. Math. Comput.
Science, Vol.12, No.2, pp 285–298.
Schnieders, A. and Weske, M., 2007. Activity Diagram
Based Process Family Architectures for Enterprise
Application Families. In: Enterprise Interoperability
2007, Part II, pp 67—76.
Schobbens, P., Heymans, P., Trigaux, J., 2006. Feature
Diagrams: a Survey and a Formal Semantics. In
RE’06, pp 139—148.
Semmak, F., Gnaho, C., Laleau, R., 2008. Extended
KAOS to Support Variability for Goal Oriented
Requirements Reuse. In MoDISE-EUS'08, Vol. 341 of
CEUR Workshop Proceedings, pp 22-33.
Valderas, P., 2004. A requirements engineering approach
for the development of web applications. PHD-thesis,
Departamento de Sistemas Informáticos y
Computación, Universidad Politécnica de Valencia.
Wright, J., Dietrich, J., 2008. Requirements for Rich
Internet Application Design Methodologies. In
WISE´08, LNCS 5175, Springer, pp 106—119.