ProductLinRE∗
Online Management Tool for Requirements Engineering of Software Product Lines
Javad Ghofrani
Department of Informatics
Clausthal University of Technology
Clausthal-Zellerfeld, Germany
javad.ghofrani@gmail.com
ABSTRACT
The lack of online tools for managing various artifacts of software
product lines is problematic, and stands in contradiction to findings
about the need to support collaboration. In this paper, we present
ProductLinRE, a web application allowing product line engineers
to work cooperatively on artifacts of requirements engineering for
software product lines. Our proposed online tool allows distributed
teamwork, using a tracking mechanism for projects, artifacts and
features while tailoring the requirements artifacts according to the
selected features.
CCS CONCEPTS
• Software and its engineering → Reusability; Software prod-
uct lines; Collaboration in software development; Software
libraries and repositories;
KEYWORDS
Software product lines, requirements engineering, online tools
ACM Reference Format:
Javad Ghofrani and Anna Lena Fehlhaber. 2018. ProductLinRE: Online Man-
agement Tool for Requirements Engineering of Software Product Lines. In
22nd International Systems and Software Product Line Conference - Volume
B (SPLC ’18), September 10–14, 2018, Gothenburg, Sweden. ACM, New York,
NY, USA, Article 4, 6 pages. https://doi.org/10.1145/3236405.3236407
1 INTRODUCTION
The lack of online tools for managing the planning phase of pro-
duction in software product lines (SPLs) [5] is problematic, and
contrary to findings about the need to support collaboration [19].
According to Pereira el al. [18], a tool aimed for the planning phase
can provide functionality for: (1) pre-analysis of documentation, (2)
construct a matrix of the domain (product-feature matrix), and (3)
scope definition. Therefore, we developed an online tool to support
these functionalities. This tool allows distributed teamwork, using
a tracking mechanism for projects, artifacts and features while sup-
porting the reuse of artifacts. It helps the project managers as well
∗ http://productlinre.com
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
SPLC ’18, September 10–14, 2018, Gothenburg, Sweden
© 2018 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-5945-0/18/09.
https://doi.org/10.1145/3236405.3236407
Anna Lena Fehlhaber
Leibniz Universität Hannover
Hannover, Germany
fehlhaberlena@gmail.com
as application engineers to manage the related artifacts of features
[2].
1.1 Background
SPL tools are used to develop a portfolio of products in various
domains such as transportation systems, mobile solutions, medical
systems, energy, automotive, and industrial solutions.
SPLs are sets of different software products with specific sim-
ilarities [5]. They are often large-scale, highly complex systems,
with an immense amount of variability — which makes it an intri-
cate task to design them, with heightened risks to create unwanted
side-effects [8]. To process according product specifications man-
ually, is therefore a complex, tedious and error-prone task [18]. It
has therefore been recommended to split large-scale models into
smaller, more manageable modules [8], to be able to organize and
re-utilize them [11].
Re-usability has become a key aspect of developing and main-
taining SPLs [14]. Accordingly, a distinct change from a project
focused approach towards a more product centered strategy oc-
curred within the economy over the decades [9].
Motivation. SPL management tools generally lay a focus on the
creation of artifacts, i.e. small- to mid-size modules, which can be
shared and reused in similar products, if necessary [18]. In product-
line-engineering, it is usually the stated goal to reach peak pro-
ductivity by maximizing asset re-usability in a varying number of
products [4]. Re-usability of artifacts is one of the basic topics in SPL
research. There are many tools from old to new for enhancing the
reuse of software artifacts in SPLs. These tools are supporting the
reuse of artifacts within a SPL, allowing the reuse of artifacts across
different SPLs — The proposed approach by Filho et al. [15] and
S.P.L.O.T1 are examples of such tools. Current SPL tools do not pro-
vide specific support for requirements engineering (RE) activities
in SPL Management — despite the principle of uniformity [2], most
of them support the reuse of other types of artifacts, like feature
models, architecture models, configuration models and software
components as libraries, while artifacts of RE are neglected.
Because nowadays teams work in distributed locations in dif-
ferent time zones with different languages spoken, especially for
large scale projects, managing and coordinating the team is very
difficult, as is managing and coordinating the SPLs. The possibility
to work together with online tools is a very useful solution for
these problems. By providing a distributed platform that transfers
the changes and updates in the system with less delay all over the
world, a SPL management tool could achieve more acceptance.
1 http://splot-research.org/
SPLC ’18, September 10–14, 2018, Gothenburg, Sweden
Although many RE tools provide support of collaborative work
(e.g. Rational Requirements composer of IBM Jazz2 ) , their focus
is on handling only the requirements which are in most cases in
the form of text description. These tools focus on preventing the
replication of requirements which are common between members
of a product family and do not support the handling the common
artifacts between these requirements. Furthermore, the existing
tools which support the collaborative works, do not support the
aforementioned functionalities of the planning phase of product
lines by Pereira et al [18] , i.e., pre-analysis documentation and
matrix of domain in order to reuse artifacts. An other important
difference is our focus on usability and re-usability aspects, which is
not a main concern of other existing tools - Actually, there is as far
as we know no existing tool which focuses on usability aspects (see
also [3]). There are also some other approaches such as Filho et al.
[15] which propose a repository based approaches for development
of SPLs. Although this approach considers the reuse of the related
components to architecture, implementation and features of a SPL,
the artifacts of RE are not well considered.
Contribution. This paper tackles the lack of online tools for prod-
uct management of product lines while considering the supporting
usability. We present ProductLinRE, an online management tool
which helps the product managers to handle the artifacts of require-
ments engineering for any domain. It provides the re-usability for
different types of artifacts between and within projects. Analysis of
scoping, commonality and variability (SCV) in product line require-
ments engineering [13] are supported by ProductLinRE. In addition
to these wanted features in product line requirements engineering,
ProductLinRE supports asset management as well. Asset manage-
ment is the unique feature to the SPL which plays an important role
not only in RE, but in all the phases of the lifecycle of a product line.
It provides effective reusability of assets by application engineers
[1].
2 ONLINE PRODUCT MANAGEMENT TOOL
The main idea behind this tool is to fill the gaps of an online tool
for managing the artifacts of RE for product lines [18]. Given that
today’s complexity in software requirements is increasing, filling
these gaps is important in several aspects. The variety and the num-
ber of these requirements makes managing and monitoring them
more complex and error-prone. On the other hand, the existence
of such a tool provides the communication between the stakehold-
ers that leads to improvement in the quality of the outputs of the
requirements analysis phase.
Furthermore, it uses a simple tagging mechanism that facilitates
the reuse of exactly needed artifacts for certain features in various
projects. One of the core aspects our tool offers is the online func-
tionality: ProductLinRE allows multiple users to work together on
managing projects, features and artifacts, rendering collaborative
work possible.
Besides the general benefits of the collaborative online tools,
such as saving time and communication costs as well as fast access
to knowledge and experts, our collaborative tool facilitates the reuse
of artifacts of requirements engineering. Since producing artifacts
2 https://jazz.net/products/rational-requirements-composer
Javad Ghofrani and Anna Lena Fehlhaber
is time consuming, solutions such as templates are used in most
cases which are suitable in textual explanation of the requirements.
Though, the artifacts of RE are not limited to these type of docu-
ments. Generating images, movies and models is time consuming
and requires investigations. Such artifacts can at least be utilized
for inspiration, elicitation and validation of requirements as well as
ascertaining stable communications between stake holders. Using
online tools increases the level of reuse which leads to optimization
in usage of resources, time and expenditure to describe the details
to the requirements engineers. Although distributed tools can cover
this case partially, handling the online solutions (e.g. update, change
or maintain) are in most cases easier since they don't need special
platforms, drivers, or extra version controls and installations.
2.1 Work-flow of ProductLinRE
The ProductLinRE online tool manages certain product lines, called
projects within ProductLinRE. The tool itself is able to handle vari-
ous product lines, and allows the shared access to artifacts. These
projects can be generated with ProductLinRE for managing them.
Furthermore, ProductLinRE provides a repository of artifacts tagged
to different features. If the users are searching for the artifacts of
a certain feature, they can search it in this repository and reuse it
instead of creating new feature or collecting new artifacts.
Figure 5 demonstrates the work-flow process of creating a new
project. Each product line is considered a project in our online tool.
After naming the project, features have to be added. Optionally,
each feature may have a connection with several artifacts. The
artifacts themselves are arbitrary, and can be chosen from existing
ones. If no existent artifact is suitable for a certain feature, a user-
defined amount of new artifacts can be added. These artifacts may
be video, audio, image or text data, or even XML files. The artifacts
will be tagged to the features as a complete file or a piece of it.
The user can specify the artifacts data type, as well as the relevant
fragments of the artifacts content for further management purposes.
Figure 1 illustrates an example of embedded tagging mechanism to
get a part of an image artifacts and link it to a certain feature. In the
case of the need for more features, they can be added to the project
in the next step. If there’s no further need of more features, the
project is completed for the time being. Editing, deleting and adding
of features and artifacts are possible during the entire process.
Finally, ProductLinRE provides a product-feature-matrix for each
project that delegates a product line (Figure 2 illustrates an exam-
ple of such matrix). The members of the product family and the
existing features will be listed as two dimensions of this matrix.
The product manager can select the features for each product. Pro-
ductLinRE provides a download button which tailors the tagged
artifacts according to the selected features and generates a pack-
age of them. This package contains only required artifacts for the
analysis and development of selected product. It can be used by
application engineers especially for RE purposes.
3 EXAMPLE OF UTILIZATION
In order to showcase the abilities of ProductLinRE, we describe a
fictional cooperative work between two application engineers. Both
users are registered with our tools and have access to the projects,
features and artifacts as they log in. They can create new projects,
 Browse” > "Assets"" in the navigation bar and search all the assets
