Anforderungsanalyse II Flashcards
Domänenanalyse
- 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
Prozess der Anforderungserhebung
- Bestimmen der Stakeholder und
Festlegen der Ziele - Analysieren des Kontexts
- Analysieren und auswählen von Lösungsoptionen
- Definieren und beschreiben von Anforderungen und Diensten
- Ermitteln von Risiken und Erfolgsfaktoren
- Analysieren und behandeln sonstiger Nebenbedingungen
Lastenheft
- Festlegung des Produktziels
- Festlegung der Produktumgebung
- Festlegung des Produkteinsatzes
- Festlegung des Datenmodells
- Festlegung der Funktionalität
- Festlegung des Risikopotenzials
Quellen von Anforderungen
- Stakeholder mit Verbesserungsvorschlägen
- Literatur, Gesetze, Normen, Standards
- Existierende Systeme
- Erfahrung aus Studien, Schulungen, Hotlines
- Prototypen
Kreativitätstechniken
- Brainstorming
- Mindmapping
- Zwicky-Box
- Progressive Abstraktion
- Osborn Checkliste
Methoden für die anforderungsgetriebene Entwicklung
- 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
User Stories
Schema:
* Als [WER]
* möchte ich [WAS]
* sodass [WARUM]
Rückseite:
* Einschränkungen für Akzeptanz
UML-Anwedungsfalldiagramm
(Use Case Diagramm)
- Anwendungsfälle
- Beziehungen zwischen diesen
- Akteure
- Generalisierung
- include, extend
- System in dem Use cases ausgeführt werden
UML-Klassendiagramm
- Klassen mit:
- Name
- Variablen (public, private etc)
- Methoden
UML-Zustandsautomat
- Name des Automaten
- Startzustand
- Zustände
- Zustandsübergänge
- Endzustand
- Abbruchzustand
UML-Sequenzdiagramm
- Name mit “sd”
- Kommunikationspartner
- Synchroner-,Asynchroner Operationsaufruf
- Antwortnachricht
- Operation mit Parametern ruft die Funktions von “Empfänger” auf
UML-Aktivitätsdiagramm
- Swim lanes
- Aktionen
- Aktivität kann Ein- und Ausgänge haben (ports)
- Startknoten
- Endknoten
- Entscheidungsknoten mit Bedingungen
UML-Komponentendiagramm
- Komponenten
- Schnittstellen (Benötige und implementierte)
- Komponente bestehend aus weiteren Komponenten -> Ports
Qualitätssicherung für Anforderungen
- Wird das richtige System entwickelt (Validierung der Anforderungen)
- Kann nachgewiesen werden, dass das System richtig entwickelt wurde (Verifizier-ung/barkeit)
Qualitätsaspekte von Anforderungen
- Konsistenz (Widerspruchsfreiheit)
- Vollständigkeit
- Korrektheit
- Eindeutigkeit
- Überprüfbarkeit
- Änderbarkeit
- Verfolgbarkeit
- Priorisierung
Validierung von Anforderungen
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
Verifizierbarkeit von Anforderungen
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
Priorisierung von Anforderungen
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
