Merge pull request #437 from raifdmueller/add-lehmans-classification

rdmueller · web-flow · commit 10d889e81f6e · 2026-04-15T11:29:15.000+02:00
feat: add Lehman's Software Classification anchor (#436)
diff --git a/docs/anchors/lehmans-classification.adoc b/docs/anchors/lehmans-classification.adoc
@@ -0,0 +1,49 @@
+= Lehman's Software Classification
+:categories: software-architecture
+:roles: software-architect, requirements-engineer, team-lead, educator
+:related: arc42, cohesion-criteria
+:proponents: Meir M. Lehman
+:tags: classification, software-evolution, requirements, maintenance, s-type, p-type, e-type
+:tier: 2
+
+[%collapsible]
+====
+Full Name:: Lehman's Classification of Software (S-/P-/E-type) and Laws of Software Evolution
+
+Also known as:: SPE Classification, Lehman's SPE Taxonomy
+
+[discrete]
+== *Core Concepts*:
+
+Three software types, classified by their relationship to the real world:
+
+S-type (Specification)::
+Software whose problem can be fully and formally specified. Correctness is provable against the specification. The world outside the program is irrelevant to its validity. Example: a sorting algorithm, a compiler for a formally defined language.
+
+P-type (Problem)::
+Software that addresses a real-world problem which cannot be fully specified, only approximated. The specification is a model of the real problem; the solution must be validated against the actual problem, not just the spec. Example: a chess-playing program, a weather forecasting system.
+
+E-type (Embedded)::
+Software that becomes part of the real world and changes it through its use. This use in turn changes the environment and thereby the requirements — creating a feedback loop. Most business and organizational software is E-type. A "correct" E-type system drifts out of correctness over time even if nothing in it changes.
+
+Laws of Software Evolution::
+Lehman derived eight laws from observing E-type systems, including *Continuing Change* (E-type systems must be continually adapted or become progressively less satisfactory), *Increasing Complexity* (complexity increases unless work is done to reduce it), *Self-Regulation*, *Conservation of Organisational Stability*, *Conservation of Familiarity*, *Continuing Growth*, *Declining Quality*, and *Feedback System*.
+
+Key Proponents:: Meir M. Lehman ("Programs, life cycles, and laws of software evolution", Proceedings of the IEEE, 1980); later developed with Laszlo Belady ("Program Evolution: Processes of Software Change", 1985).
+
+[discrete]
+== *When to Use*:
+
+* Explaining why "finished" business software still needs ongoing investment
+* Deciding how much effort to spend on formal specification vs. validation with users
+* Framing requirements discussions — E-type means requirements will keep changing by nature, not by failure
+* Reasoning about why TDD and formal proofs map cleanly onto S-type but are subtler for E-type
+* Estimating maintenance budgets and justifying them to stakeholders
+* Architectural trade-offs: E-type systems need change-friendliness above all
+
+[discrete]
+== *Related Anchors*:
+
+* <<arc42,arc42>> - Documentation template well suited for evolving E-type systems
+* <<cohesion-criteria,Cohesion Criteria>> - High cohesion reduces the cost of continuing change in E-type systems
+====
diff --git a/docs/anchors/lehmans-classification.de.adoc b/docs/anchors/lehmans-classification.de.adoc
@@ -0,0 +1,48 @@
+= Lehmans Software-Klassifikation
+:categories: software-architecture
+:roles: software-architect, requirements-engineer, team-lead, educator
+:related: arc42, cohesion-criteria
+:proponents: Meir M. Lehman
+:tags: klassifikation, software-evolution, requirements, wartung, s-type, p-type, e-type
+
+[%collapsible]
+====
+Vollständiger Name:: Lehmans Software-Klassifikation (S-/P-/E-Type) und Gesetze der Software-Evolution
+
+Auch bekannt als:: SPE-Klassifikation, Lehmans SPE-Taxonomie
+
+[discrete]
+== *Kernkonzepte*:
+
+Drei Software-Typen, klassifiziert nach ihrer Beziehung zur realen Welt:
+
+S-Type (Specification)::
+Software, deren Problem vollständig und formal spezifizierbar ist. Korrektheit ist gegen die Spezifikation beweisbar. Die Welt außerhalb des Programms ist für seine Gültigkeit irrelevant. Beispiel: ein Sortieralgorithmus, ein Compiler für eine formal definierte Sprache.
+
+P-Type (Problem)::
+Software, die ein reales Problem löst, das nicht vollständig spezifiziert, sondern nur approximiert werden kann. Die Spezifikation ist ein Modell des realen Problems; die Lösung muss gegen das echte Problem validiert werden, nicht nur gegen die Spec. Beispiel: ein Schachprogramm, ein Wettervorhersagesystem.
+
+E-Type (Embedded)::
+Software, die Teil der realen Welt wird und diese durch ihren Einsatz verändert. Dieser Einsatz verändert wiederum die Umgebung und damit die Anforderungen — es entsteht eine Rückkopplungsschleife. Die meiste Business- und Organisationssoftware ist E-Type. Ein "korrektes" E-Type-System wird mit der Zeit inkorrekt, selbst wenn sich in ihm nichts ändert.
+
+Gesetze der Software-Evolution::
+Lehman leitete acht Gesetze aus der Beobachtung von E-Type-Systemen ab, darunter *Continuing Change* (E-Type-Systeme müssen kontinuierlich angepasst werden, sonst werden sie zunehmend unbefriedigend), *Increasing Complexity* (Komplexität wächst, sofern nicht aktiv reduziert), *Self-Regulation*, *Conservation of Organisational Stability*, *Conservation of Familiarity*, *Continuing Growth*, *Declining Quality* und *Feedback System*.
+
+Schlüsselvertreter:: Meir M. Lehman ("Programs, life cycles, and laws of software evolution", Proceedings of the IEEE, 1980); später mit Laszlo Belady weiterentwickelt ("Program Evolution: Processes of Software Change", 1985).
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Um zu erklären, warum "fertige" Business-Software laufende Investitionen braucht
+* Entscheidung, wie viel Aufwand in formale Spezifikation vs. Validierung mit Nutzern fließen soll
+* Rahmen für Requirements-Diskussionen — E-Type bedeutet, dass Anforderungen ihrer Natur nach weiter wandern, nicht weil etwas schiefgelaufen ist
+* Argumentation, warum TDD und formale Beweise sauber auf S-Type passen, aber bei E-Type subtiler sind
+* Wartungsbudgets schätzen und gegenüber Stakeholdern rechtfertigen
+* Architektur-Trade-offs: E-Type-Systeme brauchen Änderungsfreundlichkeit vor allem anderen
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<arc42,arc42>> - Dokumentationstemplate, gut geeignet für evolvierende E-Type-Systeme
+* <<cohesion-criteria,Kohäsionskriterien>> - Hohe Kohäsion senkt die Kosten kontinuierlicher Änderungen in E-Type-Systemen
+====
diff --git a/docs/changelog.adoc b/docs/changelog.adoc
@@ -2,6 +2,12 @@
 
 A chronological record of all semantic anchors added to the catalog. Community contributors are credited with thanks.
 
