Update PR #1061 with the changes discussed in the FuSa call to make t… #1141

nicpappler · 2025-10-31T15:40:44Z

Update PR #1061 with the changes discussed in the FuSa call to make t…he profile more reality friendly and implementable by tool creators

This updates the PR #1061

…ke the profile more reality friendly and implementable by tool creators

stevenc-stb

some Markdown fixes

Nature: is DataProperty or ObjectProperty see format

model/Core/Properties/devLifeCycleStage.md

model/Core/Properties/requirementRational.md

model/Core/Properties/requirementStatement.md

model/Core/Properties/requirementUUID.md

stanislaw · 2025-10-31T17:21:30Z

model/Core/Properties/requirementRational.md

@@ -0,0 +1,17 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# requirementRational


Should this be requirementRationale? If yes, then, also the file name change is needed.

stanislaw

It is a great, well-focused PR. I really welcome this change!

I only left some smaller suggestions, not changing the overall structure of what is proposed.

(Sorry, I missed to join the FuSa meeting due to the timezone change 🥲 )

model/Core/Classes/Requirement.md

stanislaw · 2025-10-31T17:36:10Z

model/Core/Properties/requirementRational.md

+
+## Description
+
+Additional detail used to define the reason/rational, why this requirement is there or give some additional information, needed to understand the requirement. Usually less formal than the requirement wording of the RequirementStatement.


Here I would add:

Additional detail used to define the reason or justification for the existence of the requirement. The rationale is usually less formal than the wording of the requirement statement itself.

If a requirement is linked to a parent requirement, the rationale shall provide a high-level justification describing how the child requirement satisfies or contributes to fulfilling the intent of the parent requirement. If a requirement has no parent linkage, the rationale shall provide a self-contained explanation of the underlying reasoning or purpose for the requirement — i.e., it shall justify why the requirement is stated as it is.

Note that I removed the additional information because this can be done by using the parent SPDX element fields.

model/Core/Properties/requirementUUID.md

stanislaw · 2025-10-31T17:39:55Z

