Towards a Unified
Req irements
Requirements
Modeling Language
Brian Berenbach
Siemens Corporate Research
Princeton, NJ
Jonas Helming
Maximilian Koegel
Florian Schneider,Michael Haeger
Christine Kaminski
Bernd Brügge
Institut für Informatik
Technische Universität München
Munich, Germany
Page 1© Siemens Corporation, Corporate Research, 2010. All rights reserved.

URML – Why is a visual language needed?
UML and SysML

Unified Requirements Modeling Language! do not follow visualization heuristics! models early requirements of a system
consisting of hardware and software components
from a business level to subsystem decomposition! do not provide a homogeneous orinterdisciplinaryy comprehensible
visualization! provide isolated solutions for specific! current version of the URML focuses on theapplication domain, not the solution domain

aspects like feature modeling or hazard
modeling! provides abstract and solution independent
concept of services! do not provide integrated and interdisciplinary traceability! focuses on visualization, which is intuitively
understandable by non-software engineers andtherefore fosters interinter-disciplinary
disciplinary collaboration
collaboration.
! our goal is to derive a defined grammar forURML from the meta-model.

Although URML is an integrated model, we structure this section by aspects. For every aspect wealso describe the relationships to other aspects of URML. Since a description of the meta-model of
URML including all attributes would go beyond the scope of this paper we will focus on the model
elements and their interrelations and avoid describing all attributes in detaildetail. Terms referencing
elements of our meta-model are formatted with italic font style upon their first occurrence.
Page 2!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6Goal Modeling! URML allows the deriving of realizing
ffeatures
forf featurefmodeling.
d li! !"#$ &'(')d')+,'- allow defining
relationships among goals by either
decomposing a goal into sub
sub-goals
goals ormodeling additional dependencies

Goal Modeling! IsI a prerequisite
i it ffor requirements
itengineering! offers ways to express business,customer and end user goals and how
those goals influence each other! refines goals down to a level offunctional and non-functionalrequirements
it! goals modeled independently from aconcrete deliverable.

Page 3!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6Feature Modeling! typicallyyp
y used to model p
product lines and thefeatures of different products of the same
product line.
! can be used to express complex variation ina single (r"d/+0.
(r"d/+0! features realize goals that were set forth ingoal modeling. They can be refined into subfeatures until theyy are small and feasible
enough to be detailed into 1/)+0,")#$
r'2/,r'3')0- and attached to their constraints
that are modeled as )")41/)+0,")#$
r'2/,r'3')0- Functional and nonr'2/,r'3')0-5
non-functional
functional
requirements are not necessarily end-user
visible, and more important, they are testable.
! Apartp from decomposition,
pfeatures can also
be related by a 1'#0/r' d'(')d')+6.

Page 4!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6Subsystem Decomposition!7'r8,+'- describe which particularfunctionality is offered by thesystem. Therefore a service isrelatedl t d tto a functionalfti
l requirement
itthat is satisfied by that service.
7'r8,+'- +#) 9' d'+"3("-'d ,)0"-/9 services.
-/94services.
!That allows us to describe exactly
where the functionality isimplemented and provides anabstractionb t ti tto aggregate
t servicesiinto units of related functionality.

Page 5!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6Danger Modeling! integrates Hazard Modeling
Modeling, Risk Modeling and Threat and Security Modeling into one
joined set of abstractions. URML merges them into !"#$%&5! A Danger can be mitigated by a requirement from the requirement model or by aprocedural mitigation.

Page 6!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6Visual Notation" URML has a visual notation that is intended to be
intuitively understandable by non-engineers and to foster
inter-disciplinary collaboration.
" The main design is cognitive effectiveness.
" All components, for example Stakeholders, Goals,Features or Requirements, are represented by distinct
symbols.

Four proposed
visualizations of a goal.
Which is best???

" While there are unique symbols for each component,
there must not be too many at once.
" The hardest part in constructing adequate icons is tof
find
the simplest symbol. The decision forf certain
proposed icons must be based on an evaluation amongusers from different disciplines and is part of future work.
" Another related issue is the determination as to when
to use a new symbol vs. when to apply overlays to an
existing symbol

Page 7

Business goal and end
user goal!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6

W are pressed
Wed tot clearlyll defined fi relationships
l tihiIs thisrepresentation
correct?

Page 8!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6

A d a viable
i bl sett off icons
iAnd

Page 9!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6W are still
Wetill getting
tti input
it on Icons
IA “NonfunctionalNonfunctional Requirement
Requirement” describes quality of performance constraints for a system.
Suggestions
wagging forefinger
wooden framework
measuring tapereliability lab
paragraph sign §Brick paper
periphery
thermometerX OVER LIMITING ITEM / "x"empty field
images changing behind a screen
crossed out: technical stuff which is thrown into a box
crossed out maths "F"stop sign
pipelines
oil canbattery
gauge (Anzeigegerät)
stopwatch

Page 10Focus Group
Meeting Ideas!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6Tool Support#UNICASE Research Modeling Tool
# The complexity of URML requires tool support for an evaluation of the approach.
# First planned implementation of the URML is UNICASE.
# UNICASE offers support for collaboration on model elements and versioning.
g UNICASE
offers support for tool instrumentation and project analysis based on historical data.
# Model elements can be directly linked to each other, offering user visible traceability.
# UNICASE allows constructing
g diagram
geditors for arbitrary
y meta-models.

Page 11!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6C
CurrenttRResearch
hAActivities
ti iti$ Surveys and Focus group meetings to improverequirementsq$ Completing a draft taxonomy$ CreatingCa draft
f meta-model$ Implementing in UNICASE$ Complete the semantics--------------------------------------------------$ Future: Pilot on a live Siemens project
Page 12!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6OOpen
researchh questionsti$ WhichWhi h visualil representationt ti iincluding
l di shape
handd stylet lprovides the best Semiotic Transparency andExpressiveness?
$How are references between entities visualized?
$Which entities are represented as distinct icons
icons, whichfamilies are represented by altered tokens?
$ How to achieve Graphic Economy on complex models?

Page 13!"#$%&%'(")*r,*r-.$*'/")*r,*r-.%"0%(%-r12/"34546"788"r$92.("r%(%r:%d6Page 14© Siemens Corporation, Corporate Research, 2010. All rights reserved.