home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Probleme bei der Anforderungsanalyse

Bei der Anforderungsanalyse  gibt es verschiedene Probleme, welche dazu führen dass die Anforderungs meist nicht richtig erhoben werden.

Zu diesen Problemen gehören:

  • Kommunikation innerhalb der Firma funktioniert nicht richtig.
  • Zu wenig oder falsche Kommunikation mit dem Kunden.
  • Es wird nichts dokumentiert.
  • Unkenntnis der Kunden-/Nutzunganforderungen: falsche Annahmen, unvollständige Anforderungen
  • Mangelnde Verikation und Validierung (Verifikation: Wurden die Vorgaben richtig erfüllt. Validierung: Wird der beabsichtige Nutzung damit erreicht.)

Das "Wer-vor-Was-vor-Wie-Prinzip"

Um diese Probleme zu lösen, gibt es das "Wer-vor-was-vor-wie"-Prinzip.

  • Wer?

    • Wer sind die Stakeholder der Software?
    • Wer ist mein Gegenüber?
    • Benutzer, Administratoren, Investoren, Auftraggeber/Kunde, Weitere Betroffene (Entlassene Person), Entwicklungsteam (Programmierer, Architekt, Tester,...)
    • Was sind die Interessen, Ängste und Erwartungen der Stakeholder?

  • Was?

    • Was will ich von meinem Gegenüber? Was will mein Gegenüber von mir?
    • Z.Bsp.: ein zu realisierendes Projekt.

  • Wie?

    • Wie erreiche ich mein Ziel?
    • Hilfsmittel, andere Personen, Projektmanagement.

Hinweis: Als Software-Entwickler tendiert man meist dazu, mit dem "Wie?" zu beginnen.

Das Modell von Kano

Das Modell von Kano (auch Kano-Modell genannt) analysiert die Kundenwünsche. Es ermöglicht die Wünsche (Erwartungen) von Kunden zu erfassen und bei der Produktentwicklung zu berücksichtigen.

Bei dem Kano-Modell gibt es verschiedene Ebenen der Qualität:

  1. Basis-Merkmale, die so grundlegend und selbstverständlich sind, dass sie den Kunden erst bei Nichterfüllung bewusst werden (implizite Erwartungen). Werden die Grundforderungen nicht erfüllt, entsteht Unzufriedenheit, werden sie erfüllt, entsteht aber keine Zufriedenheit! Die Nutzensteigerung im Vergleich zur Differenzierung am Wettbewerber ist sehr gering. Am Beispiel Auto: Sicherheit, Rostschutz.
  2. Leistungs-Merkmale sind dem Kunden bewusst, sie beseitigen Unzufriedenheit oder schaffen Zufriedenheit abhängig vom Ausmaß der Erfüllung.
          Am Beispiel Auto: Fahreigenschaften, Beschleunigung, Lebensdauer.
  3. Begeisterungs-Merkmale sind dagegen Nutzen stiftende Merkmale, mit denen der Kunde nicht unbedingt rechnet. Sie zeichnen das Produkt gegenüber der Konkurrenz aus und rufen Begeisterung hervor. Eine kleine Leistungssteigerung kann zu einer überproportionalen Nutzenstiftung führen. Die Differenzierungen gegenüber der Konkurrenz können gering sein, die Nutzenstiftung aber enorm.
          Am Beispiel Auto: Sonderausstattung, besonderes Design.
  4. Unerhebliche Merkmale sind sowohl bei Vorhandensein wie auch bei Fehlen ohne Belang für den Kunden. Sie können daher keine Zufriedenheit stiften, führen aber auch zu keiner Unzufriedenheit.
    Am Beispiel Auto könnte dies für eine bestimmte Kundengruppe sein: Automatik-Getriebe
  5. Rückweisungs-Merkmale Führen bei Vorhandensein zu Unzufriedenheit; bei Fehlen jedoch nicht zu Zufriedenheit.
    Am Beispiel Auto könnte dies für eine bestimmte Kundengruppe eine gewisse Marke, ein Design, Bauart, Treibstoff, etc. sein. 

