Document 23

SEBoK *System Concept Definition*, Distilled

framework

SEBoK System Concept Definition, Distilled

Top-10 distillation #5. System Concept Definition is the SEBoK page that names the SE engagement's earliest co-production rung. The "problems and solutions depend on each other" claim is direct evidence for Doc 573's co-production form. The push/pull paradigm distinction maps to Doc 270 pin-art with two different keeper-substrate proposal directions. Concurrent architecture-development with concept-definition supports Doc 572's lattice extension at the time axis. Five corpus forms compose the page; one provisional refinement candidate (Doc 573 worked example on push/pull as proposal-direction taxonomy).

I. Source

II. Source Read

System Concept Definition encompasses SE activities that examine the problem space and the needs and requirements of business and stakeholders before formal SoI development. Two primary activities: Business/Mission Analysis (defines the problem, threat, or opportunity; identifies stakeholders, goals, success measures) and Stakeholder Needs Definition (integrates needs based on stakeholder inputs, higher-level requirements, life-cycle concepts, drivers, constraints, risks). Architecture development happens concurrently. Two paradigms drive definition: pull (solving identified gaps) and push (exploiting opportunities). System-type decision (green-field / brown-field / services / operational change) emerges from the activities. Cited: INCOSE SE Handbook v5.0, ISO/IEC/IEEE 15288:2023.

III. Structural Read

Form XI — Co-Production at Sub-Rungs (Doc 573). The page's single most load-bearing claim — "problems and solutions depend on each other" — is co-production stated at the engineering scale. The SE keeper supplies a candidate solution-frame; the substrate (the stakeholder community, the operating context) responds with a problem-shape that adapts the frame; the result is jointly held. Doc 573's three patterns all show up: (a) keeper-proposes-substrate-adapts (the SE engineer offers a concept of operations and stakeholders refine it), (b) substrate-proposes-keeper-accepts (a stakeholder articulates an unmet need and the engineer formalizes it as a system concept), (c) on-the-fly composition (joint workshops where both sides co-construct).

Form IV — Pin-Art Model (Doc 270), with two proposal directions. The pull paradigm is keeper-side problem-articulation followed by candidate-solution pin-set fitting; the push paradigm is keeper-side opportunity-articulation followed by problem-discovery within the opportunity space. Both are pin-art, but the pin-set's authoring direction differs. SEBoK's distinction between push and pull is structurally a distinction in pin-art's authoring direction, not two different forms.

Form III (extension) — Lattice Extension of the Ladder (Doc 572). "Architecture development occurs concurrently with concept definition" is direct evidence for Doc 572's lattice at the time axis, the third lattice case after Doc 572 Appendix A's spatial-rung composition (development approaches) and SE-021's cross-Pattern-layer independent siblings (SoS). Concept Definition and Architecture Development are not chained; they sibling-bind the same engagement at the same calendar moment.

Form III — Substrate-and-Keeper Composition (Doc 510). The page's voice — "enterprise/project decision-makers and key stakeholders describe solution requirements collaboratively" — names the multi-keeper case. Multiple keeper roles compose at the concept-definition rung; their collective output is the concept the SE substrate then operates on. This may indicate a Doc 510 extension on multi-keeper composition (where do the multiple keepers' outputs reconcile?), though the empirical case here may be too thin for the cluster.

Form X — Institutional Ground (Doc 571). "Higher-level requirements... drivers, constraints, and risks" are institutional-ground conditions that bind the concept-definition activity. The concept is not freely chosen; it is conditioned by the institutional ground that permits or forecloses it. Doc 571's six conditions all compose against the page's list of inputs.

IV. Tier-Tags

  • "Concept Definition examines the problem space as well as the needs and requirements" — π / α (foundational; warranted by INCOSE SEH v5.0 and 15288).
  • The two primary activities (Business/Mission Analysis + Stakeholder Needs Definition) — π / α.
  • "Problems and solutions depend on each other" — π / α as cited; μ / β under corpus when read as canonical co-production (Doc 573).
  • Push/Pull paradigm distinction — π / α as cited; μ / β under corpus when read as pin-art proposal-direction taxonomy (Doc 270).
  • "Architecture development occurs concurrently with concept definition" — μ / β under corpus when read as Doc 572 lattice; SEBoK presents at π as practice observation.
  • System-type decision (green-field / brown-field / etc.) — π / α.

V. Residuals

No residuals against the apparatus. The page is structurally focused; its load-bearing claims compose under existing forms or their lattice extensions. Doc 314's virtue-constraint apparatus is not invoked — no aspirational or evaluative language to bound out.

VI. Provisional Refinements

Doc 573 worked example: push/pull as proposal-direction taxonomy. Doc 573 articulates three co-production patterns (keeper-proposes / substrate-proposes / on-the-fly). The push/pull distinction in concept definition is a fourth view at the same structure, organized by direction-of-problem-articulation rather than direction-of-structure-proposal. Worth noting in Doc 573 that the same co-production engagement can be described under multiple direction-axes; push/pull and propose-direction are orthogonal.

Doc 510 multi-keeper extension candidate. "Enterprise/project decision-makers and key stakeholders" is the multi-keeper case. Doc 510 articulates the dyad (one keeper + one substrate); SE concept definition operates with multiple keepers (project manager, mission owner, stakeholder representatives) whose outputs reconcile at the concept-definition rung. This is a candidate extension; defer until a second engagement (e.g., enterprise architecture, federated programs) supports a cluster.

VII. Cross-Links

Form documents. Doc 573 (Co-Production), Doc 270 (Pin-Art), Doc 572 (Lattice Extension), Doc 510 (Substrate-and-Keeper), Doc 571 (Institutional Ground).

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

Related distillations. SE-022 (Generic Life Cycle Model — concept definition is the first stage). SE-024 (System Requirements Definition — concept definition's downstream sibling).

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

Methodology refinement candidates. Doc 573 push/pull worked example (co-production direction-axis). Doc 510 multi-keeper extension (deferred).

Appendix: Originating Prompt

"Continue"

(SE-023 is the fifth of ten. System Concept Definition was selected as the canonical co-production rung in SEBoK and as the surface where Doc 573 meets the SE process most directly. The structural reformulation produces clean composition with one push/pull worked example candidate.)

Referenced Documents

More in framework