The 5 best practices for managing requirements changes — and the tools to handle them
Bewährte Methoden
19 min lesen
September 25, 2023

Die 5 besten Praktiken für die Verwaltung von Anforderungsänderungen — und die entsprechenden Tools

Anforderungen sind so konzipiert, dass sie erstellt, festgehalten und ausgeführt werden können. Leider kommt es immer wieder vor, dass man etwas ändern oder sogar von Grund auf neu machen muss. Lassen Sie uns herausfinden, wie Sie durch effizientes Management von Anforderungsänderungen trotzdem erfolgreich sein können.

photo
photo
Martin Koch
Denis Matusovskiy

Was ist Anforderungsmanagement bei Softwaretests?

Um es gleich vorwegzunehmen: Anforderungsmanagement ist der Prozess der Erstellung, Verfolgung und Umsetzung von Produktanforderungen. Sie sind es, die ein Produkt in Form bringen. Man kann den Entwicklern nicht einfach sagen, dass man eine bestimmte Funktion so schnell wie möglich haben möchte. Erstellen Sie eine ordnungsgemäße Anforderung, welche die neue Funktionalität beschreibt und die Akzeptanzkriterien unmissverständlich auflistet — dies ist der einzige Weg…

Das Anforderungsmanagement läuft normalerweise folgendermaßen ab:

  1. Entdeckung: Projektbeteiligte, potenzielle Nutzer und Produktverantwortliche kommen zusammen, um die erforderlichen Funktionen zu besprechen. Marktforschung, Nutzerinterviews und Brainstorming werden eingesetzt, um herauszufinden, was ein neues Produkt tatsächlich bieten muss. Wenn das Produkt durch eine Schlüsselfunktion inspiriert wurde, prüft das Team, was sonst noch dazu entwickelt werden sollte.
  2. Dokumentation: Grundlegende Ideen und Entwürfe werden in Produktanforderungsdokumente (PRDs) umgewandelt. Obwohl die Verwendung einer Dokumentendatei für jede Anforderung möglich ist, bevorzugen die meisten Teams die Verwendung von Tools für das Anforderungsmanagement, um die Zusammenarbeit und die Nachverfolgung zu erleichtern. Hochmoderne Lösungen wie aqua nutzen sogar KI, um Sie bei der Vervollständigung, Organisation und Verbesserung von Anforderungen zu unterstützen
  3. Analyse: Die dokumentierten Anforderungen werden einer ersten Analyse unterzogen, um festzustellen, ob sie tatsächlich vollständig und relevant sind und dem Umfang und dem Zeitplan der ursprünglichen Entwicklung entsprechen. Nicht alles, was ungeeignet ist, muss verworfen werden: Manche Dinge eignen sich hervorragend für den Rückstand, bevor man sie wieder aufgreift.
  4. Validierung: Stakeholder, die nicht an den vorherigen Phasen teilgenommen haben, und potenzielle Endnutzer geben ihren Beitrag zu den ausgewählten Anforderungen ab.
  5. Prioritätensetzung: Die Anforderungen, die die Validierung überstanden haben, werden nun nach Prioritäten geordnet. Je nach Projektentwicklungsmethode, Zeitplan und der Notwendigkeit eines schnellen Markteintritts und/oder einer schnellen Mittelbeschaffung können Sie verschiedene Ansätze wählen. Die meisten Teams setzen ihre Prioritäten darauf, so schnell wie möglich einen funktionsfähigen MVP zu erstellen, aber Sie müssen die Bedeutung der übrigen Anforderungen formalisieren.
  6. Planung: In einem agilen Team müssen Sie lediglich die Stunden oder „Story Points“ für jede Aufgabe schätzen und sie auf die Sprints verteilen. Im Wasserfall ist es etwas schwieriger, da man die gesamte Entwicklung vor der Veröffentlichung sorgfältig planen muss und hoffentlich dahinter zurückfällt.
  7. Ausführung: Nachdem die Anforderungen festgelegt und zugewiesen wurden, ist es an der Zeit, dass die Entwicklung und die Qualitätssicherung sie in die Tat umsetzen. 
  8. Verifizierung: Interne Stakeholder und Teilnehmer der Benutzerakzeptanztests überprüfen, ob die endgültige Ausgabe sowohl den Produktanforderungen als auch den Erwartungen an die Software entspricht

