Anforderungen sind schnell gesammelt – aber selten durchdacht. Was wirklich fehlt? Ein gemeinsames Verständnis vom Problem. Warum Problem Engineering kein Trend, sondern die Grundlage für gute Produkte ist – und wie du mit zwei einfachen Templates sofort bessere Diskussionen führst.
In unserer Arbeit mit Produktteams, System Engineers und Requirements Engineers begegnet uns eine Frage immer wieder – und sie ist fast schon ein Reflex:
„Was sind euere Anforderungen an das System?“
Die Intention ist gut. Die Wirkung oft fatal. Denn: Die Mehrzahl aller Projekte scheitert nicht an der Technik – nicht an Java-Versionen, Container-Setups oder Testabdeckung. Sie scheitert daran, dass Anforderungen geschrieben werden, bevor überhaupt klar ist, was wirklich gebraucht wird.
Willkommen im Requirements Engineering, wie wir es nicht mehr brauchen.
In unserer Artikel-Serie zu den Qualitätskriterien von Anforderungen sind wir mit diesem Artikel bereits beim vierten und letzten Artikel angekommen.
Im ersten Artikel haben Sie erfahren, wozu Qualitätskriterien eingesetzt werden.
Kurze Wiederholung: Zur Verbesserung des Verständnisses über Systemeigenschaften, Systemfunktionen und -verhalten aller Stakeholder, welche über Anforderungen kommuniziert werden.
Im zweiten Artikel haben wir Ihnen gezeigt, dass Qualitätskriterien für die Einschätzung und Bewertung von Anforderungen wichtig sind. Es geht also um die Qualität von Anforderungen.
Und im dritten Artikel haben Sie gelernt, wie Sie die Qualitätskriterien für die Bewertung von Anforderungen einsetzen und welche Regeln Sie zur Verbesserung der Anforderungen ableiten können.
Im heutigen und damit letztem Artikel dieser Blogserie lernen Sie ein Vorgehen kennen, um entsprechend der gewünschten Qualitätsziele der Anforderungen die entsprechenden Qualitätskriterien auszuwählen und dazu messbare Subkriterien und Regeln abzuleiten.
Qualitätsziele definieren
Falls Sie schon mal nach Qualitätskriterien gegoogelt oder verschiedene Quellen konsultiert haben, waren Sie sicher überrascht, wie sich die Qualitätskriterien in den unterschiedlichen Quellen unterscheiden.
Ein pragmatischer Ansatz ist es, die ausgewählten Qualitätskriterien nach den Qualitätszielen auszurichten, die Ihre Anforderungen erfüllen sollen. Sie werden gleich feststellen, dass sich die Qualitätsziele teilweise mit den Namen der Qualitätskriterien decken, doch vielmehr geht es um die Denkweise und um einen pragmatischen Ansatz, der dahintersteht.
Was macht also die Qualität einer Anforderung aus?
Willkommen zurück bei unserer kleinen Artikel-Serie zum Thema Qualitätskriterien.
Dies hier ist der dritte Artikel.
Wir möchten Ihnen hier aufzeigen, wie Sie aus Qualitätskriterien Regeln ableiten können, um die Anforderungen qualitativ zu verbessern und um die definierten Qualitätskriterien zu erfüllen.
Hierzu werfen wir nochmal einen Blick auf den zweiten Artikel der Serie “Kriterien für die Qualität von Anforderungen” und verwenden das gleiche Beispiel.
Der Mann bringt 6 Brote mit. Die Frau wollte jedoch ein Brot und 6 Eier. Im letzten Blogbeitrag haben wir anhand von Qualitätskriterien gezeigt, dass die Frau sich missverständlich ausgedrückt hat oder in RE-Sprech: Die Frau hat missverständliche Anforderungen gestellt.
Die ersten zwei Sätze der Frau spielen hierbei die entscheidende Rolle:
WeiterlesenBevor wir hier in die Vollen gehen, ist es sinnvoll, unsere beiden bereits erschienen Artikel zu Assessments zu lesen. Im ersten Artikel “Assessments machen wir bei SOPHIST schon seit Jahren…” haben wir aufgezeigt, wie eine Beurteilung der Prozesse und Methoden durch SOPHIST aussehen kann. Und im zweiten Artikel “A… wie Assessments mit SOPHIST” haben wir beispielhaft beschrieben, wie wir Probleme im Requirements and Systems Engineering in einem Assessment erkennen und Vorschläge einbringen, um die erkannten Probleme zu lösen.
So, und jetzt kommt ein kurzer werblicher Teil .-)
SOPHIST bietet auch vorbereitende Assessments (nachfolgend Vor-Assessments genannt) im Bereich Requirements and Systems Engineering für verschiedene Assessments wie beispielsweise A-Spice an.
In diesem Artikel stellen wir Ihnen den Ablauf eines Vor-Assessments mit SOPHIST-Unterstützung vor. Sie bekommen einen Einblick, wie die Zusammenarbeit mit SOPHIST abläuft und welche Schritte nötig sind, um auf ein Assessment vorbereitet zu sein.
Die Vorbereitung = der erste Schritt im Prozess von Vor-Assessments.
Hier werden die Ziele (z.B. die Zertifizierung des A-Spice Level 2) und der Umfang des Vor-Assessments definiert. Die Ziele müssen klar und konkret sein, um eine effektive Bewertung zu ermöglichen. Es könnte beispielsweise ein Ziel sein, nur einen begrenzten Umfang der Anforderungen (Requirements) zu beurteilen, um eine Aussage über die Qualität eben dieser zu bekommen.
Ein anderes Ziel könnte sein, den ganzen Systems Engineering Prozess zu beurteilen.
Es ist auch wichtig, den Umfang des Vor-Assessments zu definieren, um sicherzustellen, dass alle relevanten Inhalte einbezogen werden. Hierbei ist der Umfang begrenzt auf Themen im Requirements and Systems Engineering. Jedoch können in Abhängigkeit der gesetzten Ziele ein unterschiedlicher Umfang im Hinblick auf die betrachteten Anforderungen und betrachteter Architektur, aber auch betrachteter Prozesse, Methoden und Artefakten wie Gesetze, Anleitungen, Handlungsanweisungen etc. gewählt werden.
Nachdem Ziele und Umfang gesetzt wurden, ist der nächste Schritt in der Vorbereitung (der Durchführung des Vor-Assessments mit SOPHIST) eine Selbstbeurteilung durch das Kundenunternehmen. Diese Beurteilung beruht auf dem identischen Fragenkatalog und Bewertungsmechanismus, welche auch im Vor-Assessment verwendet werden. Und diese werden dann auch auf den für das Vor-Assessment gewählten Umfang angewandt. Dadurch erlangt das Kundenunternehmen eine statistikbasierte Eigenwahrnehmung über die Qualität ihrer gewählten Inhalte und zudem ein Gefühl für die Fragen, die im Vor-Assessment gestellt werden.
Schließlich ist es wichtig, organisatorische Aspekte zu klären.
Einerseits, um den Zugriff auf Werkzeuge vorzubereiten, den die SOPHIST-Assessoren benötigen, um Prozesse und Methoden einzusehen. Und andererseits werden damit auch gleich die Termine für das Assessment geklärt.
