omg sysml™ requirements traceability - · pdf fileomg sysmltm adopted specification 1...

OMG SysMLTM Adopted Specification 1

OMG SysML™ Requirements Traceability

(informative)

This document has been published as OMG document ptc/07-03-09 so it can be referenced byAnnex E of the OMG SysML™ 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 textrequirement 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 SERFP 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 nosolution 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 solutionsto 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 elementtables in the chapter describe the concrete syntax (symbols) that show how the solution to the requirement isrepresented in diagrams. The usage examples in the chapters along with sample problem in “Annex B: SampleProblem” describe how the solution to the requirement is used in representative examples. Note: The reference toa chapter may require reference to a corresponding chapter in the UML specification. For example, when theblocks chapter is referenced, this may include a combination of the SysML blocks chapter and the UML classesand composite structure chapters.

Table E.1 - Requirement Traceability matrix

UML forSE Req't#

Requirementname

Compl(Y/N,Partial)

Requirement Satisfaction MetaclassExtension

SysMLDiagramChapter

Ver #

6.5 MandatoryRequirements

6.5.1 Structure N/A Structure diagrams include blockdefinition, internal block, andpackage diagrams

StructuralConstructs

6.5.1.1 Systemhierarchy

Y Block composition (black orwhite diamond) in a blockdefinition diagram and parts ininternal block diagrams are theprimary mechanisms forrepresenting system hierarchy.

SysML::Block,UML::Association,SysML::BlockProperty

Blocks 1.0

2 OMG SysMLTM Adopted Specification

a. Subsystem(logical orphysical)

Y Typically represented by a set oflogical or physical parts in aninternal block diagram thatrealize one or more systemoperations. The correspondingsequence diagram and activitydiagram with swim lanes canrepresent a hybrid of structureand behavior.

SysML::Block,SysML::BlockProperty

Blocks 1.0

b. Hardware(i.e., electrical,mechanical,optical)

Y Represented by a block or part. SysML::Block,SysML::BlockProperty

Blocks 1.0

c. Software Y Represented by a block or part ora UML component.

SysML::Block,SysML::BlockProperty,UML::Component

Blocks 1.0

d. Data Y Represented by a block or part.Refer to input/outputrequirements in 6.5.2.1.1 and6.5.2.5 for data flows.

SysML::Block,SysML::BlockProperty,SysML::ValueType,UML::DataType

Blocks 1.0

e. Manualprocedure

Y Represented by a block or part.Can also be represented by thestandard UML stereotype<<document>>.

SysML::Block,SysML::BlockProperty,UML::Document

Blocks 1.0

f. User/person Y Represented by a block or part.External users are alsorepresented as actors in a usecase diagram.


Blocks 1.0

g. Facility Y Represented by a block or part. SysML::Block,SysML::BlockProperty

Blocks 1.0

h. Naturalobject

Y Represented by a block or part. SysML::Block,SysML::BlockProperty

Blocks 1.0

i. Node Y Represented by a block or part. SysML::Block,SysML::BlockProperty

Blocks 1.0

6.5.1.2 Environment Y Environment is one or moreentities that are external to thesystem of interest and can berepresented as a block or part ofa broader context. Also,represented as actors in usecases.


Blocks,

Use Case

1.0


6.5.1.3 Systeminter-connection

Internal block diagram showsconnections using parts, ports,and connectors.

SysML::Block,SysML::BlockProperty, UMLAssociation,UML::Connector:SysML::NestedConnectorEnd

Blocks 1.0

6.5.1.3.1 Port Y A port defines an interactionpoint on a block or part thatenables the user to specify whatcan flow in/out of the block/part(flow port) or what services theblock/part requires or provides(Standard Port). Ports areconnected using connectors.

SysML::StandardPort,

UML::Interface,

SysML::FlowPort,SysML::FlowSpecification,SysML::FlowProperty

Ports andFlows

1.0

6.5.1.3.2 Systemboundary

Y The enclosing block for aninternal block diagram and itsports.

SysML::Block

SysML::StandardPort,

SysML::FlowPort

Blocks, Portsand Flows

1.0

6.5.1.3.3 Connection Y A connector binds two ports tosupport interconnection. Aconnector can be typed by anassociation. A logical connectorcan be allocated to a morecomplex physical path depictinga set of parts, ports, andconnectors (refer to allocation).Note: A connector has limiteddecomposition capability at thistime.

UML::Association,UML::Connector,SysML::NestedConnectorEnd

Blocks 1.0

6.5.1.4 Deployment ofcomponents tonodes

Y A structural allocationrelationship enables theallocation (deployment) of onestructural element to another.

SysML::Allocation,SysML::Allocated,UML::NamedElement