Warum und wie sich Anforderungen während des Lebenszyklus eines Projekts ändern können

Der Grund, warum im vorigen Abschnitt der Prozess des Anforderungsänderungsmanagements nicht erwähnt wurde, ist, dass dies in jeder Phase geschehen kann. Hier sind einige Gründe, warum Sie vielleicht plötzlich eine andere Richtung einschlagen müssen:

  • Nicht realisierbare Anforderungen können unterschiedlich lange dauern, bis sie erkannt werden. Manchmal hat man eine Anforderung, die gut genug war, einfach in den Backlog verschoben, dann wieder geöffnet und sie ist tatsächlich unordentlich. Dann gibt es Zeiten, in denen eine Anforderung nicht mehr durchführbar ist, z. B. wenn eine Änderung der Ressourcen/Kosten/Nachfrage die Ausführung der Anforderung nicht mehr sinnvoll macht.
  • Eine Veränderung in der Unternehmenslandschaft kann dazu führen, dass Sie mit der Arbeit an etwas völlig Neuem beginnen. Many companies probably did not consider adding AI functionality until ChatGPT had taken the world by storm. Die meisten Hersteller von Heimelektronik zeigten kein großes Interesse an Smartphone-Steuerungen, bis Philips sie einführte und Xiaomi anfing, aggressiv die Umsätze von Unternehmen zu schmälern, die sich nicht daran hielten.
  • Negative UAT-Ergebnisse werden wahrscheinlich einige Änderungen an den Anforderungen erzwingen. Einerseits müssen Sie vielleicht eine ausgeführte Anforderung ändern, um sie an die ursprüngliche Vision anzupassen… Andererseits kann es sein, dass Sie neue Anforderungen erstellen müssen, weil der ursprüngliche Anforderungssatz den Benutzern nicht hilft, die Geschäftsziele zu erreichen.

Warum es wichtig ist, Anforderungsänderungen zu verwalten

Hier sind die Gründe, warum das Management von Anforderungsänderungen im Software-Engineering besondere Aufmerksamkeit erfordert, anstatt die Dinge einfach wieder laufen zu lassen.

  • Die Kontinuität kann ohne ein angemessenes Management von Anforderungsänderungen nicht gewahrt werden. Marktveränderungen und/oder allgemeine Prozessverbesserungen erfordern die Durchführung von Retrospektivsitzungen. Wie wurde aus der grundlegenden Support-Chat-Funktionalität ein firmeninterner Kundensupport-Bot? Warum haben wir doppelten Aufwand für scheinbar gleiche Funktionen in verschiedenen Bereichen der Anwendung betrieben? Ohne eine vollständige Anforderungshistorie ist es schwer, diese Fragen zu beantworten und Erkenntnisse zu gewinnen — vor allem, wenn einzelne Spezialisten und ganze Teams wechseln.
  • Die Störungen im Zeitplan werden immer schlimmer. Die Änderung einer Anforderung bedeutet, dass Produktverantwortliche, Entwickler, Designer, Tester und sogar Texter ihre Arbeit unter Umständen unterbrechen und an den Änderungen arbeiten müssen. Jeder entgleiste persönliche Zeitplan bedeutet eine weitere Verzögerung Ihrer Pläne. Die Lösung ist einfach: Man muss anerkennen, dass eine Verzögerung unvermeidlich ist, und die Arbeitspläne aller von einer Änderung der Anforderungen betroffenen Mitarbeiter anpassen. 
  • Sie könnten zu viel verändern. Sowohl bei neuen als auch bei ausgereiften Produkten gibt es in der Regel eine ganze Reihe von „Nice-to-have“-Ideen, für deren Umsetzung niemand die Zeit hatte. Wenn eine Anforderung geändert wird, möchte das Team vielleicht auch einige dieser Anforderungen umsetzen. Prüfen Sie, ob es sinnvoll ist, einige Dinge einzubeziehen, aber lassen Sie ihnen normalerweise keinen Vorrang vor den ursprünglich gewünschten Änderungen.
  • Unberücksichtigter Bedarfswechsel schafft blinde Flecken. Eine gute Projektdokumentation und eine konsistente Softwareentwicklung gehen in der Regel Hand in Hand. Eine Änderung der Anforderungen erschüttert die Konsistenz: Ihr Team hat vielleicht Lust auf eine „schmutzige“ Implementierung, nur um sich wieder seinen Aufgaben widmen zu können. Nach der Beseitigung der Störungen im Zeitplan und der endgültigen Festlegung des Umfangs sollten Sie sicherstellen, dass das Team seine Arbeit einigermaßen gründlich erledigt und für die Zukunft dokumentiert.

