[SysML] #5. Understanding SysML Requirement Diagram

쉬운 목차

Understanding SysML Requirement Diagram

In the world of systems engineering, requirements are the key functions, conditions, and performance measures that a system must meet. Just like following a recipe when cooking, requirements serve as a guide that determines the success or failure of a project. These requirements specify what functions the system needs and how it should perform, reflecting user needs and preferences, various conditions related to development and production, and sometimes external factors such as government regulations.

Various sources of requirements

There are various paths through which requirements arise. User and stakeholder expectations, technical requirements during manufacturing, and even government regulations such as emissions control and safety all play a role in defining requirements. Requirements provide a clear picture of what environment the system will be used in and what user problems it will solve.

The importance of requirements management

Managing requirements well is like building a strong foundation when building a building. Successful completion of a project is only possible if requirements are clear, consistent, and executable. To achieve this, it is essential to have a good understanding of the relationship between requirements and the ability to appropriately reflect and adjust stakeholders’ expectations. Requirements management tools play a big part in this process, helping you organize, track, and update requirements efficiently.

Requirements Diagrams: Effective System Requirements Management with SysML

This image shows a requirement Diagram in order to Understanding SysML requirement Diagram. — This is a Requirement Diagram drawn with Enterprise Architect. If you want to get more information about Requirement Diagram, this article may be helpful.

Requirements diagrams in SysML (System Modeling Language) have become a powerful tool for effectively handling requirements during system development. These diagrams provide a clear and intuitive representation of the complex relationships between requirements and other model elements of the system, contributing significantly to the overall understanding and management of the project.

Core Purpose of Requirements Diagram

Provides traceability: One of the most important functions of a requirements diagram is to enable systematic tracking of whether requirements have been met. This is an essential element of project change management, ensuring that all requirements are properly accounted for and met
Linkage to system model: Diagrams help maintain consistency between requirements and each stage of system design. This gives the design team a clear understanding of how requirements affect specific parts of the system.
Expression of various requirements: Requirements diagrams provide the ability to visually integrate and express requirements in various forms such as use cases and constraints, as well as requirements described only in text.
Hierarchy visualization: To systematically manage requirements for complex systems, this diagram provides a graphical representation of the hierarchy of requirements. This is very useful for seeing the overall structure at a glance and understanding the connection between detailed requirements.

Optimization of system development through requirements diagrams

Requirements diagrams facilitate the management and integration of requirements from the early stages of system development through the successful completion of the project. This tool allows development teams to continuously monitor whether requirements are being met and immediately assess the impact of design changes on requirements. They also play an important role in clearly defining the requirements for complex systems and ensuring that those requirements remain consistent throughout all phases of the project.

Requirements Diagram Components: Mastering the Basics of SysML Diagrams

Let’s take a closer look at the key elements that make up a requirements diagram.

*Example of Header of Requirement Diagram*

Diagram header

The diagram header defines the identity of the diagram. It follows the standard format req [model element type] model element name [diagram name], which makes it clear what the diagram is about and what its purpose is. Here, the model element type represents the category of topic (e.g. package, requirement) that the diagram represents, and the model element name is the name of the specific topic.

Model element type

Requirements diagrams can contain different types of model elements, which indicate what aspects of the system the diagram covers. For example, packages are used to group related requirements, models represent the entire system, and model libraries store reusable elements.

Default namespace

The model elements specified in the diagram header form the default namespace for the elements displayed within the diagram. It indicates which part of the system model the diagram belongs to and plays an important role in understanding the relationships between elements.

Symbols and relationships

The point of a requirements diagram is to visually represent various requirements and their relationships. Relationships such as satisfy, contain, derive, and verify indicate how requirements are linked to system model elements, allowing you to track and verify that requirements have been met. . These relationships can be expressed in a variety of ways, including direct notation, section notation, and callout notation, which contribute to the clarity and understanding of the diagram.

Understanding SysML Requirement DiagramRequirements Modeling in SysML: Definition and Applications

Expression of Requirements

In SysML, requirements are expressed as rectangular model elements with the stereotype “requirement”. These model elements specify specific features, conditions, and performance criteria that the system must meet, allowing the project team to work with clear goals.

Components of Requirements

Each requirement element includes a unique identifier (ID) and descriptive text. These identifiers and text enable clear definition and traceability of requirements.

ID: Ensures the uniqueness of each requirement and provides traceability between requirements.
Text: Describes the details of the requirements and helps the project team understand the specific conditions that must be met.

SysML does not define any default properties other than id and text, but users can add custom properties such as verification method, importance, risk, etc. depending on the specific needs of their project. This extensibility makes SysML applicable to a variety of projects and environments.

*Example of Component of Requirement with EA*

Requirements and Relationships

Requirements can be linked to each other and to other model elements through various relationships. This relationship clearly indicates the connection between requirements, how they are met and verified, and the need for improvement. Requirements relationships play an important role in understanding the overall structure and logic of a project.

Extended Requirements

