View
215
Download
0
Category
Preview:
Citation preview
Universitat Bielefeld
Softwarepraktikum
Gernot A Fink
SS 2005
bull Zielerforschung
ndash Erhebungndash Zielfindung Kreativitaumltstechniken
bull Anforderungsanalyse
ndash Anwendungsfaumllle Use-Cases
Universitat Bielefeld
Softwaredesign
nach Keith Jonas
Was der Kunde erklaumlrt hat
Gernot A Fink and or gt 1
Universitat Bielefeld
Softwaredesign
Was der Entwickler verstanden hat
Gernot A Fink ≺ lt and or gt 2
Universitat Bielefeld
Softwaredesign
Das initiale Design
Gernot A Fink ≺ lt and or gt 3
Universitat Bielefeld
Softwaredesign
Der erste Prototyp
Gernot A Fink ≺ lt and or gt 4
Universitat Bielefeld
Softwaredesign
Das installierte System
Gernot A Fink ≺ lt and or gt 5
Universitat Bielefeld
Softwaredesign
Was der Kunde wirklich wollte
Gernot A Fink ≺ lt and or gt 6
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Softwaredesign
nach Keith Jonas
Was der Kunde erklaumlrt hat
Gernot A Fink and or gt 1
Universitat Bielefeld
Softwaredesign
Was der Entwickler verstanden hat
Gernot A Fink ≺ lt and or gt 2
Universitat Bielefeld
Softwaredesign
Das initiale Design
Gernot A Fink ≺ lt and or gt 3
Universitat Bielefeld
Softwaredesign
Der erste Prototyp
Gernot A Fink ≺ lt and or gt 4
Universitat Bielefeld
Softwaredesign
Das installierte System
Gernot A Fink ≺ lt and or gt 5
Universitat Bielefeld
Softwaredesign
Was der Kunde wirklich wollte
Gernot A Fink ≺ lt and or gt 6
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Softwaredesign
Was der Entwickler verstanden hat
Gernot A Fink ≺ lt and or gt 2
Universitat Bielefeld
Softwaredesign
Das initiale Design
Gernot A Fink ≺ lt and or gt 3
Universitat Bielefeld
Softwaredesign
Der erste Prototyp
Gernot A Fink ≺ lt and or gt 4
Universitat Bielefeld
Softwaredesign
Das installierte System
Gernot A Fink ≺ lt and or gt 5
Universitat Bielefeld
Softwaredesign
Was der Kunde wirklich wollte
Gernot A Fink ≺ lt and or gt 6
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Softwaredesign
Das initiale Design
Gernot A Fink ≺ lt and or gt 3
Universitat Bielefeld
Softwaredesign
Der erste Prototyp
Gernot A Fink ≺ lt and or gt 4
Universitat Bielefeld
Softwaredesign
Das installierte System
Gernot A Fink ≺ lt and or gt 5
Universitat Bielefeld
Softwaredesign
Was der Kunde wirklich wollte
Gernot A Fink ≺ lt and or gt 6
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Softwaredesign
Der erste Prototyp
Gernot A Fink ≺ lt and or gt 4
Universitat Bielefeld
Softwaredesign
Das installierte System
Gernot A Fink ≺ lt and or gt 5
Universitat Bielefeld
Softwaredesign
Was der Kunde wirklich wollte
Gernot A Fink ≺ lt and or gt 6
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Softwaredesign
Das installierte System
Gernot A Fink ≺ lt and or gt 5
Universitat Bielefeld
Softwaredesign
Was der Kunde wirklich wollte
Gernot A Fink ≺ lt and or gt 6
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Softwaredesign
Was der Kunde wirklich wollte
Gernot A Fink ≺ lt and or gt 6
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Softwaredesign
Was der Kunde eigentlich gebraucht haumltte
Gernot A Fink ≺ lt and or gt 7
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Zielerforschung
siehe auch H Mayr Projekt Engineering Kap7
Ziel Festlegung des Gesamtziels (der Grobziele) eines Projekts
(Ziele = objectives dh messbar mit Zeitziel nicht goals)
Probleme
bull Ziele und Anforderungen aumlndern und entwickeln sich im Laufe eines ProjektsrArr keine Schwaumlche der Projektfuumlhrung sondern Projektbestandteil
bull Aumlnderung erfolgt schleichend bull Bei Aumlnderung von Detailzielen Umplanung moumlglichbull Bei Aumlnderung des Gesamtziels muszlig Projekt abgebrochen werdenrArr Schwierige und wichtige Aufgabe Erkennen ob und wann Planadaption
oder Umplanung erforderlich
Gernot A Fink ≺ lt and or gt 8
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebung
Meist (unbezahlte) Vorleistung im Rahmen der Projektanbahnung
Ziel Feststellung der Projektausgangslagedurch potentiellen Auftragnehmerim Umfeld des potentiellen Auftraggebers
Aufgaben
bull Zusammenstellen der Projektvorarbeiten(seitens des potentiellen Auftraggebers)
bull Definieren des Projektumfeldes(Organisation operationale Struktur strategische Entwicklung)Beachte Sollten moumlglichst von auszligen beobachtet werden
(Auch Feststellung des IST-Zustandes)
Techniken Interview Fragebogen Dokumentenauswertung
Gernot A Fink ≺ lt and or gt 9
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebung Techniken
Kriterien zur Einteilung der Erhebungstechniken
bull nach Art der Interaktionndash auditiv persoumlnliches oder telephonisches Interviewndash schriftlich Fragebogen oder Auswertung von Dokumenten
bull nach dem Strukturierungsgradndash nicht strukturiert offenndash halb strukturiert vorgegebene Fragenndash strukturiert geschlossen Fragen und Antworten vorgegeben
bull nach dem Objekt der Erhebungndash Primaumlrerhebung Befragung und Beobachtungndash Sekundaumlrerhebung Dokumentenauswertung
bull nach der Zahl der Erhebungsobjektendash Einzelerhebung ein Elelementndash Fallstudie einzelne Elementendash Repraumlsentative Erhebung zB Fragebogenaktion bei repraumlsentativer Benutzergruppendash Totalerhebung Fragebogenaktion mit allen potentiellen Nutzern
Gernot A Fink ≺ lt and or gt 10
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebungstechniken Interview
Interaktionsprozess mit Rollenaufteilung zwischen Interviewtem und Interviewer
Moumlgliche Varianten
bull Einzel- oder Gruppeninterview (im Beratungsbereich Bewerbungsgespraumlch)
bull Von Angesicht zu Angesicht (uumlblich) oder telephonisch
bull Unterschiedlicher Strukturierungsgrad
Gernot A Fink ≺ lt and or gt 11
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebungstechniken Interview II
Nicht und halb-strukturierte InterviewsOffenes Gespraumlch bei dem nur das Thema vorgegeben ist
Anforderungen an Interviewer
bull Interessanten Antworten ldquoerzwingenrdquo
bull Flexibel auf Antworten reagierenrArr Fragen richten sich nach vorangegangenen Antworten
bull Beruumlcksichtigung auch impliziter und non-verbaler Signale
bull Aufbau eines ldquoroten Fadensrdquo
bull Vertrautheit mit Themenbereich und Umfeld
rArr Hilfestellung durch Interview-Leitfaden
bull Thema strukturiert in relevante Teilthemen bezogen auf Zielinhalte
bull Fragen teilweise vorgegeben (div Fragetypen)
Gernot A Fink ≺ lt and or gt 12
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebungstechniken Interview III
Strukturiertes Interview
bull Mischung aus Interview und Fragebogen
bull Interviewer uumlbernimmt Ausfuumlllen des Fragebogens
bull Fragebogen ist auch Protokoll
bull Fragebogen weniger formalisiert als bei reiner Fragebogenaktion(zB bezuumlglich Verstaumlndlichkeit Unklarheiten koumlnnen durch Interviewer sofortausgeraumlumt werden)
Gernot A Fink ≺ lt and or gt 13
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebungstechniken Fragebogen
bull hoher Strukturierungsgrad
bull hohe Entwicklungskosten
bull niedrige Durchfuumlhrungskosten
bull groszlige Stichproben moumlglich (ggf Totalerhebung)
Vergleichbar mit strukturiertem Interview Ausfuumlllen vom Befragten
X direkt
X schnell
E ohne Ruumlckfragemoumlglichkeit
Gernot A Fink ≺ lt and or gt 14
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebungstechniken Fragebogenaktion
1 Zielgruppe auswaumlhlen
2 Fragen formulierenbull kurze nicht-redundante offene konkrete Fragenbull keine Unter- und Kettenfragen keine Suggestivfragenbull Bearbeitungsform waumlhlen Auswahl Reihung Skalierung
3 Fragebogen zusammenstellenbull Wichtig Motivation zur Mitarbeit (Interesse durch Einleitungsfragen wecken schwierigeheikle
Fragen nicht am Anfang Abschluss zB durch generelles Statement)bull ggf Aufmerksamkeit des Ausfuumlllers testen (zB Positionsvariation bei Auswahl-Antworten)bull Stellungnahme provozieren (keine ldquoweiszlig-nichtrdquo Antworten)
4 Fragebogen testen Vortest als strukturiertes Interview
5 Fragebogen einsetzen Ruumlcklaufquote beruumlcksichtigen(Ruumlcklauf gt 10 bei Unternehmen ist Erfolg)
6 Fragebogen auswerten(ungenaueunvollstaumlndige Antworten problematisch
nicht sensitive [= ia gleich beantwortete] Antworten eliminieren)
Gernot A Fink ≺ lt and or gt 15
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebungstechniken Dokumentauswertung
Auftraggeber besitzt idR Dokumente aus (internen) Projektvorhaben eigenenVoruntersuchungen bisherigen GeschaumlftsprozessenrArr nach solchen Dokumenten fragen
bull Liefern Informationen zu
ndash Daten und Informationsfluszligndash ggf (nicht erfolgreiche) interne Vorprojekten
bull Beispiele fuumlr Dokumente
ndash Bestell- und Lieferscheinendash Arbeitsanweisungenndash Ablaufdiagrammendash Vorschlaumlge im Rahmen eines Verbesserungswesens
bull Speziell Produktvergleiche(dh Auswertung der Informationen zu Konkurrenzprodukten)
Gernot A Fink ≺ lt and or gt 16
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Erhebung Ergebnisauswertung
ist ein Dokument das die AuswertungZusammenstellung der Dokumente zurProjektanbahnung enthaumllt
bull Interviews
bull Besprechungen
bull Fragebogenaktionen
bull vorhandene Einzeldokumente (des Auftraggebers)
Stellt Problembeschreibung aus Sicht des Auftragnehmers dar ist daher kein bin-dendes Dokument (Bindende Festlegung erst durch Lastenheft bzw Auftrag)
Gernot A Fink ≺ lt and or gt 17
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Zielfindung
bull Projektziele des Auftraggebers oft ldquonebuloumlsrdquo
bull Projektausgangslage erst nach Erhebung bekannt bzw klar definiert
bull Im Rahmen der Erhebung ergeben sich evtl zusaumltzliche Aspekte die Projekt-ziele aumlndern oder erweitern
Ziel Gesamtziel des Projekts (und damit verbundene Grobziele) erarbeiten
Gernot A Fink ≺ lt and or gt 18
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Zielfindung Aufgaben
bull Gewichten und klassifizieren der ermittelten Ziele (zusammen mit Kunden)
Muszligziele (essential objectives)Sollziele (conditional objectives)Wunschziele (optional objectives) rarr ldquonice to haverdquorArr Auf Zielkonflikte achten
bull Abhaumlngigkeiten zwischen Zielen analysieren
bull Organisationsvorgaben festlegen(Unternehmens- Abteilungs- bzw Projektziele)
bull Zielarten herausarbeiten(technische organisatorische finanzielle Ziele)
Ziele muumlssen uumlberpruumlfbar sein
Zielefindung ist kreativer dh schoumlpferischer Prozeszlig
Gernot A Fink ≺ lt and or gt 19
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Zielfindung Kreativitaumltstechniken
(siehe auch Anders Bjoumlrks Web-Site)
sind Methoden zur Definition und Loumlsung schlecht strukturierter Probleme durchAnwendung intuitiver Probierverfahren
gemeinsam sind Gruppensitzungen mit Teilnehmern
bull aus verschiedenen Taumltigkeitsbereichenbull verschiedenen hierarchischen Ebenenbull und unterschiedlichen Kenntnissen und Fertigkeiten
Merkmale
bull Probleme werden in Teilprobleme zerlegtbull zu Teilproblemen werden Loumlsungsvorschlaumlge generiertbull die besten Teilloumlsungen werden ausgewaumlhlt
und zur Problemloumlsung synthetisiertbull Kreativitaumltsprozeszlig wird durch Moderator gesteuert
Gernot A Fink ≺ lt and or gt 20
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Kreativitaumltstechniken Brainstorming
Prinzipien
bull keine Kritik waumlhrend der Sitzungbull freie Gedankenspiele rarr originelle und neuartige Ideenbull viele Ideen produzierenbull Ideen anderen Mitglieder der Gruppe weiterentwickeln
Vorteile
X viele Ideen in kurzer ZeitX verschiedene Sichten auf das ProblemX relativ einfaches Verfahren
Nachteile
E Loumlsungsvorschlaumlge haumlufig realitaumltsfremdE Verlauf der Ideenfindung beeinfluszligt Ergebnis (Guppendynamik)
Gernot A Fink ≺ lt and or gt 21
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Kreativitaumltstechniken Morphologischer Kasten
Prinzip systematische Suche nach Vielzahl von Loumlsungsmoumlglichkeiten
Vorgehen
1 Problem (Objekt) praumlzise beschreiben2 in Teilprobleme (Parameter) zerlegen3 alle Parameterauspraumlgungen in Schema (Matrix Kasten) eintragen4 Loumlsungen kombinieren und bewerten5 bestmoumlgliche Loumlsung auswaumlhlen
Beispiel Design eines neuen Rasenmaumlhers
Vorteile X foumlrdert systematisches VorgehenX verhindert voreilige EntscheidungenX Loumlsung ist klar dargestellt
Nachteile E Gefahr der Unuumlbersichtlichkeit bei komplexen ProblemenE Auswahl der optimalen Loumlsung schwierig
Gernot A Fink ≺ lt and or gt 22
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Anforderungsanalyse
Anforderungen (= requirements) Faumlhigkeiten die ein System bereitstellen undBedingungen die es einhalten muss
(Grobklassifikation in funktionale und nicht-funktionale Anforderungen)
Ziel Identifizieren und dokumentieren (fuumlr Kunden und Entwicklungsteam)ldquowas wirklich gebraucht wirdrdquo dh der wesentlichen Systemanforderungen
Beachte
bull Anforderungen sind uU unklar und koumlnnen sich im Projektverlauf aumlndernbull ldquoModernerdquo iterative Softwareprozesse beruumlcksichtigen diesrArr managing requirements
(Anforderungsanalyse wird nicht vor Beginn der Entwicklung komplett abgeschlossen [Wasser-
fallmodell] sondern parallel dazu verfeinert und ggf angepasst)
Gernot A Fink ≺ lt and or gt 23
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Anforderungen Klassifikation
(nach C Larman 2001)
Das FURPS+ Modell zur Typisierung von Anforderungen
Functional - features capabilities (security)
rArr identifiziert und dokumentiert uumlber Use-Cases (= Anwendungsfaumllle)
Usability - human factors help documentation
Reliability - frequency of failure recovarability predictability
Performance - response time throughput accuracy
Supportability - maintainability internationalization
Ex untergeordnete Anforderungstypen Implementation Interface Operations Packaging Legal
Anforderungen koumlnnen ggf nicht zu 100 erfuumlllt werden
Gernot A Fink ≺ lt and or gt 24
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Grundlagen
Use-Case Eine ldquoGeschichterdquo uumlber die Benutzung des Systemsdh ein Anwendungsfall mit (im Wesentlichen)
bull einem Namen um daruumlber reden zu koumlnnen
bull Akteuren (Benutzer System andere Personen )bull einem Ziel das der Hauptakteur verfolgtbull einem Hauptszenariobull und alternativen Szenarien
rArr definiert Systemanforderungen im Kontext der Systemverwendung
Anforderungen an Use-Cases
bull Anwendungsfall ist in sich abgeschlossenbull Der Anwendungsfall ldquobefriedigtrdquo ein klar definiertes Ziel des Benutzers
(ia des Hauptakteurs)rArr Use-Cases korrespondieren im Wesentlichen mit Zielen des Benutzers
bull Nach ldquoAbarbeitungrdquo des Anwendungsfalls befindet sich das System wieder ineinem klar definierten und konsistenten Zustand
Gernot A Fink ≺ lt and or gt 25
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Beispiele
Zu entwickeln Elektronisches Kassensystem (POS [Point Of Sale] System)
Use-Case im Kurzformat (brief format)
Bearbeite Verkauf Ein Kunde kommt mit Artikeln zur Kasse Der Kassie-rer verwendet das Kassensystem zur Erfassung der zu kaufenden ArtikelDas Kassensystem zeigt Einzelpreise und den Gesamtpreis an Der Kundegibt Zahlungsinformation in das Kassensystem ein die das Kassensystemvalidiert und speichert Das Kassensystem aktualisiert die Lagerhaltungsda-ten Der Kunde erhaumllt einen Kaufbeleg vom Kassensystem und geht mit dengekauften Objekten
Hauptakteur rarr Kassierer Ziel rarr Verkauf an Kunden bearbeiten
Grund der Sichtweise Betrachtete Systemgrenze(betrachten Kassensystem und nicht gesamten Laden)
Gernot A Fink ≺ lt and or gt 26
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Beispiele II
Derselbe Use-Case im annotierten Format (fully dressed format)
Anwendungsfall Bearbeite VerkaufHauptakteur Kassierer Erfolgszustand Kauf des Benutzers bearbeitet (erfaszligt und abgerechnet)Ausloumlser Kunde kommt mit Artikeln zur KasseHauptszenario 1 Kassierer erfaszligt zu kaufende Artikel
2 Kassensystem zeigt Einzelpreise und Gesamtpreis3 Kunde gibt Zahlungsinformation ein4 Kassensystem validiert und speichert Zahlungsinforma-tionen5 Kassensystem aktualisiert Lagerhaltungsdaten6 Kunde erhaumllt Kaufbeleg
Use-Cases koumlnnen eingebettete Use-Cases enthalten
Gernot A Fink ≺ lt and or gt 27
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Szenarien
Anwendungsfall sollte immer alternative Szenarien enthalten
Grund Potentiell jeder Einzelschritt im Hauptszenario kann fehlschlagen
rArr Fehlersituation muss dokumentiert und Fehlerbehandlung spezifiziert werdenAnwendungsfall Bearbeite Verkauf Hauptszenario
4 Kassensystem validiert Zahlungsinformationen
Alternativen 4a Validierung schlaumlgt fehl4a1 Kunde zahlt bar4a2 Kassierer erfaszligt Barzahlung manuell
Beachte Verzweigungen (dh if then else Konstrukte)sind in Use-Cases tabu (erschweren Lesbarkeit)
rArr werden uumlber alternative Szenarien realisiert
Gernot A Fink ≺ lt and or gt 28
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Detailgrad
Beispiel im essential style
Anwendungsfall Autorisiere BenutzerHauptakteur Benutzer (hier Kassierer)Erfolgszustand Benutzer ist z Verwendung d Kassensystems autorisiertHauptszenario 1 Benutzer identifiziert sich gegenuumlber Kassensystem
2 Kassensystem validiert Autorisierung des Benutzers
oder im concrete style
Hauptszenario 1 Benutzer gibt ID und Passwort in Dialogfenster ein
2 Kassensystem validiert Autorisierung des Benutzers3 Kassensystem zeigt erfolgreiche Autorisierungim Anmeldebidschirm an
Beachte Konkretisierungen sind ggf wuumlnschenswert Details der Benutzer-schnittstelle jedoch nicht
Gernot A Fink ≺ lt and or gt 29
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Universitat Bielefeld
Use-Cases Zusammenfassung
Fehlerzustand
Hauptminus Nebenminus
Alternativminus
Hauptszenario
akteur akteurZiel
NameVorbedingung
szenarioAbstraktionsminus
ebene
Gernot A Fink ≺ lt and or 30
Recommended