Allocations 1.0

a. Y Software part, block orcomponent deployed to ahardware part or block(processor or storage device).

SysML::Allocation,SysML::Allocated,SysML::Block,SysML::BlockProperty,UML::Component

Allocations 1.0

b. Y Generalized deploymentrelationship between a deployedelement and its host.

SysML::Allocation,SysML::Allocated,SysML::Block,SysML::BlockProperty

Allocations 1.0


c Y Deployed element and host canbe decomposed using blocks andparts.


Allocations 1.0

6.5.2 Behavior N/A Behavior diagrams includeactivity, sequence, and statemachine diagrams.Communication diagrams,interaction overview diagrams,and timing diagrams areinteraction diagrams that are notincluded in SysML. Use casediagrams are also viewed as abehavior diagram in that theyrepresent the functionality interms of the usages of the system,but do not depict temporalrelationships and associatedcontrol flow or input/output flow.

BehavioralConstructs

6.5.2.1 FunctionalTransformationof Inputs toOutputs

A behavior is the generalizedform of a function with inputsand output parameters. Activity isa subclass of behavior.

UML::Behavior Activities

6.5.2.1.1 Input/Output Y Inputs and outputs can berepresented as parameters ofactivities, object nodes flowingbetween action nodes, and asitem flows between parts in aninternal block diagram. Note:Object nodes are more preciselyrepresented by pins on actionnodes.

UML::Parameter,UML::ObjectNode,SysML::ItemFlow

Activities,Ports andFlows

1.0

a Y Parameters, object nodes, anditem properties are typed byclassifiers (blocks or value types)that can have properties.

SysML::Block,UML::Parameter,UML::ObjectNode,SysML::ItemFlow


1.0

b Y The classifiers that represent thethings that flow (type ofparameter, object node, and itemproperty) can be decomposed andspecialized.


Activities,Ports andFlows, Blocks

1.0

c Y "ItemFlows" associate the thingsthat flow with the connectors thatbind the ports. The parametersand object nodes are bound tothe corresponding activities andactions.



1.0


6.5.2.1.2 System store Partial Stored items can be representedas parts of a block, and alsorepresented in an activitydiagram as object nodes orcentral buffer nodes.

SysML::Block,SysML::BlockProperty,

UML::ObjectNode

UML::CentralBufferNode

Blocks,Activities

1.0

a Partial Object nodes in an activitydiagram can represent depletablestores, and a data store node canrepresent non-depletable stores.

UML::ObjectNode,UML::DataStoreNode

Activities 1.0

b Y A stored item can be the sametype of classifier as an input oroutput in both an internal blockdiagram and an activity diagram.The classifier supports differentroles (store vs. flow).

SysML::Block,SysML::BlockProperty,UML::ObjectNode,UML::DataStoreNode

Blocks,Activities

1.0

6.5.2.1.3 Function Y Activity specifies a genericsubclass of behavior that is usedto represent a function definitionin activity diagrams, sequencediagrams, and state-machinediagrams. Activities containCallBehaviorActions that call(invoke) other activities tosupport execution of the genericbehaviors.

UML::Activity Activities,Interactions,StateMachines

1.0

a Y Behaviors and the associatedparameters are named (i.e., nameof activity and activity parameternode).

UML::Behavior Activities,Interactions

StateMachines

1.0

b Y The action semantics definedifferent types of actions thatinclude CreateObject,DestroyObject,ReadStructuralFeature (monitor),and WriteStructurealFeature(update). A CallBehavior actionis a generalized action that cancall any behavior (activity,interaction, state).

UML::CreateObjectAction,UML::DeleteObjectAction, the variousobject modificationactions in UML,monitoring withUML::AcceptEventAction

Activities,Interactions

StateMachines

1.0

c Y The object nodes (pins) bindinput and output parameters toactions.

UML::ObjectNode,UML::Pin

Activities 1.0


d Y The queuing semantics for objectnodes are specified. The defaultqueuing is FIFO, but other formsof queuing including LIFO,ordered, and unordered asdefined by the enumeration forObjectNodeKind.

UML::Behavior,SysML::InputPin,SysML::ObjectNode

Activities 1.0

e Partial Resource constraints to supportan execution can be specified byPreconditions andPostConditions. The constraintscan apply to resources that aregenerated, consumed, produced,and released, such as inputs andoutputs, or the availability ofmemory or CPU. The constraintsimposed on the resources can befurther modeled using parametricdiagrams.

UML::Constraint,

SysML::ConstraintBlock

Activities,ConstraintBlocks

1.0

f Y Refer to c UML::ObjectFlow,UML::Pin

Activities 1.0

g. Y An activity can be decomposedinto lower level actions thatinvoke other activities.

