The following changes are proposed (note that there are some changes from the original proposal to make it more complete and correct):

Changes to: 7.6.3 ExtRequirement
1) add /validatedBy:ValidationActivity[0..*]
Documentation: The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
2) add getValidatedBy():ValidationActivity[0..*]
documentation: The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
specification: Validate.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier

Changes to: 7.6.3 VerificationActivity
add:
verifies : AbstractRequirement[0..*] - The requirements that this VerificationActivity verifies.
add to doc (was already part of profile):
verificationMethod : VerificationMethodKind -The verificationMethod indicates the primary method that «VerificationActivity» uses to verify a Requirement.

added

getVerifies():AbstractRequirement[0..*]
Specification: Verification.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
Documentation: The query getVerifies() returns all AbstractRequirement that are suppliers ( "to" end of the concrete syntax ) of a «Verifies» relationship whose client is the element input parameter, ref. This is a static query.

Change to: Figure 7 SysML Extensions Profile
Update diagram to reflect the addition of /validatedBy:ValidationActivity[0..*] element on the ExtRequirement Stereotype.

Change to: Figure 5 Validation and Verification Profile
Update diagram to show the addition of /verifies:AbstractRequirement[0..*] on the VerificationActivity stereotype.

Add derived properties and methods to improve usability.

Add elements and add a clarifying note to model and specification:

Changes to ExtRequirement

1) add /validatedBy:ValidationActivity[0..*]
Documentation: The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
2) add getValidatedBy():ValidationActivity[0..*]
documentation: The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
specification: Validate.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier

Note about this change: First, this is intended to mirror the same pattern as SysML. Second, the verifies and verifiedBy already exists in abstractRequirement. Because Verifies is a kind of Verify, no change is required.

Changes to VerificationActivity
1) add /verifies:VerificationActivity[0..*]
2) add getVerifies():VerificationActivity[0..*]
Specification: Verification.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
Documentation: The query getVerifies() returns all the NamedElements that are suppliers ( "to" end of the concrete syntax ) of a «Verifies» relationship whose client is the element input parameter, ref. This is a static query.

Change to: Figure 7 SysML Extensions Profile
Update diagram to reflect the addition of /validatedBy:ValidationActivity[0..*] element on the ExtRequirement Stereotype.

Change to: Figure 5 Validation and Verification Profile
Update diagram to show the addition of /verifies:AbstractRequirement[0..*] on the VerificationActivity stereotype.

We are missing the comments to source and risk of ExtRequirement. The elements also need to be printed in the specification. Other tag definitions are also not printed and thus need to be displayed.

*Add comments to 7.6.3 ExtRequirement *

Add the following text to 7.6.3 after the Generalization section. To be clear, when complete with all changes we have for 7.6.3, paragraph should look like this:

Description
The «ExtRequirement» is a mix-in stereotype that contains generally useful attributes for requirements.
Note: This stereotype should be used instead of the «extendedRequirement» in the SysML non-normative extension of SysML
Generalization:
• SysML::Requirements::Requirement
Attributes
• risk : RiskKind - Risk level of the requirement.
• source : String - Source (originating person and/or organization) of the requirement.
• /validatedBy : ValidationActivity[0..*] - The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
Operations:
• getValidatedBy - The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
specification:
Validate.allInstances()->select(base Abstraction.client=ref).base_Abstraction.supplier

Need to add documentation of MeasurementSpecification.summary (paragraph 7.28) and fix MeasurementSpecification.id missing documentation.

The summary element is missing documentation.
The id incorrectly indicates that it is the id of a requirement, rather than a MeasurementSpecification.

Add documentation to summary and fix documentation in summary

Add/change documentation as follows to the model and to the specification:

MeasurementSpecification.summary
add documentation: The summary is a textual description of constraints, and measurement activities used to provide insight into the progress made in the definition and development of the technical solution, risks, and issues.

MeasurementSpecification.id
From: The unique id of the requirement.
to: The id of the MeasurementSpecification.

VerificationActivity.verificationMethod is missing documentation.

Proposed fix: add documentation to
The verificationMethod property indicates the primary method that VerificationActivity uses to verify a Requirement.

add documentation to VerificationMethod and show attributes of VerificationActivity

Change to: 7.4.3 VerificationActivity
Add the following text to 7.4.3:
In the profile, add documentation to the verifies attribute of <<VerificationActivity>>:

The requirements that this VerificationActivity verifies.

Add previously undocumented attributes (verificationMethod and verifies) of <<VerificationActivity>>: to the specification by adding the revised text to paragraph 7.4.3.

Section 7.6 to be replaced with an official SysML extensions profile. Section 1.6 was a hack that allowed the specification to move forward.

Unfortunately replacing this section with a SysML profile may not be easy because of issues with how vendors have implemented the SysML extensions. It may be simpler to replicate all or part of the extensions.

No change to 7.6 SysML Extensions is required

No change to 7.6 SysML Extensions is required.

The creation of an official version of SysML Extensions seems unwise as all the vendors and lots of users would be affected. The current profile described in this section is adequate for our purposes.

Note: We already voted on this, but having to recreate it because the result was lost.

David Kaslow requested that derived properties be added to allow reporting.

For example, a user of the profile should be able to add to a table a column that matches the Validated By or Validates concepts (and others) similar to how tables can display Verified By and Verifies.

Issue resolved in CSRM-14

CSRM-2 was re-opened to change the priority (I did not realize this could be modified), CSRM-14 essentially duplicates the issue and was already resolved. Best thing to do is to close this issue as a duplicate of CSRM-14.

