Anforderungsanalyse II

Question 1

Domänenanalyse

Answer 1

• Erfassung des Anwendungsgebiets und des Problembereichs
  Erfordert:
• Intensive Einarbeitung
• Zahlreiche Gespräche und Interviews mit Stakeholdern
• Einfühlungsvermögen
• (interdisziplinäre) Kommunikationsfähigkeiten
• Geschickte Wahl von Informationsquellen

Question 2

Prozess der Anforderungserhebung

Answer 2

1. Bestimmen der Stakeholder und
   Festlegen der Ziele
2. Analysieren des Kontexts
3. Analysieren und auswählen von Lösungsoptionen
4. Definieren und beschreiben von Anforderungen und Diensten
5. Ermitteln von Risiken und Erfolgsfaktoren
6. Analysieren und behandeln sonstiger Nebenbedingungen

Question 3

Lastenheft

Answer 3

• Festlegung des Produktziels
• Festlegung der Produktumgebung
• Festlegung des Produkteinsatzes
• Festlegung des Datenmodells
• Festlegung der Funktionalität
• Festlegung des Risikopotenzials

Question 4

Quellen von Anforderungen

Answer 4

• Stakeholder mit Verbesserungsvorschlägen
• Literatur, Gesetze, Normen, Standards
• Existierende Systeme
• Erfahrung aus Studien, Schulungen, Hotlines
• Prototypen

Question 5

Kreativitätstechniken

Answer 5

• Brainstorming
• Mindmapping
• Zwicky-Box
• Progressive Abstraktion
• Osborn Checkliste

Question 6

Methoden für die anforderungsgetriebene Entwicklung

Answer 6

• Design Thinking
  Verstehen -> Definieren -> Ideen finden -> Prototyp -> Evaluieren
• Feature-Driven Development (FDD)
  Gesamtmodell definieren -> Feature Liste erstellen -> Basieren auf features planen -> Entwirf Feature <-> Implementiere feature

Question 7

User Stories

Answer 7

Schema:
* Als [WER]
* möchte ich [WAS]
* sodass [WARUM]

Rückseite:
* Einschränkungen für Akzeptanz

Question 8

UML-Anwedungsfalldiagramm
(Use Case Diagramm)

Answer 8

• Anwendungsfälle
• Beziehungen zwischen diesen
• Akteure
• Generalisierung
• include, extend
• System in dem Use cases ausgeführt werden

Question 9

UML-Klassendiagramm

Answer 9

• Klassen mit:
• Name
• Variablen (public, private etc)
• Methoden

Question 10

UML-Zustandsautomat

Answer 10

• Name des Automaten
• Startzustand
• Zustände
• Zustandsübergänge
• Endzustand
• Abbruchzustand

Question 11

UML-Sequenzdiagramm

Answer 11

• Name mit “sd”
• Kommunikationspartner
• Synchroner-,Asynchroner Operationsaufruf
• Antwortnachricht
• Operation mit Parametern ruft die Funktions von “Empfänger” auf

Question 12

UML-Aktivitätsdiagramm

Answer 12

• Swim lanes
• Aktionen
• Aktivität kann Ein- und Ausgänge haben (ports)
• Startknoten
• Endknoten
• Entscheidungsknoten mit Bedingungen

Question 13

UML-Komponentendiagramm

Answer 13

• Komponenten
• Schnittstellen (Benötige und implementierte)
• Komponente bestehend aus weiteren Komponenten -> Ports

Question 14

Qualitätssicherung für Anforderungen

Answer 14

• Wird das richtige System entwickelt (Validierung der Anforderungen)
• Kann nachgewiesen werden, dass das System richtig entwickelt wurde (Verifizier-ung/barkeit)

Question 15

Qualitätsaspekte von Anforderungen

Answer 15

• Konsistenz (Widerspruchsfreiheit)
• Vollständigkeit
• Korrektheit
• Eindeutigkeit
• Überprüfbarkeit
• Änderbarkeit
• Verfolgbarkeit
• Priorisierung

Question 16

Validierung von Anforderungen

Answer 16

So früh wie möglich im Entwicklungsprozess:
* “Wird das richtige System entwickelt?”
* ”Sind die erfassten Anforderungen zutreffend und vollständig?”

Mögliche Methoden:
* Diagnosen durch Analysewerkzeuge
* Interne Entwurfsüberprüfungen (etwa Design Reviews, Design Inspections)
* Strukturierte Reviews (etwa Structured Walk Throughs)
* Erstellung von Prototypen (etwa für Tests oder Studien mit potentiellen Nutzern)
* Überprüfung und Abnahme durch eine unabhängige Qualitätskontrolle

Question 17

Verifizierbarkeit von Anforderungen

Answer 17

Gegeben, wenn ein erstelltes Softwaresystem mit vertretbarem
Aufwand auf Einhaltung der Anforderungen überprüft werden kann
* Insbesondere durch Softwaretests (später mehr), aber auch andere
Methoden möglich
* Immer: Anforderungen müssen hinreichend konkret formuliert werden, sodass eindeutige Verifikation möglich ist

Question 18

Priorisierung von Anforderungen

Answer 18

MoSCoW als einfache Priorisierungsmethode mit vier Ebenen (häufig
verwendet bei agilem Vorgehen) :
* M(ust) have für Anforderungen, die auf jeden Fall erfüllt werden müssen
* S(hould) have für Anforderungen, die realisiert werden sollten
* C(ould) have für Anforderungen, die “nice to have” sind und realisiert
werden könnten, wenn noch Kapazität im Projekt vorhanden ist
* Won’t have für Anforderungen, die (vorerst) nicht realisiert werden