UML::Activity,UML::CallBehaviorAction, UML::ActivityParameterNode,UML::ObjectFlow,UML:: Pin

Activities 1.0

h. Y An action has control inputs thatcan enable the execution of afunction, and a control valueinput from a control operatorthat can both enable or disablean execution of a function. Anexecution of a function can alsobe terminated when it is enclosedin an interruptible region.Alternatively, state machinediagrams can be used to enableor disable execution upontransition events.

UML::Action,UML::InterruptibleActivityRegion,SysML::ControlValueUML::State

Activities,StateMachines

1.0


i Y A computational expression canbe used to specify the behavior(i.e. activity) that is invoked byan action or an action thatrepresents a primitive functionsuch as an arithmetic expression.Specific math expressions may beincluded in a math model library.The expressions should berepresented in a formalmathematical language andspecify the language if they are tobe interpreted by a computationalengine.

UML::Activity,UML::Action


StateMachines

1.0

j Y A continuous or discrete ratestereotype can be applied toinputs and outputs. Inputs andoutputs are discrete by default. Atime continuous input or output isan input or output whose valuecan change in infinitely smallincrements of time. An activitycan accept the continuous inputsand provide continuous outputswhile executing if the inputs andoutputs are also streaming. Analternative approach is tocontinuously invoke an activitythat does not have streaminginputs or outputs, in which caseeach execution of an activityaccepts the inputs at the start ofexecution and produces theoutput at the completion ofexecution.

SysML::Rate

SysML::Continous,SysML::Discrete

UML::Parameter(isStream=Value)


1.0

k Partial Different actions can invokeconcurrent executions of thesame generalized behavior.Actions can have multiplicity.

UML::Behavior,UML::Action

Activities 1.0

6.5.2.2 Functionactivation/deactivation

N/A Actions can be activated anddeactivated using multiplemechanisms within SysML asdescribed below includingcontrol flows, control operators,and interruptible regions.


StateMachines

1.0

6.5.2.2.1 Control input Y Control flows in activitydiagrams provide the controlinput. Control flow is representedin state machine diagrams by atransitions which activate statesand in sequence diagrams by thepassing of messages.

UML::ActivityEdge,

UML::ControlFlow,UML::Transition,UML::Message,SysML::ControlValue


StateMachines

1.0


a Y Multiple control flows in anactivity diagram that are input toa single activity node (i.e.,action) are assumed to be"anded" together.

SysML::ControlValue, SysML::InputPin.isControl=true forcontrol queuing

Activities 1.0

b Y Control inputs are discretevalued inputs that can enable ordisable an activity node.

SysML::ControlValue Activities 1.0

c Y In activity diagrams, the activityis invoked (enabled) when atoken is received by the callingaction. This includes tokens fromall mandatory inputs and controlinputs.

UML::Action,

UML::ControlFlow,UML::ActivityEdge

Activities 1.0

d Y In activity diagrams, a controloperator can produce an outputcontrol value to disable theexecution of an activity. Anaction enclosed within aninterruptible region also candisable the execution of anactivity. In state machinediagrams, transition events candisable the actions in a state.

UML::Action,UML::InterruptibleActivityRegion,SysML::ControlValue, UML::State


1.0

e Y An executing activity with non-streaming inputs and outputsterminates when it completes itstransformation and produces anoutput value. An executingactivity with continuousstreaming inputs will terminatewhen it receives a disable from acontrol value and/or a signal thatterminates the actions within aninterruptible region. ATimeExpression can be specifiedin a control operator or cansignal a termination in aninterruptible region. An activitycan also be terminated based onevents, including timeout events,on a transition in a state machinediagram. In state machinediagrams, completion eventsoccur upon completion of anactivity.

UML::Activity,UML::InterruptibleActivityRegion,SysML ControlValue,UML::TimeExpression,UML::State


1.0

f Y The enabling of actions withoutexplicit control flows as inputsare enabled based on the controlassociated with its inputs.

UML::Action,UML::ObjectNode

Activities 1.0


g Y A control flow connects thecontrol inputs from one activitynode to another. The controlinput can also be the outputcontrol value of a controloperator.

SysML::ControlValue, UML::Parameter,UML::ControlFlow

Activities 1.0

6.5.2.2.2 Controloperator

Y A control operator provides themechanism apply control logic toenable and disable activity nodes.

SysML::ControlOperator,SysML::ControlValue

Activities 1.0

a Y Control Nodes such as joins,forks, etc. provide capability toactivate activity nodes based on"and" and "or" logic. A SysMLControl Operator provides theadditional capability to disablean activity node.

UML::ControlNode,SysML::ControlOperator,SysML::ControlValue, UML::Parameter

