add stakeholder need by stevenc-stb · Pull Request #1243 · spdx/spdx-3-model

stevenc-stb · 2026-04-02T19:51:52Z

This is a stakeholder need class and definition for review
added hasStakeholderNeed, requirementRefinesStakeholderNeed Relationship Type
added class of StakeholderNeed

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Co-authored-by: Chuck Wolber <chuckwolber@gmail.com> Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb · 2026-06-06T14:06:18Z

@nicpappler @chuckwolber @kestewart Here is the update based on Friday's june 5 meeting. Thoughts?

Co-authored-by: Arthit Suriyawongkul <arthit@gmail.com> Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

bact · 2026-06-10T16:55:38Z

We may like to update the description of Requirement too, as it refer to "need" and we introduce Need here.

2nd paragraph of Requirement's description:

A requirement element is a distinct unit that defines an expectation, need, behavior, or design intent of an item that either already exists or is to be created in accordance with this requirement.

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

kestewart · 2026-08-07T16:42:36Z

@@ -0,0 +1,19 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# statement


I'm a bit worried this name will be overloaded (others may want to use the term), may want something a bit more specific as a property name.

Why can't "Need" which is a statement cover this this?

kestewart · 2026-08-07T16:49:15Z

 - republishedBy: Designates a `from` /Security/Vulnerability's details were tracked, aggregated, and/or enriched to improve context (i.e. NVD) by each `to` Agent.
 - resolved: The `to` /SupplyChain/OutOfSpecAction is resolved in the `from` /SupplyChain/ResolutionAction.
 - runsOn: The `from` Element (the instructions) runs on each `to` /Hardware/Hardware (processing element), during a LifecycleScopeType period.
+- satisfies: The `from` Requirement satisfies `to` /FunctionalSafety/Need. Note: The Requirement is not generally intended to singularly satisfy a particular Need. It is more likely that a set of higher level Requirements is required to achieve a reasonable satisfaction of an expressed /FunctionalSafety/Need.


I'm thinking may be "satisfies" may be useful beyond requiement class. Specification for example.

kestewart · 2026-08-07T20:31:30Z

@@ -0,0 +1,28 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# DesignRelationship


NAK

Not completely clear why we need to artifically restrict this down. The design elements may be in core, FUSA, software, hardware, data, etc.

We've already discussed having status as a property on a requirement, putting it on the relationship will just confuse things.

Let's keep avoid commiting this for now and let folks use standard files for capturing information - we'll need this as a transition from 3.0 where folks are using SPDX already.

Would rather see this modeled as a "RelationshipType" than a new class.

We agreed in the call that a Design is just a form of Requirement. What we need to document in a different setting is "Decision". We did not even start the discussion of decision. Discussed this with both the Elisa and the Zephyr community, all agree that Design is just a form of Requirement (or Specification, if you use a Bundle to group these design Requirements to be used in a document). Lifecycle management tools and process descriptions out there also treat the design as something that is created the same way as requirements, just with describing the requirements of a component (e.g. a set of .c/h. files, a function, a single .c file) instead of the (e.g. functional) requirements to it.

nicpappler

This has not been discussed this way in the safety calls, it does not always reflect, how the Needs concept is used in engineering, and it makes things too complicated.

nicpappler · 2026-08-10T05:58:36Z

@@ -0,0 +1,28 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# DesignRelationship


We agreed in the call that a Design is just a form of Requirement. What we need to document in a different setting is "Decision". We did not even start the discussion of decision. Discussed this with both the Elisa and the Zephyr community, all agree that Design is just a form of Requirement (or Specification, if you use a Bundle to group these design Requirements to be used in a document). Lifecycle management tools and process descriptions out there also treat the design as something that is created the same way as requirements, just with describing the requirements of a component (e.g. a set of .c/h. files, a function, a single .c file) instead of the (e.g. functional) requirements to it.

nicpappler · 2026-08-10T06:02:52Z

+
+## Description
+
+A Need represents the high-level intent expressed by Role during the Needs Analysis phase of the life cycle. It defines the problem space or desired capability before it is translated into verifiable system requirements.


