Defintion vs Usage

Summary Tables

Naming and Reference Rules

Context	Use Short Name?	Use Declared Name?	Example
Requirement definition	✅ Yes	✅ Yes	requirement <'REQ-001'> 'Max Speed' { }
Verify statement	❌ No	✅ Yes	verify Requirements::'Max Speed';
Satisfy statement	❌ No	✅ Yes	satisfy Requirements::'Max Speed' by Part;
Allocate statement	❌ No	✅ Yes	allocate Requirements::'Power' to Part;

Metadata Usage

Field	Source	Purpose
rationale	RequirementMetadata	Why requirement exists, justification
level	RequirementMetadata	Hierarchy level (1=top, 2=derived, etc.)
Custom fields	CustomRequirementMetadata	Project-specific metadata needs

Risk Levels

Risk Level	Enum Value
Low	RiskMetadata::RiskLevelEnum::low
Medium	RiskMetadata::RiskLevelEnum::medium
High	RiskMetadata::RiskLevelEnum::high

Prompt Engineering for SysML v2

Requirements Import to SysGit from CSV

Stage 1: Requirements

Please create a set of SysML v2 Requirement Usage statements using the attached CSV. You have the following headers: - Requirement ID - Description - Type - Parent ID - Notes - Validation Method

Specific to the above: - Notes go in the notes string under CustomRequirementMetadata - Validation Method go in the validationMethod string under CustomRequirementMetadata - Parent ID is a Declared Short Name

Given the following requirement template

requirement  <'Declared Short Name'> 'Declared Name' {
    doc 
    /* docstring */
}

Any kind of "ID" or similar shorthand identifier should be placed in the Requirement Declared Short Name Any kind of long-form generic descirption, or a "shall statement" should go in the docstring If available, a unique name should be in the Long Name. If one is not available, generate one. Any kind of technical attribute (usually a value with units, though sometimes they are unitless) should be added as an attribute (with an appropriate unit value, if available). If the technical attribute is descrived as a constraint, use the constrant syntax instead. Additional non-relationship descriptions or notes should be added as CustomRequirementMetadata. In order to use CustomRequirementMetadata, a single metadata def must be created and provided for inclusion. Then a CustomRequirementMetadata usage can be used within each requirement usage block.

Example usage of CustomRequiremenMetadata:

    metadata CustomRequirementMetadata {
        notes = "notes";
        validationMethod = "validation method"
    }

Example definition of CustomRequirementMetadata:

  metadata def CustomRequirementMetadata {
    attribute validationMethod : ScalarValues::String;
    attribute notes : ScalarValues::String;
  }

If the requirement is listing a simplified "validaiton method", then create a consolodated list of Verification usages to make. Do not be inventive and create a few as possible while providing sufficent coverage. These will require a Declared Name, an Objective (this includes the docstring which describes the verification, as well as the list of requirements being verified), a Method (if provided or implied), and a Risk Level (if provided). If a risk level is not provided, do not include it. If a Method is not provided, you may select one from the list that makes sense, or do not include it if unsure. A verificaiton usage can have many Requirement usages related to it, so please only do this step after you have generated the consolodated list as not to duplicate verifications.

This is the template of the Verification:

verification  'Verification Name' {
    objective { 
        doc /** Verification Description */ 
        verify Package::'Requirement';
    }

    metadata VerificationCases::VerificationMethod {
        kind = VerificationCases::VerificationMethodKind::inspect; // method
    }

    metadata RiskMetadata::Risk {
      totalRisk = RiskMetadata::RiskLevelEnum::low;
    }
}

Your available methods are as follows: kind = VerificationCases::VerificationMethodKind::inspect; kind = VerificationCases::VerificationMethodKind::test; kind = VerificationCases::VerificationMethodKind::analyze; kind = VerificationCases::VerificationMethodKind::demo;

Your available risk levels are as follows: totalRisk = RiskMetadata::RiskLevelEnum::low; totalRisk = RiskMetadata::RiskLevelEnum::medium; totalRisk = RiskMetadata::RiskLevelEnum::high;