Auswirkungen von Anforderungsänderungen auf die QS

Änderungen an den Anforderungen wirken sich auf die gesamte Projektpipeline aus, und dazu gehört auch die Qualitätssicherung. Hier sind die wichtigsten Konsequenzen für Tester: 

  • Die Testsuite hört auf, nicht nur den betroffenen Bereich, sondern die gesamte Anwendung abzudecken. Dies gilt umso mehr, wenn eine umgesetzte Anforderung geändert wird. Während Teams immer Regressionstests durchführen, um zu sehen, ob alte Funktionen nicht mehr funktionieren, haben Sie jetzt eine Mischung aus alt und neu. 
  • Der QS-Zeitplan wird unterbrochen, es sei denn, die Tester waren bereits im Leerlauf. Die Erstellung neuer Tests, die Erstellung von QS-Schätzungen und die Ausführung dieser Tests beeinträchtigen die Zeit, die für andere Aktivitäten vorgesehen ist. Dazu kann es gehören, andere Tests durchzuführen und/oder zu verbessern, und die Vernachlässigung dieser Tests kann die nächste Version ebenfalls verzögern.
  • Es können neue Fehlerquellen in die Software eingeführt werden. Wenn Sie sich nicht bereits in einer guten Position befinden, wirkt sich eine Änderung der Anforderungen in der Regel auf die Kernfunktionalität oder zumindest auf andere Abhängigkeiten aus. Wenn der neue Code keine String-Prüfungen durchläuft, kann er die Software leicht unbrauchbar machen. Dies ist eine größere Belastung als eine reguläre Funktionserweiterung mit konventionell geplanten Anforderungen.

Wenn Sie an einer robusten QS-Struktur interessiert sind, die das Management von Anforderungsänderungen bewältigen kann, haben wir das Richtige für Sie. Unsere Vorlage für eine Teststrategie gibt Ihrem Team ein praktisches Dokument an die Hand, das die gesamte QS-Planung und den Prozess umreißt. Sie können es leicht an Ihre Bedürfnisse anpassen und sogar Punkte hinzufügen, an denen sich die Anforderungen ändern können, damit Ihr Team weiß, wie es die Veränderungen bewältigen kann.

image
3zbdcc601729bfa1d4e33335cfb5176b61c737a68bafd4b4a38a8ef653a7771392
testing strategy template

Vorlage für eine Teststrategie, die jede Anforderungsänderung übersteht

Bewährte Praktiken für den Umgang mit Anforderungsänderungen in der QS

Als Unternehmen mit über 20 Jahren Erfahrung in der QS-Beratung haben wir die folgenden Praktiken für den Umgang mit Anforderungsänderungen gelernt:

  • Äußern Sie Ihre Bedenken in einer Sitzung des Änderungskontrollgremiums. Wenn Sie Bedenken hinsichtlich der Auswirkungen der vorgeschlagenen Änderungen haben, sollten Sie dafür sorgen, dass das Team sie hört. Aktualisierte Anforderungen können in der Tat den Geschäftszielen besser entsprechen, aber manche Dinge sind zu kompliziert, um sie in einem laufenden Produkt schnell zu ändern
  • Formalisieren Sie den neuen Geltungsbereich so bald wie möglich. Sie werden Tests entwickeln, validieren und ausführen müssen. Sie werden eine weitere, möglicherweise gründlichere Runde von Regressionstests durchführen müssen. Es wird möglicherweise neue Grenzfälle geben, die Sie analysieren müssen, bevor Sie sie isolieren und/oder die Zeit aufwenden, um die wichtigsten zu erfassen.
  • Beurteilen Sie die Arbeitsbelastung und passen Sie Ihren Zeitplan an. Auch wenn Techniken wie die Poker-Planung für nur einen Bedarf überflüssig erscheinen mögen, brauchen Sie dennoch eine Schätzung. Stellen Sie sicher, dass Sie einige andere Aktivitäten zurückstellen und Platz für das Testen des Codes schaffen, der als Teil der Anforderungsänderung geliefert wird.
  • Verwenden Sie eine Anforderung-Traceability-Matrix, um die Abdeckung zu verfolgen. Je nach Projektorganisation erstellen Sie eine Unteranforderung oder eine neue Anforderung, in der die erforderlichen Änderungen aufgeführt sind. Sobald Sie sie haben, können Sie Testfälle anhängen, die gleich bleiben. Fügen Sie dann neue Tests hinzu, bis Sie sich einer Abdeckung von nahezu 100 % nähern.
  • Laden Sie den Initiator der Änderung zu einer abschließenden Überprüfung ein. Auch wenn Ihre Tester die geschäftlichen Ziele gut verstehen, kann eine plötzliche Änderung der Anforderungen zu viel sein, um sie zu verstehen. Die Kosten, die entstehen, wenn die Änderungen nicht richtig durchgeführt werden, sind ebenfalls hoch, da einige, wenn nicht alle Betroffenen ihre Zeitpläne erneut ändern müssen. Führen Sie im Wesentlichen eine Mini-UAT-Sitzung mit wichtigen Personen durch, um zu sehen, ob sie die gewünschten Veränderungen erreicht haben.