Activities 1.0

b Y A join specification can be usedto specify arbitrarily complexlogic for enabling an activitynode. A control operator can alsobe used to specify complex logicfor enabling and disabling anactivity node.

UML::JoinNode withjoin specification,UML::Parameter,SysML::ControlOperator,SysML::ControlValue

Activities 1.0

c Y The control nodes identifiedbelow provide the basic controllogic for enabling activity nodes.Note: multi exit functions aresupported by parameter sets.Also, Interaction Operatorsprovide similar logic in SequenceDiagrams.

UML::ControlNode,UML::InteractionOperator


1.0

c1 Y Decision nodes in activitydiagrams support selection. The"alt" Interaction Operatorsupports selection in sequencediagrams.

UML::DecisionNode,UML::InteractionOperator.Alt


1.0

c2 Y Forks in activity diagrams sup-port a single input flow gener-ating multiple concurrentoutput flows. The “par” Interac-tion Operator supports concur-rent message flow inSequence Diagrams.

UML::Fork,UML::InteractionOperator.par


1.0

c3 Y A join “and's” multiple inputflows together resulting in asingle output flow.

UML::Join Activities 1.0

c4 Y A merge results a single outputflow upon arrival of the first ofmultiple input flows.

UML::Merge Activities 1.0


c5 Y Decision and loop nodes supportiteration and looping. The“loop” Interaction Operatorsupports loops in sequencediagrams.

UML::Decision-Node, UML::LoopNode, Interaction-Operator.loop


1.0

c6 N

6.5.2.2.3 Events andconditions

Partial Triggers and constraints asguards provide the mechanismfor modeling events andconditions.

Activities,Interactions,StateMachines

1.0

a Partial A trigger can be used to specifyan event. Events can beassociated with control flows inactivity diagrams, transitions instate machine diagrams, andsending and receiving ofmessages in sequence diagrams.

UML:: Trigger,UML::AcceptEventAction includingUML::TimeTrigger,UML::EventOccurence inInteractions.

Note: Failure eventcan be result invarious types ofactions that terminatean InterruptibleRegion in Activities,etc.

Activity,Interactions

StateMachines

1.0

b Y Refer to a) above UML::ActivityEdge,UML::Trigger


StateMachines

1.0

c Y Conditions can be specified asconstraints that define guards tocontrol execution of behaviors.

UML::Constraint(guard)


StateMachines

1.0

6.5.2.3 Function-basedbehavior

Y Activity diagrams provide thecapability to model functionbased behavior.

UML:: Activity Activities 1.0


6.5.2.4 State-basedbehavior

State machine diagrams providethe capability to model statebased behavior with the specificmodeling constructs indicated.Note 2 response: Activities arecommon to each type of behaviorincluding both function basedand state based. Note 3 response:A state is defined based on someinvariant being true. Theinvariant can include reference tocertain property values.

UML::StateMachine StateMachines

1.0

a Y State UML::State StateMachines

1.0

b Y Simple state UML::State,

isSimple=True

StateMachines

1.0

c Y Composite states can contain oneregion or two or more orthogonal(concurrent) regions, each withone or more mutually exclusivedisjoint states

UML::State

isComposite=True

StateMachines

1.0

d Y Transitions between states whichare triggered by events withguard conditions.

UML::Transition,UML::Trigger

StateMachines

1.0

e Y Transition within a compositestate

UML::Transition(TransitionKind=Internal)

StateMachines

1.0

f Y Pseudo states include joins, forksand choice

UML::PseudoState StateMachines

1.0

g Y Transitions between states whichare triggered by events withguard conditions.

UML::Activity StateMachines

1.0

h Y Entry, exit, doActivities areperformed upon entry or exitfrom a state or while in a state.

UML::Activity StateMachines

1.0

i Y State machine semantics definethe ordering of actions that arecompleted when exiting acomposite state (refer to UMLtransition semantics). When acomposite state is exited, the exitactions are executed beginningwith the most nested state.

UML::State (Note:refer to semantics)

StateMachines

1.0


j Y Entry and exit actions must becompleted prior to exiting a state.A doActivity does not need to becompleted to execute.

UML::State (Note:refer to semantics)

StateMachines

1.0

k Y Send and receive signals can besent via actions to interact withother objects.

UML::SendSignalAction

StateMachines

1.0

l Partial The failure and/or exceptionstates are user defined andhave no uniquely defined rep-resentation. The use of exitpoints on states can be usedto exit the state when a failureevent occurs.

UML::State StateMachines

1.0

