Gallery Tutorial TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7] Section Section: SysML-1.6: HSUV sample Tags and keywords SysML keywords Requirement HSUV sample problem AbstractRequirement::text AbstractRequirement::id Slide kind SysML Requirement Diagram Click on the image to view it full size Up next Figure D.12 - Establishing Derived Requirements and Rationale from Lowest Tier of Requirements Hierarchy Notes [TIP]{SUGGESTED} SysML: Webel recommends use of an additional custom «requirementGroup» stereotype for compound Requirements that serve as owning Namespaces and are subject to the satisfaction policy that all child requirements must be satisfied. [NAMING, POLICY]{SUGGESTED} Webel suggests using a verbose 'name' for leaf (child) Requirements but NO 'text' to prevent Single Source of Truth issues and for improved callout vs relationships (but this might not always work when syncing with external requirements management tools) Snippets (quotes/extracts) [SysML-1.6] The vehicle system specification contains many text based requirements. A few requirements are highlighted in Figure D.11, including the requirement for the vehicle to pass emissions standards, which is expanded for illustration purposes. [SysML-1.6] The containment (cross hair) relationship, for purposes of this example, refers to the practice of decomposing a complex requirement into simpler, single requirements. [SysML-1.6] A requirement specifies a capability or condition that must (or should) be satisfied. [SysML-1.6] A requirement may specify a function that a system must perform or a performance condition that a system must satisfy. [SysML-1.6] Requirements are used to establish a contract between the customer (or other stakeholder) and those responsible for designing and implementing the system. [SysML-1.6] A requirement is a stereotype of both Class and Abstract Requirement. [SysML-1.6] Compound requirements can be created by using the nesting capability of the class definition mechanism. [SysML-1.6] The default interpretation of a compound requirement, unless stated differently by the compound requirement itself, is that all its subrequirements shall be satisfied for the compound requirement to be satisfied. [SysML-1.6] When a requirement has nested requirements, all the nested requirements apply as part of the container requirement. Deleting the container requirement deleted [deletes] the nested requirements, a functionality inherited from UML. Visit also Visit also (backlinks) Related slides (includes other tutorials) Related slides (backlinks, includes other tutorials) A most basic Requirement with a 'name', an 'id', and 'text' A basic Requirement is an AbstractRequirement Derived requirements and the DeriveReqt relationship Derived requirements and the DeriveReqt relationship - compartment styles Refining requirements Satisfying Requirements and the Satisfy relationship Requirements and the Trace relationship - metamodel Trace used for model element elicitation - callout style Trace used for model element elicitation - tagged value and element property styles TestCase and Verify metamodel TestCase and Verify example - callout style Composite (a.k.a. "compound") Requirements The Copy relationship MagicDraw/Cameo: Satisfy Requirement Matrix: Hybrid SUV vs Block (all) MagicDraw/Cameo: Satisfy Requirement Matrix: Hybrid SUV vs Block and PartProperty (relations only) Flags Book traversal links for Figure D.11 - Establishing HSUV Requirements Hierarchy (containment) Previous Up Next
