Requirements and Verification in SysML v2 Projects

Overview

A SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 project has the same requirements and verification pages as an LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. project. They work on the model: the requirements are the model's requirement elements, and the test cases are its verification cases.

Some data is SysML text, and some is Holarch data stored next to the model:

• In the text: the number (short name), name, description (doc), nesting, satisfy, verify, dependency and derivation relationships, and attribute values with their units.
• Holarch data: Status, Priority, Verification Method and the other requirement attributes, labels, test status, results, steps and test cycles. Other SysML v2 tools do not read these.

Concepts

Requirements in the model

A requirement is a requirement usage or a requirement def. Holarch reads its fields from the text:

requirement def <'VR-1'> CurbMass {
  doc /* The car's curb mass shall not exceed the mass limit. */
  subject car : Car;
  attribute limit : MassValue;
  require constraint { car.curbMass <= limit }
}

The pages show names in title case, so sedanMass reads as Sedan Mass.

Relationships

Adding or removing one of these on any page changes the text, as one undo step.

Test cases and test suites

• A test case is a verification usage or a verification def.
• The requirements it verifies are the verify members of its objective.
• A package that owns verification cases is a test suite.

verification def CurbMassTest {
  doc /* Weigh the car on a scale with full fluids and no driver. */
  subject car : Car;
  objective massObjective {
    verify carSpec.sedanMass;
  }
}

TBD and TBR

A requirement is open (TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date. or TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed.) when any of these is true:

• Its TBD/TBR attribute is TBD or TBR.
• TBD, TBR or TBSTo Be Supplied A value that another party will provide later. Holarch treats it as an open item, like a TBD. appears in its name or doc.
• One of its attribute values carries TBD or TBR metadata.

Writing TBD in place of a value is not valid SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams.. Mark the attribute with metadata from the Holarch library package HolarchMetadata instead (see Mark a value TBD or TBR).

How to use it

When and why

Use these pages after you have written the first requirements in the model, and keep using them through verification:

• Requirements and Quality while you write: is each requirement well formed?
• Approvals at reviews: who has signed off?
• TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date./TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed. and Suspect Links while the design changes: what is still open, and what needs a second look?
• Traceability Matrix, Test Center and RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. while you plan and run verification: is every requirement satisfied and verified?

Write a requirement

1. Open Needs & Requirements → Requirements.
2. Click + New. A requirement usage is added with the next number, in the package Requirements.
3. Type the name and the description in the inspector or in the table. The text changes at once, one undo step per edit.
4. Set Priority, Verification Method and the other attributes in the inspector. These are Holarch data; the text does not change.

You can also write requirements in the Editor. They appear on the Requirements page as soon as the text parses.

Write requirements in a document

A document can hold the requirement usages of one package.

1. In a document, choose Write ▾ → Requirements Package… and pick the package. A new document gets a package named after it with its first requirement.
2. Add, indent, outdent and move requirements as in LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. documents.
   • A requirement under a section belongs to the package.
   • A requirement under another requirement is nested in it.
   • The number is its short name.
3. Requirements written in the Editor in that package appear in the document.

Remove deletes a requirement of the package after a confirmation. To take a requirement out of the document without deleting it, move it to another package in the Editor.

Check quality

1. Open Needs & Requirements → Quality.
2. Click Check Quality. Each requirement's description is scored on nine criteria, with the same rules as in LML projects.
3. Fix the lowest scores first.

A score marked Stale belongs to an older text. Check quality again.

Approve requirements

A requirement's Status runs Draft → In Review → Approved or Rejected.

1. Set a requirement's Status to In Review. It is listed on Approvals and, for the reviewers, in My Work under Awaiting review. Reviewers get a notification.
2. As a reviewer, select the requirement. The inspector shows its status with Approve, Reject… and Reopen.
3. Click Approve, or Reject… with an optional reason. The inspector records who set the status and when.

People with the Reviewer role can approve and reject. Editing the text of an Approved requirement moves it back to In Review.

Mark a value TBD or TBR

1. Import the metadata package in the requirement's package: private import HolarchMetadata::*;.
2. Write #TBD before an attribute whose value is still to be determined. Leave the value out, or give an estimate.
3. Write #TBR before an attribute whose value is to be reviewed.
4. To record who owns it and why, use the long form in the attribute's body.

#TBR attribute limit : TimeValue = 0.5 [h];
attribute chargerPower : PowerValue {
  @TBD { owner = "Powertrain lead"; rationale = "The fast-charging standard is not chosen yet."; due = "2026-12-01"; }
}

