Skip to content

Requirements Management#

Requirements Management is at the core of SysGit, and is the business layer of any complex engineering project. Requirements is the highest layer where we map the needs of the organization to the hardware implementation. It’s the formalized common ground between customers and engineers.

Many organizations have different approaches to this activity, but the most simplified approach is:

  • Maintaining a list of “shall statements” that have been contractually agreed upon between the Engineering Team and the Customer.
  • Creating a series of “derived requirements” that better match to development strategies to be implemented by the Engineering Team.
  • Developing Verification artifacts, which can prove to the Customer that the agreed upon Requirements have been met.
  • Ensuring traceability between the top level contractual Requirements, the Derived Requirements, and the Verification Activities.

SysGit’s Requirements Table, Verification Table, and Traceability views are designed to work together as an integrated system. They support end-to-end visibility from stakeholder needs through implementation and verification, enabling teams to manage complexity while ensuring accountability.

Requirements Table#

The primary interface for working with requirements is the Requirements Table. This is built to be an Excel-like user experience while still generating underlying data structures that adhere to the SysML v2 standard. The Requirements Table has one requirement per row, and the following columns:

  • ID: an internally generated paragraph number, computed based on the ordering and depth of the Requirement
  • Short Name: a unique alphanumeric identifier for referencing the Requirement
  • Description: the descriptive text detailing the requirement, often referred to as a “shall statement”
  • Rationale: an optional column for detailing the rationale behind a requirement
  • Relationship: this is used to establish or modify a relationship between this requirement and other objects within the current SysML package, including other requirements, parts, verifications, and more. Simply use the dropdown to select the intended object, as well as the relationship type.

When interacting with the table, you can do a few things, including:

  • Adding a row
  • Selecting multiple rows
  • Grouping and ungrouping rows, establishing a decomposition hierarchy
  • Moving one or more rows up or down within a level
  • Adding comments

To add a row, click the “add a row” button at the bottom of the table. You can also right click on the table to insert a row just below the highlighted row at the same level of the hierarchy as that row.

To select one or more rows, click the leftmost column (containing the generated IDs). Hold shift to select multiple rows.

To group rows, select multiple rows, right-click on the leftmost column, and choose ‘Group Row'. This will make all selected requirements (except the first one) a decomposed child of the first requirement selected. If the decomposed parent is moved, the children will follow. Note that children cannot be moved outside of the grouping. To undo the grouping, right-click on any individual member and click “un-group”, this will ungroup the entire group.

You can use the keyboard to navigate the table as well. Use the arrow keys to move up, down, left, and right between the cells. To change the content of a cell that can be edited, just start typing, and hit Enter to save the changes.

Verification Table#

Verification is the process by which requirements are validated against real-world behavior, ensuring that the system conforms to the specified needs. In SysGit, each Verification artifact is a formal object that ties a Requirement to an engineering activity used to confirm compliance—whether through inspection, test, analysis, or demonstration.

The Verification Table offers a dedicated, streamlined view for managing all verification artifacts associated with your current project. This table presents a row for each Verification and includes the following columns:

  • ID: A unique identifier for the verification artifact.
  • Name: A short title or description of the verification activity.
  • Objective: Describes the purpose and procedure of the verification effort.
  • Verifies: Links to the associated Requirement(s) being verified. Clicking the link opens the corresponding Requirement in context.
  • Method: The method of verification used (e.g., Test, Analyze, Inspect, Demo).
  • Results: Optionally links to the result artifact, such as a report, document, or data capture.
  • Risk Level: A color-coded indicator (Low, Medium, High) that allows engineers to quickly identify high-risk verification efforts.

This view allows Systems Engineers and QA stakeholders to assess the verification coverage and identify critical areas of the system that may require deeper scrutiny or additional testing. Each row is interactively linked with the Requirements and can be filtered or exported for reporting purposes.

By keeping this table up to date, engineering teams can easily demonstrate compliance to stakeholders and customers, and provide the necessary documentation trail for system certification.

Traceability#

Traceability is the act of ensuring your Requirements (and other objects) maintain the appropriate relationships to other relevant artifacts important to the success of your project. Typically, a Systems Engineer is most interested in ensuring the Requirements (the highest level engineering artifacts) have the correct relationships with downstream objects, such as derived Requirements, allocated Parts, and Verifications.

SysGit currently enables two approaches to Traceability:

  • Verification Matrix
  • Trace Matrix

Verification Matrix#

The Verification Matrix is used to ensure all Requirements correctly map to their ultimate Verifications. This is incredibly useful for ensuring the business needs of the organization map into the engineering activities of the team. A Verification is used to ensure that the ultimate physical creation correctly meets the intent of the Requirement.

The Verification Matrix presents this mapping in a tabular format, helping users quickly identify which requirements have been covered and where gaps in verification remain.

For more information, please visit the SEBoK section on the Systems Engineering Vee.

Trace Matrix#

The Trace Matrix in SysGit is a powerful tool for visualizing the relationships across your project’s systems model. Unlike the Verification Matrix, which focuses specifically on the link between Requirements and their Verifications, the Trace Matrix provides a broader and more flexible overview of how objects across the SysML model relate to one another.

This matrix answers questions like:

  • Which Requirements are satisfied by which Parts?
  • Which Requirements are decomposed into sub-requirements?
  • Which Requirements are verified by which artifacts?
  • Are there Requirements that lack verification coverage?

Interface Overview#

The matrix allows users to select two object types—for example, Requirements vs Parts, or Requirements vs Verifications—and view the relationships between them. The rows represent one object type (e.g., Requirements), and the columns represent another (e.g., Verifications). An arrow and letter indicates the presence of a relationship (e.g., “is verified by”), its type, and its direction.

Each cell in the matrix provides traceability feedback that can be clicked to navigate directly to the linked item. This makes it especially useful during peer reviews, compliance audits, or when onboarding new team members who need to understand the system’s structure quickly.

By maintaining a well-structured trace matrix, teams gain confidence that all engineering activities—requirements, design elements, tests—are aligned and synchronized, reducing the likelihood of integration errors, compliance gaps, or redundant work.