Requirements Engineering | Knowledge Department
 
Sie befinden sich hier: Blog  

Anforderungen: Grundlagen der Qualität

Qualität ist lateinischen Ursprungs (qualitas, -atis, Eigenschaft, Beschaffenheit) und enthält in seiner ursprünglichen Bedeutung keinerlei Wertung. Das ist hat sich im Laufe der Zeit verändert. Wer heute von „Qualität” spricht, meint implizit „gute Qualität” (denken sie nur an das Gütesiegel „Made in Germany”). Eine Eigenschaft, die jeder von uns auch Software zu- oder abspricht. Was genau sind die Kriterien, mit denen wir uns ein Urteil über die Qualität der Software bilden? Und wie wird „Qualität“ in Software-Produkten überhaupt erreicht?

Schlagen wir in den ISO-Standards nach (genauer ist es die ISO 9000), finden wir dort die folgende Definition: „Qualität ist der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt.”

Wenn sich bei Ihnen bei dieser Definition ein „Wie bitte?“ ins Bewusstsein drängt, dann geht es Ihnen hier ähnlich wie vielen unserer Seminarteilnehmer. Zerlegen wir den Satz daher in überschaubare Einheiten.

Die Definition besagt, dass
1) es mehrere Facetten gibt („Merkmale”),
2) die in einer Software enthalten sind („inhärent”),
3) welche Forderungen gegenübergestellt werden („Anforderungen”)
4) um dann die Qualität dieser Software bewerten zu können („Grad”).

Schon etwas besser. Damit lässt sich doch etwas anfangen.Wagen wir ein kleines Experiment und denken wir uns ein Szenario aus, indem wir etwas an dem Parameter „Anforderung“ “herumspielen”. Wie würde sich das auf die Qualität auswirken?

Sagen wir, in unserem fiktiven Szenario konstruieren wir ein Softwareentwicklungsprojekt, in dem die Anforderungen an die Software unklar bleiben. Die gut gemeinten Vorgaben des Kunden laufen in Richtung „Machen Sie mir das Beste daraus” – ab dann werden die Entwickler auf sich alleine gestellt. Scheinbar ist doch klar, was mit „das Beste“ gemeint ist: technische Kniffeleien professionell lösen. Das Beste für Entwickler ist eine hoch-performante, effiziente Software! Die Entwicklung ist sich einig. Guten Gewissens werden Aufwände gebucht, in denen Bit um Bit geschubst wird. Kryptische Ausdrücke, wildeste Zeigerarithmetik: Algorithmen in Assembler, die jede Millisekunde aus dem System holen. – Und trotzdem: die Abnahme wird zur einzigen Katastrophe! „Verschwendung von Ressourcen”, „reines Gold-Plating” und „Suboptimizing“ ruft der Kunde. Es stellt sich heraus, dass „das Beste“ für den Kunden nichts mit „dem Besten“ für die Entwickler zu tun hatte. Langlebig sollte die Software sein, Änderungsauswirkungen leicht zu bewerten, auf eine sich ändernde Umgebung anpassbar: „Performanz“ bedeutet ihm nichts. Der Kunde hatte gänzlich andere Anforderungen an die Software.

In unserem Experiment scheint jeder „Qualität“ für etwas anderes zu halten. Und wie lässt sich ein gemeinsames Verständnis für „Qualität“ erreichen?

Durch hochwertige Anforderungen. Wer prinzipiell eine „beste” Qualität fordert, hat es nicht verstanden. Qualität liegt immer in einem „richtigen” Maß vor. Hier muss sich der Kunde festlegen, ob es ihm um Änderbarkeit oder Zuverlässigkeit, Interoperabilität, Benutzbarkeit oder – wie in unserem Experiment – um Wartbarkeit geht. Qualität ist eine Entscheidung, die in Form von Anforderungen für die Projektbeteiligten transparent, im Sinne von „sichtbar machen“, wird. Das Requirements Engineering analysiert Anforderungen an die Software, dokumentiert diese nach bestimmten Kriterien („spezifizieren”) und unterstützt den Kunden nicht nur das zu bekommen, was er will, sondern auch das, was er tatsächlich braucht. Anforderungen sind die Grundlage der Qualität. Von Qualität zu sprechen ohne die Anforderungen zu kennen ist undenkbar.

Welche Methoden und Techniken kann der Requirements Engineer hierfür einsetzen? Wie steuert man als Requirements Engineering die Erhebung, Analyse, Spezifikation und Qualitätssicherung der Anforderungen über die gesamte Entwicklungs- und Wartungszeit? Wie lassen sich Reifegradmodelle für ein Prozessassessment bzw. -optimizing des Requirements Engineerings-Prozess nutzen? Welche Möglichkeiten gibt es vorzugehen – und wie läuft das bei „agilen“ Projekten? Wie schätzt man Aufwände im Requirements Engineering?

Diese Themen sind Teil unserer neuen REQB Certified Professional for Requirements Engineering Advanced Level-Trainings. Die Wichtigkeit des Requirements Engineerings für Projekterfolg war unser Ansporn, einen weitergehenden Kurs mit optionaler, international anerkannter Zertifizierung, in unser Angebot aufzunehmen und das notwendige Material, passend zum Lehrplan, zu entwickeln und akkreditieren zu lassen!

Tags: , , ,

Hinterlassen Sie eine Antwort