Insert ▾ → TBD Value and TBR Value in the Editor write these for you. TBD and TBR specialize ModelingMetadata::StatusInfo, so other SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 tools read them as status annotations. @StatusInfo { status = StatusKind::tbd; } counts too. The package is listed under Holarch in the Standard Library.

Close a TBD or TBR

1. Open Needs & Requirements → TBD/TBR. Each open item shows its owner, due date and age, with a burn-down of open items.
2. Enter the final value in the text or the inspector, then click Close on the row. The TBD/TBR attribute goes back to None, and the TBD/TBR metadata is removed from the values.

Marks in the doc close when you edit the doc. Export XLSX exports the register.

Review suspect links

When a requirement changes, the links that depend on it become suspect in the same undo step.

1. Open Needs & Requirements → Suspect Links. Each suspect link shows what changed, when and by whom.
2. Click Diff to see the old and new name and doc, or Show in Text to open the requirement in the Editor.
3. Check the linked element. Update it if it no longer fits.
4. Click Clear…, add an optional comment, and confirm.

A suspect element also shows a banner with Review… in the inspector and a Suspect badge in tables. The Database view Suspect links lists them.

Plan and run verification

1. Open Verification → Test Center.
2. Click + New ▾ → Test Suite… to add a package, then + New ▾ → Test Case… to add a verification usage.
3. Link a requirement to the test case. A verify is added to the test case's objective.
4. Add steps, run the suite with Run Suite, and set each test case's status. Status, expected and actual results, steps and cycles are Holarch data.
5. Open Verification → RVTM to see each requirement with its verification method, its verifying test cases and the status rolled up from sub-requirements.

Worked example: the Hybrid Car demo

Create the demo first: Manage Projects → Project Files ▾ → New Demo Project → Hybrid Car (SysML v2). Its requirements are in the package VehicleRequirements.

1. Open Needs & Requirements → Requirements. Among them are VR-1 Curb Mass to VR-6 Battery Mass Limit, and the requirement carSpec with VR-1.1 Sedan Mass, VR-2.1 Sedan Acceleration and VR-4.1 Sedan Range under it.
2. Select VR-1.1 Sedan Mass. It is verified by the verification case CurbMassTest, through the verify carSpec.sedanMass; in its objective.
3. Open TBD/TBR. VR-5 Charge Time is open: its limit carries #TBR, and its chargerPower carries @TBD with the owner Powertrain lead.
4. In the Editor, change maxCurbMass from 1650 [kg] to 1600 [kg]. VR-1.1 Sedan Mass uses maxCurbMass as its limit, so its links become suspect.
5. Open Suspect Links. The verified by link of VR-1.1 Sedan Mass is listed. Click Diff, check the test, then click Clear….
6. Open Verification → Traceability Matrix with requirements as rows and Assets as columns. The cell for carSpec and fleet.sedan shows satisfied by, from satisfy carSpec by fleet.sedan;.

Tips and good practice

• Give every requirement a short name. It is the number on every page and in documents.
• Write values as attributes, not in the doc. attribute :>> limit = maxCurbMass; can be evaluated, checked by the Parametric View and tracked by suspect links.
• Mark open values with #TBD or #TBR, not with "TBD" in the value. The text stays valid and the register finds them.
• Keep test cases in their own package. It becomes a test suite in the Test Center.

Common mistakes

• Expecting Status in the text. Status, Priority and Verification Method are Holarch data. Exchange files do not carry them.
• Writing limit = TBD. That is not valid SysML and the text stays a draft. Use #TBD attribute limit : TimeValue;.
• Removing a requirement from a document to move it. Remove deletes it from the model. Move it to another package in the Editor instead.

How it connects to other features

• Views: a Requirement View draws the same requirements, satisfy, verify, derive and refine relationships (SysML v2 Views).
• Simulator: Check Against Requirement… takes its criterion from a requirement's require constraint and records the result on a verification case (Evaluation, Units and Analysis).
• Documents: RTMRequirements Traceability Matrix A report of requirements and the items they trace to., RVTM, VCRMVerification Cross-Reference Matrix A table that maps requirements to verification methods (test, analysis, inspection, demonstration) and events., flow-down and allocation matrix blocks list the model's requirements.
• Change control: baselines hold the model; Compare lists the requirement changes (Holarch Features in SysML v2 Projects).

Requirements and Quality

