[SysML] #7. How to draw a Req Diagram with EA

SysML requirements diagrams are a powerful tool for visualizing the requirements of a system. I will explain step by step how to draw such a diagram using Sparx Enterprise Architect (EA). This guide is designed to be easy to follow even for those new to systems engineering.

Getting started: Understanding basic model elements


When you create a requirements diagram in EA, you will see two main model elements by default:

1. Requirement : Specifies the function the system must perform or the conditions it must meet. There are three pieces of information that each requirement element must include: a name, an ID, and a description. If the ID and text are not visible, you can make them visible by activating ‘Tags’ in the ‘Compartment Visibility’ menu. The attributes of a requirement are organized into tags.

This Requirement Element is helpful understanding how to draw a req diagram with EA
If you want to get more information about Requirement Diagram, this article may be helpful.

2. TestCase : Describes a method of inspection, analysis, demonstration, or testing to determine whether requirements have been met. The information that must be included in a test case element is its name and verdict. Test cases can be associated with activities, interactions, decision tables, scenarios, etc. to describe a test method or process. In the requirements diagram, you add a name and a brief description of the test case. Descriptions can be written in the notes of the test case and made visible by activating ‘Notes’ in ‘Compartment Visibility’. Test cases are linked to requirements through a ‘Verify’ relationship.

image 11

3. Effective Diagramming Tips

  • Maintain clarity: Write requirements and test cases clearly and concisely. Avoid vague language and provide specific details to increase understanding.
  • Leverage tags: Use tags to manage various attributes of requirements (e.g. priority, status). This helps enhance analytics and traceability.
  • Enable notes: Write descriptions of complex test cases in notes to improve the readability of information. You can use this feature by activating ‘Notes’ in the ‘Design’ menu.



In SysML, it is important to clearly express the relationships between a system’s requirements, or between requirements and other model elements. Let’s learn how to model these relationships using Sparx Enterprise Architect (EA). This guide introduces how to visualize relationships through three main methods:

1. Direct connection using connector : The most intuitive way is to link the two model elements directly. Select ‘Relationship’ in EA’s Toolbox, then drag to connect between the two elements you want to connect. This method is simple and allows you to choose from a variety of connector styles depending on the type of relationship.

2. Compartmental representation of requirements elements : The second way is to display relationships as compartments inside boxes that represent elements. By right-clicking on an element and selecting the related relationship from ‘Compartment Visibility’, you can internally display how the element relates to other elements. In EA, if a relationship is already expressed as a connector within the same diagram, it may not be displayed as a compartment.

image 12

3. Callout notation : A third way is to use Callouts to display relationships in the form of notes. The process for creating a callout is as follows:\

  1. Add ‘Note’ of ‘Common Elements’ to the diagram.
  2. Connect the created note to the element you want to link with ‘Note Link’ in ‘Common Relationships’.
  3. You can also use Quick Links on elements to create notes right away. This can be done by selecting an element, dragging the upward arrow that appears, and then selecting ‘common → note’.
  4. Right click on the link between the created note and element and select ‘Link this Note to an Element feature…’ ‘, then select the relevant relationship type.

Callout notation is especially useful when models become complex, and can be applied to any diagram. This method increases the readability of the model and helps express complex relationships clearly.

image 13

4. Tips for expressing relationships effectively :

  • Be clear about the purpose and type of relationship: You need to be clear about what each relationship means within your model and what type of relationship it is.
  • Maintain model readability: In complex models, it is important to use callout notation to clarify relationships and maintain readability.
  • Choose the appropriate representation method: Depending on the purpose and context of your model, choose the most appropriate method of representing relationships. Sometimes using a combination of methods helps us understand the model.


The Requirements Diagram provided by EA provides the seven relationships described above.

image 14

There is nothing particularly difficult about using Relationships in each EA, just connect the elements according to the syntax of SysML. Therefore, I will only add brief explanations and examples for each.

1. Containment :

  • Description: Containment relationships are used to hierarchically structure and group requirements. It helps organize the requirements of complex systems into manageable units.
  • Example: Include specific requirements such as “Airbag Deployment Time” and “Brake Response Time” under the “Safety Requirements” group.