+== 2026-04-15
+
+*New anchors* (proposed by Ralf D. Müller in https://github.com/LLM-Coding/Semantic-Anchors/issues/436[#436]):
+
+* *Lehman's Software Classification* — Meir M. Lehman's S-/P-/E-type taxonomy and Laws of Software Evolution
+
 == 2026-04-12
 
 *New anchors:*
diff --git a/skill/semantic-anchor-translator/references/catalog.md b/skill/semantic-anchor-translator/references/catalog.md
@@ -146,6 +146,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors
 - **Proponents:** Stefan Toth, Stefan Zörner
 - **Core:** Lightweight architecture description framework — describe a system through four lenses: Layers (structural decomposition), Aspects (cross-cutting concerns), Solution Strategy (key technology and design choices), Rationale (documented reasoning behind decisions); pairs naturally with arc42 and ADRs
 
+### Lehman's Software Classification
+- **Also known as:** SPE Classification, Lehman's SPE Taxonomy
+- **Proponents:** Meir M. Lehman
+- **Core:** Three software types by relationship to reality — S-type (formally specifiable, provable), P-type (real problem, only approximable, validate against reality), E-type (embedded in the world, changes the world through use, requirements drift by nature); basis for Lehman's Laws of Software Evolution (Continuing Change, Increasing Complexity, etc.) which explain why E-type systems require ongoing maintenance
+
 ### OWASP Top 10
 - **Also known as:** OWASP Top Ten, Open Worldwide Application Security Project Top 10
 - **Proponents:** OWASP Foundation
diff --git a/website/public/data/anchors.json b/website/public/data/anchors.json
@@ -1977,6 +1977,37 @@
     "filePath": "docs/anchors/lasr.adoc",
     "tier": 3
   },