6.5.2.4.1 Activation time Y The interval of time that anactivity or state is active can bemodeled by a UML Time Triggeror Time Interval andcorresponding Time Expression(refer to UML trigger andinterval notation). Note: A UMLtiming diagram is not included inSysML at this time, but could beused to model the time associatedwith the occurrence of events,such as state changes, or changesin property values.

UML::SimpleTime Activities,Interactions,StateMachines

1.0

6.5.2.5 Allocation ofbehavior tosystems

Y An allocation relationship pro-vides a generalized capabilityto allocate one model elementto another.

SysML::Allocation,SysML::Allocated,UML::NamedElement

Allocations 1.0

a Y In general, behaviors such asactivities, interactions, andstate machines are owned bya Behaviored Classifier whichcan correspond to an block.The SysML Allocation relation-ship can be used to explicitlyallocate behaviors to blocks.Alternatively, activity partitions(swim lanes) can be used toallocate the action and/oractivity to a part and/or block.

UML::BehavioredClassifier andUML::Behavior(owned behavior) -Refer to UMLCommon Behaviors,SysML::Allocate,SysML::AllocateAcitivtyPartition

Allocations,Activities

1.0


b Partial An object node in an activitydiagram can be allocated to anitem that flows in an internalblock diagram using anallocation relationship. Note: theobject node is typed by the sameclassifier as the item that flows.See req't 6.5.2.1.1.

SysML::Block (type ofObjectNode to type ofItemProperty),UML::ObjectNode,UML::Property

Allocations,Activities,Ports andFlows

1.0

6.5.3 Property N/A Properties and their relation-ships are represented inSysML using properties ofblocks in conjunction with con-straint blocks to capture therelationships between them.

Blocks,ConstraintBlocks

6.5.3.1 Property type Y Primitive types, data types,and value types provide thecapability to model the differ-ent types of quantitative prop-erties.

UML:: PrimitiveType,UML::DataType,

SysML::Value Type

Blocks 1.0

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 upof primitive types.

Refer to a-f

h Y Composite data type made upof primitive types.

Refer to a-f

6.5.3.2 Property value Y Auxiliary 1.0

a Y Value properties are typed bya value type or data type andhave an associated value.

SysML::BlockProperty,SysML::ValueType,UML::DataType,

Blocks 1.0

b Y A value type can include adimension and units such aslength and feet or meters.

SysML::ValueType(unit and dimensionare defined asblocks in a modellibrary)

Blocks 1.0

c Y A value property is a blockproperty that is typed by avalue type that can have anassociated probability distribu-tion on its values.

SysML::ValueType,SysML::DistributionDefinition

Blocks 1.0


d Y Source data can be included ina comment attached to theproperty or a user defined ste-reotype could be applied.

UML::Comment ModelElements

1.0

e Y Reference data can beincluded in a commentattached to the property or auser defined stereotype couldbe applied.

UML::Comment ModelElements

1.0

6.5.3.3 Propertyassociation

A value property can be a featureof any classifier (.i.e., block)


Blocks 1.0

a Y Blocks, parts, or items thatflow can have (or reference)properties.


Blocks 1.0

b Y A function (activity) can haveproperties since it is a class

UML::Activity Activities 1.0

c Partial An event is specified by a trig-ger which is an element. Theelement does not have proper-ties.A signal which is sentupon the occurrence of theevent can have properties.

UML::Signal 1.0

d Y A property can be related toother properties through a con-straint property

SysML::Constraint-Block,SysML::Constraint-Property

ConstraintBlocks

1.0

6.5.3.4 Time property Y Time can be treated as a prop-erty, typed by a Real that canrepresent either continuous ordiscrete time. Time ultimatelyderives from clocks which canbe continuous or discrete.Clocks can be modeled asblocks which have a time prop-erty that can be bound to aparameter of a constraint prop-erty (e.g., equation). Timedurations, start and stop times,etc. can be modeled using theUML time model for timetriggers, time expressions,intervals, and durations. Note:More elaborate models of timeand clocks can be found in theUML schedulability,performance, and time profile.

SysML::Block,

SysML::BlockProperty,

SysML::ValueType,

SysML::ConstraintProperty,SysML::ConstraintParameter,UML::SimpleTimePackage

Blocks,

ConstraintBlocks,Interactions

1.0


6.5.3.5 Parametricmodel

Y The parametric diagram supportsmodeling of constraints whichbind parameters of theconstraints to value properties.

SysML::ConstraintBlock,

SysML::ConstraintProperty

SysML::ConstraintParameter,

SysML::BlockProperty,

UML::Connector,SysML::NestedConnectorEnd

ConstraintBlocks

1.0

a Y Constraints blocks and theirusages (constraint properties)specify the mathematicalrelationships/constraintsbetween constraint parame-ters.

SysML::Constraint-Block,SysML::Constraint-Parameter

