Assignment #2 – Requirements Modeling

Assignment #2 ECSE326 
1/2
Assignment #2 – Requirements Modeling (6%)
The second assignment is to be done individually and is due on Monday, October 29th, 2018, at 23:30.
You are required to submit a jucm file with your URN model in myCourses. The URN model must be
based on the descriptions below and compatible with jUCMNav version 7.0. Clearly state the course
name and number, term, and your name in a comment on your feature model. The assignment is graded
out of 100 marks.
URN Model
The goal of this assignment is to use feature modeling, goal modeling, and scenario modeling to describe
the requirements of a system. You are not required to model a complete system, i.e., you may choose a
large system and only model a part of it. You are free to choose any system you would like to work on, as
long as you adhere to the following constraints:
• You must use jUCMNav version 7.0 to create and analyze your requirements model. For
installation instructions, see the folder of the first URN tutorial in myCourses.
• The feature model of your system must contain at least one mandatory feature, at least one
optional feature, and at least one XOR or OR feature group. Note that you will not get bonus
marks for modeling a larger system (i.e., a feature model with at least 6 features is sufficient –
the root feature, one mandatory feature, one optional feature, one parent feature for the
XOR/OR feature group, and two features in the XOR/OR feature group). In addition, add a
comment with a two-paragraph description of your chosen system to your feature model.
• The goal model must describe exactly 1 stakeholder and show how the features of your system
impact the goals of the stakeholder (especially the variable features). In addition, you need to
show the situation without your system in place (i.e., the impacts of the current manual system
or an old system that needs to be replaced by your system). Make sure that you have additional
tasks in your goal model that represent the situation without your system in place. The goal tree
for your stakeholder must contain at least 8 intentional elements (not counting features and the
tasks for the old/manual system). Again, you will not get bonus marks for modeling a larger
system.
• The scenario model must contain a root map that shows the causal relationships of the features
in the feature model, i.e., which feature must occur before or after another feature, which ones
may occur in parallel, and which ones are alternatives. Each feature must be modeled as a stub.
A URN link must be created between each pair of corresponding feature and stub. If a feature
(i.e., the child) is part of another feature (i.e., the parent), then place the stub of the child feature
on the plug-in map of the stub of the parent feature.
• In addition to a stub for each feature, exactly 1 variable feature must be described with a
detailed plug-in map for the stub of the feature. The plug-in map of the chosen variable feature
must include at least one alternative path.
• To analyze the system requirements, you must create 3 strategies. In the preferences, you must
select the “Feature Model Evaluation Algorithm” for your evaluations and set “Should we include
GRL intentional elements as variables for UCM scenarios?” to yes to initialize GRL variables.
1. The “base” strategy describes the current manual or old system. For this strategy,
“automatic selection of mandatory features” needs to be turned off in the preferences.
2. The “feature in” strategy describes a feature configuration of your system where your
variable feature (the one you modeled in more detail with a plug-in map) is selected. For
this strategy, “automatic selection of mandatory features” needs to be turned on in the
preferences. The evaluation of this strategy must show that the strategy is a valid feature 
Assignment #2 ECSE326 / Fall 2018
2/2
configuration, show the impact on the stakeholder’s high-level goals, and enable/disable
the variable feature in your scenario model accordingly with its GRL variable.
3. The “feature out” strategy describes a feature configuration of your system where your
variable feature is not selected. Otherwise, the same rules apply to the “feature out”
strategy and the “feature in” strategy.
• To further analyze the system requirements, you must create 2 scenario definitions. Both of
them start at a start point of your root map and either end with an end point of your root map or
with an end point of the plug-in map of your variable feature. Furthermore, the two scenario
definitions must go through different alternative paths on the plug-in map of your variable
feature. Clearly specify which scenario definition can be executed with which strategy.
Marking Scheme
Part of Assignment Marks
Feature Model 10/15
Comment with description of system 5/15
Goal Model – Stakeholder 20/20
Scenario Model – Root map with all feature stubs including URN links 15/25
Scenario Model – Detailed plug-in map for variable feature 10/25
Analysis – “Base” strategy for manual/old system 6/40
Analysis – Strategy for feature configuration “feature in” 6/40
Analysis – Strategy for feature configuration “feature out” 6/40
Analysis – First scenario definition 7/40
Analysis – Second scenario definition 7/40
Analysis – GRL variables to enable/disable features in scenario model 8/40
Total Marks: 100