Wie kann die Übereinstimmung zwischen Anforderungen, Testfällen und Benutzerakzeptanzkriterien sichergestellt werden?

Die Antwort auf diese Frage ist erstaunlich einfach: Sie benötigen eine visualisierte Testabdeckung. Die Auflistung von Anforderungen in Jira, aber die Durchführung von Tests in Form von Excel-Tabellen ist keine gute Methode, um den Überblick über bestehende Funktionen zu behalten, geschweige denn über plötzliche Änderungen. Sie benötigen Integrationen oder ein All-in-One-Tool, mit dem die Beteiligten Änderungen auflisten können, die die Entwickler sehen und die Tester validieren können. 

Ebenso müssen Tester und Entwickler die Ergebnisse des jeweils anderen sehen, um eine schnelle Lösung zu finden. Ihre Entwickler sollten nicht über Reifen springen müssen, um die neuesten Fehlerberichte zu sehen, während die Tester in der Lage sein sollten, Änderungen am Code einfach zu sehen.

Hier ist der ideale Ablauf:

  1. Sie beschließen, eine Anforderung zu ändern
  2. Ihre Testmanagementlösung enthält bereits Testfälle, die diesen Bereich abdecken
  3. Sie nehmen Änderungen an den Anforderungen vor
  4. Tester werden alarmiert, um Testfälle zu aktualisieren (eine Übersicht über die Revisionen ist entscheidend)
  5. Prüfer erstellen bei Bedarf zusätzliche Testfälle
  6. Sowohl aktualisierte als auch neue Tests werden nun auf der aktualisierten Anforderungskarte angezeigt

Werkzeuge und Technologien für die Verwaltung von Anforderungsänderungen

Hier sind einige QS-Optionen für ein erfolgreiches Änderungsmanagement.

 

  • Jira + ein QS-Plugin ist eine beliebte Option, da Jira ein Anforderungsmanagement bietet und Plugins das Fehlen eines Testmanagements ausgleichen. Leider sind diesen Plugins sowohl durch Jira als auch durch die Marktbedingungen Grenzen gesetzt. Die meisten Unternehmen, die spezielle Jira-Plugins für QS entwickeln, konkurrieren eher über den Preis als über die Funktionen.
  • Herkömmliche All-in-One-Lösungen sind die bessere Wahl, aber auch sie bringen Herausforderungen mit sich. Einige Lösungen verfügen nicht über eine Matrix zur Rückverfolgbarkeit von Anforderungen oder über eine geeignete Alternative. Anderen fehlt die Skalierbarkeit des Testmanagements, die für die Bewältigung veränderter Anforderungen von entscheidender Bedeutung ist.

 

