https://training-course-material.com/index.php?action=history&feed=atom&title=SysML_RequirementsSysML Requirements - Revision history2026-04-12T22:57:41ZRevision history for this page on the wikiMediaWiki 1.45.1https://training-course-material.com/index.php?title=SysML_Requirements&diff=65980&oldid=prevFstachecki: /* A Package Containing Requirements⌘ */2018-03-07T13:40:02Z<p><span class="autocomment">A Package Containing Requirements⌘</span></p>
<p><b>New page</b></p><div>[[Category:SysML]]<br />
[[Category:private]]<br />
<br />
==SysML Requirements⌘==<br />
===A Requirement⌘===<br />
[[File:ClipCapIt-160720-073728.PNG]]<br />
* A requirement specifies a capability or condition that must (or should) be satisfied.<br />
* A requirement may specify a function that a system must perform or a performance condition a system must achieve.<br />
* SysML provides modeling constructs to represent text-based requirements and relate them to other modeling elements.<br />
* The requirements diagram can depict the requirements in graphical, tabular, or tree structure format.<br />
* A requirement can also appear on other diagrams to show its relationship to other modeling elements.<br />
====Requirements Tabular Representation⌘====<br />
[[File:ClipCapIt-160720-075634.PNG]]<br />
===Requirements relationships⌘===<br />
* Several requirements relationships are specified that enable the modeler to relate requirements to other requirements as well as to other model elements. <br />
* These include relationships for defining a requirements '''hierarchy''', '''deriving''' requirements, '''satisfying''' requirements, '''verifying''' requirements, and '''refining''' requirements.<br />
====requirement containment⌘====<br />
[[File:ClipCapIt-160720-113307.PNG]]<br />
* A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism. <br />
* This relationship enables a complex requirement to be decomposed into its containing child requirements.<br />
=====requirement containment example⌘=====<br />
[[File:ClipCapIt-160720-122213.PNG]]<br />
====A Package Containing Requirements⌘====<br />
[[File:RequirementsContainmentByPackage.png]]<br />
<br />
====copy⌘====<br />
[[File:ClipCapIt-160720-113323.PNG]]<br />
* A '''Copy''' relationship is a dependency between a supplier requirement and a client requirement that specifies that the '''text''' of the client requirement is a read-only copy of the text of the supplier requirement.<br />
=====copy example⌘=====<br />
[[File:ClipCapIt-160720-123507.PNG]]<br />
<br />
====deriveReqt⌘====<br />
[[File:ClipCapIt-160720-074559.PNG]]<br />
* A '''DeriveReqt''' relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement. <br />
* For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement. <br />
* The arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived.<br />
=====deriveReqt example⌘=====<br />
[[File:RequirementsDeriviationDiagram.png]]<br />
=====deriveReqt & problem example⌘=====<br />
[[File:ClipCapIt-160726-161348.PNG]]<br />
<br />
====satisfy⌘====<br />
[[File:ClipCapIt-160720-074711.PNG]]<br />
* A '''Satisfy''' relationship is a dependency between a requirement and a model element that fulfills the requirement. <br />
* The arrow direction points from the satisfying (client) model element to the (supplier) requirement that is satisfied.<br />
<br />
====verify⌘====<br />
[[File:ClipCapIt-160720-074948.PNG]]<br />
* A '''Verify''' relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. <br />
* The arrow direction points from the (client) element to the (supplier) requirement.<br />
<br />
====refine⌘====<br />
[[File:ClipCapIt-160720-074832.PNG]]<br />
* The '''refine''' requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. <br />
* For example, a use case or activity diagram may be used to refine a text-based functional requirement.<br />
====Example⌘====<br />
[[File:ClipCapIt-160720-124740.PNG]]<br />
<br />
====trace⌘====<br />
[[File:ClipCapIt-160720-075126.PNG]]<br />
* A generic '''trace''' requirement relationship provides a general-purpose relationship between a requirement and any other model element. <br />
* The semantics of trace include no real constraints and therefore are quite weak.<br />
* It is recommended that the trace relationship not be used in conjunction with the other requirements relationships.<br />
===Requirement relationships as matrices⌘===<br />
[[File:ClipCapIt-170909-115839.PNG]]<br />
===Non-normative Requirements subclasses⌘===<br />
* Annex E: Non-normative Extensions of the SysML specification describes an example of a non-normative extension for a requirements profile.<br />
* More specialized requirement stereotypes are introduced: functional, interface, performance, physical, design constraint.<br />
* Additional properties are proposed: source, risk, and verifyMethod<br />
:[[File:ClipCapIt-170909-113918.PNG]]</div>Fstachecki