Quelle: http://de.wikipedia.org/wiki/Kano-Modell

Anforderungen erheben mit der Kontextanalyse

Mit Hilfe der Kontextanalyse ist man in der Lage die Anforderungen eines Kunden zu erheben. Wichtig dabei ist der Fokus auf die Aufgaben der Personen. Nach den Wünschen des Kunden wird zunächst nicht gefragt.

1: Kontextinterview

  • 5 Repräsentative Benutzer pro Rolle. (Bereits mit 5 Benutzern pro Gruppe, werden 80% aller Nutzungsanforderungen erfasst)
  • Verwendung der Methode Personas. Aus einer Nutzergruppe nimmt man sich repräsentative Mitglieder heraus und sammelt Informationen über sie.
  • Beschreibung der Fakten.
  • nicht nach Wünschen fragen, sondern nach Aufgaben.

    Beispiel: Navigationsgerät (Kundengruppe, Vertreter)

Herr Maier ist Vertreter, Verkauft Schweißtechnik, fährt 60.000 km im Jahr, Einkommen ist abhängig von den Vertragsabschlüssen, trifft meist den Einkäufer direkt beim Kunden, Oft Leerlauf (auf Kunden warten, man ist zu früh beim Kunden, ist beim Kunden früher fertig)...

2: Erfordernisse ableiten

Definition Erfordernis (englisch: implied need):
Eine notwendige Voraussetzung die es ermöglicht den, in einem Sachverhalt des Nutzungskontext enthaltenen Zweck effizient zu erfüllen.

Erfordernis := Voraussetzung + Zweck
   
Formulierungsrichtlinie:

Der <Rollenbezeichnung> muss <tun, sehen, wissen, verfügbar haben, vorbereitet haben> um <Zweck> zu erreichen/erfüllen

Qualitätskriterien für Erfordernisse:

  • Das Erfordernis lässt sich direkt aus dem Kontext ableiten.
  • Es enthält eine Voraussetzung und einen Zweck.
  • Es enthält keine Lösung.
  • Es trifft auch die Mehrzahl der Benutzer zu.

Beispiel aus der Vorlesung:

Der Vertreter muss pünktlich beim Kunden sein, um möglichst viele Abschlüsse zu erzielen.

Der Vertreter muss möglichst viele Kunden besuchen, um möglichst viele Abschlüsse zu erzielen.

3: Nutzunganforderungen erheben

Nutzungsanforderungen basieren immer auf den Erfordernissen.


Definition: Nutzungsanforderung (Usability requirement)
Eine erforderliche Benutzeraktion an einem Interaktiven System, in einer die Tätigkeit beschreibenden Weise - nicht in technisch realisierter Weise.

Anmerkung: Nutzungsanforderungen beruhen auf Erfordernissen des Nutzungskontexts. Dadurch werden sie erst valide!

Mögliche Interaktionen eines Benutzers mit einem System: eingeben/auswählen

Mögliche Interaktionen eines Systems mit einem Benutzers: anzeigen/ausgeben

Kognitive Leistung: sehen, erkennen, verstehen

Formulierungsrichtlinie:
Der Nutzer, muss am System <Handlung/kognitive Leistung> können, um <Zweck> zu erreichen.

Beispiel: Der Nutzer muss am System sehen könne, wann der nächste Termin geplant ist, um pünktlich anwesend zu sein.

4:  Nutzungsszenarien beschreiben

Hierbei wird die Reihenfolge der Schritte spezifiziert mit denen der Benutzer mit dem System interagiert. Man betrachtet die Kernaufgaben die ein Benutzer erledigen muss (erhoben durch die Kontextinterviews), und teilt diese in Teilaufgaben.

Es handelt sich hierbei um Aktions- (des Benutzers) und Reaktionspaare (des Systems). Diese werden übrigens häufig als Use-Cases beschrieben.

Hinweis: Nach diesem Schritt hat man die Problemdomäne verlassen, und tritt in die Lösungsdomäne ein.