Die beste Option wäre hier eine All-in-One-Lösung mit einer starken QS-Suite, aber auch mit modernen Funktionen zur Abwicklung dynamischer Projekte. Diese Lösung lautet aqua, eine Testmanagementlösung mit ALM-Funktionalität, mit der jede Umfangsänderung bewältigt werden kann. Hier sind die Merkmale, die dies verdeutlichen: 

 

  • Anforderungserzählung mit KI für Inspiration und Einheitlichkeit. Sagen Sie die Änderungen in das Mikrofon Ihres Computers, und aqua AI wird die Anforderungen entsprechend aktualisieren. Sie können die Ausgabe weiter optimieren, indem Sie Prompts auswählen oder der KI benutzerdefinierte Anfragen stellen. 
  • Übersicht über die Testabdeckung direkt auf dem Anforderungsbild. Sie können sehen, ob es für eine Anforderung Testfälle oder Testszenarien gibt. Bewegen Sie den Cursor, und aqua zeigt alle relevanten Tests an, die Sie in der Vorschau anzeigen können, während Sie auf der Anforderungsseite bleiben. Die Beziehungen zwischen den Anforderungen, den manuellen und automatisierten Tests und den dabei entdeckten Fehlern werden für Sie kein Geheimnis mehr sein. 

 

Track requirement coverage at a glance

  • Neueste Technologie für KI-gestütztes Anforderungsmanagement und Testen. aqua bietet Testgenerierung mit dem Algorithmus hinter ChatGPT, sodass Sie Tests nach einer Änderung der Anforderungen schnell aktualisieren oder neue Tests von Grund auf erstellen können. Dazu gehören auch Grenzfälle, deren Entdeckung oder Erfassung mit herkömmlichen Tests zu lange dauern würde.

Cover entire requirements with AI

  • Benutzerdefinierte Berichte und Dashboards mit KPI-Warnungen zur Erkennung von Anomalien. Bei der Einführung einer Änderung kritischer Anforderungen ist es wichtig, dass es keine signifikanten negativen Auswirkungen auf bestehende Nutzer gibt. Sie können ein Dashboard erstellen, das Probleme nach Schweregrad für ein einzelnes Release verfolgt. Entscheiden Sie, wie viele Probleme Sie zu bewältigen bereit sind, und seien Sie gewarnt, wenn der neue Build bisher nicht gut genug ist.

Get alerts for QA metrics that matter to you

Sorgen Sie mit aqua AI für eine problemlose Änderung der Anforderungen

Kostenlos testen

Schlussfolgerung

Anforderungsänderungen sind ein sehr störender, aber auch unvermeidlicher Teil der Softwareentwicklung. Unternehmen brauchen solide und strukturierte Bemühungen von Interessenvertretern, Entwicklern und Testern, damit Änderungen am Ende der Software zugute kommen und diese nicht kaputt gehen. Eine reibungslose Verwaltung von Anforderungsänderungen ist ohne eine moderne Lösung, welche die Arbeit der Produktverantwortlichen mit der Entwicklungs- und QS-Arbeit zusammenführt, nicht möglich.

Auf dieser Seite:
Sehen Sie mehr
Beschleunigen Sie Ihre Releases x2 mit aqua
Gratis starten
step
FAQ
Was ist eine Anforderungsänderung?

Eine Änderung der Anforderungen ist entweder eine Änderung einer bestehenden Anforderung oder eine neue Anforderung, die zu einem zuvor vereinbarten Umfang hinzugefügt wird.

Was kann eine Anforderungsänderung verursachen?

Die Hauptgründe für eine Anforderungsänderung sind nicht realisierbare Anforderungen, Veränderungen in der Unternehmenslandschaft und negative Ergebnisse von Benutzerakzeptanztests.

Was passiert, wenn sich die Anforderungen ändern?

Wenn sich die Anforderungen ändern, benötigt jeder im Projekt eine Anpassung. Der Projektleiter passt den Zeitplan an die neuen Änderungen an. Entwickler, Tester, Designer und alle anderen Beteiligten verschieben das, was sie begonnen oder geplant haben, um die Änderungen zu berücksichtigen. Danach wird das Projekt wie gewohnt fortgesetzt.

Wie wirken sich Änderungen der Anforderungen auf den QS-Prozess aus?

Ihre Testsuite muss stark angepasst werden: Die bestehenden Testfälle decken nicht mehr die gesamte Anforderung ab. Regressionstests erfordern weitere Änderungen und zusätzlichen Zeitaufwand. Die geänderten Anforderungen bringen auch den Zeitplan für andere QS-Aktivitäten durcheinander und schaffen zusätzliche Fehlerquellen für die Software. 

closed icon