Document 30

SEBoK *Stakeholder Needs Definition*, Distilled

framework

SEBoK Stakeholder Needs Definition, Distilled

Top-20 distillation #12. Stakeholder Needs Definition is the SEBoK page that operationalizes co-production at the earliest engagement rung. The "approving authorities must be identified within the stakeholder community" claim engages Doc 571 Section X.5's organization-vs-enterprise sub-form directly: approving authorities live at the organization-component while needs live at the enterprise-component. The six activities (identify stakeholders, elicit needs, identify drivers/constraints, handle risk, mature life-cycle concepts, baseline integrated set) are pin-art at the concept-formation rung. Five corpus forms compose; one residual on the multi-keeper composition that adds independent evidence to SE-023's deferred candidate.

I. Source

II. Source Read

Stakeholder Needs Definition is the second process in Concept Definition. Six activities: identify stakeholders, elicit needs, identify drivers/constraints, identify-assess-handle risk, mature life-cycle concepts, define and baseline the integrated set. Stakeholders include customers, operators, maintainers, regulators, disposal organizations across the full life cycle. Elicitation: structured workshops, interviews, focus groups, document reviews, V&V feedback. Stakeholders provide rationale and prioritization; "approving authorities must be identified within the stakeholder community (not assumed to be only the customer)." Stakeholder needs feed downstream into System Requirements Definition, which transforms needs into design-input requirements. Standards: INCOSE NRM v1.1, INCOSE GtNR v1, GtWR v4, ISO/IEC/IEEE 29148, 15288. Authors: Tami Katz (lead), Lou Wheatcraft, Mike Ryan.

III. Structural Read

Form XI — Co-Production at Sub-Rungs (Doc 573), at the earliest rung. Stakeholder Needs Definition is co-production at the engagement's beginning. The substrate (the operating context with its problems, constraints, and unmet capabilities) articulates needs in its own voice; the SE keeper supplies the structuring framework (rationale, prioritization, traceability). The output is jointly held: needs are neither pure stakeholder voice (without engineering structure) nor pure engineering specification (which comes downstream at requirements). Doc 573's three patterns (keeper-proposes, substrate-proposes, on-the-fly) all apply; the elicitation techniques (workshops, interviews, focus groups) are operational instances of each.

Form X — Institutional Ground (Doc 571), with Section X.5 organization-vs-enterprise sub-form. "Approving authorities must be identified within the stakeholder community (not assumed to be only the customer)" engages Doc 571 Section X.5 directly. The corpus reads:

  • Approving authorities live at the organization-component of institutional ground (formal positions, constitutive authority for binding stakeholder needs into project commitments).
  • Stakeholder needs live at the enterprise-component (functional context: what the operating community actually needs, including knowledge, processes, doctrines that shape need-articulation).

A failure to identify approving authorities is a Section X.5 failure mode: the engagement may capture enterprise-component needs without anchoring them in organization-component authority, producing needs that have been articulated but cannot be bound. The page's empirical claim that "leaving out a relevant stakeholder often results in missing needs and requirements" is direct evidence that the organization-vs-enterprise distinction is operationally load-bearing.

Form III — Substrate-and-Keeper Composition (Doc 510), with multi-keeper candidate. The page's emphasis on identifying stakeholders "across the system's life cycle, including customers, operators, maintainers, regulators, and disposal organizations" is the multi-keeper case at the engagement's beginning. SE-023's reformulation of Concept Definition flagged the multi-keeper extension candidate; SE-030 adds independent evidence. Each stakeholder-class operates as a co-keeper of the needs-definition activity, and their outputs reconcile through the SE keeper's facilitation. This is the second independent instance of the multi-keeper case (after SE-023); two instances may be sufficient to support the cluster, but "stakeholder identification" and "concept-definition stakeholders" are arguably the same case at different scopes.

Form IV — Pin-Art Model (Doc 270). The six activities are pin-art at the concept-formation rung. Each activity is a pin-set the keeper supplies; the substrate (the stakeholder community + the operating context) flows through; needs emerge as the shape. The risk activity is interesting: it embeds a small pulverization (Doc 445) inside the concept-formation pin-art, identifying threats and hazards that could prevent successful delivery.

Form VI — Pulverization (Doc 445). "Distinguishing critical needs from 'nice-to-haves'" via stakeholder rationale and prioritization is a pulverization at the needs rung: each candidate need is tested against stakeholder-articulated criteria and either passes (binds as a baseline need) or is downgraded. The traceability requirement ("from needs back to stakeholders ensures proper communication") is the pulverization's audit trail.

IV. Tier-Tags

  • Stakeholder Needs Definition's process position (between Mission Analysis and Requirements Definition) — π / α (foundational).
  • Six activities — π / α (well-cited; INCOSE NRM, GtNR, 15288, 29148).
  • "Approving authorities must be identified within the stakeholder community" — π / α as cited; μ / β under corpus when read through Doc 571 §X.5 organization-vs-enterprise sub-form.
  • "Leaving out a relevant stakeholder often results in missing needs" — π / α (well-warranted by SE practice).
  • "Stakeholders should provide rationale and prioritization" — π / α; μ / β under corpus when read as co-production with stakeholder-side audit.
  • Elicitation techniques (workshops, interviews, focus groups) — π / α as cited; μ / β under corpus when read as Doc 573 Section II patterns.

V. Residuals

No residuals against the apparatus. The page composes cleanly with multiple form-refinement confirmations:

  • Doc 571 §X.5 (organization-vs-enterprise sub-form) gets independent confirmation in the approving-authority distinction.
  • SE-023's multi-keeper composition candidate gets independent confirmation in the multi-stakeholder activity.
  • Doc 573 Section II patterns (keeper-proposes / substrate-proposes / on-the-fly) all show up operationally in the elicitation techniques.

The page is structurally rich in confirmation rather than in new residuals.

VI. Provisional Refinements

The multi-keeper extension candidate (Doc 510 / SE-023) now has two independent instances. The cluster may be ready for formalization. Worth treating as a candidate for the next round of corpus refinements after this batch closes.

No new refinements unique to this distillation.

VII. Cross-Links

Form documents. Doc 573 (Co-Production at Sub-Rungs), Doc 571 (Institutional Ground, with §X.5 organization-vs-enterprise), Doc 510 (Substrate-and-Keeper, multi-keeper candidate), Doc 270 (Pin-Art), Doc 445 (Pulverization).

Part-level reformulation. SE-006 (Part 3 — SE & Management).

Related distillations. SE-023 (System Concept Definition — predecessor process). SE-024 (System Requirements Definition — successor process). SE-027 (Enterprise SE — organization-vs-enterprise primary surface).

Adjacent SEBoK concepts (per source). Business or Mission Analysis, Stakeholder Requirements Definition, System Requirements Definition, Concept Definition.

Appendix: Originating Prompt

"Continue with next 10"

(SE-030 is the twelfth of twenty. Stakeholder Needs Definition was selected as the upstream co-production rung counterpart to SE-024's System Requirements Definition. Independent confirmation of Doc 571 §X.5 and SE-023's multi-keeper candidate emerges; no new residuals.)

Referenced Documents

More in framework