2. Trace (tracking relationship) :

  • Description: Trace relationships represent connections between requirements and other model elements. It is used to visualize information flow or dependencies.
  • Example: Track specific safety requirements by linking them directly to specific features in the early design stages.

3. Copy (copy relationship) :

  • Description: Indicates that one requirement is a copy of another requirement. This allows you to efficiently manage the reuse of requirements.
  • Example: Copy safety-related requirements that must be common across multiple subsystems and include them as requirements for each subsystem.

4. Derive (derivative relationship) :

  • Description: One requirement arises from, expands upon, or refines another requirement.
  • Example: A high-level requirement such as “The system must respond to user commands within 1 second” is derived from a specific low-level requirement such as “The system must maintain a database query response time of 300 ms or less.”

5. Verify (verification relationship) :

  • Description: Models the process of verifying that specific requirements have actually been met.
  • Example: The requirement “The system must operate accurately even in low light conditions” is verified using the “After Dark” and “Shadow” test cases.

6. Refine (Reification Relationship) :

  • Description: Clarifies the meaning of the requirement and provides additional details.
  • Example: Refine the requirement “The system must quickly provide information requested by the user” by defining a specific use case.

7. Satisfy (satisfaction relationship) :

  • Description: Explicitly states how the architecture or design elements of a system meet specific requirements.
  • Example: State that the design of the engine control module (ECM) satisfies the requirement to “improve fuel efficiency.”
    Using these relationships effectively in SysML requirements diagrams using EA makes the process of structuring, managing, and validating system requirements much clearer. Accurate understanding and application of each relationship type is the foundation for successful project execution. By mastering these aspects of requirements modeling, you can more effectively manage the design and development process of complex systems.



Requirement Diagram in Sparx Enterprise Architect (EA) provides powerful extensions for SysML requirements modeling. These extensions make requirements management more granular and efficient. This section explains the concept of extending SysML requirements and how to add Rationale and Problem notes.

Extending SysML Requirements

EA’s requirements diagrams provide requirements extensions to SysML, allowing each requirement to be given additional properties such as source, risk, and verifyMethod. This greatly aids project management and requirements tracking by explicitly documenting the origin and risk level of requirements and how those requirements will be verified.

  • Source: Specifies the source of the requirements. For example, there may be customer requirements, legal requirements, etc.
  • Risk: Evaluate the potential risks to your requirements. Depending on the level of risk, more attention may be given to specific requirements.
  • VerifyMethod: Describes the method for verifying requirements. Examples include simulation, testing, code review, etc.
image 16


How to add Rationale & Problem notes


Adding a Rationale or Problem note in EA is basically the same as adding any other note. These notes clearly document the rationale for the requirement or any associated issues.

  • Using Toolbox: In SysML Common, add a Rationale or Problem directly to the diagram and link it to the Note Link in the Common Relationship.
  • Using the Quick Link Menu: You can directly select and link to a Rationale or Problem using the Quick Link Menu.
  • Change Note Stereotype: After creating and connecting a Note, change the Stereotype of the Note to Rationale or Problem. In the Properties window, click the Settings button for Stereotype, change Profile to SysML, and then select Rationale or Problem.

Through this method, the basis or problems of requirements can be effectively expressed within the requirements diagram, which increases understanding of requirements and provides important information in the project decision-making process. By utilizing the requirements extension and note addition features, you can maximize the effectiveness of SysML requirements modeling and increase the success rate of complex system development projects.



Specification Manager in Sparx Enterprise Architect (EA) is one of the powerful features that allows you to efficiently manage complex requirements. This tool allows you to view, edit, and manage requirements in a table format, streamlining the requirements management process for your project. This guide explains how to use Specification Manager in EA to represent requirements in tabular form.

Activating Specification Manager

  1. Access Specification Manager: From the Design menu, select Specification View under Package. This allows elements in the NameSpace to be displayed in table form.
  2. View requirements by diagram: When you want to view only the elements in a specific diagram in Specification View, open the diagram on the screen and select Design → Diagram → Views → Specification View.