Requirements can be classified into various categories such as functional requirements, interface requirements, performance requirements, etc. SysML supports the following Extended Requirements.

Stereotype	Constraints	Description
extendedRequirements	N/A	An additional stereotype that contains generally useful attributes for requirements.
functionalRequirements	Satisfied by an operation or behavior	Requirement that specifies an operation or behavior that a system, or part of a system, must perform.
interfaceRequirement	Satisfied by a port, connector, item flow, and/or constraint property	Requirement that specifies the ports for connecting systems and system parts and that optionally may include the item flows across the connector and/ or interface constraints.
performanceRequirement	Satisfied by a value property	Requirement that quantitatively measures the extent to which a system, or a system part, satisfies a required capability or condition.
physicalRequirement	Satisfied by a structural element	Requirement that specifies physical characteristics and/or physical constraints of the system, or a system part.
designConstraint	Satisfied by a block or a part	Requirement that specifies a constraint on the implementation of the system or system part, such as “the system must use a commercial off-the-shelf component”.

*Extended Requirements in EA Req Diagram Toolbox*

Relationships

Requirements can be linked to other requirements or model elements through various relationships, which are important for traceability and indicating whether they have been met. The table below describes the notation of various relationships used in requirements diagrams.

Relationship Name	Keyword Depicted on Relation	Supplier (arrow) End Callout/Compartment	Client (no arrow) End Callout/Compartment
Satisfy	«satisfy»	Satisfied by «model element»	Satisfies «requirement»
Verify	«verify»	Verified by «model element»	Verifies «requirement»
Refine	«refine»	Refined by «model element»	Refines «requirement»
Derive Requirement	«deriveReqt»	Derived «requirement»	Derived from «requirement»
Copy	«copy»	(No callout)	Master «requirement»
Trace	«trace»	Traced «model element»	Traced from «requirement»
Containment (Requirement decomposition)	(Crosshair icon)	(No callout)	(No callout)

*Relationships in EA Req Diagram Toolbox*

The Role and Importance of Containment: A Deeper Understanding of SysML Requirements Modeling

In SysML requirements diagrams, containment relationships are an important mechanism for clearly and efficiently expressing the hierarchical structure of system requirements. These relationships allow you to visualize the parent-child relationships that exist between requirements in a complex system and clarify the affiliation and grouping of each requirement. Let’s learn more about the role and importance of inclusion relationships.

Structuring and Organizing

Embedding relationships play a key role in systematically organizing requirements within a system. This makes it easy to understand the overall structure of the system by classifying the requirements of a complex system into easy-to-understand units and establishing a hierarchical order between each requirement. For example, a structure where high-level requirements contain lower-level requirements can clarify how high-level goals are decomposed into lower-level details.

Clear ownership and responsibility

Containment relationships that clearly indicate that each requirement belongs to a specific namespace (e.g. package, model) clarify the management and ownership of requirements. This clearly assigns responsibility for specific requirements or groups of requirements and helps you respond quickly and efficiently when requirements change or updates are required.

Enhanced traceability

Containment relationships enhance traceability of requirements by providing a clear structure between requirements. This allows you to analyze the impact of system changes on requirements and efficiently propagate changes to other parts of the system. It also plays an important role in minimizing omission or duplication of requirements that may occur during the system development process.

Namespace Containment Notation: Representing Hierarchical Relationships of Elements in SysML Diagrams

Clearly expressing the hierarchical relationships and affiliations between elements in SysML diagrams is an important challenge. To this end, namespace inclusion notation provides a variety of visual ways to clearly indicate how elements are related to each other and organized within a particular namespace. Let’s look at the characteristics and use cases of each notation.

Crosshair notation

Crosshair notation is one of the most intuitive ways to represent containment relationships between elements. Use a solid line with a circled plus sign to visually represent that one element is contained within another. This method is especially useful when child elements are directly contained within a parent element, making it easier to understand the clear structural relationships between elements.

Nested notation

Nested notation is a way for elements to appear visually nested within other elements physically. This method is mainly used in package diagrams, where it clearly shows how elements are grouped. The nested notation provides an intuitive understanding of the containment relationships between elements and is particularly effective in representing the structural organization of a namespace.

Relative qualified name string

Relative qualified name strings provide a path to an element within the model, based on the diagram’s default namespace or current context. This method takes into account the namespace the element belongs to, allowing a more concise representation of the element’s location within the model. When referencing elements in complex models, you can efficiently represent them using relative paths instead of full paths.

Fully qualified name string

A fully qualified name string is a string that represents the full path to a specific element, starting from the root of the model. This is used to identify the exact location of an element within a model, and is especially useful when you need to clearly reference an element between various parts of the model. Fully qualified name strings help you clearly understand the structure of your model and allow you to accurately track relationships between elements.

If you are interested in other articles about the basic Knowledge of SysML with EA, please refer to the links below!

[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #3. Understanding Dependencies of Pkg Diagram

[SysML] #6. Understanding Relations In Req Diagram

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

[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