You still have the option "Browse”
in the repository. You can also use the built-in
built search function.

Delete assets
You cannot delete assets.

Artefacts
ProductLinRE SPLC ’18, September 10–14, 2018, Gothenburg, Sweden

Table 1: Feature-Product-Matrix for User 1

products/features withdraw touch-pad security

P1 x
P2 x
P3 x x

Table 2: Feature-Product-Matrix for User 2

products/features withdraw touch-pad security deposit

P1 x x
P2 x x

ProductLinRE User 2 works on a similar project in another place and doesn’t

Figure 1: Tagging a part of a Picture Artifact even know user 1. He should also manage a family of products for a
Figure 5: Cut a Picture Artefact from Asset bank as ATMs. His project has also an additional feature as follow-
ication-Feature-Matrix ing: Some machines are equipped with a deposit option. Before the
Defining new artefacts money withdrawal process, the customer should be asked whether
To add new artefacts, select the features in which you want to add the artefact. Then select he has a deposit or a would like to make a withdrawal. Instead of col-
"Add Artefact".". Then choose whether you want to upload a new asset or want to use an
existing one.
lecting new artifacts, he searches first for his required features and
finds them in the project created by user 1. He makes a copy of men-
You will be directed to the artefact file corresponding to the files of type, and you may betioned able features and starts his project. Then, he uploads his artifacts
to edit the artefact there. about the new feature and adds them to his product-feature-matrix,
Alternatively, you can specify a URL of the file. Please note that the link must lead directly which
to is depicted in Table 2. Reuse is not only supported within
the file. A YouTube link for example,
ex refers not on the video and is not ot allowed
allowed. the project by assigning the artifacts once and using them in three
products of a same family, but it is also supported by reusing the
artifacts from other projects.
Both users work actively on their projects and user 1 makes a
Figure 3: Application-Feature-Matrix small change on the selected artifact for the withdrawal. User 2 will
Figure 2: Example of Product-Feature-Matrix for a product
be informed about the new changes and can also apply them to his
properties of line the provided
application by ofProductLinRE
a product line are defined by using the Application Application-
project. Any changes will occur in the origin project only. In case
ture-Matrix.
Matrix. To do this, you only need to add or remove the checkbox signs.
of new changes, the people who reuse the artifacts will be notified.
nload applications But they are free to accept changes or keep their own copy without
features and artifacts. We introduce the following specification for
accepting the changes. If a user copies a new project or feature, a
u have addeda all product line of Auto
the features to aTeller Machinesand
application (ATM).filled all the features with artefacts,
new project will be generated only with reference to the old project
can export it. That The means
ATM shouldin thisbe case,
operable youviacan
a touch-pad
download andathe
zippin
fileinput
with the application
and is a separate project alone.
e, applicationshould be madeand
description, via aallpin
thepad. Some ATMs
features could be operated
w describing
with artefactsby To do this, select
artefacts.
Download icon blind people.
to the rightThe
ofmoney issue should be done via a slot, which only
the Application-Feature-Matrix.
Application
during the dispensing process opens wide enough. As a security
4 WORKING TOGETHER ON SPL
ssing first time, option, the machinewill
the download should jerk the card
be provided. so that
After a fraudster
a second can not
press, MANAGEMENT WITH PRODUCTLINRE
you can download
zip file. read the bank data by a third-party device. Working cooperatively with ProductLinRE is one of the most im-
These specifications are captured per video during the meetings portant aspects the tool can offer, and it’s even some kind of unique
te applicationof the developer team and the customer. There are some sketches selling point, considering there are barely any online tools for SPL
that showselect
delete an application, how thethetouch-pad
button with is tothe
be cross
designed and an
behind XML
the file
application, management.
on the right The main benefit is our focus on usability, carried
e matrix in a that contains the use cases for money disposal.
project. over by an online functionality and usability design decisions. Es-
User 1 creates a project and defines the following features for pecially motivation is lacking for most of the tools reviewed by
his/her product family: withdraw, touch-pad, security. He/she de- Bashroush, so it’s useful to focus on motivation impact factors.
fines three products P1, P2 and P3. These products and features There are quite a lot of examples to mention: Sysiphus-IVMM [20],
are listed in Table 1. Furthermore, this user can upload the gener- which investigates the issue-based variability management (IVM)
ated artifacts (captured videos from meetings, use cases and the by extending variability management with rationale management,
sketches as image files) and assign the defined features to the parts DecisionKing [6], which is part of DOPLER [7] approach, DOPLER
of the video, XML file and the image sketches. These artifacts and itself, AORA [21], which covers aspect-oriented requirements anal-
features are stored in the repository of ProductLinRE. User 1 can ysis, Kumbang [16], a modeller and configurator, DREAM [17] for
now generate a set of files which contains only the related artifacts domain requirement management, Holmes [19], DARE, [10], and
for each of the mentioned products in the product-feature-matrix. even further tools have the neglect of an online functionality in
SPLC ’18, September 10–14, 2018, Gothenburg, Sweden
common. Because working together in distributed teams over var-
ious geographical locations becomes increasingly important and
seems to have a positive impact on work flow and user experience
[12], it was our utmost concern to integrate an online functionality
in ProductLinRE, despite the prior mentioned tracking problems.
4.1 Evaluating ProductLinRE Referring to
Usability and User Experience
For evaluation purposes, we conducted a qualitative survey and
assignment of tasks with eight test persons. All of them had a
background in computer science, but despite one subject, none of
them had any experience with SPL management tools. As men-
tioned before, user experience, usability and collaborative work
are the main features of ProductLinRE, so it was convenient that
almost all of our test persons had no prior experience with SPLs.
Because of the above-mentioned quality requirements, which can
be valued individually, we focused on a qualitative approach for our
evaluation. Therefore, we asked our test subjects after assigning
the tasks about upcoming difficulties, overall progression with the
tasks, usage and problems with the manual, general usability, user
experience over the whole scope and performance of ProductLinRE.
The result indicated that even if half of our subjects wasn’t able
to solve the task without errors, everyone, except one person, was
able to finish the tasks. Few of them used the manual, and rated the
usability and overall user experience with high values. They stated
some missing aspects within the user manual, so we overhauled
the manual later on. Even those who didn’t used the user manual at
all rated usability and user experience from average to good, mean
value somewhat lower to those persons which used the manual.
For future work, we want to conduct an experiment with more test
persons and advanced surveys to establish an adequate methodol-
ogy for measuring usability of SPL management tools, which is a
severe research gap at the moment [3]. The limited results at the
moment seem to show that ProductLinRE becomes accepted due
to its intuitive and user-friendly behaviour, generating an overall
high-ranking usability.
5 CONCLUSION AND FUTURE WORK
ProductLinRE is an online software product line management tool
for requirements engineering, allowing collaborative work on man-
aging the artifacts of requirements engineering for software product
lines trough online tracking of projects, features and artifacts. Our
findings indicate that ProductLinRE has found acceptance amongst
our subjects. They stated a good overall usability while experi-
encing ProductLinRE, which was one of our main goals we tried
to accomplish with ProductLinRE’ online functionality. There are
barely any online software product line management tools available
until now, therefore ProductLinRE will bridge this gap.
The most obvious challenges for our approach are (1) handling
the origin of the artifacts (copyright) and (2) labeling the artifacts
in the way that the other users can find and reuse them easily.
Since our tool is an online tool, it inherits the common challenges
of online and distributed systems, such as security and problems
related to network. However, most of these challenges have stable
solutions that are dependent to the use case of this tool. In future
work, we are going to utilize the relationships between words to
Javad Ghofrani and Anna Lena Fehlhaber
facilitate the search functionality that works based on assigned tags
to the features. Furthermore, supporting the constraints between
the features of product lines [2] is postponed to the future work.
6 APPENDIX
This section contains the domain model (Figure 3), the MVC di-
agram (Figure 4), and the work-flow diagram (Figure 5) of our
proposed tool.
REFERENCES
[1] Vander Alves, Nan Niu, Carina Alves, and George Valença. 2010. Requirements
engineering for software product lines: A systematic literature review. Informa-
tion and Software Technology 52, 8 (2010), 806–820.
[2] Sven Apel, Don Batory, Christian Kästner, and Gunter Saake. 2016. Feature-
oriented software product lines. Springer.
[3] Rabih Bashroush, Muhammad Garba, Rick Rabiser, Iris Groher, and Goetz Bot-
terweck. 2017. CASE Tool Support for Variability Management in Software
Product Lines. ACM Comput. Surv. 50, 1, Article 14 (March 2017), 45 pages.
https://doi.org/10.1145/3034827
[4] Elder Cirilo, UirÃą Kulesza, and Carlos Lucena. 2008. A Product Derivation Tool
Based on Model-Driven Techniques and Annotations. 14 (01 2008), 1344–1367.
[5] Paul Clements and Linda Northrop. 2001. Software Product Lines: Practices and
Patterns. Addison-Wesley Professional.
[6] Deepak Dhungana, Paul Grünbacher, and Rick Rabiser. 2007. DecisionKing: A
Flexible and Extensible Tool for Integrated Variability Modeling. VaMoS 2007
(2007), 01.
[7] Deepak Dhungana, Paul Grünbacher, and Rick Rabiser. 2011. The DOPLER meta-
tool for decision-oriented variability modeling: a multiple case study. Automated
Software Engineering 18, 1 (2011), 77–114.
[8] Nicolas Dintzner, Uirá Kulesza, Arie van Deursen, and Martin Pinzger. 2014.
Evaluating Feature Change Impact on Multi-product Line Configurations Using
Partial Information. In Software Reuse for Dynamic Systems in the Cloud and Be-
yond, Ina Schaefer and Ioannis Stamelos (Eds.). Springer International Publishing,
Cham, 1–16.
[9] Christof Ebert and Michel Smouts. 2003. Tricks and Traps of Initiating a Product
Line Concept in Existing Products. In Proceedings of the 25th International Con-
ference on Software Engineering (ICSE ’03). IEEE Computer Society, Washington,
DC, USA, 520–525. http://dl.acm.org/citation.cfm?id=776816.776882
[10] William Frakes, Ruben Prieto-Diaz, and Christopher Fox. 1997. DARE-COTS.
A domain analysis support tool. In Computer Science Society, 1997. Proceedings.,
XVII International Conference of the Chilean. IEEE, 73–77.
[11] Stephan Herrmann, Mira Mezini, and Klaus Ostermann. 2001. Joint efforts to
dispel an approaching modularity crisis - Divide et impera, quo vadis? (2001).
[12] J. Highsmith and A. Cockburn. 2001. Agile software development: the business of
innovation. Computer 34, 9 (Sep 2001), 120–127. https://doi.org/10.1109/2.947100
[13] CharlesW Krueger. 2001. Easing the transition to software mass customization.
In International Workshop on Software Product-Family Engineering. Springer, 282–
293.
[14] Horst Lichter, Thomas von der Maçen, Alexander Nyçen, and Thomas Weiler.
2003. Vergleich von AnsÃďtzen zur Feature Modellierung bei der Softwarepro-
duktlinienentwicklung. (07 2003).
[15] Sindolfo Miranda Filho, Heitor Mariano, Uirá Kulesza, and Thais Batista. 2010.
Automating Software Product Line Development: A Repository-Based Approach.
In Software Engineering and Advanced Applications (SEAA), 2010 36th EUROMICRO
Conference on. IEEE, 141–144.
[16] Varvana Myllärniemi, Mikko Raatikainen, and Tomi Männistö. 2007. Kumbang
Tools.. In SPLC (2). 135–136.
[17] Jihyeon Park, Mikyeong Moon, and Keunhyuk Yeom. 2004. Dream: domain
requirement asset manager in product lines. In International Symposium on Future
Software Technology (ISFST).
[18] Juliana Alves Pereira, Kattiana Constantino, and Eduardo Figueiredo. 2015. A
systematic literature review of software product line management tools. In Inter-
national Conference on Software Reuse. Springer, 73–89.
[19] Giancarlo Succi, Jason Yip, and Witold Pedrycz. 2001. Holmes: an intelligent
system to support software product line development. In Software Engineering,
2001. ICSE 2001. Proceedings of the 23rd International Conference on. IEEE, 829–830.
[20] Anil Kumar Thurimella and Bernd Bruegge. 2012. Issue-based variability man-
agement. Information and Software Technology 54, 9 (2012), 933–950.
[21] Patrícia Varela, João Araújo, Isabel Brito, and Ana Moreira. 2011. Aspect-oriented
analysis for software product lines requirements engineering. In Proceedings of
the 2011 ACM Symposium on Applied Computing. ACM, 667–674.
ProductLinRE SPLC ’18, September 10–14, 2018, Gothenburg, Sweden
ProductLinRE domain model

