Warum muss vor der Softwareentwicklung bekannt sein, was entwickelt werden soll? (S.6)
Damit die Entwicklung zielgerichtet erfolgen kann und Missverständnisse vermieden werden.
Was passiert in der Analysephase eines Softwareprojekts? (S.11)
Es werden die Anforderungen ermittelt, die in der Software realisiert werden sollen.
Was passiert in der Spezifikationsphase eines Softwareprojekts? (S.11)
Die ermittelten Anforderungen werden verbindlich dokumentiert.
Warum wird in vielen Projekten auf Spezifikation verzichtet? (S.7)
Weil oft keine systematische Anforderungserhebung erfolgt oder diese als unnötig angesehen wird.
Was ist die Gefahr, wenn ohne Spezifikation entwickelt wird? (S.7)
Man entwickelt „ins Blaue“ und erfährt erst am Ende, was das Ergebnis ist, was für den Kunden riskant ist.
Was wird in den frühen Phasen der Softwareentwicklung getan? (S.12)
Anforderungen analysieren und dokumentieren, Begriffe dokumentieren, Spezifikation prüfen.
Wie definiert IEEE Std. 610.12 (1990) Anforderungen? (S.13)
Als Bedingung oder Fähigkeit, die ein Nutzer oder System benötigt oder erfüllen muss, oder deren Dokumentation.
Was sind offene Anforderungen? (S.14)
Anforderungen, die offen geäußert und nur dokumentiert werden müssen.
Was sind latente Anforderungen? (S.14)
Anforderungen, die bestehen, aber dem Auftraggeber erst bewusst werden, wenn man ihn darauf hinweist.
Was sind Entwickler-Optionen? (S.14)
Anforderungen, die dem Kunden egal sind und daher vom Entwickler entschieden werden können.
Was sind harte Anforderungen? (S.15)
Exakt beschriebene Anforderungen, deren Erfüllung klar mit Ja oder Nein überprüft werden kann.
Was sind weiche Anforderungen? (S.15)
Anforderungen, deren Erfüllung nicht klar mit Ja oder Nein überprüft werden kann, z. B. Wartbarkeit.
Was sind objektivierbare weiche Anforderungen? (S.15)
Weiche Anforderungen, die überprüfbar formuliert sind, z. B. „30 Policen pro Stunde“.
Was sind vage Anforderungen? (S.15)
Weiche Anforderungen, die nicht exakt bestimmt sind, z. B. „schnelle Arbeitsweise“.
Was sind nicht-funktionale Anforderungen? (S.16)
Forderungen nach Eigenschaften wie Zuverlässigkeit, Komfort, Benutzbarkeit und Wartbarkeit.
Warum sind nicht-funktionale Anforderungen oft problematisch? (S.16)
Weil sie meist weich und vage sind und schwer objektiv zu bewerten sind.
Wie sollten nicht-funktionale Anforderungen dokumentiert werden? (S.17)
Präzise, klar und prüfbar, ggf. unter Bezug auf Normen.
Nenne ein Beispiel für eine prüfbare Formulierung „einfach bedienbar“. (S.18)
Das Programm soll nach maximal einer Stunde Einarbeitung von Laien nutzbar sein.
Nenne ein Beispiel für eine prüfbare Formulierung „robust“. (S.18)
Bei Fehlbedienung darf das Programm nicht abstürzen.
Nenne ein Beispiel für eine prüfbare Formulierung „portabel“. (S.18)
Das Programm muss auf Windows, Linux und MacOS X ohne Überarbeitung laufen.
Nenne ein Beispiel für eine prüfbare Formulierung „plattformunabhängig“. (S.18)
Maschinenspezifischer Code darf nur in einem Modul enthalten sein.
Welche Dokumente entstehen in den frühen Phasen? (S.19)
Projektplan, Anforderungsdokument (Lastenheft), Begriffslexikon, Spezifikation (Pflichtenheft).
Nenne ein Beispiel für eine prüfbare Formulierung „angemessenes Handbuch“. (S.18)
Das Handbuch muss gemäß Unternehmensvorgaben erstellt werden.
Analysetechniken nach soll und ist Zustand: (s.22)
Was ist der Unterschied zwischen Ist- und Soll-Analyse? (S.21)
Ist-Analyse beschreibt den aktuellen Zustand
Soll-Analyse den gewünschten Zielzustand
Was besagt die Wunschzettel-Methodik? (S.23)
Alle Kundenanforderungen werden aufgenommen, unsinnige später gemeinsam gestrichen.
Nenne Beispiele für unsinnige Anforderungen. (S.23)
Technisch nicht realisierbare, wirtschaftlich nicht tragbare, widersprüchliche oder ethisch bedenkliche Anforderungen.
Welche typischen Schwierigkeiten treten bei der Analyse auf? (S.25)
Einbringen eigener Anforderungen, falscher Fokus, fehlende Wertschätzung der Spezifikation, Sabotage durch späte Änderungen.
Was ist bei Freiräumen in der Analyse erlaubt? (S.26)
Eigene Vorstellungen, aber keine Anforderungen einzubringen.
Welche Fragen sollte man bei der Analyse eines Tankautomaten stellen? (S.27)
Fragen zum aktuellen Tankstellenbetrieb und zu den geplanten Änderungen für Selbstbedienung.
Fragen zum Ist-Zustand:
Wie funktioniert der aktuelle Tankstellenbetrieb?
Welche Zahlungssysteme werden derzeit genutzt?
Welche Sicherheitsmaßnahmen gibt es?
Wie läuft der Betankungsvorgang aktuell ab?
Fragen zum Soll-Zustand:
Soll der Automat 24/7 verfügbar sein?
Welche Zahlungsmethoden sollen unterstützt werden (Bargeld, Karte, App)?
Soll der Automat Quittungen drucken oder digital versenden?
Gibt es besondere Sicherheits- oder Bedienungsanforderungen?
Kundengespräch:
Diese Fragen stellen, Antworten notieren, Unklarheiten direkt klären.
Dokumentation:
Alle Anforderungen in einem strukturierten Anforderungsdokument festhalten (Lastenheft).
Charakterisieren Sie offene, latente Anforderungen und Entwickleroptionen. (S.29)
Offen: direkt geäußert
latent: unbewusst bis Hinweis
Entwickleroption: egal für Kunden, Entwickler entscheidet.
Charakterisieren Sie Ist- und Soll-Analyse. (S.29)
Ist: aktueller Zustand
Soll: gewünschte Änderung.
Welche Technik eignet sich vor allem für die Ist-Analyse? (S.29)
Beobachtung.
Welche Technik eignet sich vor allem für die Soll-Analyse? (S.29)
Kundeninterview.
Welche Technik kann sowohl für Ist- als auch Soll-Analyse genutzt werden? (S.29)
Workshops.
Welche Eigenschaften hat die Anforderung „Not-Aus-Schalter muss in sehr kurzer Zeit auslösen“? (S.30)
Nicht-funktional, sicherheitsrelevant, harte Zeitbedingung, prüfbar durch Test.
Formulieren Sie die Not-Aus-Anforderung prüfbar. (S.30)
„Nach Betätigung des Not-Aus-Schalters muss die Maschine innerhalb von maximal 1 Sekunde in einen sicheren Zustand übergehen.“
Zuletzt geändertvor einem Monat