I would not call it "Need Analysis Phase". There is no specific need analysis phase, this kind of analysis happens whenever one want to specify the requirements to a component. E.g. if your system consists of a microconcoller (that already comes with its abstraction layer etc.) and you have the application software, you still want an RTOS. Here you take what you need to integrate your uC, its abstraction and your application software together - so you specify the needs you have on an RTOS. This usually happens when you specify your system/software architecture. But for sure there are other architectural or design phases in your system (or service) where you specify what you need.

nicpappler · 2026-08-10T06:04:19Z

+
+A Need represents the high-level intent expressed by Role during the Needs Analysis phase of the life cycle. It defines the problem space or desired capability before it is translated into verifiable system requirements.
+
+This entity captures the natural language expression of the Need via the statement property, ensuring the Role's voice is preserved in the model. Role Needs are distinct from System Requirements; while requirements must be technically verifiable, needs express the underlying value or necessity that justifies the system's existence. Traceability from derived requirements back to Needs is essential to ensure alignment with stakeholder expectations with the RelationshipType 'satisfies'.


Needs also must be verifiable, otherwise you will get into contractual issues. A tier 1 supplier has to prove that they met all the needs the OEM has specified for them to implement.

nicpappler · 2026-08-10T06:06:04Z

+
+The statement property captures the natural language articulation of a Need during the Needs Analysis phase. It represents the primary input for the Requirements Engineering process, preserving the role's original intent before transformation into verifiable system requirements.
+
+While derived requirements must adhere to strict verification criteria, the statement within a Need may initially be qualitative or subjective. This property serves as the foundational traceability link, ensuring that downstream system capabilities can be traced back to the original role intent. The use of xsd:string accommodates the unstructured nature of early elicitation, allowing for the recording of raw role input prior to refinement.


I also don't get why we need this "statement" - the description sounds very much like a "comment".

nicpappler · 2026-08-10T06:07:24Z

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


We already use status within Requirement now, which was agreed with and requested by the safety communities (Elisa, Zephyr, Xen) - we also discussed this in the safety call this way. It is important we do not have a conflict here.

nicpappler · 2026-08-10T06:08:06Z

@@ -0,0 +1,21 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# StatusType


Same request to not create a conflict with what we agreed on in the Requirement status discussion.

nicpappler · 2026-08-10T06:10:53Z

 - hasHost: The `from` /Build/Build was run on the `to` Element during a LifecycleScopeType period (e.g. the host that the build runs on).
 - hasInput: The `from` /Build/Build, DefinedProcess or Action element has each `to` Element as an input.
 - hasMetadata: Every `to` Element is metadata about the `from` Element (`from` hasMetadata `to`).
+- hasNeed: The `from` Role has the `to` /FunctionalSafety/Need.


I do not agree that a Role is the only thing that can have a "Need". Sometime you have a Need, that results from an assumption of another system component. It can also come from a contract. And in these cases you would have to make up a Role, just to satisfy this statement. I'd suggest to not use "Role", but "Element".

stevenc-stb added 15 commits March 28, 2026 09:36

Add files via upload

0737b7c

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Add files via upload

1f61784

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Merge branch 'spdx:develop' into stevenc-add-StakeholderNeed

7ceb6ca

Update StakeholderNeed.md

414be3a

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update StakeholderNeed.md

21c21bc

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update stakeholderPriority.md

6ad2594

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update statement.md

acb402c

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update RelationshipType.md

66b69a8

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update RelationshipType.md

646f8d2

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update RelationshipType.md

2e221cd

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update StakeholderNeed.md

aaf2787

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update stakeholderPriority.md

7687c47

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update stakeholderPriority.md

5ed658e

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update StakeholderNeed.md

4e5c990

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update StakeholderNeed.md

b070d00

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb added Profile:FuSa FunctionalSafety profile and related matters labels Apr 2, 2026

stevenc-stb added 2 commits April 10, 2026 10:32

Update StakeholderNeed.md

1a23656

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update StakeholderNeed.md

36ea34c

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

chuckwolber reviewed Apr 17, 2026

View reviewed changes

Comment thread model/Core/Vocabularies/RelationshipType.md Outdated

Update model/Core/Vocabularies/RelationshipType.md

869176e

Co-authored-by: Chuck Wolber <chuckwolber@gmail.com> Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb commented Apr 17, 2026