model/Software/Vocabularies/ContentIdentifierType.md


 - gitoid: [Gitoid](https://www.iana.org/assignments/uri-schemes/prov/gitoid), stands for [Git Object ID](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects). A gitoid of type blob is a unique hash of a binary artifact. A gitoid may represent either an [Artifact Identifier](https://github.com/omnibor/spec/blob/eb1ee5c961c16215eb8709b2975d193a2007a35d/spec/SPEC.md#artifact-identifier-types) for the software artifact or an [Input Manifest Identifier](https://github.com/omnibor/spec/blob/eb1ee5c961c16215eb8709b2975d193a2007a35d/spec/SPEC.md#input-manifest-identifier) for the software artifact's associated [Artifact Input Manifest](https://github.com/omnibor/spec/blob/eb1ee5c961c16215eb8709b2975d193a2007a35d/spec/SPEC.md#artifact-input-manifest); this ambiguity exists because the Artifact Input Manifest is itself an artifact, and the gitoid of that artifact is its valid identifier. Gitoids calculated on software artifacts (Snippet, File, or Package Elements) should be recorded in the SPDX 3.0 SoftwareArtifact's contentIdentifier property. Gitoids calculated on the Artifact Input Manifest (Input Manifest Identifier) should be recorded in the SPDX 3.0 Element's externalIdentifier property. See [OmniBOR Specification](https://github.com/omnibor/spec/), a minimalistic specification for describing software [Artifact Dependency Graphs](https://github.com/omnibor/spec/blob/eb1ee5c961c16215eb8709b2975d193a2007a35d/spec/SPEC.md#artifact-dependency-graph-adg).
 - swhid: SoftWare Hash IDentifier, a persistent intrinsic identifier for digital artifacts, such as files, trees (also known as directories or folders), commits, and other objects typically found in version control systems. The format of the identifiers is defined in the [SWHID specification](https://www.swhid.org/specification/v1.1/4.Syntax) (ISO/IEC DIS 18670). They typically look like `swh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2`.
+- reqUID: the UID used by a requirements management or any other lifecycle management tool to uniquely identify a requirement item. UID, or unique ID, is a standard term in requirements engineering.


Should this be reqUID or reqUUID? I think the addition of universally unique is very important here.

Also, should it be written as requirementUUID?

stanislaw · 2025-10-31T17:46:13Z

model/Core/Vocabularies/RelationshipType.md

 - republishedBy: Designates a `from` Vulnerability's details were tracked, aggregated, and/or enriched to improve context (i.e. NVD) by each `to` Agent.
 - serializedInArtifact: The `from` SpdxDocument can be found in a serialized form in each `to` Artifact.
 - testedOn: The `from` Element has been tested on the `to` Element(s).
+- tracedToDetail: the `from` Requirement has some more detailed implementation information in each `to` Requirement.


Suggested change

- tracedToDetail: the `from` Requirement has some more detailed implementation information in each `to` Requirement.

- tracedToDetail: the `from` Requirement is refined and further elaborated by each `to` Requirement, which contains more detailed implementation information.

stanislaw · 2025-10-31T17:47:59Z

model/Core/Properties/requirementRational.md

+
+## Summary
+
+Text used to define the rational or additional information.


Suggested change

Text used to define the rational or additional information.

Text used to describe the rationale of the requirement, explaining the reasoning or justification behind its formulation.

stanislaw · 2025-10-31T17:49:33Z

model/Core/Classes/Requirement.md

+
+## Description
+
+A requirement element is a distinct article or unit defining an expectation, need, behaviour, design intent etc. of an item that already exists or is to be created based on this requirement.


Suggested change

A requirement element is a distinct article or unit defining an expectation, need, behaviour, design intent etc. of an item that already exists or is to be created based on this requirement.

A requirement element is a distinct article or unit defining an expectation, need, behaviour, design intent, etc., of an item that already exists or is to be created based on this requirement.

model/Core/Properties/devLifeCycleStage.md

stanislaw · 2025-10-31T17:54:03Z

model/Core/Properties/devLifeCycleStage.md

@@ -0,0 +1,17 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# devLifeCycleStage


I am not a native English speaker but I think we can simply do devLifecycleStage because lifecycle is really one word.

I'm not a native English speaker as well and in general I don't have a preference between "LifeCycle" and "Lifecycle" -- but as we already have /Core/LifecycleScopedRelationship, we should keep using "Lifecycle".

Co-authored-by: Stanislav Pankevich <s.pankevich@gmail.com> Signed-off-by: Nicole Pappler <nicole@alektometis.com>

Co-authored-by: Stanislav Pankevich <s.pankevich@gmail.com> Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>

This is a fix for the .md as per https://github.com/spdx/spdx-3-model/blob/develop/docs/format.md#properties Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update PR spdx#1061 with the changes discussed in the FuSa call to ma…

4e5e6ca

…ke the profile more reality friendly and implementable by tool creators

nicpappler mentioned this pull request Oct 31, 2025

Adding safety profile png and model for Requirement Class #1061

Open

nicpappler added 2 commits October 31, 2025 16:58

adding new relationships

4b6550f

incorporating Steven's feedback during the FuSa call

8d349d7

stevenc-stb requested changes Oct 31, 2025

View reviewed changes

stanislaw reviewed Oct 31, 2025

View reviewed changes

nicpappler and others added 4 commits October 31, 2025 19:02

Update model/Core/Classes/Requirement.md

1dcff2d

Co-authored-by: Stanislav Pankevich <s.pankevich@gmail.com> Signed-off-by: Nicole Pappler <nicole@alektometis.com>

Update model/Core/Classes/Requirement.md

a96a89c

Co-authored-by: Stanislav Pankevich <s.pankevich@gmail.com> Signed-off-by: Nicole Pappler <nicole@alektometis.com>

Update model/Core/Properties/devLifeCycleStage.md

3bfcd85

Co-authored-by: Stanislav Pankevich <s.pankevich@gmail.com> Signed-off-by: Nicole Pappler <nicole@alektometis.com>

Fix typo as suggested

6e647ba

Co-authored-by: Stanislav Pankevich <s.pankevich@gmail.com> Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>

bact added the Profile:FuSa FunctionalSafety profile and related matters label Nov 3, 2025

Fix for validation

79a23a0

This is a fix for the .md as per https://github.com/spdx/spdx-3-model/blob/develop/docs/format.md#properties Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

		@@ -0,0 +1,17 @@
		SPDX-License-Identifier: Community-Spec-1.0

		# requirementRational


		## Description

		Additional detail used to define the reason/rational, why this requirement is there or give some additional information, needed to understand the requirement. Usually less formal than the requirement wording of the RequirementStatement.

	- tracedToDetail: the `from` Requirement has some more detailed implementation information in each `to` Requirement.
	- tracedToDetail: the `from` Requirement is refined and further elaborated by each `to` Requirement, which contains more detailed implementation information.


		## Summary

		Text used to define the rational or additional information.

	Text used to define the rational or additional information.
	Text used to describe the rationale of the requirement, explaining the reasoning or justification behind its formulation.


		## Description

		A requirement element is a distinct article or unit defining an expectation, need, behaviour, design intent etc. of an item that already exists or is to be created based on this requirement.

		@@ -0,0 +1,17 @@
		SPDX-License-Identifier: Community-Spec-1.0

		# devLifeCycleStage

Update PR #1061 with the changes discussed in the FuSa call to make t… #1141

Are you sure you want to change the base?

Update PR #1061 with the changes discussed in the FuSa call to make t… #1141

Uh oh!

Conversation

nicpappler commented Oct 31, 2025

Uh oh!

stevenc-stb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stanislaw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants