MVP-001-REQUIREMENT-VERIFICATION-TRACEABILITY-CONTRACT

MVP-001 – Anforderungs-, Verifikations- und Traceability-Vertrag#

Übersicht · 2: zweite Ebene · Ziehen/Klicken: navigieren

Zweck#

Dieser Vertrag definiert die gemeinsame Nachweiskette der führenden solution-architecture. Er konsolidiert keine fachlichen Requirements neu, sondern macht die bereits vorhandenen Requirement-Sets, Architekturverträge, Realisierungsartefakte und Verification-Matrizen einheitlich navigierbar und prüfbar.

Verbindliche Nachweiskette#

Solution Contract oder Architecture Decision
                → Requirement
                → Capability- und Realisierungsbeitrag
                → Verification Contract
                → konkrete Evidence oder sichtbare Evidence-Lücke

Die Kette darf über mehrere Artefakte verlaufen. Jeder Übergang muss jedoch durch eine stabile ID, einen auflösbaren Dokumentverweis oder eine eindeutig bezeichnete Matrixzeile nachvollziehbar sein.

Artefaktrollen#

Artefaktrolle	Verantwortung
Solution Contract und SADR	normative Zusage oder bindende Solution-Entscheidung
Requirement Set	überprüfbare Soll-Aussage mit stabiler ID
Capability-, Komponenten-, Service-, Daten-, Runtime- oder Building-Block-Vertrag	solutionweite Realisierung oder begrenzter Realisierungsbeitrag
Verification Matrix	Prüfverfahren, erwartetes Ergebnis und Requirement-Bezug
	tatsächlich ausgeführter Test, Review, Report, Manifest, Runtime-Nachweis oder begründete indirekte Evidence

Verbindliche Regeln#

Jedes normative Requirement besitzt eine innerhalb seines Requirement-Sets eindeutige ID.
Ein Requirement verweist auf mindestens einen führenden Vertrag, eine Capability-Zusage oder eine Accepted SADR, sofern der Bezug nicht bereits im führenden MVP-Contract eindeutig ist.
Jede Verification-Zeile nennt die geprüften Requirement-IDs ausdrücklich.
Verification-Artefakte definieren Nachweise; sie behaupten keine erfolgreiche Ausführung ohne konkrete Evidence.
directly-verified, indirectly-verified, not-applicable und verification-gap sind die zulässigen Coverage-Status für konkrete Code- oder Evidence-Flächen.
security-critical darf nicht not-applicable sein. Domain- und Application-Logik benötigen direkte Evidence, sobald sie implementiert sind.
Ein Requirement ohne Verification-Einstieg ist eine sichtbare Traceability-Lücke.
Eine Verification ohne Requirement-Bezug ist ein ungebundener Nachweis und damit ebenfalls eine Lücke.
Historische Requirements, Tests oder Reports werden nicht parallel normativ übernommen. Tragfähige Aussagen werden in aktuelle Requirement- oder Verification-Artefakte eingeordnet.
Zukünftige oder noch nicht freigegebene Anforderungen werden nicht als erfüllter MVP-Scope dargestellt.

Granularität#

Ein Requirement beschreibt genau eine überprüfbare Verpflichtung. Kombinierte Prüfungen dürfen mehrere Requirement-IDs abdecken, müssen diese aber einzeln aufführen. Ein Testname oder Dateipfad ersetzt keine fachliche Erwartung.

Evidence-Grenze#

Architektur-Verifikation unterscheidet:

Verification Contract: beschreibt, wie geprüft werden muss;
Evidence: belegt eine tatsächlich ausgeführte Prüfung;
: dokumentiert eine Abweichung oder Lücke;
Acceptance: bestätigt die fachliche End-to-End-Erfüllung des freigegebenen Scopes.

Fehlende Evidence wird nicht durch Formulierungen wie „geprüft“ oder „bestanden“ ersetzt.

Repositoryweiter Einstieg#

Die zentrale Coverage- und Navigationssicht liegt in . Detailanforderungen und Detailmatrizen bleiben in ihren fachlichen Clustern führend.