+  {
+    "id": "lehmans-classification",
+    "title": "Lehman’s Software Classification",
+    "categories": [
+      "software-architecture"
+    ],
+    "roles": [
+      "software-architect",
+      "requirements-engineer",
+      "team-lead",
+      "educator"
+    ],
+    "related": [
+      "arc42",
+      "cohesion-criteria"
+    ],
+    "proponents": [
+      "Meir M. Lehman"
+    ],
+    "tags": [
+      "classification",
+      "software-evolution",
+      "requirements",
+      "maintenance",
+      "s-type",
+      "p-type",
+      "e-type"
+    ],
+    "filePath": "docs/anchors/lehmans-classification.adoc",
+    "tier": 2
+  },
   {
     "id": "linddun",
     "title": "LINDDUN",
diff --git a/website/public/data/categories.json b/website/public/data/categories.json
@@ -159,6 +159,7 @@
       "hexagonal-architecture",
       "iso-25010",
       "lasr",
+      "lehmans-classification",
       "madr",
       "tracer-bullet",
       "vertical-slice-architecture",
diff --git a/website/public/data/metadata.json b/website/public/data/metadata.json
@@ -1,15 +1,15 @@
 {
-  "generatedAt": "2026-04-12T15:16:42.235Z",
+  "generatedAt": "2026-04-15T09:23:51.831Z",
   "version": "1.0.0",
   "counts": {
-    "anchors": 130,
+    "anchors": 131,
     "categories": 14,
-    "roles": 12
+    "roles": 13
   },
   "statistics": {
-    "averageRolesPerAnchor": "3.14",
+    "averageRolesPerAnchor": "3.15",
     "averageCategoriesPerAnchor": "1.01",
-    "anchorsWithTags": 90,
-    "anchorsWithRelated": 61
+    "anchorsWithTags": 91,
+    "anchorsWithRelated": 62
   }
 }
diff --git a/website/public/data/roles.json b/website/public/data/roles.json
@@ -134,6 +134,7 @@
       "heros-journey",
       "kishotenketsu",
       "kiss-principle",
+      "lehmans-classification",
       "mental-model-according-to-naur",
       "myers-briggs-type-indicator",
       "para-method",
@@ -212,6 +213,13 @@
       "testing-pyramid"
     ]
   },
+  {
+    "id": "requirements-engineer",
+    "name": "Requirements Engineer",
+    "anchors": [
+      "lehmans-classification"
+    ]
+  },
   {
     "id": "software-architect",
     "name": "Software Architect",
@@ -262,6 +270,7 @@
       "iso-25010",
       "kiss-principle",
       "lasr",
+      "lehmans-classification",
       "linddun",
       "llm-evaluations",
       "madr",
@@ -414,6 +423,7 @@
       "invest",
       "iso-25010",
       "lasr",
+      "lehmans-classification",
       "madr",
       "mental-model-according-to-naur",
       "mikado-method",
