SysCon 2013 SysML & Requirements
Upcoming SlideShare
Loading in...5
×
 

SysCon 2013 SysML & Requirements

on

  • 910 views

Tutorial sur la capture des exigences avec SysML (SysCon 2013)

Tutorial sur la capture des exigences avec SysML (SysCon 2013)

Statistics

Views

Total Views
910
Views on SlideShare
910
Embed Views
0

Actions

Likes
0
Downloads
41
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SysCon 2013 SysML & Requirements SysCon 2013 SysML & Requirements Presentation Transcript

  • Requirements Modelingwith SysMLPascal RoquesIEEE SysCon 2013 TutorialApril 15th, 2013
  • • Senior Consultant & Trainer,25 years of experience in modeling SADT, OMT, UML, SysML• OMG Certified on UML2 and SysML• Co-founder of association• Author of UML best-sellers in France• … and of the first FrenchSysML bookpascal.roques@prfc.frThe Speaker: Pascal Roques2
  • What is SysML?3• SysML™ is a general-purpose graphicalmodeling language for specifying,analyzing, designing, and verifyingcomplex systems that may includehardware, software, information,personnel, procedures, and facilities• It is a specialized UML profile targeted tosystem engineering
  • Why Model?4• In all domains, those building complexsystems have been modelling for ages!• To harness complexity• To reduce risks• To communicate!• Abstraction• Hide details• …
  • Reference: INCOSE5• www.incose.org
  • (Brief) History of SysML6
  • SysML Stakeholders7• American Systems, BAE SYSTEMS, Boeing, Deere &Company, EADS Astrium, Eurostep, Israel AircraftIndustries, Lockheed Martin, Motorola, NIST, NorthropGrumman, oose.de, Raytheon, THALESIndustry• ARTiSAN, EmbeddedPlus, Gentleware, IBM, I-Logix,Mentor Graphics, PivotPoint Technology, SparxSystems,Telelogic, VitechTool Vendors• AP-233, INCOSE, Georgia Institute of Technology, etc.• In France: l’AFISOthers
  • SysML = UML2 Profile8www.omgsysml.org/
  • SysML Diagram Types9www.omgsysml.org/
  • The Four « Pillars » of SysML10 www.omgsysml.org/
  • SysML and Requirements11• SysML defines elements for modelingrequirements and their relationships• including relationships to other artifacts suchas test cases or blocks
  • Requirements in SysML(1/3)• A requirement specifies a capability orcondition that must (or should) besatisfied• A requirement may specify a function thata system must perform or a performancecondition a system must achieve• Use cases are typically effective forcapturing the functional requirements, butnot as well for non-functional• The incorporation of text-based requirementsinto SysML effectively accommodates a broadrange of requirements12
  • Requirements in SysML(2/3)• SysML provides modeling constructs torepresent text-based requirements andrelate them to other modeling elements• The requirements diagram can depict therequirements in graphical, tabular, or treestructure format• A requirement can also appear on otherdiagrams to show its relationship to othermodeling elements• The requirements modeling constructs areintended to provide a bridge betweentraditional requirements management toolsand the SysML models13
  • Requirements in SysML(3/3)• A standard requirement includesproperties to specify its unique identifierand text requirement• Additional properties such as verification status,can be specified by the user• Several requirements relationships arespecified that enable the modeler to relaterequirements to other requirements as wellas to other model elements• These include relationships for defining arequirements hierarchy, deriving requirements,satisfying requirements, verifying requirements,and refining requirements14
  • Composite Requirement• A Composite Requirement can contain subrequirements in terms of a requirementshierarchy, specified using the namespacecontainment mechanism• A composite requirement may state that thesystem shall do A and B and C, which can bedecomposed into the child requirements thatthe system shall do A, the system shall do B,and the system shall do C15
  • Requirement Reuse• There is a real need for Requirementreuse across product families and projects• Typical scenarios are regulatory, statutory, orcontractual requirements that are applicableacross products and/or projects andrequirements that are reused across productfamilies• SysML introduces the concept of a slaverequirement16
  • Derive Relationship• The derived requirements generallycorrespond to requirements at the nextlevel of the system hierarchy17
  • Satisfy Relationship• The satisfy relationship describes how adesign or implementation model satisfiesone or more requirements18
  • Verify Relationship• The verify relationship defines how a testcase or other model element verifies arequirement19
  • Refine Relationship• The refine requirement relationship can beused to describe how a model element orset of elements can be used to furtherrefine a requirement20
  • Trace Relationship• A generic trace requirement relationshipprovides a general-purpose relationshipbetween a requirement and any othermodel element• The semantics of trace include no realconstraints and therefore are quite weak21
  • Warning: Arrow direction!• Most requirement relationships in SysMLare based on the UML dependency• The arrow points from the dependent modelelement (client) to the independent modelelement (supplier)• In SysML, the arrowhead direction isopposite of what has typically been usedfor requirements flow-down where thehigher-level requirement points to thelower-level requirement22
  • Requirement Subclasses• Modelers can customize requirementstaxonomies by defining additionalsubclasses of the Requirement stereotype• For example, a modeler may want to definerequirements categories to representoperational, functional, interface, performance,physical, storage, activation/deactivation,design constraints, and other specializedrequirements such as reliability andmaintainability, or to represent a high levelstakeholder need• Some potential Requirement subclassesare defined in Non-normative Extensions23
  • HSUV Sample ProblemRequirement Diagrams (1/3)24
  • HSUV Sample ProblemRequirement Diagrams (2/3)25
  • HSUV Sample ProblemRequirement Diagrams (3/3)26
  • Requirements Table (1/2)• The requirement diagram has a distinctdisadvantage when viewing large numbersof requirements• The traditional method of viewing requirementsin textual documents is a more compactrepresentation than viewing them in a diagram• SysML embraces the concept of displayingresults of model queries in tables as wellas using tables as a data inputmechanism, but the specifics of generatingtables is left to the tool implementer27
  • Requirements Table (2/2)• The tabular format can be used torepresent the requirements, theirproperties and relationships28
  • Distiller Sample Problem29
  • Requirement Packages• Requirements can be organized into apackage structure• A typical structure may include a top-levelpackage for all requirements• Each nested package within this package maycontain requirements from differentspecifications (system, subsystem, component,etc.)• Each specification package contains the text-based requirements for that specification• This package structure corresponds to a typicalspecification tree that is a useful artifact fordescribing the scope of requirements for aproject30
  • Other Ways to Represent“Requirements”• Nearly all SysML diagram types canrepresent Requirements!• Use Case Diagram• Sequence Diagram• State Diagram• Activity Diagram• Block Definition Diagram• Internal Block Diagram• Parametric Diagram31
  • Use Case Diagram• The Use Case diagram describes theusage of a system (subject) by its actors(environment) to achieve a goal, that isrealized by the subject providing a set ofservices to selected actors32
  • Sequence Diagram• The Sequence diagram describes the flowof control between actors and systems(blocks) or between parts of a system• This diagram represents the sending andreceiving of messages between theinteracting entities called lifelines, wheretime is represented along the vertical axis33
  • Sequence Diagram34
  • State Machine Diagram• The StateMachine package defines a setof concepts that can be used for modelingdiscrete behavior through finite statetransition systems• The state machine represents behavioras the state history of an object in termsof its transitions and states35
  • State Machine Diagram36
  • Activity Diagram• Activity modeling emphasizes the inputs,outputs, sequences, and conditions forcoordinating other behaviors. It providesa flexible link to blocks owning thosebehaviors37
  • Activity Diagram38
  • Block Definition Diagram• The Block Definition Diagram definesfeatures of blocks and relationshipsbetween blocks such as associations,generalizations, and dependencies• It captures the definition of blocks interms of properties and operations, andrelationships such as a system hierarchyor a system classification tree39
  • Block Definition Diagram(Domain)40
  • Internal Block Diagram (Domain)• The Internal Block Diagram captures theinternal structure of a block in terms ofproperties and connectors betweenproperties• A block can include properties to specifyits values, parts, and references to otherblocks• Ports are a special class of property usedto specify allowable types of interactionsbetween blocks41
  • Internal Block Diagram (Domain)42
  • Parametric Diagram• Parametric diagrams include usages ofconstraint blocks to constrain theproperties of another block• The usage of a constraint binds theparameters of the constraint, such as F,m, and a, to specific properties of a block,such as a mass, that provide values forthe parameters43
  • Parametric Diagram44
  • The Four Pillarsof SysML (1/2)45
  • The Four Pillarsof SysML (2/2)46
  • Industrial Feedback (1)47• In 2009, MagicDraw R&D decided tomigrate from Document-driven to Model-driven Requirement Engineering usingSysML• Advantages:• Much better teamwork and versionmanagement capabilities• More formal/structured descriptions of therequirements• Maintain the information about alreadyimplemented functionality• Traceability to the architecture and test cases
  • Industrial Feedback (2)48• SE^2 and APE Case Study• Large telescope SysML Model• Guidelines for modeling Requirements:• Distinguish Objectives, StakeholderRequirements, System Requirements andAnalysis elements (e.g. Use Cases)• Modeling can be used for requirementsspecification• Above a certain number of requirements, theybecome difficult to visualize graphically. It isbetter to use the tabular format• SysML requirements are not a replacement ofRM tools but a visualization aid forarchitectural important requirements
  • APE Project Examples(1/5)49
  • APE Project Examples(2/5)50
  • APE Project Examples(3/5)51
  • APE Project Examples(4/5)52
  • APE Project Examples(5/5)53
  • Tools (1/3)54http://www.sparxsystems.com.au/resources/demos/Traceability/Traceability_Impact.htm
  • Tools (2/3)55http://www.nomagic.com/products/cameo-systems-modeler.html
  • Tools (3/3)56
  • Conclusion (1/3)57• A Requirements Model can provideinformation that helps determine if therequirements meet their desired attributes• SysML requirements modeling provides a‘link’ between the text requirements andthe rest of the model elements• … But for the moment, SysMLrequirements are not a completereplacement of RM tools
  • Conclusion (2/3)58• SysML Requirement modeling conceptshould not remain just a buzz!• It can be a real breakthrough for peoplewho do not master yet a tooledRequirements Management process• It can be also valuable for people used toRequirements Management tools• Models can help a lot to formalize requirements(state machines, block diagrams, etc.)• Diagrams are a very powerful communicationtool between all stakeholders
  • Conclusion (3/3)59Validation TestsSystem ValidationUserRequirementsNeed Operational UsederivationComponentsRequirementsComponentsTestsComponents VerificationSubsystemsRequirementsSubsystemsTestsSubsystems VerificationderivationSystemRequirements Verification TestsSystem Verificationderivation
  • Additional Resources…• Websites:• www.omgsysml.org/• www.incose.org/• http://mbse.gfse.de/index.html• Books:• P. Roques, SysML par l’exemple,2009, Eyrolles• S. Friedenthal, A. Moore, and R. Steiner, APractical Guide to SysML, 2011, OMG Press• T. Weilkiens, Systems Engineering withSysML/UML: Modeling, Analysis, Design, 2008,OMG Press60