View reviewed changes

Comment thread model/Core/Vocabularies/RelationshipType.md Outdated

Comment thread model/Core/Vocabularies/RelationshipType.md Outdated

stevenc-stb added 2 commits April 17, 2026 10:46

Update model/Core/Vocabularies/RelationshipType.md

8e99aac

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update model/Core/Vocabularies/RelationshipType.md

d11637d

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb commented Apr 17, 2026

View reviewed changes

Comment thread model/Core/Vocabularies/RelationshipType.md Outdated

Update model/Core/Vocabularies/RelationshipType.md

60f05af

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb commented Apr 17, 2026

View reviewed changes

Comment thread model/Core/Vocabularies/RelationshipType.md Outdated

Update model/Core/Vocabularies/RelationshipType.md

49f7f93

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb commented Apr 17, 2026

View reviewed changes

Comment thread model/Core/Vocabularies/RelationshipType.md Outdated

Update model/Core/Vocabularies/RelationshipType.md

c46c02d

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb added 6 commits June 6, 2026 07:34

Update DesignRelationship.md

1d981d3

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update status.md

6a16f6a

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update priority.md

d87a9ce

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update StatusType.md

b47d903

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update Need.md

ceea00d

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update DesignRelationship.md

ee49414

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb requested review from chuckwolber and kestewart and removed request for chuckwolber June 6, 2026 13:58

stevenc-stb added 2 commits June 6, 2026 08:02

Update DesignRelationship.md

cb067ee

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update DesignRelationship.md

a3c0cbc

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

bact reviewed Jun 6, 2026

View reviewed changes

stevenc-stb and others added 3 commits June 6, 2026 08:53

Apply suggestions from code review

6c0402d

Co-authored-by: Arthit Suriyawongkul <arthit@gmail.com> Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update Need.md

8e2afdd

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update Need.md

114fea3

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb requested a review from bact June 6, 2026 15:13

stevenc-stb added 7 commits August 5, 2026 07:13

Merge branch 'develop' into stevenc-add-StakeholderNeed

f41e9fc

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update RelationshipType.md

3d26781

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update RelationshipType.md

7f25533

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update RelationshipType.md

1f73732

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update Need.md

3116fc4

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update Need.md

100dc77

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

Update DesignRelationship.md

a962eb4

Signed-off-by: stevenc-stb <steven@smarttalkbeacon.com>

stevenc-stb marked this pull request as ready for review August 7, 2026 14:35

kestewart requested changes Aug 7, 2026

View reviewed changes

nicpappler suggested changes Aug 10, 2026

View reviewed changes

goneall added this to the 3.1-rc3 milestone Aug 28, 2026

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

		# statement

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

		# DesignRelationship


		## Description

		A Need represents the high-level intent expressed by Role during the Needs Analysis phase of the life cycle. It defines the problem space or desired capability before it is translated into verifiable system requirements.


		A Need represents the high-level intent expressed by Role during the Needs Analysis phase of the life cycle. It defines the problem space or desired capability before it is translated into verifiable system requirements.

		This entity captures the natural language expression of the Need via the statement property, ensuring the Role's voice is preserved in the model. Role Needs are distinct from System Requirements; while requirements must be technically verifiable, needs express the underlying value or necessity that justifies the system's existence. Traceability from derived requirements back to Needs is essential to ensure alignment with stakeholder expectations with the RelationshipType 'satisfies'.


		The statement property captures the natural language articulation of a Need during the Needs Analysis phase. It represents the primary input for the Requirements Engineering process, preserving the role's original intent before transformation into verifiable system requirements.

		While derived requirements must adhere to strict verification criteria, the statement within a Need may initially be qualitative or subjective. This property serves as the foundational traceability link, ensuring that downstream system capabilities can be traced back to the original role intent. The use of xsd:string accommodates the unstructured nature of early elicitation, allowing for the recording of raw role input prior to refinement.

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

		# StatusType

Uh oh!

Conversation

stevenc-stb commented Apr 2, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stevenc-stb commented Jun 6, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bact commented Jun 10, 2026

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!

kestewart Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nicpappler left a comment

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

kestewart Aug 7, 2026 •

edited

Loading