Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SysCon 2013 SysML & Requirements


Published on

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

Published in: Technology

SysCon 2013 SysML & Requirements

  1. 1. Requirements Modelingwith SysMLPascal RoquesIEEE SysCon 2013 TutorialApril 15th, 2013
  2. 2. • 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
  3. 3. 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
  4. 4. 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• …
  5. 5. Reference: INCOSE5•
  6. 6. (Brief) History of SysML6
  7. 7. SysML Stakeholders7• American Systems, BAE SYSTEMS, Boeing, Deere &Company, EADS Astrium, Eurostep, Israel AircraftIndustries, Lockheed Martin, Motorola, NIST, NorthropGrumman,, 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
  8. 8. SysML = UML2
  9. 9. SysML Diagram
  10. 10. The Four « Pillars » of SysML10
  11. 11. SysML and Requirements11• SysML defines elements for modelingrequirements and their relationships• including relationships to other artifacts suchas test cases or blocks
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. Derive Relationship• The derived requirements generallycorrespond to requirements at the nextlevel of the system hierarchy17
  18. 18. Satisfy Relationship• The satisfy relationship describes how adesign or implementation model satisfiesone or more requirements18
  19. 19. Verify Relationship• The verify relationship defines how a testcase or other model element verifies arequirement19
  20. 20. Refine Relationship• The refine requirement relationship can beused to describe how a model element orset of elements can be used to furtherrefine a requirement20
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. HSUV Sample ProblemRequirement Diagrams (1/3)24
  25. 25. HSUV Sample ProblemRequirement Diagrams (2/3)25
  26. 26. HSUV Sample ProblemRequirement Diagrams (3/3)26
  27. 27. 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
  28. 28. Requirements Table (2/2)• The tabular format can be used torepresent the requirements, theirproperties and relationships28
  29. 29. Distiller Sample Problem29
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. Sequence Diagram34
  35. 35. 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
  36. 36. State Machine Diagram36
  37. 37. Activity Diagram• Activity modeling emphasizes the inputs,outputs, sequences, and conditions forcoordinating other behaviors. It providesa flexible link to blocks owning thosebehaviors37
  38. 38. Activity Diagram38
  39. 39. 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
  40. 40. Block Definition Diagram(Domain)40
  41. 41. 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
  42. 42. Internal Block Diagram (Domain)42
  43. 43. 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
  44. 44. Parametric Diagram44
  45. 45. The Four Pillarsof SysML (1/2)45
  46. 46. The Four Pillarsof SysML (2/2)46
  47. 47. 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
  48. 48. 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
  49. 49. APE Project Examples(1/5)49
  50. 50. APE Project Examples(2/5)50
  51. 51. APE Project Examples(3/5)51
  52. 52. APE Project Examples(4/5)52
  53. 53. APE Project Examples(5/5)53
  54. 54. Tools (1/3)54
  55. 55. Tools (2/3)55
  56. 56. Tools (3/3)56
  57. 57. 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
  58. 58. 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
  59. 59. Conclusion (3/3)59Validation TestsSystem ValidationUserRequirementsNeed Operational UsederivationComponentsRequirementsComponentsTestsComponents VerificationSubsystemsRequirementsSubsystemsTestsSubsystems VerificationderivationSystemRequirements Verification TestsSystem Verificationderivation
  60. 60. Additional Resources…• Websites:•••• 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