image 17


Represent requirements in table form

  1. Select Field: To select a field to be displayed in the Specification View, right-click on the area that says “Item” in the table. You can then select the fields you want to display in the table.
  2. Requirement Adding a Tag to a requirement: When you want to add the fields of a specific requirement to the table, select the requirement, right-click on the field bar, and click “Add Tag Value Column.” You can select “Tagged Values from the selected Element” in List Options to select the attributes of your requirement as fields.
image 18

Create a readable requirements table

  1. Add id and text fields: Add key information such as id and text of the requirement as fields. This allows you to identify and understand each requirement more clearly.
  2. Field Sorting: Properly organize columns with added fields by dragging and dropping to improve readability and make information easier to understand.
image 19

Specification Manager makes it easy to manage requirements visually and makes it easy for everyone on the project team to keep track of the latest status of requirements. Managing requirements effectively in this way can greatly help increase project clarity and efficiency.



The relationship matrix feature provided by Sparx Enterprise Architect (EA) is a useful tool that allows you to clearly and intuitively visualize the relationships between elements within a project. This allows you to see the structure of the project at a glance and analyze the interactions between elements. Let’s take a step-by-step look at how to use a relationship matrix.

Creating a Relationship Matrix

  1. Accessing the relationship matrix: From the Design menu, select Package/Matrix under Package to open the relationship matrix window.
  2. Source and Target Package settings: Specify each package in the Source and Target Package fields at the top. This sets the range of elements in the matrix that we want to analyze.
  3. Use the Filter function: You can use the Filter function to limit the data displayed in the matrix to the elements of your choice. This is useful when you want to focus on a specific type of element or relationship.

Set matrix options

  1. Highlighting options: The Options menu allows you to highlight unrelated rows or columns in a separate color. This makes it easy to identify elements for which relationships are missing.
  2. Sorting and display options: You can set how elements are sorted within the matrix and whether element names are prefixed with the package name. This improves the readability of the matrix and the clarity of information.
  3. Highlight Settings: You can adjust the options for highlighting source and target element rows and columns that have no connection. This helps analyze relationships more clearly.

Utilizing relationship matrices

  • Using a relationship matrix, you can systematically analyze the relationships between elements within a project and gain a deeper understanding of the structure and behavior of the system. For example, you can use a relationship matrix to analyze traceability between requirements and implementation, or to review dependencies between components.

The relationship matrix is an important tool for clearly communicating the complex relationships of a project to all stakeholders involved in the project, including project managers, systems engineers, and architects. These visualization features provided by EA can increase project efficiency and support more effective decision-making.


[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #3. Understanding Dependencies of Pkg Diagram

[SysML] #5. Understanding SysML Requirement Diagram

[SysML] #6. Understanding Relations In Req Diagram

[SysML] #8. Understanding SysML UseCase Diagram

[SysML] #9. How to draw a UseCase Diagram with EA

[SysML] #10. Understanding SysML bdd Diagram

[SysML] #11. Understanding SysML ibd Diagram

[SysML] #12. Understanding Part Property of Block

[SysML] #13. Understanding Reference Property of Block

[SysML] #14. Understanding Value Type

[SysML] #15 Understanding Parametric Diagram

[SysML] #16. Understanding Flow Property

[SysML] #17. Understanding Port and Association Block

[SysML] #18. Understanding Behavior of Block

[SysML] #19. Understanding Generalizations

[SysML] #20. Understanding Dependencies, Allocate, Comment

[SysML] #21. Understanding Activity Diagram

[SysML] #22. How to draw a Activity Diagram with EA

[SysML] #23. Seq Diagram LifeLine and Message

[SysML] #24. Seq Diag Constraints Fragment Decompose

[SysML] #25. How to draw a Sequence Diagram with EA

[SysML] #26. Understanding Stm Diagram State and Transition

[SysML] #27. Understanding Stm Diagram Event Pseudostate Region

[SysML] #28. How to draw a State Machine Diagram with EA

Leave a Comment