User
avatar binary
confirmation_sent_at datetime
confirmation_token string
confirmed_at datetime
current_sign_in_at datetime
current_sign_in_ip string
description text
email string  21 27 U
encrypted_password string  12 72 SecurityQuestion
failed_attempts integer  21 27
answer string
image string
locale string
is_admin boolean
question string
last_sign_in_at datetime
last_sign_in_ip string
locked_at datetime
name string  21 27 U
remember_created_at datetime
reset_password_sent_at datetime
reset_password_token string
sign_in_count integer  21 27
unconfirmed_email string
unlock_token string

Artifact
description text  12 72
name string  21 27

Project
description text  21 27
name string  12 72

Feature
description text  21 27
name string  21 27

ActiveStorage::Blob
byte_size integer (8)  12 72
Passage Product
checksum string  21 27
content_type string description text  22
17 description text  21 27
filename string  12 72 name string  12 72 name string  12 72
key string  21 27
metadata text

ActiveStorage::Attachment
name string  21 27
record_type string  21 27

Figure 3: ProductLinRE Domain Model

SPLC ’18, September 10–14, 2018, Gothenburg, Sweden Javad Ghofrani and Anna Lena Fehlhaber

Project User

name: String name: String

description: String description: String
0..*
features: Feature[] avatar: Image
products: Product[]
1 password: String 1
createProject(name, description) email: String
showProject(id) createUser(name,email,password,description)
editProject(id) 1..* showUser(id)
deleteProject(id) editUser(id, name, email, password,
description)
deleteUser(id)
1 1
1..*
0..*
0..*
Feature
Product 1 ..*
name: String
name: String description: String Editor
description: String 1 1..* products: Product[]
features: Feature[] artifacts: Artifact[] addArtifactToFeature(artifact, feature)
passages: Passage[] 1..* addPassageToFeature(passage, feature)
createProduct(name, description)
showProduct(id) createFeature(name, description) addFeatureToProduct(feature,product)
1..*
editProduct(id, name, description) showFeature(id) copyFeature(feature,targetProject)
deleteProduct(id) editFeature(id, name, description) copyProject(project)
deleteFeature(id) downloadZip(product)
1..* logout(user)
1 1

1..* 1
Login
0..* 1..*
1..* login()
10..*
1..*
register()
Artifact
Passage
name: String
name: String description: String
features: Feature[] 1..* 1 passages: Passage[] 1..*
begin: String features: Feature[]
end: String type: String
file: File
createPassage(name, begin, end)
showPassage(id) createArtifact(name, desc, file, type)
editArtifact(id, name, begin, end) showArtifact(id)
deleteArtifact(id) editArtifact(id, name, desc)
deleteArtifact(id)

Figure 4: ProductLinRE MVC Diagram

new project

name project

add feature

want
artifact(s) No
for this
feature?
Yes
Yes

does an No need
add and specify completed
artifact more
artifact(s types) No project
exist? feature?

Yes
No
artifact(s)
relevant
for
feature?

Yes
choose existing
artifact(s)

Figure 5: Work-flow process of creating a new project in ProductLinRE