Requirements page

Requirements is the Database filtered to the Requirement class. It has the Database's filters, views, columns, Tree mode, inline editing, bulk tools and exports (Requirements).

• + New adds a requirement usage with the next number in the package Requirements.
• Editing the number, name or description changes the model text, one undo step per change.
• The Table and Definitions exports include Kind, Type, Multiplicity and Value.
• Selecting a requirement shows it in the SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 inspector. Its link opens it in the Browser.

Not available for model elements: Change Class, Duplicate, Lock and Copy with Children, and the JSON and .inno exports.

Quality page

Quality scores each requirement's description on the nine criteria of LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. projects: Appropriate, Complete, Conforming, Correct, Feasible, Necessary, Singular, Unambiguous and Verifiable (Requirement Quality). The score is Holarch data. A score marked Stale belongs to an older text.

Change control

Suspect links

A requirement's change makes these links suspect: satisfied by (satisfy), verified by (verify), decomposed by (owned requirements) and traced to (dependency).

A change is an edit of any of these:

• The requirement's name or doc.
• A key attribute: Priority, Criticality, Verification Method or Verification Level.
• The value of an attribute it owns, such as attribute :>> limit = maxCurbMass;, or one of its constraints.
• A target attribute those values or constraints name, such as attribute maxCurbMass : MassValue = 1650 [kg];.

It counts wherever you make it: the Editor, a view, the inspector or a table. A changed Verification Method or Verification Level makes only the verified by links suspect, and setting the first one makes none suspect.

The Suspect Links page has Diff, Show in Text and Clear… per link.

Approvals

Approvals lists the requirements In Review. The inspector shows the status with Approve, Reject… and Reopen, and who set it and when. The status is Holarch data next to the model; it is not part of the SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. text.

TBD/TBR register

The register lists each open requirement with its owner, due date and age, a burn-down of open items and Export XLSX. Close sets the TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date./TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed. attribute back to None and removes the values' TBD/TBR metadata.

Verification pages

Test Center

Suites, test cases, status buttons, steps, test cycles, Run Suite and reports work as in LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. projects (Verification).

• + New ▾ → Test Case… adds a verification usage; Test Suite… adds a package.
• Linking a requirement adds a verify to the test case's objective.
• Status, expected and actual results, steps and cycles are Holarch data stored next to the model.

RVTM

Each requirement with its verification method, its verifying test cases and the status rolled up from sub-requirements (RVTM).

Traceability Matrix

Rows, columns and the relationship work as in LML projects (The Traceability Matrix).

• Assets are the part usages (the parts in the system), and Actions are the action usages.
• For a class axis, Elements → Definitions lists the definitions instead.
• Between model elements, a cell can hold satisfied by (satisfy), verified by (verify), performed by (allocate or perform), traced to (dependency) and decomposed by (ownership). Other relationships show as not allowed.
• Each click is one undo step and changes the model text.

Model Checks

The rules that apply to a model run (Model Checks), in SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 words:

• requirement usages without a name, a short name (leaf requirements), a description (theirs or their definition's), a satisfy or a verify, and leaf requirements without "shall";
• repeated short names, vague words, live values that point to missing targets, UAFUnified Architecture Framework An OMG architecture framework that organizes views in a grid of viewpoints and aspects. It covers DoDAF and NATO needs. views that cannot be shown;
• open top-level risks without a mitigation, failed verification cases without an Issue, TPMsTechnical Performance Measure A key technical parameter, such as mass or power, tracked over time against its target and threshold. that breach their threshold;
• the items next to the model (risks, tasks, decisions, documents) with the same name or without relationships.

The checker in the Editor covers names, types and structure, so the LML functional-analysis rules (Action, Asset, Conduit and Input/Output) do not run and Settings lists only these rules. Merge fixes are not offered for model elements.

Messages

Limits

• Status, Verification Method, the other requirement attributes, labels and test results are Holarch data. SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 exchange files do not carry them.
• Change Class, Duplicate, Lock and Copy with Children are not available for model elements.
• Merge fixes in Model Checks are not offered for model elements.

Related pages

• Getting Started with SysML v2 Projects
• SysML v2 Views
• The Text Editor and Browser
• Evaluation, Units and Analysis in SysML v2 Projects
• Requirements
• Verification
• Traceability

SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams.® and OMGObject Management Group The standards body that maintains UML, SysML, UAF and XMI.® are registered trademarks of Object Management Group, Inc. in the United States and other countries.