ConstraintBlocks

1.0

b Partial Mathematical and logicalexpressions can be defined inSysML in a reference lan-guage, but there is no inter-preter built into SysML. Therange of values can be speci-fied via value properties andprobability distributions per6.5.3.2a-c.

SysML::BlockProperty,SysML::Distribution-Definition

Blocks 1.0

c Y The reference language forinterpreting the constraint canbe included as part of the Con-straintBlock along with thecompartment for the expres-sion.

SysML::Constraint-Block

ConstraintBlocks

1.0

6.5.3.6 Probe N No specific mechanization hasbeen provided. In the testingprofile, there is a mechanism tocapture data and create actionsin response to the data. This willbe investigated in a futureversion of SysML.

N

6.5.4 Requirement N/A The requirements diagramprovides the basic capabilityfor relating text based require-ments to other SysML models.

Require-ments

1.0


6.5.4.1 Requirementspecification

Y A requirement is a stereotypeof a class in SysML. The vari-ous subtypes of requirementare specified as subclasses ofthe the requirement stereotypeand can include specific prop-erties and constraints on whatmodel elements can satisfy thesubclass of requirement. Asample set of subclasses ofrequirements are included inthe NonNormative ExtensionsAnnex C.

SysML::Requirement Requirements,

Non-NormativeExtensions,Profiles &ModelLibraries

1.0

Note 1 Y Values and tolerances can bespecified as part of the textproperty or via property valuesand distributions per 6.5.3.2a-c.

Requirement.text,SysML::ValueProperty

Require-ments,Blocks

1.0

Note 2 Y There is no explicit subclass ofrequirement as a stakeholderneed, but a requirement canbe named or subclassed as“stakeholderNeed.”

SysML::Require-ment

Requirements,

Non-NormativeExtensions

1.0

Note 3 Y User defined requirements canbe added via subclasses tospecify any type of life cyclerequirement of interest to themodeler.

SysML::Requirement

Requirements,


1.0

a Y Operational requirement SysML::Requirement

Requirements,


1.0

b Y Functional requirement SysML::functional-Requirement

Requirements,


1.0

c Y Interface requirement SysML::interfaceRequirement

Requirements,


1.0

d Y Performance requirement SysML::perfor-manceRequirement

Requirements,


1.0


e Y Activation/Deactivation (Con-trol) requirement

SysML::Requirement

Requirements,


1.0

f Y Storage requirement SysML::Requirement

Requirements,


1.0

g Y Physical requirement SysML::physicalRequirement

Requirements,


1.0

h Y Design constraint SysML::Requirement

Requirements,


1.0

i Y Specialized requirement SysML::Requirement

Requirements,


1.0

j Y Measure of effectiveness SysML::moe Requirements,

NonNormativeExtensions

1.0

6.5.4.2 Requirementproperties

Y A requirement includes defaultproperties for id and text.Other properties can be addedvia stereotype properties.

SysML::Requirement Requirements,


1.0

6.5.4.3 Requirementrelationships

Y The requirement relationshipsinclude the relationshipscontainment, trace, deriv-eReqt, satisfy, verify and refinerelationships.

Require-ments

1.0

a Y A derive relationship relates aderived (target) requirement toa source requirement.

SysML::deriveReqt Requirements 1.0

b Y A satisfy relationship relatesthe model elements (i.e. thedesign) to the requirementsthat aresatisfied.

SysML::satisfy Requirements 1.0


c Y Goals, capabilities, or usagesof systems are oftenexpressed using use cases.Subgoals can be representedusing the include and extendrelationships between usecases.Requirements can be relatedto use cases using the refinerelationship. Requirementsuse the containment relation-ship to breakdown an existingrequirement into its containingrequirements.

UML:UseCase,UML::Include,

SysML::Requirement,UML:refine

Require-ments, UseCase

1.0

6.5.4.4 Problem Y A problem is an extension of acomment that can be attachedto any model element. Note:This could also be used to rep-resent issues.

SysML::Problem ModelElements

2.0

6.5.4.5 Problemassociation

Y Refer to 6.5.4.4 SysML::Problem ModelElements

2.0

6.5.4.6 Problem cause N 2.0

6.5.5 Verification N/A The following responses to theVerification requirements willinclude references to the TestingProfile [OMG AdoptedSpecification

ptc/03-08-03] which is notcurrently part of SysML but isintended to be evaluated forintegration with version 1.1 ofSysML [refer to white paper onintegrating SysML with TestingProfile]

Require-ments

6.5.5.1 VerificationProcess


