add stakeholder need

model/Core/Vocabularies/RelationshipType.md

@@ -67,6 +67,7 @@ name completes the sentence:
 - 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.
 - hasOptionalComponent: Every `to` Element is an optional component of the `from` Element (`from` hasOptionalComponent `to`).
 - hasOptionalDependency: The `from` Element optionally depends on each `to` Element, during a LifecycleScopeType period.
 - hasOutput: The `from` /Build/Build, DefinedProcess or Action element generates each `to` Element as an output.
@@ -81,6 +82,7 @@ name completes the sentence:
 - hasTestCase: Every `to` Element is a test case for the `from` Element (`from` hasTestCase `to`).
 - hasVariant: Every `to` Element is a variant the `from` Element (`from` hasVariant `to`).
 - implementedBy: The `from` Requirement is implemented in the `to` Element(s).
+- isQualifiedFor: The `from` Agent is qualified for or can provided the `to` Role.
 - invokedBy: The `from` Element was invoked by the `to` Agent, during a LifecycleScopeType period (for example, a /Build/Build element that describes a build step).
 - locatedAt: `from` Element located at a specific `to` Location. A time period is optional.
 - modifiedBy: The `from` Element is modified by each `to` Element.
@@ -95,6 +97,7 @@ name completes the sentence:
 - 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.
 - 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 is refined and further elaborated by each `to` Requirement, which contains more detailed implementation information.

model/FunctionalSafety/Classes/DesignRelationship.md

@@ -0,0 +1,28 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# DesignRelationship
+
+## Summary
+
+DesignRelationship defines a relationship between design-related elements, capturing their contextual linkage and lifecycle state.
+
+## Description
+
+DesignRelationship models the connections between design artifacts, system elements, or engineering work products. It provides a structured mechanism to track how design decisions, components, or specifications relate to one another and to higher-level requirements or verification activities. The `status` property records the current state of the relationship (e.g. draft, approved, or deprecated), supporting lifecycle management and change control. The `priority` property enables stakeholders to assign relative importance or urgency to specific design linkages, facilitating impact analysis and decision-making.
+
+## Metadata
+
+- name: DesignRelationship
+- SubclassOf: /Core/Relationship
+- Instantiability: Concrete
+
+## Properties
+
+- status
+  - type: StatusType
+  - minCount: 0
+  - maxCount: 1
+- priority
+  - type: /Core/DefinedType
+  - minCount: 0
+  - maxCount: 1

model/FunctionalSafety/Classes/Need.md

@@ -0,0 +1,30 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# Need
+
+## Summary
+
+A Need is condition, objective or capability desired by a Role.
+
+## 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.
+
+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'.
+
+## Metadata
+
+- name: Need
+- SubclassOf: /Core/Element
+- Instantiability: Concrete
+
+## Properties
+
+- statement
+  - type: xsd:string
+  - minCount: 1
+
+## External properties restrictions
+
+- /Core/Element/name
+  - minCount: 1

model/FunctionalSafety/Properties/priority.md

@@ -0,0 +1,21 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# priority
+
+## Summary
+
+The relative importance or urgency assigned `to` a Need or Requirement of the `from` Element.
+
+## Description
+
+The priority property enables the ranking and categorization of agent needs to facilitate requirements prioritization and scope management. This property is critical during the Needs Analysis and Requirements Analysis phases, where competing agent needs must be evaluated and balanced against constraints such as cost, schedule, and technical feasibility.
+
+The DefinedType range allows for standardized priority classifications (e.g., MoSCoW: Must, Should, Could, Won't Have; or numerical scales: High, Medium, Low) that can be consistently applied across the project. A priority assignment supports trade-off analysis and ensures that the most critical agent needs are addressed first when resource limitations exist.
+
+This ObjectProperty references a DefinedType to enable formal classification and validation of priority levels, supporting automated analysis and traceability throughout the system life cycle. Priority information may change over time as agent needs evolve or project constraints shift.
+
+## Metadata
+
+- name: priority
+- Nature: ObjectProperty
+- Range: /Core/DefinedType

model/FunctionalSafety/Properties/statement.md

@@ -0,0 +1,19 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# statement
+
+## Summary
+
+A condition, objective or capability required by a role to solve a problem.
+
+## Description
+
+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.
+
+## Metadata
+
+- name: statement
+- Nature: DataProperty
+- Range: xsd:string

model/FunctionalSafety/Properties/status.md

@@ -0,0 +1,17 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# status
+
+## Summary
+
+Indicates the current lifecycle state or maturity level of an engineering element.
+
+## Description
+
+The status property records the current progression state of an element throughout the system engineering lifecycle. By referencing the `StatusType` enumeration, it enables standardized tracking of work item maturity (e.g., Draft, Approved, Deprecated) across Needs, Requirements, and other artifacts. This property supports workflow enforcement, auditability, and impact analysis by clearly indicating whether an artifact is under development, formally accepted, superseded, or pending review from a context. The status value may evolve as the element undergoes validation, stakeholder review, or lifecycle transitions.
+
+## Metadata
+
+- name: status
+- Nature: ObjectProperty
+- Range: StatusType

model/FunctionalSafety/Vocabularies/StatusType.md

@@ -0,0 +1,21 @@
+SPDX-License-Identifier: Community-Spec-1.0
+
+# StatusType
+
+## Summary
+
+StatusType defines a controlled vocabulary of lifecycle states used to track the progression and maturity of engineering elements.
+
+## Description
+
+The StatusType enumeration provides standardized lifecycle states for engineering artifacts such as needs, requirements, designs, relationships, and verification items. It enables consistent tracking of an element's progression from initial conception through review, approval, and eventual obsolescence. By assigning a status, stakeholders can monitor work item maturity, enforce workflow rules, and facilitate traceability across system engineering phases.
+
+## Metadata
+
+- name: StatusType
+
+## Entries
+
+- draft: The element is in an initial or unreviewed state and has not yet undergone formal evaluation or approval.
+- approved: The element has been formally reviewed, validated, and accepted by the appropriate stakeholders or governing process.
+- deprecated: The element is officially superseded, obsolete, or no longer recommended for use, though it may be retained for reference or historical traceability.