4. anforderungsanalysehome.edvsz.hs-osnabrueck.de/skleuker/ws10_ooad/ooad_teil02_4… · ooad wise...
TRANSCRIPT
47Prof. Dr. Stephan KleukerOOAD WiSe 10
4. Anforderungsanalyse4.1 Stakeholder und Ziele4.2 Klärung der Hauptfunktionalität (Use Cases)4.3 Beschreibung typischer und alternativer Abläufe4.4 Ableitung funktionaler Anforderungen4.5 Nicht-funktionale Anforderungen4.6 Lasten- und Pflichtenheft
Literatur:• [RS] C. Rupp, SOPHIST GROUP, Requirements- Engineering und –
Management , Hanser Fachbuchverlag• [OW] B. Oestereich, C. Weiss, C. Schröder, T. Weilkiens, A. Lenh ard,
Objektorientierte Geschäftsprozessmodellierung mit der UML , dpunkt.Verlag
48Prof. Dr. Stephan KleukerOOAD WiSe 10
so nicht (1/4): Beispiel-Szenario
Zur Stundenerfassung und Abrechnung werden von den Projektmitarbeitern spezielle Excel-Tabellen jeden Freitag ausgefüllt und am Montag vom Projektleiter bei der Verwaltung abgegeben.
Der zuständige Sachbearbeiter überträgt dann die fü r den Projektüberblick relevanten Daten manuell in ei n SAP-System. Dieses System generiert automatisch eine Übersicht, aus der die Geschäftsführung ablesen kann, ob die Projekte wie gewünscht laufen.
Dieser Bericht liegt meist am Freitag der Woche vor . Die Bearbeitungszeit ist der Geschäftsführung zu lang, deshalb soll der Arbeitsschritt automatisiert werden.
49Prof. Dr. Stephan KleukerOOAD WiSe 10
so nicht (2/4): Die Projektplanung
• Es wird ein Projekt „Projektberichtsautomatisierung “(ProAuto) beschlossen.
• Der Leiter der hausinternen IT-Abteilung wird über die anstehende Aufgabe informiert. Er erhält eine Beschreibung der Excel-Daten und der gewünschten SAP-Daten.
• Der Leiter stellt fest, dass seine Abteilung das Kn ow-how und die Kapazität hat, das Projekt durchzuführen und legt der Geschäftsführung einen Projektplan mit einer Aufwandsschätzung vor.
• Die Geschäftsführung beschließt, das Projekt intern durchführen zu lassen und kein externes Angebot einzuholen.
50Prof. Dr. Stephan KleukerOOAD WiSe 10
so nicht (3/4): Die Schritte zum Projektmisserfolg
• Die IT-Abteilung analysiert die Excel-Daten und wie die Daten in das SAP-System eingefügt werden können.
• Kurz nach dem geschätzten Projektende liegt eine technisch saubere Lösung vor. Excel wurde um einen Knopf erweitert, so dass dieProjektleiter per Knopfdruck die Daten nach SAP überspi elen können.
• Vier Wochen nach Einführung des Systems wird der Leiter der IT-Abteilung entlassen, da die Daten zwar jeden Mon tag vorliegen, sich aber herausgestellt hat, dass sie nich t nutzbar sind und die erzürnte Geschäftsleitung falsche Entscheidungen getroffen hat. Das Projekt wird an ein e Beratungsfirma neu vergeben.
ProAuto
51Prof. Dr. Stephan KleukerOOAD WiSe 10
so nicht (4/4): so doch, Geschäftsprozessanalyse
[
[
]
]
52Prof. Dr. Stephan KleukerOOAD WiSe 10
Aufgabe der Anforderungsanalyse
Bestimmung aller Anforderungen an die zu erstellend e Software bzw. an das zu erstellende DV-System, Anforderungen müssen
–vollständig,–notwendig ("WAS statt WIE"), –eindeutig und–richtig ("abgestimmt als Teil einer Zielhierarchie" )
sein.
Bemerkung zur Ablauforganisation: Anforderungen müssen nicht notwendig in einer Phase vor Beginn de s Entwurfs vollständig bestimmt werden
4.1
53Prof. Dr. Stephan KleukerOOAD WiSe 10
Probleme mit Anforderungen an große Systeme
• Auftraggeber, Nutzer, Betreiber etc. sind häufig verschi edene Personen, unterschiedliche Personen haben teilweise widersprüchliche Anforderungen
• die Effekte des angestrebten Systems sind schwer vorhe rsehbar• Anforderungen ändern sich im Laufe der Entwicklungszeit • großer Umfang der Anforderungen • komplexe Interaktion mit anderen Systemen
• Erste Aufgabe: Ermittlung der StakeholderDefinition: Jemand der Einfluss auf die Anforderungen hat, da ervom System betroffen ist (Systembetroffener)
• Zweite Aufgabe: Ermittlung der Ziele des Systems
54Prof. Dr. Stephan KleukerOOAD WiSe 10
Checkliste zum Finden von Stakeholdern (1/3) [RS]
• Endanwender– Die größte und wichtigste Gruppe, liefert Großteil der
fachlichen Ziele– Durchdachtes Auswahlverfahren für die
Anwenderrepräsentanten nötig (Vertrauensbasis der gesamten Anwendergruppe berücksichtigen!)
• Management des Auftragnehmers (wir)– Gewährleisten die Konformität mit Unternehmenszielen un d
Strategien, sowie der Unternehmensphilosophie– Sind die Sponsoren!
• Käufer des Systems– Wer ist für die Kaufentscheidung verantwortlich?– Liefer-Vertrags-Zahlungskonditionen?
• Prüfer, Auditoren– sind für Prüfung, Freigabe und Abnahme notwendig,
• Entwickler– Entwickler nennen die technologiespezifischen Ziele
55Prof. Dr. Stephan KleukerOOAD WiSe 10
Checkliste zum Finden von Stakeholdern (2/3)
• Wartungs- und Servicepersonal– Wartung und Service muss unkompliziert und zügig
durchzuführen sein– Wichtig bei hohen Stückzahlen
• Produktbeseitiger– Wichtig, wenn ausgeliefertes Produkt nicht nur Software
umfasst, Frage der Beseitigung (z.B. Umweltschutz), k ann enormen Einfluss auf die Zielsetzung einer Produktentwicklung haben
• Schulungs- und Trainingspersonal– Liefern konkrete Anforderungen zur Bedienbarkeit,
Vermittelbarkeit, Hilfesystem, Dokumentation, Erlernb arkeit,• Marketing und Vertriebsabteilung
– Marketing und Vertrieb als interne Repräsentanten der externen Kundenwünsche und der Marktentwicklung
56Prof. Dr. Stephan KleukerOOAD WiSe 10
Checkliste zum Finden von Stakeholdern (3/3)
• Systemschützer– Stellen Anforderungen zum Schutz vor Fehlverhalten von
Stakeholdern• Standards und Gesetze
– vorhandene und zukünftige Standards/Gesetze berücksichtigen
• Projekt- und Produktgegner– Die Klasse der Projekt- und Produktgegner - vor allem zu
Beginn des Projekts wenn möglich mit einbeziehen, so nst drohen Konflikte
• Kulturkreis– setzt Rahmenbedingungen, z.B. verwendete Symbolik,
Begriffe, …• Meinungsführer und die öffentliche Meinung
– beeinflussen oder schreiben Ziele vor, Zielmärkte berücksichtigen
57Prof. Dr. Stephan KleukerOOAD WiSe 10
Regeln für die Definition von Zielen
Hinweis: Ziele sind abstrakte Top-Level-Anforderunge n
Ziele müssen– vollständig,– korrekt,– konsistent gegenüber anderen Zielen und in sich
konsistent,– testbar,– verstehbar für alle Stakeholder,– umsetzbar — realisierbar,– notwendig,– eindeutig und positiv formuliert sein.
Zwei weitere Merkmale:– Lösungsneutralität– einschränkende Rahmenbedingungen
58Prof. Dr. Stephan KleukerOOAD WiSe 10
Schablone zur Zielbeschreibung
Was muss organisatorisch beachtet werden?Sonstiges
Ist die Zielverknüpfung mit anderen Zielen unmittelbar verknüpft? Dies kann einen positiven Effekt haben, indem die Erfüllung von Anforderungen zur Erreichung mehrerer Ziele beiträgt. Es ist aber auch möglich, dass ein Kompromiss gefunden werden muss, da Ziele unterschiedliche Schwerpunkte haben.
Abhängigkeiten
Welche unveränderlichen Randbedingungen müssen bei der Zielerreichung beachtet werden?
Rand-bedingungen
Welche Veränderungen werden für die Stakeholder erwartet?
Auswirkungen auf Stakeholder
Welche Stakeholder sind in das Ziel involviert? Ein Ziel ohne Stakeholder macht keinen Sinn.
StakeholderWas soll erreicht werden?Ziel
59Prof. Dr. Stephan KleukerOOAD WiSe 10
Projektbeschreibung
Zu entwickeln ist ein individuell auf die Unternehme nswünsche angepasstes Werkzeug zur Projektverwaltung. Dabei sind die Arbeitspakete (wer macht wann was) und das Projektcontrolling (wie steht das Projekt bzgl. seine r Termine und des Budgets) zu berücksichtigen. Projekte werden zur Zeit ausgehend von Projektstrukturplänen geplant und verwal tet.Projekte können in Teilprojekte zerlegt werden.Die eigentlichen Arbeiten finden in Arbeitspaketen, auch Aufgaben genannt, statt.Projekten werden von zusammenzustellenden Projektteams bearbeitet, die zugehörigen Mitarbeiterdaten sind zu ve rwalten. Zur Ermittlung des Projektsstands tragen Mitarbeiter ihre Arbeitszeit und den erreichten Fertigstellungsgrad in das System ein.
60Prof. Dr. Stephan KleukerOOAD WiSe 10
Ziele für eine Projektmanagementsoftware (1/3)
Es liegt eine Studie des Kunden vor, warum kein Produkt vom Markt zur Realisierung genommen wird.
Sonstiges
-Abhängigkeiten
Existierende Datenbestände sollen übernommen werden. Die Randbedingungen zur Verarbeitung personalbezogener Daten sind zu beachten.
Rand-bedingungen
Projektplaner: Alle Planungsdaten fließen in das neue Werkzeug, es gibt sofort eine Übersicht, wer an was, von wann bis wann arbeitet.Projektleiter: Der Projektleiter ist immer über den Stand informiert, er weiß, wer an was arbeitet.Mitarbeiter: Die Mitarbeiter sind verpflichtet, ihre Arbeitsstunden und erreichten Ergebnisse in das Werkzeug einzutragen. Sie sehen, für welche Folgearbeiten sie wann verplant sind.
Auswirkungen auf Stakeholder
Projektplaner, Projektleiter, Mitarbeiter, Controlling (alle als Endanwender)
Stakeholder
1. Die Software muss die Planung und Analyse aller laufenden Projekte ermöglichen
Ziel
61Prof. Dr. Stephan KleukerOOAD WiSe 10
Ziele für eine Projektmanagementsoftware (2/3)
Das Verhalten des neuen Kunden bei Änderungswünschen ist unbekannt.
Sonstiges
Überschneidung mit dem Ziel 3, da eine Konzentration auf die Wünsche des neuen Kunden eventuell einer Verwendbarkeit für den allgemeinen Markt widersprechen kann.
Abhängigkeiten
Es muss noch geprüft werden, ob langfristig eine für beide Seiten lukrative Zusammenarbeit überhaupt möglich ist.
Rand-bedingungen
Management: Der Projekterfolg hat große Auswirkungen auf die nächsten beiden Jahresbilanzen.Entwickler: Es werden hohe Anforderungen an die Software-Qualität gestellt.
Auswirkungen auf Stakeholder
Management, EntwicklerStakeholder
2. Der neue Kunde soll von der fachlichen Kompe-tenz unseres Unternehmens überzeugt werden.
Ziel
62Prof. Dr. Stephan KleukerOOAD WiSe 10
Ziele für eine Projektmanagementsoftware (3/3)
Eine Analyse der Konkurrenten auf dem Markt liegt vor. Es sind Möglichkeiten für neue, den Markt interessierende Funktionalitäten aufgezeigt worden.
Sonstiges
zu Ziel 2 (Beschreibung dort)Abhängigkeiten
-Randbedingungen
Management: Es soll eine Marktposition auf dem Marktsegment Projektmanagement-Software aufgebaut werden.Vertrieb: In Gesprächen mit Kunden wird das neue Produkt und seine Integrationsmöglichkeit mit anderen Produkten ab Projektstart beworben.Entwickler: Die Software muss modular aufgebaut aus Software-Komponenten mit klaren Schnittstellen bestehen.
Auswirkungen auf Stakeholder
Management, Vertrieb, EntwicklerStakeholder
3. Das neue Produkt soll für einen größeren Markt einsetzbar sein.
Ziel
63Prof. Dr. Stephan KleukerOOAD WiSe 10
Rahmenbedingungen und weiteres Vorgehen
Traceability:• alle Anforderungen müssen sich auf ein Ziel
zurückführen lassen • alle Ziele benötigen einen Stakeholder (Ökonomie-
Check)Kommunikation:• die ausgewählten Stakeholder müssen nun
detaillierter befragt und dauerhaft in das Projekt integriert werden
Warum der ganze Aufwand:• Vergessene Ziele und Stakeholder führen zu
massiven Change Requests
Das eigentliche SW-Projekt kann beginnen64Prof. Dr. Stephan KleukerOOAD WiSe 10
Überblick über den Analyseprozess
1. Erfassung der Systemaufgaben mit „Use Cases“
2. Beschreibung der Aufgaben mit Aktivitätsdiagrammen
(optional 3. Formalisierung der Beschreibungen in Anforderungen)
4. Aufbau eines tieferen Verständnisses durch Klassenmodellierung und
Sequenzdiagramme (Grobdesign)
iterativer Prozess
4.2
65Prof. Dr. Stephan KleukerOOAD WiSe 10
Erfragung des WAS?
• Zentrale Frage: Was sind die Hauptaufgaben des Systems?
• Wer ist an den Aufgaben beteiligt?
• Welche Schritte gehören zur Aufgabenerfüllung?
=> Aufgaben werden als Use Cases (Anwendungsfälle) beschrieben=> Beteiligte werden als Aktoren festgehalten (können meist aus der Menge der Stakeholder entnommen werden)
66Prof. Dr. Stephan KleukerOOAD WiSe 10
Use Case (Anwendungsfall)
• Use Case beschreibt in der Sprache der Stakeholder, d.h. in natürlicher Sprache, eine konsistente und zielgerichte te Interaktion des Benutzers mit einem System, an deren Anfang ein fachlicher Auslöser steht und an deren Ende ein de finiertes Ergebnis von fachlichem Wert entstanden ist
• Ein Use Case beschreibt das gewünschte externe Systemverhalten aus Sicht des Anwenders und somit Anforderungen, die das System erfüllen soll
• eine Beschreibung was es leisten muss, aber nicht wi e es dies leisten soll
• Unterscheidung in Geschäftsanwendungsfall (business use case) formuliert aus Geschäftssicht (z. B. Vertriebsp rozess vom Anfang) und Systemanwendungsfall (system use case) formuliert aus Sicht der durch die neue SW zu lösenden Aufgabe
67Prof. Dr. Stephan KleukerOOAD WiSe 10
Business Use Case [OW]
2.1.8 Geschäftsanwendungsfall• Verwandte Begriffe: engl. business use Case, Geschäftsfall. Definition• Ein Geschäftsanwendungsfall beschreibt einen geschäftl ichen
Ablauf, wird von einem geschäftlichen Ereignis ausgel öst und endet mit einem Ergebnis, das für den Unternehmenszwe ck und die Gewinnerzielungsabsicht direkt oder indirekt e inen geschäftlichen Wert darstellt.
Beschreibung• Bei einem Geschäftsanwendungsfall wird die Frage nac h der
möglichen systemtechnischen Umsetzung noch nicht ge stellt, sondern völlig unabhängig davon ganz allgemein aus geschäftlicher Sicht beschrieben.
• Beispiel: Business Use Case „Angebotserstellung“
68Prof. Dr. Stephan KleukerOOAD WiSe 10
System Use Case [OW]
2.1.9 Systemanwendungsfall• Verwandte Begriffe: engl. System use caseDefinition• Ein Systemanwendungsfall ist ein Anwendungsfall, der speziell
das für außen stehende Akteure (Benutzer oder Nachbarsysteme) wahrnehmbare Verhalten eines (Hard-/Software-) Systems beschreibt.
Beschreibung• Aus UML- und Softwareentwicklungssicht ist der
Systemanwendungsfall die normale Form eines Anwendungsfalles. In Abgrenzung zu den verschiedenen Arten von Geschäftsanwendungsfällen beschreibt ein Systemanwendungsfall konkret das Verhalten bzw. den Arbeitsablauf, wie er durch ein System (z.B. Software ) unterstützt wird. Dabei wird das äußerlich wahrnehmba re Verhalten beschrieben, also was das System macht, abe r nicht wie es dies tut.
69Prof. Dr. Stephan KleukerOOAD WiSe 10
Zusammenhang der Use Case Arten
• Für ein neu geplantes SW-System wird zunächst analysi ert, welche Prozesse mit der SW unterstützt werden sollen (Geschäftsprozessmodellierung)
• Oft geht mit dieser Modellierung auch eine Optimierung einher• Man erhält zentrale Aufgaben, die das SW-System übern ehmen
soll (Business Use Case)• Ausgehend davon werden die Aufgaben geplant, die das SW-
System unterstützen/ausführen soll, dies sind die Sys tem Use Cases
• Häufig gehört zu einem Business Use Case ein System Use Case, d. h. es gibt die gleiche Überschrift, aber ein e unterschiedliche Beschreibung (im System Use Case s teht die Nutzung des neues SW-Systems im Mittelpunkt)
• Es kann weitere System Use Cases geben, die z. B. di e Systemwartung oder neue Analysemöglichkeiten betreffe n
70Prof. Dr. Stephan KleukerOOAD WiSe 10
Wege zur Use Case-Ermittlung
• moderierter Workshop zentraler Stakeholder• Beobachtung des Kunden, der Endnutzer• Fragebögen• Interviews• Kunde vor Ort im Projekt• Analyse von Altsystemen und Dokumenten des
Kunden• Simulationsmodelle
71Prof. Dr. Stephan KleukerOOAD WiSe 10
Darstellungsbeispiel: Lagerverwaltungssystem
Externe Sicht des Nutzers auf die Aufgaben des Systems
Aktoren können Personen oder andere Systeme sein
Use Cases können in Teilpaketen strukturiert werden
72Prof. Dr. Stephan KleukerOOAD WiSe 10
Systematische Use-Case Ermittlung (1/2)
1. Welche Basisinformationen / Objekte sind zu bearbei ten (keine Detailmodellierung, keine Informationen, die aus ande ren berechenbar sind)?Beispiel (Projektmanagementsystem): Projekte, Mitarbei terPrüfe ob neues System Basisinformationen verwaltet o der Sie
aus existierenden Systemen stammenneues System: Use Case „Basisinformation XY verwalt en“
gefunden (evtl. in „anlegen“, „bearbeiten“, „löschen “trennen)
existierendes System: tritt als Aktor auf, wenn Daten benötigt2. Welche Prozessinformationen sind zu verwalten, also
dynamisch entstehende Daten, Daten zur Verknüpfung vo n BasisinformationenBeispiel: Projektteams, Arbeitsstunden der Mitarbeiter Ergänze Use Cases, die die Verknüpfung der Daten herste llen, z. B. „Projektteams zusammenstellen“, „Arbeitsstand aktualisieren“
73Prof. Dr. Stephan KleukerOOAD WiSe 10
Systematische Use-Case Ermittlung (2/2)
3. Ermittle Funktionalität, die auf Basis der Verarbeitu ng von Basis- und Prozessinformationen benötigt wirdabstrakte Beispiele: Entscheidungsprozesse/ Analyseprozesse zur Auswertung (Statistiken, Übersich ten)Ergänze Use Case für jede der Prozessarten (Art bedeutet , Zusammenfassung eng verwandter Funktionalität)Beispiel: „Projektstand analysieren“
4. Ermittle Use Cases zur reinen Systempflege insofern e s besondere Herausforderungen gibtabstrakte Beispiele: langfristige Datenhaltung, Syste mstart, Systemterminierung
Zeichne Use Case-Diagramm und ergänze Aktoren (z. B. Stakeholder, genutzte Systeme, Time) und Dokumentati on
74Prof. Dr. Stephan KleukerOOAD WiSe 10
Abgeleitetes Use Case-Diagramm
75Prof. Dr. Stephan KleukerOOAD WiSe 10
Use Case-Erstellung genauer
• Beschreibung eines Use Cases– zunächst verbal– relativ abstrakt, wird später verfeinert
• Leitfragen für die Ermittlung von Akteuren und Prozesse n– Welcher Akteur löst Use Case aus?– Welche Akteure sind am Use Case beteiligt?– Welche Aufgaben sind im Use Case zu erfüllen?– Wer ist verantwortlich für Planung, Durchführung, Kontro lle
der Aufgaben?– Welche Ereignisse starten den Use Case, treten im Use Case
auf?– Welche Bedingungen sind zu beachten?– Was sind die Ergebnisse des Use Cases?– Welche Beziehungen gibt es zu welchen anderen Use Ca ses?
76Prof. Dr. Stephan KleukerOOAD WiSe 10
Verfeinerung der Use Case-Dokumentation
• Im ersten Schritt werden in den Use Cases nur die Hauptaufgaben des Systems beschrieben
• Zur Dokumentation der Use Cases gehört zunächst nur eine grobe kurze Beschreibung (maximal 5 Sätze) des Inhalts
• Im nächsten Schritt wird dieser Inhalt konkretisier t. Dabei ist es sinnvoll, auf eine Dokumentationsschablone zurück zu greifen (oder eine für das Projekt zu entwickeln)
• Im ersten Schritt der Beschreibungsentwicklung wird nur der typische Ablauf des Use Cases ohne Alternativen, dann mit Alternativen beschrieben
4.3
77Prof. Dr. Stephan KleukerOOAD WiSe 10
Dokumentationsschablone für Use Cases (1/3)
welche Aktoren sind beteiligt, wer stößt den Use Case an
1beteiligte Aktoren (Stakeholder)
kurze Beschreibung, was mit dem Use Case auf welchem Weg erreicht werden soll,
1Kurzbeschrei-bung
aktuelle Versionsnummer, möglichst mit Änderungshistorie, wer hat wann was geändert
1Version
wer hat den Use Case erstellt und wer mitgearbeitet
1Autor
bei sehr komplexen Systemen können Use Cases in Teilaufgabenbereiche zusammengefasst werden, diese Bereiche können in der UML als Pakete dargestellt werden
2Paket
eindeutige Nummer zur Verwaltung, sollte von der eingesetzten Entwicklungsumgebung vergeben werden
1Nummer
kurze prägnante Beschreibung, meist aus Verb und Nomen
1Name des Use Case
78Prof. Dr. Stephan KleukerOOAD WiSe 10
Dokumentationsschablone für Use Cases (2/3)
welche Alternativen existieren zum typischen Ablauf
3alternative Abläufe
welche einzelnen Schritte werden im Use Case durchlaufen, dabei wird nur der gewünschte typische Ablauf dokumentiert
2typischer Ablauf
wie sieht das mögliche Ergebnis aus, im nächsten Schritt sind auch die Ergebnisse alternativer Abläufe zu berücksichtigen
2Nachbedin-gungen
was muss erfüllt sein, damit der Use Case starten kann
2Vorbedingun-gen
Nennung aller Informationen, die bei der späteren Ausimplementierung zu beachten beziehungsweise hilfreich sind, dies können Verweise auf Gesetze, Normen oder Dokumentationen existierender Systeme sein
2Referenzen
wer steht auf fachlicher Seite für Fragen zum Use Case zur Verfügung und entscheidet auf Auftraggeberseite für die Software über den Inhalt
1Fachverant-wortlicher
79Prof. Dr. Stephan KleukerOOAD WiSe 10
Dokumentationsschablone für Use Cases (3/3)
welche konkreten nicht-funktionalen Anforderungen werden aus diesem Use Case abgeleitet
4nicht-funktionale Anforderungen
welche konkreten funktionalen Anforderungen werden aus diesem Use Case abgeleitet
4funktionale Anforderungen
welche Zusammenhänge bestehen zu anderen Use Cases
3Verknüpfungen
wie wichtig ist diese Funktionalität für das Gesamtsystem
3Kritikalität
• Nummer gibt Iteration an, in der das Feld gefüllt wird• typischer und alternative Abläufe werden jetzt genaue r
betrachtet• funktionale und nicht-funktionale Anforderungen weite r
hinten in diesem Abschnitt
80Prof. Dr. Stephan KleukerOOAD WiSe 10
Beispielbeschreibung (1/2)
Handbuch zur Führung von Projekten des KundenReferenzen
Lisa Leitung (zentrale Ansprechpartnerin des Kunden )Fachverant-wortlicher
Projektbüro (startet Use Case durch Auswahl der Funktionalität im zu erstellenden System)
beteiligte Aktoren(Stakeholder)
Mitarbeiter des Projektbüros haben die Möglichkeit, Projekte mit Teilprojekten anzulegen und zu bearbeiten.
Kurzbeschrei-bung
1.0, 30.01.2008, ErstellungVersion
Ali AnalytikerAutor
-Paket
U1Nummer
Projektstruktur bearbeitenName des Use Case
81Prof. Dr. Stephan KleukerOOAD WiSe 10
Beispielbeschreibung (2/2)
sehr hoch, System macht ohne Funktionalität keinen Sinn
Kritikalität
Nutzer kann existierendes Projekt auswählen,Nutzer kann Daten eines Teilprojekts ändern
alternative Abläufe
1. Nutzer wählt Funktionalität zur Bearbeitung von Projektstrukturen2. Nutzer legt Projekt mit Projektstandarddaten an3. Nutzer ergänzt neue Teilprojekte4. Nutzer verlässt Funktionalität
typischer Ablauf
Neue Projekte und Teilprojekte sowie Änderungen von Projekten und Teilprojekten wurden vom System übernommen.
Nachbedingun-gen
Die Software ist vollständig installiert und wurde gestartet.
Vorbedingun-gen
82Prof. Dr. Stephan KleukerOOAD WiSe 10
Hinweise zu Use Cases (1/2)
• Verwende für den Use Case eine sinnvolle Bezeichnung, die mindestens aus einem echten Substantiv und einem aktiven Verb ("Antrag erfassen") oder dem zugehörigen Gerundium ("Antragserfassung") besteht!
• Definiere zuerst den fachlichen Auslöser und das fachliche Ergebnis, um Anfang und Ende des Use Cases festzulegen!
• Formuliere den Use Case so abstrakt wie möglich und so konkret wie nötig!
• Betreibe zunächst keine Zerlegung in abgeleitete, sekundäre Use Cases!
• Standardisiere die Sprache in den Use Cases!
83Prof. Dr. Stephan KleukerOOAD WiSe 10
Hinweise zu Use Cases (2/2)
• Use Cases eignen sich nicht zur funktionalen Zerlegung, d.h. ein Use Case beschreibt keine einzelnen Schritte, Operationen oder Transaktionen (bspw. "Vertrag drucken", "Kunden-Nr. erzeugen" etc.), sondern relativ große Abläufe (bspw. "Neuen Kunden aufnehmen")
• Es wird keine Ablaufreihenfolge definiert. Hierzu g ibt es andere Ausdrucksmittel, z.B. Aktivitätsdiagramme
• Use Cases belassen das Sprachmonopol beim Stakeholder, wodurch die Use Cases angreifbarer und besser kritisierbar werden
84Prof. Dr. Stephan KleukerOOAD WiSe 10
Analyse von Use-Case-Dokumentationen
• Bei der Dokumentation von Use Cases kann es passieren, dass identische Abläufe mehrfach beschrieben werden
• Diese (nicht trivialen) Abläufe können als eigene U se Cases ausgegliedert werden; man sagt dann „ein Use Case nutzt einen anderen Use Case“
• UML-Darstellung:
• In spitzen <<Klammern>> stehen so genannte Steoreotypen, mit denen man UML-Elementenzusätzliche Eigenschaften zuordnen kann
A B<<include>>
85Prof. Dr. Stephan KleukerOOAD WiSe 10
Beispiel zu <<include>>
86Prof. Dr. Stephan KleukerOOAD WiSe 10
<<extend>>
• Seltene Variation des erweiterten Use Cases• Wird nur unter bestimmter Bedingung ausgeführt, z. B.
Sonderfall oder Fehlerbehandlung • eigentlicher Use Case nicht durch Spezialfälle überf rachtet
87Prof. Dr. Stephan KleukerOOAD WiSe 10
Hinweis zu <<include>>, <<extend>> (persönlich)
• <<include>> ist ein sehr nützlicher Stereotyp, der die Dokumentation verkürzen kann
• Gerade bei in der Modellierung unerfahrenen Kunden sollte <<include>> zunächst verheimlicht werden, da sonst funktionale Zerlegungen in Bäumen das Ergebnis sind
• <<include>> wird dann bei der Dokumentation und späteren Verfeinerung bei der Umstrukturierung der Use Cases als Optimierung eingesetzt
• Hinweis: <<extend>> und weitere nicht erwähnte Möglichkeiten werden hier ignoriert, da es Kunden eher verwirrt
88Prof. Dr. Stephan KleukerOOAD WiSe 10
Beschreibung verschiedener Abläufe
• Bei Projekten mit enger Kundenbindung (z.B. bei engen Beziehungen zwischen AG und IT-Abteilung bei Inhouse-Projekten) können Use Cases (oder Nutzer Stories) als Anforderungsdokumentation ausreichen, wenn das Projekt in kleinen Iterationen und der Möglichkeit eines großen Kundeneinflusses entwickelt wird
• Oftmals ist die Beschreibung der Use Cases aber zu ungenau, gerade bei der Darstellung typischer und Alternativer Abläufe stellt sich die rein sprachlic he Beschreibung als recht aufwändig heraus
• Da die UML eine graphische Sprache ist, stellt sie auch für Ablaufbeschreibungen eine grafische Darstellungsmöglichkeit, nämlich Aktivitätsdiagramme, zur Verfügung
89Prof. Dr. Stephan KleukerOOAD WiSe 10
Modellierungsrichtlinie für Aktivitätsdiagramme
Modelliere zu jedem Use Case genau ein Aktivitätsdia gramm• Mache aus den Use Case-Schritten Aktionen• Zerlege die Aktionen ggfls. mit einem Aktivitätsdiag ramm, so
dass sie stets genau einen fachlichen Arbeitsschritt repräsentieren
• Ergänze den Ablauf um alle bekannten fachlichen Ausn ahmen, fachlichen Fehler und fachlichen Ablaufvarianten, so dass das Diagramm eine vollständige Beschreibung aller zulässig en Ablaufmöglichkeiten darstellt
(sinnvoll jetzt oder später) Modelliere den Objektflus s:• Beschreibe zu jeder Aktion die vorausgesetzten (zu
verarbeitenden) und resultierenden (erzeugten oder veränderten) Geschäftsobjekte (Produkte).
• Unterscheide, bei welchen ausgehenden Transitionen bz w. Bedingungen welche Objekte bzw. Objektzustände result ieren.
90Prof. Dr. Stephan KleukerOOAD WiSe 10
Aktivitätsdiagramm mit typischen Ablauf
Anmerkung: typischer Ablauf ist immer einfache Sequenz von Aktionen, Ausnahme wie hier: einfache Schleifen
Use Case: Projektstruktur bearbeiten
91Prof. Dr. Stephan KleukerOOAD WiSe 10
Aktivitätsdiagramm um Alternativen ergänzt
92Prof. Dr. Stephan KleukerOOAD WiSe 10
Erinnerung: Modellierung aus Business-Sicht
93Prof. Dr. Stephan KleukerOOAD WiSe 10
Modellierung aus System-Sicht
94Prof. Dr. Stephan KleukerOOAD WiSe 10
Formulierung von Anforderungen
• Analog zu den Use Cases sind die Aktivitätsdiagramme zu dokumentieren, dabei ist genau zu beschreiben, was u nter Nutzung welcher Hilfsmittel unter Berücksichtigung we lcher Nebenbedingungen gilt
• Die Beschreibungen können oft unvollständig oder unkl ar formuliert sein, so dass es in größeren oder kritischere n Projekten sinnvoll ist, die Texte genauer zu analysie ren
• Statt einer Fließtextdokumentation von Aktivitätsdi agrammen, kann eine Darstellung von systematisch abgeleiteten textuellen Anforderungen sinnvoll sein
• Man benötigt einen Ansatz, Texte möglichst präzise zu formulieren
4.4
95Prof. Dr. Stephan KleukerOOAD WiSe 10
Sprache als Darstellungsmittel
Formulierte Anforderungen• sind in natürlicher Sprache verfasst• gewissen Prozessen bei der Entstehung unterworfenEntstehungsprozesse• verändern/verfälschen die beabsichtigte Bedeutung ei ner
Anforderung• hat jeder Mensch,
sind regelgeleitet
96Prof. Dr. Stephan KleukerOOAD WiSe 10
Probleme mit natürlich-sprachlichen Formulierungen
• Auslassungen bzw. implizite Annahmen, da etwas für Experten „offensichtlich“ ist
• Tilgung• Generalisierung• Nominalisierung
• In Prosatexten sind Wiederholungen unerwünscht; bei Anforderungen müssen immer die gleichen Worte für den gleichen Sachverhalt genutzt werden
97Prof. Dr. Stephan KleukerOOAD WiSe 10
Definition: Tilgung
• Tilgung ist ein Prozess, durch den wir unsere Aufmerksamkeit selektiv bestimmten Dimensionen unserer Erfahrungen zuwenden und andere ausschließen. (Bandler/Grindler)
• Beispiel: Die Fähigkeit des Menschen, In einem Raum voller sprechender Menschen alle anderen Geräusche auszuschließen oder auszufiltern, um der Stimme einer bestimmten Person zuzuhören.
98Prof. Dr. Stephan KleukerOOAD WiSe 10
Beispiele für Tilgungen (1/2)
• Grundstruktur: Manche Prozessworte (Verben und Prädikate) implizieren zwei oder mehr Substantivargumente
• Sprachliche Vertreter– Eingeben: Wer? Was? Wie? Wo? Wann?– Anzeigen: Was? Wo? In welcher Weise? Wann?– Übertragen: Wer? Was? Von wo? Wohin? Wann?– „Die Auszahlungsmöglichkeit soll überprüft und
die Auszahlung verbucht werden“– Überprüfen: Wer überprüft? Was wird überprüft?
Nach welchen Regeln wird überprüft? Wann wird überprüft? Wie?
– Verbuchen: Wer verbucht? Was wird verbucht? Wann wird es verbucht? Wie?
99Prof. Dr. Stephan KleukerOOAD WiSe 10
Beispiele für Tilgungen (2/2)
• Grundstruktur: Der Bezugspunkt. die Messbarkeit und die Messgenauigkeit für einen Komparativ oder Superlativ fe hlt.
• Sprachliche Vertreter: Adjektiv + Endung "-er/en", "-s te" oder "more", "less", "least", oder "weniger", "mehr"
• In beiden Sprachen: Adjektive wie leicht, easy, schw er, complicated, ...
• Für durchschnittlich große Menschen soll das Display i m normalen Bedienabstand gut lesbar sein.
• Die Eingabe des angeforderten Geldbetrages soll vom S ystem durch eine intuitive Benutzerführung so unterstützt we rden, dass Fehleingaben minimiert werden.– Kann man den Sachverhalt überhaupt messen?– Ist der Bezugspunkt des Vergleiches angegeben?– Mit welcher Messgenauigkeit wird gemessen?
100Prof. Dr. Stephan KleukerOOAD WiSe 10
Definition: Generalisierung
• Generalisierung ist der Prozess, durch den Elemente oder Teile eines persönlichen Modells von der ursprünglichen Erfahrung abgelöst werden, um dann die gesamte Kategorie, von der diese Erfahrung ein Beispiel darstellt, zu verkörpern. (Bendler/Grindle r)
• Beispiel: Ein Kind verbrennt sich an einer heißen Herdplatte die Hand. Es sollte für sich die richtig e Generalisierung aufstellen, dass es schmerzhaft ist auf heiße Herdplatten zu fassen.
101Prof. Dr. Stephan KleukerOOAD WiSe 10
Generalisierung durch Universalquantoren
Universalquantoren• Grundstruktur: Menge an Objekten wird
zusammengefasst• Sprachliche Vertreter:
– Im Deutschen: nie, immer, kein, jeder, alle, ...– Im Englischen: never, ever, not, each, always, ...
• Frage:– Wirklich alle/jede, immer/nie? Gibt es keine
Ausnahme?– Achtung! Auch Sätze ohne Universalquantoren
überprüfen, die keine Angaben über die Häufigkeit enthalten!
102Prof. Dr. Stephan KleukerOOAD WiSe 10
Beispiele für Generalisierungen
• Jede Auszahlung soll für die Rückverfolgbarkeit zusätzlich mit einem Zeitstempel etikettiert werden .– Wirklich jede Auszahlung?
• Das System soll eine Sicherung von aufgezeichneten Auszahlungsdaten auf ein externes Speichermedium ermöglichen.– Durch jede Person? Immer? Aller
Auszahlungsdaten? –
• Fragen über Fragen....
103Prof. Dr. Stephan KleukerOOAD WiSe 10
Verzerrung durch Nominalisierung
• Grundstruktur: Ein Prozesswort (Verb oder Prädikat) wird zu einem Ereigniswort (Substantiv oder Argument) umgeform t.
• Dadurch wird ein Vorgang zu einem Ereignis und viele vorgangsrelevante Informationen gehen verloren.
• Es ist möglich, dass sich die Bedeutung der Aussage dadurch ändert.– Die Berechtigung für die Administration des Geldautomat en– Die Auszahlung wird nach der Buchung durchgeführt
– Wer? zahlt wann? Wem? Was? Unter Einhaltung welcher Regeln? Mit welcher Zuverlässigkeit? Mit welcher Verfügbarkeit?
– Wer? bucht wann? Was? Wohin? Unter Einhaltung welcher Regeln? Mit welcher Zuverlässigkeit? Mit welcher Verfügbarkeit?
104Prof. Dr. Stephan KleukerOOAD WiSe 10
Erkennen von Nominalisierungen
Fragen/Vorgehen:• Intuition, Sprachgefühl• Suche nach ähnlichem Prozesswort• Sprachtest durch Einsetzen in "ein(e) andauernde(r) ".
Wahre Substantive passen nicht in wohlgeformter Weis e in diese Aussage
Beispiele:• Bei der Auswahl der Auszahlungsfunktion soll die …• Es soll eine Darstellung der xy-Funktionen inkl. aller Systeme
möglich sein.• der Anzeige, Benutzerführung, Bestätigung, ....• die Eingabe, Erfassung, ....• das Ereignis, die Meldung, ...• die Buchung, Ausgabe, Prüfung, ....
105Prof. Dr. Stephan KleukerOOAD WiSe 10
Entwicklung strukturierter Anforderungen
• ein Ansatz zu qualitativ hochwertigen Anforderungen: erste Version erstellen und dann Textqualität schrittweise verbessern
• Alternative: „von Anfang an“ hochwertige Anforderungen zu schreiben
• Dieser Ansatz kann durch Anforderungsschablonen unterstützt werden, die den Satzbau von Anforderungen vorgeben (vorgestellter Ansatz folgt [RS])
• Man beachte, bereits erwähnte Ausdrucksprobleme auch in diesem Ansatz noch relevant
106Prof. Dr. Stephan KleukerOOAD WiSe 10
Charakterisierung von Systemaktivitäten
• Selbständige Systemaktivität:Das System führt den Prozess selbständig durch.
• Benutzerinteraktion:Das System stellt dem Nutzer die Prozessfunktionalität zur Verfügung .
• Schnittstellenanforderung:Das System führt einen Prozess in Abhängigkeit von einem Dritten (zum Beispiel einem Fremdsystem) aus, ist an sich passiv und wartet auf ein externes Ereignis.
• Für jede dieser Systemaktivitäten gibt es eine Schablone.
• Frage: Werden Systemaktivitäten so in disjunkteKlassen aufgeteilt?
107Prof. Dr. Stephan KleukerOOAD WiSe 10
Visualisierung der Systemaktivitäten
Nutzer
Typ 2 Anforderungen:Funktionalität zur Verfügung stellen
Typ 1 Anforderungen:System führt Prozess aus
System-Kern
Schnittstelle
stößt an
externer Prozess
stößt an
Typ 3 Anforderungen:System fähig, externeAnfrage zu bearbeiten
ruft auf
machtEingaben
zu entwickelndes S
ystem
108Prof. Dr. Stephan KleukerOOAD WiSe 10
Anforderungsformulierung
<Wann?><Randbe-dingung>
muss
soll
wird
das System
-
<wem?> dieMöglichkeitbieten
fähig sein
<Objekt mitRandbedin-gung>
<Prozess-wort>
Typ 1
Typ 3
Typ 2
Typ 1: Selbständige Systemaktivität, System führt Pro zess selbständig durch, z. B. Berechnung des bisherigen Auf wandes eines Projekts durch Abfrage aller Teilprojekte und Erge bnisanzeigeTyp 2: Benutzerinteraktion, System stellt Nutzer die Prozessfunktionalität zur Verfügung, z: B. Verfügbarke it eines Eingabefeldes, um den Projektdaten einzugebenTyp 3: Schnittstellenanforderung, d. h. das System fü hrt einen Prozess in Abhängigkeit von einem Dritten (zum Beispi el einem Fremdsystem) aus, ist an sich passiv und wartet auf ein externesEreignis, z. B. Anfrage einer anderen Bürosoftware nach e iner Übersicht über die laufenden Projekte annehmen
109Prof. Dr. Stephan KleukerOOAD WiSe 10
Typ 1: Selbständige Systemaktivität
<Wann?><Randbe-dingung>
muss
soll
wird
das System
-
<wem?> dieMöglichkeitbieten
fähig sein
<Objekt mitRandbedin-gung>
<Prozess-wort>
Typ 1
Typ 3
Typ 2
Nach Abschluss der Eingabe (mit „Return“-Taste oder Bestätigungsknopf) bei der Bearbeitung von Daten muss das System neu eingegebene Daten in seine permanente Dat enhaltung übernehmen. [„Daten“ muss konkretisiert werden]
Nach der Eingabe eines neuen Teilprojekts oder einer n euen Projektaufgabe und nach der Aktualisierung des Aufwand es eines Teilprojekts oder einer neuen Projektaufgabe muss das S ystem die Aufwandsangaben auf Plausibilität prüfen.
110Prof. Dr. Stephan KleukerOOAD WiSe 10
Typ 2: Benutzerinteraktion
<Wann?><Randbe-dingung>
muss
soll
wird
das System
-
<wem?> dieMöglichkeitbieten
fähig sein
<Objekt mitRandbedin-gung>
<Prozess-wort>
Typ 1
Typ 3
Typ 2
In der Projektbearbeitung muss das System dem Nutzer di e Möglichkeit bieten, ein neues Projekt mit Projektausg angsdaten anzulegen.
In der Projektbearbeitung muss das System dem Nutzer di e Möglichkeit bieten, jedes Projekt auszuwählen.
Nach der Projektauswahl muss das System dem Nutzer d ie Möglichkeit bieten, für existierende Projekte neue Te ilprojekte anzulegen.
111Prof. Dr. Stephan KleukerOOAD WiSe 10
Typ 3: Schnittstellenanforderung
<Wann?><Randbe-dingung>
muss
soll
wird
das System
-
<wem?> dieMöglichkeitbieten
fähig sein
<Objekt mitRandbedin-gung>
<Prozess-wort>
Typ 1
Typ 3
Typ 2
Nach der Kontaktaufnahme durch die Software „Globalvie w“ muss das System fähig sein, Anfragen nach den Projektnamen , deren Gesamtaufwänden und Fertigstellungsgraden zu beantwort en.
112Prof. Dr. Stephan KleukerOOAD WiSe 10
Vom Aktivitätsdiagramm zur textuellen Anforderung
• Jede Aktion wird mit einer Anforderung oder mehreren Anforderungen beschrieben
• Jede Transition und Entscheidung wird mit einer Anforderung oder mehreren Anforderungen beschrieben
• Aus dem Ablauf der zur Aktion, Transition oder Entscheidung führt, wird der erste Teil der jeweili gen Anforderung („Wann?“) erzeugt.
• Hinweis: Anforderungen zum Beispiel stehen im folgenden Kapitel
113Prof. Dr. Stephan KleukerOOAD WiSe 10
Beispielübersetzung
114Prof. Dr. Stephan KleukerOOAD WiSe 10
Nicht-funktionale Anforderungen (1/2) [sehr kurz]
• Bisher lag der Schwerpunkt auf funktionalen Anforderunge n „was muss das System machen“
• SW unterliegt unterschiedlichen nicht-funktionalen Anforderungen, die maßgeblich für den Projekterfolg sei n können
Hier wird eine Charakterisierung vorgestellt:• technische Anforderungen: Hardwareanforderungen,
Architekturanforderungen, Anforderungen an die Programmiersprachen
• Anforderungen an die Benutzungsschnittstelle : Form und Funktion von Ein- und Ausgabe-Geräten
• Anforderungen an die Dienstqualität: DIN EN ISO 66272 unterteilt die Dienstgüte in die fünf Merkmale Zuverl ässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragba rkeit
4.5
115Prof. Dr. Stephan KleukerOOAD WiSe 10
Nicht-Funktionale Anforderungen (2/2)
• Anforderungen an sonstige Lieferbestandteile: Selten besteht das System nur aus einem Stück kompilierten Programmcodes, es werden Zusatzlieferungen, wie Systemhandbücher und Installationshandbücher gefordert
• Anforderungen an die Durchführung der Entwicklung und Einführung: z. B. Anforderungen an die Vorgehensweise (Software-Erstellung, Software-Prüfung), anzuwenden de Standards, Hilfsmittel (Tools), die Durchführung von Besprechungen, von Abnahmetests (fachliche Abnahme, betriebliche Abnahme) und die Festlegung von Termine n
• rechtlich-vertraglichen Anforderungen : z. B. Angaben zu Zahlungsmeilensteinen, Vertragsstrafen, dem Umgang m it Änderungen der Anforderungen, Eskalationspfade
116Prof. Dr. Stephan KleukerOOAD WiSe 10
Lastenheft / Pflichtenheft
• Struktur0. Administrative Daten: von wem, wann genehmigt, . ..1. Zielbestimmung und Zielgruppen
In welcher Umgebung soll das System eingesetzt werd en?Was soll das System lösen, welche Stakeholder betroff en?
2. Funktionale AnforderungenProduktfunktionen (Use Cases, Aktivitätsd., Anforderun gen)Produktschnittstellen (a.GUI-Konzept b. andere SW)
3. Nichtfunktionale AnforderungenQualitätsanforderungenweitere technische Anforderungen
4. Lieferumfang5. Abnahmekriterien6. Anhänge (insbesondere Glossar)
• Alternativ / zusätzlich kann der Auftragnehmer ein Pfl ichtenheft schreiben, detaillierter als Lastenheft
• Lasten- oder Pflichtenheft ist zentraler Vertragsbesta ndteil
4.6