Successfully reported this slideshow.

SysCon 2013 SysML & Requirements

5

Share

Loading in …3
×
1 of 60
1 of 60

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

SysCon 2013 SysML & Requirements

  1. 1. Requirements Modeling with SysML Pascal Roques IEEE SysCon 2013 Tutorial April 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 French SysML book pascal.roques@prfc.fr The Speaker: Pascal Roques 2
  3. 3. What is SysML? 3 • SysML™ is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities • It is a specialized UML profile targeted to system engineering
  4. 4. Why Model? 4 • In all domains, those building complex systems have been modelling for ages! • To harness complexity • To reduce risks • To communicate! • Abstraction • Hide details • …
  5. 5. Reference: INCOSE 5 • www.incose.org
  6. 6. (Brief) History of SysML 6
  7. 7. SysML Stakeholders 7 • American Systems, BAE SYSTEMS, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, THALES Industry • ARTiSAN, EmbeddedPlus, Gentleware, IBM, I-Logix, Mentor Graphics, PivotPoint Technology, SparxSystems, Telelogic, Vitech Tool Vendors • AP-233, INCOSE, Georgia Institute of Technology, etc. • In France: l’AFIS Others
  8. 8. SysML = UML2 Profile 8 www.omgsysml.org/
  9. 9. SysML Diagram Types 9 www.omgsysml.org/
  10. 10. The Four « Pillars » of SysML 10 www.omgsysml.org/
  11. 11. SysML and Requirements 11 • SysML defines elements for modeling requirements and their relationships • including relationships to other artifacts such as test cases or blocks
  12. 12. Requirements in SysML (1/3) • A requirement specifies a capability or condition that must (or should) be satisfied • A requirement may specify a function that a system must perform or a performance condition a system must achieve • Use cases are typically effective for capturing the functional requirements, but not as well for non-functional • The incorporation of text-based requirements into SysML effectively accommodates a broad range of requirements 12
  13. 13. Requirements in SysML (2/3) • SysML provides modeling constructs to represent text-based requirements and relate them to other modeling elements • The requirements diagram can depict the requirements in graphical, tabular, or tree structure format • A requirement can also appear on other diagrams to show its relationship to other modeling elements • The requirements modeling constructs are intended to provide a bridge between traditional requirements management tools and the SysML models 13
  14. 14. Requirements in SysML (3/3) • A standard requirement includes properties to specify its unique identifier and text requirement • Additional properties such as verification status, can be specified by the user • Several requirements relationships are specified that enable the modeler to relate requirements to other requirements as well as to other model elements • These include relationships for defining a requirements hierarchy, deriving requirements, satisfying requirements, verifying requirements, and refining requirements 14
  15. 15. Composite Requirement • A Composite Requirement can contain sub requirements in terms of a requirements hierarchy, specified using the namespace containment mechanism • A composite requirement may state that the system shall do A and B and C, which can be decomposed into the child requirements that the system shall do A, the system shall do B, and the system shall do C 15
  16. 16. Requirement Reuse • There is a real need for Requirement reuse across product families and projects • Typical scenarios are regulatory, statutory, or contractual requirements that are applicable across products and/or projects and requirements that are reused across product families • SysML introduces the concept of a slave requirement 16
  17. 17. Derive Relationship • The derived requirements generally correspond to requirements at the next level of the system hierarchy 17
  18. 18. Satisfy Relationship • The satisfy relationship describes how a design or implementation model satisfies one or more requirements 18
  19. 19. Verify Relationship • The verify relationship defines how a test case or other model element verifies a requirement 19
  20. 20. Refine Relationship • 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 20
  21. 21. Trace Relationship • A generic trace requirement relationship provides a general-purpose relationship between a requirement and any other model element • The semantics of trace include no real constraints and therefore are quite weak 21
  22. 22. Warning: Arrow direction! • Most requirement relationships in SysML are based on the UML dependency • The arrow points from the dependent model element (client) to the independent model element (supplier) • In SysML, the arrowhead direction is opposite of what has typically been used for requirements flow-down where the higher-level requirement points to the lower-level requirement 22
  23. 23. Requirement Subclasses • Modelers can customize requirements taxonomies by defining additional subclasses of the Requirement stereotype • For example, a modeler may want to define requirements categories to represent operational, functional, interface, performance, physical, storage, activation/deactivation, design constraints, and other specialized requirements such as reliability and maintainability, or to represent a high level stakeholder need • Some potential Requirement subclasses are defined in Non-normative Extensions 23
  24. 24. HSUV Sample Problem Requirement Diagrams (1/3) 24
  25. 25. HSUV Sample Problem Requirement Diagrams (2/3) 25
  26. 26. HSUV Sample Problem Requirement Diagrams (3/3) 26
  27. 27. Requirements Table (1/2) • The requirement diagram has a distinct disadvantage when viewing large numbers of requirements • The traditional method of viewing requirements in textual documents is a more compact representation than viewing them in a diagram • SysML embraces the concept of displaying results of model queries in tables as well as using tables as a data input mechanism, but the specifics of generating tables is left to the tool implementer 27
  28. 28. Requirements Table (2/2) • The tabular format can be used to represent the requirements, their properties and relationships 28
  29. 29. Distiller Sample Problem 29
  30. 30. Requirement Packages • Requirements can be organized into a package structure • A typical structure may include a top-level package for all requirements • Each nested package within this package may contain requirements from different specifications (system, subsystem, component, etc.) • Each specification package contains the text- based requirements for that specification • This package structure corresponds to a typical specification tree that is a useful artifact for describing the scope of requirements for a project 30
  31. 31. Other Ways to Represent “Requirements” • Nearly all SysML diagram types can represent Requirements! • Use Case Diagram • Sequence Diagram • State Diagram • Activity Diagram • Block Definition Diagram • Internal Block Diagram • Parametric Diagram 31
  32. 32. Use Case Diagram • The Use Case diagram describes the usage of a system (subject) by its actors (environment) to achieve a goal, that is realized by the subject providing a set of services to selected actors 32
  33. 33. Sequence Diagram • The Sequence diagram describes the flow of control between actors and systems (blocks) or between parts of a system • This diagram represents the sending and receiving of messages between the interacting entities called lifelines, where time is represented along the vertical axis 33
  34. 34. Sequence Diagram 34
  35. 35. State Machine Diagram • The StateMachine package defines a set of concepts that can be used for modeling discrete behavior through finite state transition systems • The state machine represents behavior as the state history of an object in terms of its transitions and states 35
  36. 36. State Machine Diagram 36
  37. 37. Activity Diagram • Activity modeling emphasizes the inputs, outputs, sequences, and conditions for coordinating other behaviors. It provides a flexible link to blocks owning those behaviors 37
  38. 38. Activity Diagram 38
  39. 39. Block Definition Diagram • The Block Definition Diagram defines features of blocks and relationships between blocks such as associations, generalizations, and dependencies • It captures the definition of blocks in terms of properties and operations, and relationships such as a system hierarchy or a system classification tree 39
  40. 40. Block Definition Diagram (Domain) 40
  41. 41. Internal Block Diagram (Domain) • The Internal Block Diagram captures the internal structure of a block in terms of properties and connectors between properties • A block can include properties to specify its values, parts, and references to other blocks • Ports are a special class of property used to specify allowable types of interactions between blocks 41
  42. 42. Internal Block Diagram (Domain) 42
  43. 43. Parametric Diagram • Parametric diagrams include usages of constraint blocks to constrain the properties of another block • The usage of a constraint binds the parameters of the constraint, such as F, m, and a, to specific properties of a block, such as a mass, that provide values for the parameters 43
  44. 44. Parametric Diagram 44
  45. 45. The Four Pillars of SysML (1/2) 45
  46. 46. The Four Pillars of SysML (2/2) 46
  47. 47. Industrial Feedback (1) 47 • In 2009, MagicDraw R&D decided to migrate from Document-driven to Model- driven Requirement Engineering using SysML • Advantages: • Much better teamwork and version management capabilities • More formal/structured descriptions of the requirements • Maintain the information about already implemented 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, Stakeholder Requirements, System Requirements and Analysis elements (e.g. Use Cases) • Modeling can be used for requirements specification • Above a certain number of requirements, they become difficult to visualize graphically. It is better to use the tabular format • SysML requirements are not a replacement of RM tools but a visualization aid for architectural 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 http://www.sparxsy stems.com.au/reso urces/demos/Trace ability/Traceability_ Impact.htm
  55. 55. Tools (2/3) 55 http://www.nomagic.com/products/ cameo-systems-modeler.html
  56. 56. Tools (3/3) 56
  57. 57. Conclusion (1/3) 57 • A Requirements Model can provide information that helps determine if the requirements meet their desired attributes • SysML requirements modeling provides a ‘link’ between the text requirements and the rest of the model elements • … But for the moment, SysML requirements are not a complete replacement of RM tools
  58. 58. Conclusion (2/3) 58 • SysML Requirement modeling concept should not remain just a buzz! • It can be a real breakthrough for people who do not master yet a tooled Requirements Management process • It can be also valuable for people used to Requirements Management tools • Models can help a lot to formalize requirements (state machines, block diagrams, etc.) • Diagrams are a very powerful communication tool between all stakeholders
  59. 59. Conclusion (3/3) 59 Validation Tests System Validation User Requirements Need Operational Use derivation Components Requirements Components Tests Components Verification Subsystems Requirements Subsystems Tests Subsystems Verification derivation System Requirements Verification Tests System Verification derivation
  60. 60. 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, A Practical Guide to SysML, 2011, OMG Press • T. Weilkiens, Systems Engineering with SysML/UML: Modeling, Analysis, Design, 2008, OMG Press 60

×