Recent Posts

Kontakt

Rufen Sie uns an
+49 89 4161524-10
Schreiben Sie uns
kontakt@visioneleven.com
Wir beantworten
Ihre Fragen
Frage stellen
Generic selectors
Exact matches only
Search in title
Search in content

Anforderungsanalyse

Geht es um die Anforderungsanalyse, denken viele in erster Linie an die Aufgaben der Business Analysten. Im Austausch mit den Key Usern identifizieren, analysieren und priorisieren sie die Requirements an Prozesse und IT-Systeme.

Doch die Analyse der Anforderungen hat noch eine weitere Dimension. Dass das Requirement Engineering dabei strikt vom Testing getrennt werden muss, wird jedoch häufig falsch verstanden. Denn Anforderungsmanagement und Testing sind zwei Seiten derselben Medaille. Und Testanalysten können in dieser Phase maßgeblich dazu beitragen, potenzielle Fehler – und die entsprechenden Kosten – frühzeitig zu vermeiden.

 

So können sich bereits während der Erstellung der Anforderungen – z. B. in Form von User Stories – weitreichende Fehlerquellen einschleichen. Oft werden hier etwa Begrifflichkeiten verwendet, die im ersten Moment hinreichend klar erscheinen. Sobald es jedoch um die Testbarkeit geht, wird deutlich, dass sie eben nicht exakt genug definiert wurden. (Beispiel: siehe unten)

 

Testanalysten sind dank ihrer Expertise in der Lage, diese Art von Fehlern frühzeitig zu erkennen und bereits während der Anforderungsanalyse zu beheben. Der entscheidende Vorteil dieser Vorgehensweise: Sie ist äußerst kostengünstig. Denn wenn ein Fehler erst im Testsystem auffällt, müssen sämtliche vorhergehenden Phasen noch einmal durchlaufen werden.

 

Das bedeutet: Der Fehler wird in Defect Calls besprochen, von den Business Analysten im Nachgang analysiert, Anpassung werden vorgenommen und an den Entwickler weitergegeben. Nach der erneuten Entwicklungsarbeit wird der Fix dann mit einer neuen Version auf das Testsystem aufgespielt, um schließlich vom Testanalysten bestätigt zu werden …

Die folgende Grafik zeigt, wie extrem die Kosten für die Behebung von Fehlern steigen, je später sie identifiziert werden – bzw. wie hoch das Einsparpotenzial durch frühzeitige Fehlererkennung ist.

Anforderungsanalyse: Kosten eines Softwarefehlers

Praxisbeispiel:

User Stories durch die Brillen von Business- und Testanalysten

Wie aber unterscheidet sich die Sichtweise eines Testanalysten von der eines Business Analysten? Aufschluss gibt hier ein Beispiel aus unserer Praxiserfahrung. Dabei handelt es sich um eine Anforderung eines Kunden, der ein neues CRM-System einführen möchte, um seinen Sales-Prozess zu optimieren.

Der elementare Unterschied zwischen den Sichtweisen: Business Analysten betrachten eine User Story im Gesamten. Ihr Fokus liegt dabei auf dem Ziel und den Weg dorthin. Testanalysten betrachten die User Story aus der Perspektive der Qualitätssicherung. Auf der Suche nach potenziellen Fehlerquellen betrachten sie jedes Detail.

 

Business Analyst:

Als User möchte ich eine Datei an meinen Kunden anhängen, um alle Informationen an einem Ort zu sammeln.

Testanalyst:

Als User möchte ich eine Datei an meinen Kunden anhängen, um alle Informationen an einem Ort zu sammeln.

Welcher User genau soll das im System machen? Hier wurden die Rollen und Rechte nicht berücksichtigt.

Um welche Dateitypen handelt es sich? Würde die User Story ohne Spezifikationen (z.B. Word- oder Excel-Dateien) umgesetzt, könnte es zu Fehlern kommen, die eine nachträgliche Anpassung erfordern.

Auch hier wurde der „Kunde“ nicht näher spezifiziert. Muss ggf. zwischen Anwendern im B2B- oder B2C-Bereich unterschieden werden? Gibt es weitere relevante  Anwender? Die mangelnde Differenzierung könnte zu vermeidbaren Fehlern führen.

Bereinigte User Story:

Als Salesmanager möchte ich eine Excel-File an meinen B2C-Kunden anhängen, um alle Informationen an einem Ort zu sammeln.

Schluss mit unnötigen Entwicklungsrunden!

Unser Beispiel zeigt:

Schon beim Definieren einer Anforderung können Fehlerquellen mit schwerwiegenden Folgen entstehen.

Durch den frühzeitigen Einsatz unserer Testanalysten lassen sich diese Stolpersteine bereits im Vorfeld identifizieren

und kostengünstig beseitigen. Kunden ersparen sich auf diese Weise unnötige Entwicklungsrunden

– und können von Anfang an mit einer fehlerfreien Software arbeiten.

Unsere Referenzen

Ihr Ansprechpartner

Daniel Loderer

Daniel Loderer

+49 151 6294 5816

Insights aus dem Blog

Software-Qualitätssicherung: Mehr als nur Testen

Oftmals wird im Softwarebereich das Software Testing als Pendant zur Qualitätssicherung gesehen. Dabei ist Software-Qualitätssicherung weit mehr als stumpfes Testen. Sie startet bereits vor Beginn des Projektes und erstreckt sich bis über den Abschluss hinaus. Integrieren Unternehmen Testing-Teams frühzeitig in ihre Projekte, können sie erhebliche Kosten im weiteren Prozess vermeiden.

Projektmanagement: Ist das klassische Wasserfallmodell tot?

Spätestens seit der Einführung des agilen Manifests in 2001 ist agiles Projektmanagement in aller Munde. Heute werden die entsprechenden Frameworks branchenübergreifend eingesetzt, nicht nur im Bereich der Softwareentwicklung. Hat Agilität das klassische Wasserfallmodell also abgelöst? Und welche Effekte ergeben sich dadurch für die Qualitätssicherung einer Software und das Testmanagement?

Digitales Qualitätsmanagement: Beispiel Connected Car

Auch wenn sich viele externe Faktoren nicht steuern lassen: Professionelles digitales Qualitätsmanagement bietet dem Kunden ein intuitives Gefühl von Sicherheit – vor allem bei innovativen Entwicklungen, die sich erst langsam in der breiten Masse etablieren.