a Y The SysML verify relationshipbetween one or more systemrequirements and one or moretest cases represents the methodfor verifying that a system designsatisfies its requirements. Averified system design impliesthat the system will satisfy itsrequirements if the componentparts satisfy their allocatedrequirements. An alternativeapproach to capture the verifyrelationship is to associate a testcase with a satisfy relationshipusing the rationale.

SysML::Verify,SysML::Rationale

Requirements,ModelElements

1.0

b Y The SysML verify relationshipbetween one or morerequirement(s) and one or moretest case(s) is used to verify thatthe implemented system designinstances satisfy theirrequirements. Alternatively, areference to a TestCase usingSysML:Rationale may beattached to a satisfy relationship.

SysML::VerifySysML::Rationale

Require-ments,ModelElements

1.0

c Y A derive relationship between therequirement being validated andthe higher level requirement orneed may have a Rationaleattached that references thevalidation method(s).

SysML:deriveReqt

SysML::Rationale

Require-ments,ModelElements

1.0

Note 1 Y Verification methods of analysisand similarity may be modeled asa Rationale with reference to thespecific analysis report or otherreference data. Verificationmethods including Test,Inspection, and Demonstrationmay be modeled as a TestCase.

SysML::Rationale,SysML::TestCase

Require-ments

1.0

Note 2 Partial Validation methods are userdefined. A rationale canreference the user definedmethods.

SysML::Rationale ModelElements

1.0

6.5.5.2 Test case Partial A test case refers to themethod for verifying a require-ment. Note: The testing profileassociates a test case with abehavior that can include thespecific method and associ-ated input stimulus andresponse.

SysML::TestCase Requirements 1.0


Note 1 Partial Refer to above note on thetesting profile.

1.x

Note 2 Partial The test criteria can beestablished via the require-ment

1.x

Note 3 Partial Test cases can contain othertest cases, like any othernamed element.

SysML::TestCase Require-ments

1.0

6.5.5.3 Verificationresult

Partial The result of a SysML:TestCasemay be expressed through itsverdict attribute (Testing Profile)

SysML::TestCase,SysML::Verdict

Requirements 1.0

6.5.5.4 Requirementverification

Partial A constraint may be used torelate the required value to theverification result.

SysML::ConstraintProperty;

SysML::TestCase,

SysML::Rationale

Requirements,ConstraintBlocks

1.0

6.5.5.5 Verificationprocedure

Partial A rationale can be associatedwith the test case or the satisfyrelationship between a require-ment and a design, andreference a verificationprocedure. Note: The testingprofile will associate a behav-ior with a test case which canbe implemented by a specificprocedure.

SysML::TestCase,SysML::Rationale

Requirements,ModelElements

1.x

Note

6.5.5.6 Verificationsystem

Partial A verification system can bemodeled as any other system(block) or it can be modeled asthe system environment.However, the future integrationwith the testing profile isintended to provide explicitmodeling of the verificationsystem.

SysML::Block Blocks 2.0

6.5.6 Other N/A

6.5.6.1 Generalrelationships

Y SysML includes several standardUML relationships as describedbelow.

a Y An association relationship. UML::Association Blocks 1.0

b Y A package contains package-able elements and can repre-sent collections of elements.

UML::Package,UML::PackageableElement;UML::ownedMember

Class 1.0


c Partial Blocks can be decomposedinto parts that are typed byother blocks using composition(refer to Reqt 6.5.1.1). Thecompleteness of thedecomposition is not explicitlyrepresented.

SysML::Block,SysML::BlockProperty,UML::Association(composition)

Blocks 1.0

d Y A dependency relationship. UML::Dependency ModelElements

1.0

e Y Generalization/specializationrelationship. Generalizationsets provide the means to par-tition specializations to supportfurther categorization.

UML::Generalization,UML::GeneralizationSet

Blocks 1.0

f Y Instantiation is modeled usingInstance Specifications touniquely identify a classifier.Instances are represented as aproperty specific value with aunique set of values.

UML::InstanceSpecification,UML::InstanceValue

Blocks 1.0

6.5.6.2 Model views Partial A view represents the modelfrom a particular viewpoint.Both the view and the view-point are represented inSysML. The view is a stereo-type of package that identifiesthe set of model elements thatconform to the viewpoint, andthe viewpoint specifies thestakeholders, their purpose,concerns and the constructionrules (language and methods)to specify the view. Note: Themodel elements that depict theview are visually representedin diagrams, tables, and othernotation. Integrity betweenmodel views is accomplishedby creating a well formedmodel. This in part results fromthe constraints imposed by thelanguage, and in part isdefined by the specific meth-odology and tools that areemployed. Navigation amongviews results from a tool ven-dor implementation.

SysML::View,SysML::ViewpointSysML::Conform

ModelElements

1.0

