Anforderungsprofil aus Anwendersicht
Grundlage für das Kriterienraster in Kapitel 2 und die Anforderungen in Kapitel 4.1. Stand: 2026-09-04.
Methodischer Zweck. Die Betreuervorgabe vom 2026-08-03 verlangt, die Kriterien vor der Systemprüfung festzulegen. Werden sie aus der eigenen Architektur abgeleitet, ist der spätere Ausschluss der Marktsysteme tautologisch. Deshalb steht am Anfang ein lösungsneutrales Profil aus der Sicht der Handelnden: es benennt, was jemand erreichen will, nicht wie ein System es löst. Erst daraus folgen die technischen Anforderungen, daraus die Vergleichsachsen. Jeder Schritt ist einzeln begründbar.
Rollen
Drei handelnde Rollen und eine passive Randrolle:
| Rolle | Beschreibung |
|---|---|
| Markenverantwortlicher | verantwortet beim Franchisegeber das einheitliche Erscheinungsbild aller Standorte |
| Standortbetreiber | betreibt eine Filiale beziehungsweise ist Franchisenehmer, pflegt die lokalen Angaben |
| Plattformbetreiber | betreibt das System, auf dem alle Standortseiten laufen |
| Besucher | ruft eine Standortseite auf (Randbedingungen, keine Vergleichsachse) |
Forderungen
Markenverantwortlicher
| Nr. | Forderung |
|---|---|
| N1 | Ich ändere das Erscheinungsbild an einer Stelle, und es gilt für alle Standorte. Danach muss ich nichts verteilen, freigeben oder nachziehen. |
| N2 | Ich lege fest, was ein Standort an seiner Seite ändern darf. Diese Festlegung treffe ich einmal, und sie gilt für alle Standorte gleich. |
| N3 | Ich kann mich darauf verlassen, dass kein Standort das Markenbild verletzt, auch nicht aus Versehen. |
| N4a | Ich gebe zentrale Inhalte vor (Kampagnen, rechtliche Texte), die auf allen Standortseiten erscheinen, ohne dass ein Standort sie pflegen muss. |
| N4b | Ich begrenze solche Vorgaben auf eine Teilmenge der Standorte (Region, Land), ohne sie einzeln zu pflegen. |
Standortbetreiber
| Nr. | Forderung |
|---|---|
| N5 | Ich pflege meine eigenen Angaben (Öffnungszeiten, Ansprechpartner, Angebote) selbst, ohne jemanden zu beauftragen und ohne technische Kenntnisse. |
| N6 | Ich kann dabei nichts kaputt machen: Was ich nicht ändern darf, ist gar nicht erst bedienbar. |
| N7 | Ich pflege nur das, was bei mir anders ist. Alles Übrige kommt von der Zentrale und bleibt von allein aktuell. |
| N8 | Ich kann einzelne Abschnitte ausblenden, die auf meinen Standort nicht zutreffen. |
| N9 | Meine Seite hat eine eigene Adresse und ist meine Seite, keine Unterseite der Zentrale. |
Plattformbetreiber
| Nr. | Forderung |
|---|---|
| N10 | Ein zusätzlicher Standort verursacht keinen zusätzlichen laufenden Pflegeaufwand. |
| N11 | Standorte sehen und verändern gegenseitig nichts. |
| N12 | Ein vorhandener Gestaltungsbaustein lässt sich an neuen Stellen einsetzen, ohne zu programmieren. |
Besucher (Randbedingungen)
| Nr. | Forderung |
|---|---|
| N13 | Die Seite antwortet schnell genug, dass ich sie nicht verlasse. |
| N14 | Ich sehe einen in sich stimmigen Markenauftritt, unabhängig davon, welchen Standort ich aufrufe und wann. |
Bewusst keine Vergleichsachse. Antwortzeiten sind dokumentationsbasiert nicht prüfbar, eigene Messungen sind im Umfang nicht vorgesehen, und die Zwischenspeicherung ist im eigenen Entwurf offen (siehe unten). N13 und N14 begründen stattdessen zwei Textstellen: N14 liefert die eigentliche Begründung für N1, weil ein Verteilvorgang über viele Standorte einen Zeitraum erzeugt, in dem Besucher unterschiedlicher Standorte unterschiedliche Markenstände sehen. N13 begründet die Zwischenspeicherung als Entwurfsfrage in Kapitel 4.9.
Trennschärfe
Nicht jede Forderung unterscheidet die Systeme. Die Unterscheidung selbst ist ein Argument im Text, weil sonst die Erfüllung von Selbstverständlichkeiten als Verdienst des eigenen Entwurfs erscheint.
- Hygieneforderungen (alle betrachteten Systeme erfüllen sie): N5, N9, N11
- Trennscharf: N1, N2, N4b, N6, N7, N10
- Teilweise trennscharf: N3, N8, N12
- Randbedingung, nicht im Vergleich: N13, N14
Übersetzung auf die technischen Anforderungen
| Anwenderforderung | technische Anforderung |
|---|---|
| N1, N7, N14 | A3 kein abgeleitetes Artefakt je Standort; A4 spärliches Overlay |
| N2, N3, N6 | A5 Abweichungsfreigabe als Eigenschaft des Bausteintyps, feldweise, standardmäßig verboten |
| N4a | A4 (Kettenebene als Basis, die ohne lokales Zutun wirkt) |
| N4b | derzeit nicht erfüllt, siehe Ist-Stand |
| N5, N8 | A7 Redaktion durch Endnutzer; Sichtbarkeit immer schaltbar |
| N9, N11 | A6 Domainzuordnung und durchgehendes Scoping |
| N10 | A1, A3 und A4 zusammen |
| N12 | A2 Zuordnung als Konfiguration statt Programmcode |
Technische Anforderungen (Fassung für Kapitel 4.1)
| Nr. | Anforderung |
|---|---|
| A1 | Die Designquelle ist ein systemweiter Katalog typisierter Bausteine, jeder mit verbindlichem Feldschema. |
| A2 | Die Zuordnung eines Bausteintyps zu einer Seitenposition ist Konfiguration, nicht Programmcode. |
| A3 | Je Standort entsteht kein abgeleitetes Artefakt; die Standortseite wird erst bei der Anfrage aufgelöst. |
| A4 | Standortinhalte liegen als spärliches Overlay über der Kettenebene, nicht als Vollkopie. |
| A5 | Die Abweichungsfreigabe ist Eigenschaft des Bausteintyps, wirkt feldweise und ist standardmäßig verboten. |
| A6 | Die Mandantentrennung erfolgt über Domainzuordnung und durchgehendes Scoping in geteilter Datenhaltung. |
| A7 | Die lokale Pflege erfolgt durch Endnutzer ohne Entwicklerbeteiligung, in denselben Grenzen. |
Die Anforderung des Themenvorschlags zum Betriebsverhalten (hinreichende Antwortzeiten, Zwischenspeicherung) ist nicht Teil dieser Liste und nicht Teil des Vergleichsrasters. Sie wird als Entwurfsfrage und offener Zielkonflikt in Kapitel 4.9 behandelt. Grund: Im Modul existiert keine Zwischenspeicherung über die Anfrage hinaus, und ein Vergleich an einer Anforderung, die der eigene Entwurf nicht erfüllt, wäre nicht belastbar.
Ist-Stand im Modul (Belege)
Die folgenden Befunde stammen aus dem Quellcode der Alexium-Plattform und begründen, dass die Anforderungen A1 bis A7 nah an der tatsächlichen Umsetzung formuliert sind. Sie belegen zugleich die Grenzen.
| Befund | Fundstelle |
|---|---|
| Bausteintyp ist systemweit, kein Projektfilter; enthält Markup, Feldschema und Handlerdeklaration | Renderer/PageRenderer.class.php, loadTemplate(), ADR-073 |
| Bindung Position zu Typ je Projekt, Varianten mit Elternverweis | Renderer/PageRenderer.class.php, getTemplateBinding() |
Zwei Inhaltsebenen global und unit, Zusammenführung zur Renderzeit über die Bausteinkennung | Renderer/PageRenderer.class.php, renderSlot() und mergeUnitOverride() |
| Abweichungsfreigabe steht im Feldschema des Typs; fehlendes Kennzeichen gilt als gesperrt | Renderer/PageRenderer.class.php, mergeUnitOverride() |
| Sichtbarkeit darf der Standort immer schalten, Menge und Reihenfolge nicht | ebenda |
| Rohes Markup ist niemals lokal überschreibbar (Schutz vor Skripteinschleusung) | Service/PageEditor/PageEditorStoreService.class.php |
| Keine Zwischenspeicherung über die Anfrage hinaus; nur anfragelokale Zwischenspeicher für Typen und Bindungen | Renderer/PageRenderer.class.php |
Bekannte Grenzen des eigenen Entwurfs
- Vererbung ist zweistufig. Die Ebenen sind Kette und Standort. Das Scope-Feld kennt zwar zusätzlich einen Systemwert, der Renderer wertet ihn aber nicht aus, und einen Regionsbegriff gibt es nicht. N4b ist damit nicht erfüllt. Adobe Experience Manager staffelt Vererbungshierarchien mehrstufig und ist an dieser Stelle nachweislich stärker. Die Ebenenzahl ist eine Eigenschaft der Scopekette, nicht des Ansatzes; die Erweiterung gehört deshalb in den Ausblick (Kapitel 9) und darf die Lückenaussage in Kapitel 2.6 nicht tragen.
- Keine Zwischenspeicherung. Siehe oben; Entwurfsfrage in Kapitel 4.9.
Diese Grenzen werden im Vergleich offen ausgewiesen. Eine Vergleichstabelle, in der der eigene Entwurf jede Zeile für sich entscheidet, entwertet die übrigen Zeilen.
Zusammenhänge
- Kriterienraster: kriterienraster
- Systeme und Positionierung: verwandte-arbeiten
- Gliederung: outline
- Exposé: exposé
- Betreuervorgaben: anschreiben-prof-schneider