As the spec already has a reference to the machine-readable file, this line is redundant.

This line in paragraph 2 should be removed:

dtc/22-04-06 - CSRM Profile - XMI File (see the description in Section 6)

Reported by Pete Rivett during FTF review.

Remove the following text in section 2 Conformance

Remove the following text in section 2 Conformance

dtc/22-04-06 - CSRM Profile - XMI File (see the description in Section 6)

Clarify the use of the Group stereotype.
Pete Rivette wrote:
7.1.12 says that <<Group>> groups related requirements but not which property is used to achieve that.

Add Clairifying info and paragraph to documentation of 7.1.12 Group

Change the existing documentation of 7.1.12 Group to help understand how the element is used and examples of use.

The original issue is perhaps incorrect as I misunderstood the intent. The name changes were to additions to the spec. I am proposing to close with no change as only CubeSatRequirement actually exists and a SatelliteRequirement is there if desired by a user of the profile.

Incorrectly submitted issue was against a future plan

JD complained that the priority was incorrect. Changed priority to trivial.
This was originally written up as a bug of initial submission, but it is actually against a proposed plan, not the current version. It is therefore immaterial to the changes of the FTF, so Closed: No Change.

Remove section 0 (zero) from finalized specification.

Change already made by OMG editor

Added the task without realizing that taskj already performed by OMG editor. No change required

This issue created by mistake

Removal of incorrectly created subtask

Parent task is closed; No Change, so doing the same with sub task.

To make the case for updating CSRM stereotypes. Once agreement is reached, updates to the CSRM Specification will be developed.
This is a big deal and needs lots of discussion.

Figures 1 lists CSRM element stereotypes. Black font denotes current baseline as captured in the normative CSRM Profile. Blue font denotes recommended additions.

Figure 2 lists requirement elements related properties that are part of the SysML language.

Figure 3 illustrates one of many ways to establish relationships between the mission stakeholders, requirements, technical measures, and use cases stereotypes. These stereotypes are denoted by italicized font in Figure 1.
The relationships are captured in the element specifications and are displayed and maintained in diagrams and tables as shown in Figure 1.
Object Constraint Language

There has been discussion about codifying the allowable relationships using Object Constraint Language (OCL). OCL is a declarative language describing rules applying to Unified Modeling Language (UML) models. For example, a refine relationship can exist between a requirement. and any other model element, whereas a derive relationship can only exist between requirements.

That could be done founded on the examples in Figure 3. This would be of limited benefit. A mission team will be using the stereotypes and relationships best suited to their mission and the stereotypes in Figure 3 are very limited as compared to Figure 1.

A case could be made to established relationships for the stereotypes in Figure 1. But that is out-of-Scope for the SSWG CSRM effort.

An Issue that Needs Resolution.

The intent of defining addition stereotypes as shown in Figure 1 is to provide stereotypes for a variety of mission architectures. However, several of the stereotypes are identified as CubeSat stereotypes. But they are not unique to CubeSats. The only thing that makes a model a CubeSat model is the incorporation of a CubeSat form factor such as the Cal Poly CubeSat Design Specification.

My recommendation is to rename the stereotypes as show in Table 1 below.

Table 1. Renaming of Stereotypes (Proposed name changes from Figure 1)
CubeSatRequirement SatelliteRequirement
CubeSatSubsystemRequirement SatelliteSubsystemRequirement
CubeSatComponentRequirement SatelliteComponentRequirement
CubeSatUseCase SatelliteUseCase
CubeSatSubsystemUseCase SatelliteSubsystemUseCase

Defer to RTF

Defer to RTF

Constraints should be added to aid in the creating of correct models. For example, an MoE needs to be related to a moeRequirement which in turn is refined by a moeSpecification.

In addition, by categorization and content of warings and error of the constraints, we could add hints for new users of minimal and advanced concepts.

Defer adding constraints to RTF

This is rather complex and our team does not have the resources to address. It is also better to address the constraints as people begin to use the profile and as RTF possibly expands the standard.

Note: We already voted on this in Ballot #1, but the result was lost.

Dave Kaslow proposes the following changes to stereotypes:

From: CubeSatRequirement to: SatelliteRequirement
From: CubeSatSubsystemRequirement to: SatelliteSubsystemRequirement
From: CubeSatComponentRequirement to: SatelliteComponentRequirement
From: CubeSatUseCase to: SatelliteUseCase
From: CubeSatSubsystemUseCase to: SatelliteSubsystemUseCase

Document attached was where the issue was raised.

Issue created by mistake

This issue related to a proposal and this was mistakingly created against the FTF. Closing with no change required.

Originally the first versions of CSRM had examples. However, when the spec was reduced to a profile, the examples were removed. Because of some of the changes, not all examples are viable, so it is proposed we create new examples. Dave Kaslow also requested that the examples be categorized as a simplified and expert use of the profile to aid adoption by students.

Defer to RTF

The profile is fairly straight forward with much of the vocabulary in MBSE and space domains. Deferring issue to RTF to reconsider for a later version.

The original icons used for stereotypes in the profile were drafts and need to be replaced with better versions. The icons also need to be delivered as SVG.

The document does not currently show these icons, so diagrams need to be updated or an appendix added to the icons.

Defer to RTF

Punting this issue to the next release.

Per standard process, Section 0 (zero) is to be removed from the Finalized document.,

Change already made by OMG editor

Closing subtask that was created by mistake..