6.5.6.3 Diagram types DiagramAppendix

1.0


a The standard UML diagramtypes that are needed to sup-port the requirements havebeen included in SysML. Someadditional diagram types pro-vide some redundant capabili-ties, but have been preservedto allow flexibility in represen-tations and methodologies. Forexample, the sequence dia-grams along with activity andstate diagrams provide over-lapping capability for repre-senting behavior. A fewdiagram types have not beenincluded explicitly in SysML,although they are not pre-cluded from use along withSysML.

N/A DiagramAppendix

1.0

b The requirements diagram andparametric diagram have beenadded to address the require-ments of this RFP. In addition,an informal mechanism hasbeen added to represent dia-gram usages. This enablesrenaming and constraining theusage of a particular diagramtype for a particular usage.

SysML::DiagramUsage

DiagramAppendix

1.0

6.5.6.4 System role Partial A part in a block represents therole for a classifier in the con-text of the enclosing block. Itdefines the relationshipbetween an instance of theclassifier that types the partand an instance of the blockthat encloses the part. This is aprimary mechanism for provid-ing a unique context for a partof a whole (enclosing block).The part may use only a sub-set of the behavior and proper-ties of the class that types thepart. However, the specificmechanism for containing thesubset has not been explicitlydefined.

SysM::Block,SysML:BlockProperty

Blocks 1.0

6.6 OptionalRequirements

N/A

6.6.1 Topology N

a N 2.0


b N 2.0

6.6.2 Documentation Y A document (stereotype ofartifact).

UML::Document DiagramAppendix

1.0

a Y The document stereotype caninclude stereotype propertiesto represent information aboutthe document.

UML::Document Profiles &ModelLibraries

1.0

b Y The trace relationship relates adocument to other modelelements.

UML::Trace DiagramAppendix

1.0

c N The ability to represent the textof the document in terms of thedescriptions provided by therelated (traced) model ele-ments is accomplished by atool implementation.

6.6.3 Trade-offstudies andanalysis

Partial Parametric diagrams can depictthe relationship betweenmeasures of effectiveness andvarious system properties(including probabilitydistributions on their values) toevaluate the effectiveness of aparticular system model. Specificconstructs for criteria, weighting,and alternatives are planned fora future version of SysML tosupport modeling of tradestudies.

SysML::moe,SysML::objectiveFunction,SysML::ConstraintProperty

ConstraintBlocks, Non-NormativeExtensions

1.0

a Y Alternative models can bespecified via organization ofmodels/packages. Modellibraries can be used to estab-lish reusable portions of themodel.

UML::Model,UML::Package

ModelElements,Profiles &ModelLibraries

1.0

b Partial Criteria can be modeled asproperties typed by valuetypes or as Requirements

SysML::BlockProperty,SysML::ValueType,SysML::Require-ment

Blocks,Require-ments

1.0,2.0

c Y Measures of effectiveness aremodeled as a subclass ofblock property that representsa value property. A constraintcan represent the objectivefunction.

SysML::moe,SysML::Constraint-Property

Non-NormativeExtensions,ConstraintBlocks

1.0

6.6.4 Spatialrepresentation

N


6.6.4.1 Spatialreference

N

6.6.4.2 Geometricrelationships

N

6.6.5 Dynamicstructure

Partial

a Y The action semantics providethe capability for creating anddestroying objects.

UML::CreateObjectAction,UML::DestroyObjectAction

Action (UMLSpec)

1.0

b Partial The capability is partiallyprovided by 6.6.5a.

2.0

c N 2.0

d N 2.0

6.6.6 Executablesemantics

Partial The action semantics areintended to provide executionsemantics. There is no formalgraphical syntax for this.

UML::Action Action inUML Spec

1.0

6.6.7 Other behaviormodelingparadigms

Y A UML behavior is a general-ized behavior that can accom-modate a wide range ofbehavior modeling paradigms.This includefunction based, state based,and message based behavior(sequence diagrams).

UML::Behavior Activities,Interactions,StateMachines

1.0

6.6.8 Integration withdomain-specificmodels

Partial SysML is a general purposelanguage that will integratewith other types of domainspecific models. This isaccomplished in part by map-ping SysML via XMI to theAP233 data interchange stan-dard. In addition, the paramet-ric diagram is intended toprovide a capability to inte-grate with domain specificengineering analysis models.

ModelInterchange

1.x,2.0

6.6.9 Testing Model Partial SysML is intended to be inte-grated with the UML TestingProfile. Refer to Response toReqt 6.5.5 above.

SysML::TestCase Requirement 2.0

6.6.10 ManagementModel

N

omg sysml™ requirements traceability - · pdf fileomg sysmltm adopted specification 1...

Documents