Information about http://www.omg.org/docs/ptc/07-03-09.pdf
OMG SysMLTM Requirements Traceability …
Tags: annex, concrete syntax, element tables, header rows, omg, paragraph, partial satisfaction, proposed solution, ptc, representative examples, requirement statement, rfp, rtm, section 6, section header, space limitations, tions, uml, umns,Pages: 26
Language: english
Created: Wed Jul 25 11:08:08 2007
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
OMG SysMLTM Requirements Traceability
(informative)
This document has been published as OMG document ptc/07-03-09 so it can be referenced by
Annex E of the OMG SysMLTM specification.
This document describes the requirements tracability matrix (RTM) that shows how SysML satisfies the requirements in Sec-
tions 6.5 (Mandatory) and 6.6 (Optional) of the UML for SE RFP (OMG document ad/03-03-41). The matrix includes col-
umns that correspond to those identified in the first paragraph of Section 6.5 of the RFP and are restated here. The text
requirement statement is included in the RFP and was excluded from this document due to space limitations.
a) The UML for SE requirement number.
b) The UML for SE requirement name (or other letter designator). Note: The reader should refer to the UML for SE
RFP for the specific text of the requirement, since there was inadequate room in the table to repeat it here.
c) Describes whether the proposed solution is a full or partial satisfaction of the requirement, or whether there is no
solution provided. The section header rows that do not have a text requirement are marked N/A.
d) A description of how SysML addresses the requirement. Note: In some cases, there may be other SysML solutions
to satisfy the requirement, but the intent was to describe at least one solution.
e) The specific UML and SysML metaclasses that address the requirement.
f) Reference to the applicable chapter in the SysML specification which addresses e) above. This diagram element
tables in the chapter describe the concrete syntax (symbols) that show how the solution to the requirement is
represented in diagrams. The usage examples in the chapters along with sample problem in "Annex B: Sample
Problem" describe how the solution to the requirement is used in representative examples. Note: The reference to
a chapter may require reference to a corresponding chapter in the UML specification. For example, when the
blocks chapter is referenced, this may include a combination of the SysML blocks chapter and the UML classes
and composite structure chapters.
Table E.1 - Requirement Traceability matrix
UML for Requirement Compl Requirement Satisfaction Metaclass SysML Ver #
SE Req't name (Y/N, Extension Diagram
# Partial) Chapter
6.5 Mandatory
Requirements
6.5.1 Structure N/A Structure diagrams include block Structural
definition, internal block, and Constructs
package diagrams
6.5.1.1 System Y Block composition (black or SysML::Block, Blocks 1.0
hierarchy white diamond) in a block UML::Association,
definition diagram and parts in SysML::Block
internal block diagrams are the Property
primary mechanisms for
representing system hierarchy.
OMG SysMLTM Adopted Specification 1
a. Subsystem Y Typically represented by a set of SysML::Block, Blocks 1.0
(logical or logical or physical parts in an SysML::Block
physical) internal block diagram that Property
realize one or more system
operations. The corresponding
sequence diagram and activity
diagram with swim lanes can
represent a hybrid of structure
and behavior.
b. Hardware Y Represented by a block or part. SysML::Block, Blocks 1.0
(i.e., electrical, SysML::Block
mechanical, Property
optical)
c. Software Y Represented by a block or part or SysML::Block, Blocks 1.0
a UML component. SysML::Block
Property,
UML::Component
d. Data Y Represented by a block or part. SysML::Block, Blocks 1.0
Refer to input/output SysML::Block
requirements in 6.5.2.1.1 and Property,
6.5.2.5 for data flows. SysML::ValueType,
UML::DataType
e. Manual Y Represented by a block or part. SysML::Block, Blocks 1.0
procedure Can also be represented by the SysML::Block
standard UML stereotype Property,
. UML::Document
f. User/person Y Represented by a block or part. SysML::Block, Blocks 1.0
External users are also SysML::Block
represented as actors in a use Property
case diagram.
g. Facility Y Represented by a block or part. SysML::Block, Blocks 1.0
SysML::Block
Property
h. Natural Y Represented by a block or part. SysML::Block, Blocks 1.0
object SysML::Block
Property
i. Node Y Represented by a block or part. SysML::Block, Blocks 1.0
SysML::Block
Property
6.5.1.2 Environment Y Environment is one or more SysML::Block, Blocks, 1.0
entities that are external to the SysML::Block
system of interest and can be Property Use Case
represented as a block or part of
a broader context. Also,
represented as actors in use
cases.
2 OMG SysMLTM Adopted Specification
6.5.1.3 System Internal block diagram shows SysML::Block, Blocks 1.0
inter- connections using parts, ports, SysML::Block
connection and connectors. Property, UML
Association,
UML::Connector:
SysML::Nested
ConnectorEnd
6.5.1.3.1 Port Y A port defines an interaction SysML::Standard Ports and 1.0
point on a block or part that Port, Flows
enables the user to specify what
can flow in/out of the block/part UML::Interface,
(flow port) or what services the SysML::FlowPort,
block/part requires or provides SysML::Flow
(Standard Port). Ports are Specification,
connected using connectors. SysML::Flow
Property
6.5.1.3.2 System Y The enclosing block for an SysML::Block Blocks, Ports 1.0
boundary internal block diagram and its and Flows
ports. SysML::Standard
Port,
SysML::FlowPort
6.5.1.3.3 Connection Y A connector binds two ports to UML::Association, Blocks 1.0
support interconnection. A UML::Connector,
connector can be typed by an SysML::Nested
association. A logical connector ConnectorEnd
can be allocated to a more
complex physical path depicting
a set of parts, ports, and
connectors (refer to allocation).
Note: A connector has limited
decomposition capability at this
time.
6.5.1.4 Deployment of Y A structural allocation SysML::Allocation, Allocations 1.0
components to relationship enables the SysML::Allocated,
nodes allocation (deployment) of one UML::Named
structural element to another. Element
a. Y Software part, block or SysML::Allocation, Allocations 1.0
component deployed to a SysML::Allocated,
hardware part or block SysML::Block,
(processor or storage device). SysML::Block
Property,
UML::Component
b. Y Generalized deployment SysML::Allocation, Allocations 1.0
relationship between a deployed SysML::Allocated,
element and its host. SysML::Block,
SysML::Block
Property
OMG SysMLTM Adopted Specification 3
c Y Deployed element and host can SysML::Block, Allocations 1.0
be decomposed using blocks and SysML::Block
parts. Property
6.5.2 Behavior N/A Behavior diagrams include Behavioral
activity, sequence, and state Constructs
machine diagrams.
Communication diagrams,
interaction overview diagrams,
and timing diagrams are
interaction diagrams that are not
included in SysML. Use case
diagrams are also viewed as a
behavior diagram in that they
represent the functionality in
terms of the usages of the system,
but do not depict temporal
relationships and associated
control flow or input/output flow.
6.5.2.1 Functional A behavior is the generalized UML::Behavior Activities
Transformation form of a function with inputs
of Inputs to and output parameters. Activity is
Outputs a subclass of behavior.
6.5.2.1.1 Input/Output Y Inputs and outputs can be UML::Parameter, Activities, 1.0
represented as parameters of UML::ObjectNode, Ports and
activities, object nodes flowing SysML::ItemFlow Flows
between action nodes, and as
item flows between parts in an
internal block diagram. Note:
Object nodes are more precisely
represented by pins on action
nodes.
a Y Parameters, object nodes, and SysML::Block, Activities, 1.0
item properties are typed by UML::Parameter, Ports and
classifiers (blocks or value types) UML::ObjectNode, Flows
that can have properties. SysML::ItemFlow
b Y The classifiers that represent the SysML::Block, Activities, 1.0
things that flow (type of UML::Parameter, Ports and
parameter, object node, and item UML::ObjectNode, Flows, Blocks
property) can be decomposed and SysML::ItemFlow
specialized.
c Y "ItemFlows" associate the things SysML::Block, Activities, 1.0
that flow with the connectors that UML::Parameter, Ports and
bind the ports. The parameters UML::ObjectNode, Flows
and object nodes are bound to SysML::ItemFlow
the corresponding activities and
actions.
4 OMG SysMLTM Adopted Specification
6.5.2.1.2 System store Partial Stored items can be represented SysML::Block, Blocks, 1.0
as parts of a block, and also SysML::Block Activities
represented in an activity Property,
diagram as object nodes or
central buffer nodes. UML::ObjectNode
UML::Central
BufferNode
a Partial Object nodes in an activity UML::ObjectNode, Activities 1.0
diagram can represent depletable UML::DataStore
stores, and a data store node can Node
represent non-depletable stores.
b Y A stored item can be the same SysML::Block, Blocks, 1.0
type of classifier as an input or SysML::Block Activities
output in both an internal block Property,
diagram and an activity diagram. UML::ObjectNode,
The classifier supports different UML::DataStore
roles (store vs. flow). Node
6.5.2.1.3 Function Y Activity specifies a generic UML::Activity Activities, 1.0
subclass of behavior that is used Interactions,
to represent a function definition State
in activity diagrams, sequence Machines
diagrams, and state-machine
diagrams. Activities contain
CallBehaviorActions that call
(invoke) other activities to
support execution of the generic
behaviors.
a Y Behaviors and the associated UML::Behavior Activities, 1.0
parameters are named (i.e., name Interactions
of activity and activity parameter
node). State
Machines
b Y The action semantics define UML::CreateObject Activities, 1.0
different types of actions that Action, Interactions
include CreateObject, UML::DeleteObject
DestroyObject, Action, the various State
ReadStructuralFeature (monitor), object modification Machines
and WriteStructurealFeature actions in UML,
(update). A CallBehavior action monitoring with
is a generalized action that can UML::AcceptEvent
call any behavior (activity, Action
interaction, state).
c Y The object nodes (pins) bind UML::ObjectNode, Activities 1.0
input and output parameters to UML::Pin
actions.
OMG SysMLTM Adopted Specification 5
d Y The queuing semantics for object UML::Behavior, Activities 1.0
nodes are specified. The default SysML::InputPin,
queuing is FIFO, but other forms SysML::ObjectNode
of queuing including LIFO,
ordered, and unordered as
defined by the enumeration for
ObjectNodeKind.
e Partial Resource constraints to support UML::Constraint, Activities, 1.0
an execution can be specified by Constraint
Preconditions and SysML::Constraint Blocks
PostConditions. The constraints Block
can apply to resources that are
generated, consumed, produced,
and released, such as inputs and
outputs, or the availability of
memory or CPU. The constraints
imposed on the resources can be
further modeled using parametric
diagrams.
f Y Refer to c UML::ObjectFlow, Activities 1.0
UML::Pin
g. Y An activity can be decomposed UML::Activity, Activities 1.0
into lower level actions that UML::CallBehavior
invoke other activities. Action, UML::Activity
ParameterNode,
UML::ObjectFlow,
UML:: Pin
h. Y An action has control inputs that UML::Action, Activities, 1.0
can enable the execution of a UML::Interruptible State
function, and a control value ActivityRegion, Machines
input from a control operator SysML::ControlValue
that can both enable or disable UML::State
an execution of a function. An
execution of a function can also
be terminated when it is enclosed
in an interruptible region.
Alternatively, state machine
diagrams can be used to enable
or disable execution upon
transition events.
6 OMG SysMLTM Adopted Specification
i Y A computational expression can UML::Activity, Activities, 1.0
be used to specify the behavior UML::Action Interactions
(i.e. activity) that is invoked by
an action or an action that State
represents a primitive function Machines
such as an arithmetic expression.
Specific math expressions may be
included in a math model library.
The expressions should be
represented in a formal
mathematical language and
specify the language if they are to
be interpreted by a computational
engine.
j Y A continuous or discrete rate SysML::Rate Activities, 1.0
stereotype can be applied to State
inputs and outputs. Inputs and SysML::Continous, Machines
outputs are discrete by default. A SysML::Discrete
time continuous input or output is UML::Parameter
an input or output whose value (isStream=Value)
can change in infinitely small
increments of time. An activity
can accept the continuous inputs
and provide continuous outputs
while executing if the inputs and
outputs are also streaming. An
alternative approach is to
continuously invoke an activity
that does not have streaming
inputs or outputs, in which case
each execution of an activity
accepts the inputs at the start of
execution and produces the
output at the completion of
execution.
k Partial Different actions can invoke UML::Behavior, Activities 1.0
concurrent executions of the UML::Action
same generalized behavior.
Actions can have multiplicity.
6.5.2.2 Function N/A Actions can be activated and Activities, 1.0
activation/ deactivated using multiple Interactions
deactivation mechanisms within SysML as
described below including State
control flows, control operators, Machines
and interruptible regions.
6.5.2.2.1 Control input Y Control flows in activity UML::ActivityEdge, Activities, 1.0
diagrams provide the control Interactions
input. Control flow is represented UML::ControlFlow,
in state machine diagrams by a UML::Transition, State
transitions which activate states UML::Message, Machines
and in sequence diagrams by the SysML::ControlValue
passing of messages.
OMG SysMLTM Adopted Specification 7
a Y Multiple control flows in an SysML::ControlValue Activities 1.0
activity diagram that are input to , SysML::InputPin.is
a single activity node (i.e., Control=true for
action) are assumed to be control queuing
"anded" together.
b Y Control inputs are discrete SysML::ControlValue Activities 1.0
valued inputs that can enable or
disable an activity node.
c Y In activity diagrams, the activity UML::Action, Activities 1.0
is invoked (enabled) when a
token is received by the calling UML::ControlFlow,
action. This includes tokens from UML::ActivityEdge
all mandatory inputs and control
inputs.
d Y In activity diagrams, a control UML::Action, Activities, 1.0
operator can produce an output UML::Interruptible State
control value to disable the ActivityRegion, Machines
execution of an activity. An SysML::ControlValue
action enclosed within an , UML::State
interruptible region also can
disable the execution of an
activity. In state machine
diagrams, transition events can
disable the actions in a state.
e Y An executing activity with non- UML::Activity, Activities, 1.0
streaming inputs and outputs UML::Interruptible State
terminates when it completes its ActivityRegion, Machines
transformation and produces an SysML ControlValue,
output value. An executing UML::Time
activity with continuous Expression,
streaming inputs will terminate UML::State
when it receives a disable from a
control value and/or a signal that
terminates the actions within an
interruptible region. A
TimeExpression can be specified
in a control operator or can
signal a termination in an
interruptible region. An activity
can also be terminated based on
events, including timeout events,
on a transition in a state machine
diagram. In state machine
diagrams, completion events
occur upon completion of an
activity.
f Y The enabling of actions without UML::Action, Activities 1.0
explicit control flows as inputs UML::ObjectNode
are enabled based on the control
associated with its inputs.
8 OMG SysMLTM Adopted Specification
g Y A control flow connects the SysML::ControlValue Activities 1.0
control inputs from one activity , UML::Parameter,
node to another. The control UML::ControlFlow
input can also be the output
control value of a control
operator.
6.5.2.2.2 Control Y A control operator provides the SysML::Control Activities 1.0
operator mechanism apply control logic to Operator,
enable and disable activity nodes. SysML::ControlValue
a Y Control Nodes such as joins, UML::ControlNode, Activities 1.0
forks, etc. provide capability to SysML::Control
activate activity nodes based on Operator,
"and" and "or" logic. A SysML SysML::ControlValue
Control Operator provides the , UML::Parameter
additional capability to disable
an activity node.
b Y A join specification can be used UML::JoinNode with Activities 1.0
to specify arbitrarily complex join specification,
logic for enabling an activity UML::Parameter,
node. A control operator can also SysML::Control
be used to specify complex logic Operator,
for enabling and disabling an SysML::ControlValue
activity node.
c Y The control nodes identified UML::ControlNode, Activities, 1.0
below provide the basic control UML::Interaction Interactions
logic for enabling activity nodes. Operator
Note: multi exit functions are
supported by parameter sets.
Also, Interaction Operators
provide similar logic in Sequence
Diagrams.
c1 Y Decision nodes in activity UML::DecisionNode, Activities, 1.0
diagrams support selection. The UML::Interaction Interactions
"alt" Interaction Operator Operator.Alt
supports selection in sequence
diagrams.
c2 Y Forks in activity diagrams sup- UML::Fork, Activities, 1.0
port a single input flow gener- UML::Interaction Interactions
ating multiple concurrent Operator.par
output flows. The "par" Interac-
tion Operator supports concur-
rent message flow in
Sequence Diagrams.
c3 Y A join "and's" multiple input UML::Join Activities 1.0
flows together resulting in a
single output flow.
c4 Y A merge results a single output UML::Merge Activities 1.0
flow upon arrival of the first of
multiple input flows.
OMG SysMLTM Adopted Specification 9
c5 Y Decision and loop nodes support UML::Decision- Activities, 1.0
iteration and looping. The Node, UML::Loop Interactions
"loop" Interaction Operator Node, Interaction-
supports loops in sequence Operator.loop
diagrams.
c6 N
6.5.2.2.3 Events and Partial Triggers and constraints as Activities, 1.0
conditions guards provide the mechanism Interactions,
for modeling events and State
conditions. Machines
a Partial A trigger can be used to specify UML:: Trigger, Activity, 1.0
an event. Events can be UML::AcceptEvent Interactions
associated with control flows in Action including
activity diagrams, transitions in UML::TimeTrigger, State
state machine diagrams, and UML::Event Machines
sending and receiving of Occurence in
messages in sequence diagrams. Interactions.
Note: Failure event
can be result in
various types of
actions that terminate
an Interruptible
Region in Activities,
etc.
b Y Refer to a) above UML::ActivityEdge, Activity, 1.0
UML::Trigger Interactions
State
Machines
c Y Conditions can be specified as UML::Constraint Activity, 1.0
constraints that define guards to (guard) Interactions
control execution of behaviors.
State
Machines
6.5.2.3 Function-based Y Activity diagrams provide the UML:: Activity Activities 1.0
behavior capability to model function
based behavior.
10 OMG SysMLTM Adopted Specification
6.5.2.4 State-based State machine diagrams provide UML::StateMachine State 1.0
behavior the capability to model state Machines
based behavior with the specific
modeling constructs indicated.
Note 2 response: Activities are
common to each type of behavior
including both function based
and state based. Note 3 response:
A state is defined based on some
invariant being true. The
invariant can include reference to
certain property values.
a Y State UML::State State 1.0
Machines
b Y Simple state UML::State, State 1.0
isSimple=True Machines
c Y Composite states can contain one UML::State State 1.0
region or two or more orthogonal Machines
(concurrent) regions, each with isComposite=True
one or more mutually exclusive
disjoint states
d Y Transitions between states which UML::Transition, State 1.0
are triggered by events with UML::Trigger Machines
guard conditions.
e Y Transition within a composite UML::Transition State 1.0
state (TransitionKind= Machines
Internal)
f Y Pseudo states include joins, forks UML::PseudoState State 1.0
and choice Machines
g Y Transitions between states which UML::Activity State 1.0
are triggered by events with Machines
guard conditions.
h Y Entry, exit, doActivities are UML::Activity State 1.0
performed upon entry or exit Machines
from a state or while in a state.
i Y State machine semantics define UML::State (Note: State 1.0
the ordering of actions that are refer to semantics) Machines
completed when exiting a
composite state (refer to UML
transition semantics). When a
composite state is exited, the exit
actions are executed beginning
with the most nested state.
OMG SysMLTM Adopted Specification 11
j Y Entry and exit actions must be UML::State (Note: State 1.0
completed prior to exiting a state. refer to semantics) Machines
A doActivity does not need to be
completed to execute.
k Y Send and receive signals can be UML::SendSignal State 1.0
sent via actions to interact with Action Machines
other objects.
l Partial The failure and/or exception UML::State State 1.0
states are user defined and Machines
have no uniquely defined rep-
resentation. The use of exit
points on states can be used
to exit the state when a failure
event occurs.
6.5.2.4.1 Activation time Y The interval of time that an UML::SimpleTime Activities, 1.0
activity or state is active can be Interactions,
modeled by a UML Time Trigger State
or Time Interval and Machines
corresponding Time Expression
(refer to UML trigger and
interval notation). Note: A UML
timing diagram is not included in
SysML at this time, but could be
used to model the time associated
with the occurrence of events,
such as state changes, or changes
in property values.
6.5.2.5 Allocation of Y An allocation relationship pro- SysML::Allocation, Allocations 1.0
behavior to vides a generalized capability SysML::Allocated,
systems to allocate one model element UML::NamedElement
to another.
a Y In general, behaviors such as UML::BehavioredCla Allocations, 1.0
activities, interactions, and ssifier and Activities
state machines are owned by UML::Behavior
a Behaviored Classifier which (owned behavior) -
can correspond to an block. Refer to UML
The SysML Allocation relation- Common Behaviors,
ship can be used to explicitly SysML::Allocate,
allocate behaviors to blocks. SysML::Allocate
Alternatively, activity partitions AcitivtyPartition
(swim lanes) can be used to
allocate the action and/or
activity to a part and/or block.
12 OMG SysMLTM Adopted Specification
b Partial An object node in an activity SysML::Block (type of Allocations, 1.0
diagram can be allocated to an ObjectNode to type of Activities,
item that flows in an internal ItemProperty), Ports and
block diagram using an UML::ObjectNode, Flows
allocation relationship. Note: the UML::Property
object node is typed by the same
classifier as the item that flows.
See req't 6.5.2.1.1.
6.5.3 Property N/A Properties and their relation- Blocks,
ships are represented in Constraint
SysML using properties of Blocks
blocks in conjunction with con-
straint blocks to capture the
relationships between them.
6.5.3.1 Property type Y Primitive types, data types, UML:: PrimitiveType, Blocks 1.0
and value types provide the UML::DataType,
capability to model the differ-
ent types of quantitative prop- SysML::Value Type
erties.
a Y Primitive type. UML::Integer
b Y Primitive type. UML::Boolean
c Y Primitive type. UML::Enumeration
d Y Primitive type. UML::String
e Y Primitive type. SysML::Real
f Y Data type. SysML::Complex
g Y Composite data type made up Refer to a-f
of primitive types.
h Y Composite data type made up Refer to a-f
of primitive types.
6.5.3.2 Property value Y Auxiliary 1.0
a Y Value properties are typed by SysML::Block Blocks 1.0
a value type or data type and Property,
have an associated value. SysML::ValueType,
UML::DataType,
b Y A value type can include a SysML::ValueType Blocks 1.0
dimension and units such as (unit and dimension
length and feet or meters. are defined as
blocks in a model
library)
c Y A value property is a block SysML::ValueType, Blocks 1.0
property that is typed by a SysML::Distribution
value type that can have an Definition
associated probability distribu-
tion on its values.
OMG SysMLTM Adopted Specification 13
d Y Source data can be included in UML::Comment Model 1.0
a comment attached to the Elements
property or a user defined ste-
reotype could be applied.
e Y Reference data can be UML::Comment Model 1.0
included in a comment Elements
attached to the property or a
user defined stereotype could
be applied.
6.5.3.3 Property A value property can be a feature SysML::Block, Blocks 1.0
association of any classifier (.i.e., block) SysML::Block
Property
a Y Blocks, parts, or items that SysML::Block, Blocks 1.0
flow can have (or reference) SysML::Block
properties. Property
b Y A function (activity) can have UML::Activity Activities 1.0
properties since it is a class
c Partial An event is specified by a trig- UML::Signal 1.0
ger which is an element. The
element does not have proper-
ties.A signal which is sent
upon the occurrence of the
event can have properties.
d Y A property can be related to SysML::Constraint- Constraint 1.0
other properties through a con- Block, Blocks
straint property SysML::Constraint-
Property
6.5.3.4 Time property Y Time can be treated as a prop- SysML::Block, Blocks, 1.0
erty, typed by a Real that can
represent either continuous or SysML::Block Constraint
discrete time. Time ultimately Property, Blocks,
derives from clocks which can Interactions
SysML::ValueType,
be continuous or discrete.
Clocks can be modeled as SysML::Constraint
blocks which have a time prop- Property,
erty that can be bound to a SysML::Constraint
parameter of a constraint prop- Parameter,
erty (e.g., equation). Time UML::SimpleTime
durations, start and stop times, Package
etc. can be modeled using the
UML time model for time
triggers, time expressions,
intervals, and durations. Note:
More elaborate models of time
and clocks can be found in the
UML schedulability,
performance, and time profile.
14 OMG SysMLTM Adopted Specification
6.5.3.5 Parametric Y The parametric diagram supports SysML::Constraint Constraint 1.0
model modeling of constraints which Block, Blocks
bind parameters of the
constraints to value properties. SysML::Constraint
Property
SysML::Constraint
Parameter,
SysML::Block
Property,
UML::Connector,
SysML::Nested
ConnectorEnd
a Y Constraints blocks and their SysML::Constraint- Constraint 1.0
usages (constraint properties) Block, Blocks
specify the mathematical SysML::Constraint-
relationships/constraints Parameter
between constraint parame-
ters.
b Partial Mathematical and logical SysML::Block Blocks 1.0
expressions can be defined in Property,
SysML in a reference lan- SysML::Distribution-
guage, but there is no inter- Definition
preter built into SysML. The
range of values can be speci-
fied via value properties and
probability distributions per
6.5.3.2a-c.
c Y The reference language for SysML::Constraint- Constraint 1.0
interpreting the constraint can Block Blocks
be included as part of the Con-
straintBlock along with the
compartment for the expres-
sion.
6.5.3.6 Probe N No specific mechanization has N
been provided. In the testing
profile, there is a mechanism to
capture data and create actions
in response to the data. This will
be investigated in a future
version of SysML.
6.5.4 Requirement N/A The requirements diagram Require- 1.0
provides the basic capability ments
for relating text based require-
ments to other SysML models.
OMG SysMLTM Adopted Specification 15
6.5.4.1 Requirement Y A requirement is a stereotype SysML::Requirement Requirements, 1.0
specification of a class in SysML. The vari-
ous subtypes of requirement Non-
are specified as subclasses of Normative
the the requirement stereotype Extensions,
and can include specific prop- Profiles &
erties and constraints on what Model
model elements can satisfy the Libraries
subclass of requirement. A
sample set of subclasses of
requirements are included in
the NonNormative Extensions
Annex C.
Note 1 Y Values and tolerances can be Requirement.text, Require- 1.0
specified as part of the text SysML::Value ments,
property or via property values Property Blocks
and distributions per 6.5.3.2a-
c.
Note 2 Y There is no explicit subclass of SysML::Require- Requirements, 1.0
requirement as a stakeholder ment
need, but a requirement can Non-
be named or subclassed as Normative
"stakeholderNeed." Extensions
Note 3 Y User defined requirements can SysML:: Requirements, 1.0
be added via subclasses to Requirement
specify any type of life cycle Non-
requirement of interest to the Normative
modeler. Extensions,
Profiles &
Model
Libraries
a Y Operational requirement SysML:: Requirements, 1.0
Requirement
Non-
Normative
Extensions
b Y Functional requirement SysML::functional- Requirements, 1.0
Requirement
Non-
Normative
Extensions
c Y Interface requirement SysML::interface Requirements, 1.0
Requirement
Non-
Normative
Extensions
d Y Performance requirement SysML::perfor- Requirements, 1.0
manceRequirement
Non-
Normative
Extensions
16 OMG SysMLTM Adopted Specification
e Y Activation/Deactivation (Con- SysML:: Requirements, 1.0
trol) requirement Requirement
Non-
Normative
Extensions
f Y Storage requirement SysML:: Requirements, 1.0
Requirement
Non-
Normative
Extensions
g Y Physical requirement SysML::physical Requirements, 1.0
Requirement
Non-
Normative
Extensions
h Y Design constraint SysML:: Requirements, 1.0
Requirement
Non-
Normative
Extensions
i Y Specialized requirement SysML:: Requirements, 1.0
Requirement
Non-