le 5: richtigkeit praktikum softwaretechnik … · lastenheft vs. pflichtenheft funktional vs....
Post on 17-Sep-2018
215 Views
Preview:
TRANSCRIPT
Stephan Salinger 1/52
LE 5: Richtigkeit
Softwareanforderungen
Praktikum Softwaretechnik Sommersemester 2004
Stephan Salinger 2/52
Softwareanforderungen
Quellen
1. Ian Sommerville: Software Engineering, 6. Auflage, Pearson Education Deutschland GmbH
2. Helmuth Balzert: Lehrbuch der Software-Technik –Software-Entwicklung, 2. Auflage, Spektrum Akademischer Verlag Heidelberg Berlin
Stephan Salinger 3/52
Softwareanforderungen
Inhalt
1. Anforderungen und ihre Beschreibung (Darstellung der Dienste und Einschränkungen)
Benutzeranforderungen vs. SystemanforderungenLastenheft vs. PflichtenheftFunktional vs. nichtfunktionale AnforderungenBeispielstruktur LastenheftBeispielstruktur Pflichtenheft
2. AnforderungsanalyseProzess des Herausfindens, Analysierens und Überprüfens der Dienste und Einschränkungen
Stephan Salinger 4/52
Spezifikationsarten Anforderung: Teil 1
• Kunde beschreibt in einem Lastenheft die Erfordernisse an ein Softwareentwicklungsprojekt
Wir nennen die Inhalte des Lastenheftes Benutzeranforderungen (fachliche Anforderungen):• Aussagen in natürlicher Sprache• Evtl. Verwendung von Diagrammen (zur Beschreibung der
Dienste)• Angabe von Randbedingungen, unter denen das System
betrieben wirdVerwendung eines hohen AbstraktionsniveausDer Lösung nicht vorgreifen. Im Lastenheft wird definiert, WAS WOFÜR zu lösen ist und nicht, WIE die Leistungen zu erbringen sind.Achtung: Es kann sein, dass kein konkreter Kunde existiert (Produktentwicklung)
Stephan Salinger 5/52
Spezifikationsarten Anforderung: Teil 2
• Auftragnehmer stellt in einem Pflichtenheft (funktionale Spezifikation) eine genaue Systemdefinition für den Kunden auf• Wir nennen die Inhalte des Pflichtenheftes
Systemanforderungen:• Legen Dienste und Beschränkungen detailliert fest
• Kunde muss verstehen was das System tun wird• Soll als Basis für die Spezifikation des Softwareentwurfs
verwendet werden• Eine Benutzeranforderung kann sich zu mehreren
Systemanforderungen erweitern• Im Pflichtenheft wird definiert, WIE und WOMIT die
Anforderungen zu realisieren sind.• Achtung: Oft wird die Zusammenführung der Dokumente
mit den Benutzer- und Systemanforderungen als Pflichtenheft bezeichnet.
Stephan Salinger 6/52
Spezifikationsarten: alternative Definitionen 1
• Helmut Balzert: Lehrbuch der Softwaretechnik„Das fachliche Dokument der der Planungsphase wird oft als Lastenheft oder grobes Pflichtenheft bezeichnet, ergänzt um ein Glossar“„Die detaillierte verbale Beschreibung der Anforderungen an ein neues Produkt wird oft als Pflichtenheftbezeichnet“„Das Pflichtenheft enthält eine Zusammenfassung aller fachlichen Anforderungen, die das zu entwickelnde Software-Produkt aus Sicht des Auftraggebers erfüllen muss. … Außerdem werden Entwicklungsprioritäten aus Auftraggebersicht festgelegt. … Die Inhalte stellen eine Konkretisierung und Detaillierung der Lastenheft-Inhalte dar. Das Lastenheft kann daher als Ausgangsdokument für das Pflichtenheft verwendet werden.“
Stephan Salinger 7/52
Spezifikationsarten: alternative Definitionen 2
• DIN 69905Das Lastenheft wird vom Auftraggeber erstellt. Es enthält es die • "Gesamtheit der Forderungen an die Lieferungen und
Leistungen eines Auftragnehmers". Gleichzeitig dient das Lastenheft auch als • Grundlage zur Einholung von Angeboten.
Konkret umfasst ein solches Heft die technischen und inhaltlichen Vorgaben, die an die Software gestellt werden.IT Dienstleister, die sich an einer Ausschreibung beteiligen, erstellen ein Pflichtenheft. Es enthält nach DIN 69905 die vom "Auftragnehmer erarbeiteten Realisierungsvorgaben" und beschreibt die "Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts".
Stephan Salinger 8/52
Zielgruppen Spezifikationsarten
• Lastenheft/BenutzeranforderungenManager des KundenEndbenutzer des SystemsTechniker des KundenManager des Softwareherstellers
• Pflichtenheft/SystemanforderungenEndbenutzer des SystemsTechniker des KundenSystemarchitektenSoftwareentwickler
Stephan Salinger 9/52
Aufteilung von Anforderungen
• Funktionale AnforderungenFunktionalitäten oder Dienste, die das System leisten sollReaktion des Systems auf bestimmte EingabenVerhalten des Systems in bestimmten Situationen
• Nichtfunktionale AnforderungenBeschränkungen der durch das System angebotenen Dienste und Funktionen• Zeitbeschränkungen• Einzuhaltende Standards
• ProblembereichsanforderungenAnforderungen, die die Charakteristika des Problembereiches des Systems widerspiegeln (funktional oder nichtfunktional). • Spiegeln nicht spezielle Bedürfnisse des Benutzers wieder.• Sind meist von Fachexperten in einer anwendungssystemspezifischen
Sprache ausgedrückt, so dass Softwareentwickler oft Problem haben, diese zu verstehen.
Stephan Salinger 10/52
Beispiel funktionale Anforderungen
• Funktionale Benutzeranforderungen an ein Universitätsbibliothekssystem zur Bestellung von Büchern/Dokumenten von anderen Bibliotheken:
Der Benutzer soll die gesamte anfängliche Menge der DB durchsuchen oder eine Teilmenge davon auswählen können.Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentenspeicher lesen kannJeder Bestellung soll ein geeigneter Bezeichner(ORDER_ID) zugeordnet werden.
Stephan Salinger 11/52
Bedingungen an die Spezifikation funktionaler Anforderungen
• VollständigkeitAlle vom Benutzer benötigten Dienste werden festgelegt
• KonsistenzAnforderungen enthalten keine widersprüchlichen Festlegungen
• Achtung:In der Praxis ist es für große, komplexe Systeme so gut wie unmöglich zu erreichen, dass Anforderungen sowohl komplett als auch konsistent sind.
Stephan Salinger 12/52
Beispiele nichtfunktionale Anforderungen
• ProduktanforderungenEffizienzanforderungen• Leistungsanforderungen• SpeicherplatzanforderungenPortierbarkeitsanforderungenBenutzbarkeitsanforderungen
• UnternehmensanforderungenLieferanforderungenVorgehensanforderungen
• Externe AnforderungenKompatibilitätsanforderungenRechtliche Anforderungen• Datenschutzanforderungen• Sicherheitsanforderungen
Stephan Salinger 13/52
Eigenschaften nichtfunktionaler Anforderungen
• Beziehen sich eher auf das System als Ganzes als auf einzelnen Funktionalitäten
• Sind somit oft entscheidender als einzelnen funktionale Anforderungen
Nichteinhalten einer einzelnen funktionalen Anforderung macht System schlechterIgnorieren einer nichtfunktionalen Anforderung kann ganze System unbrauchbar machen
• Stehen oft mit anderen (funktionalen) Anforderungen im Konflikt
• Oft schwer zu überprüfen. Deshalb sollten Metriken für nichtfunktionale Anforderungen festgelegt werden.
Stephan Salinger 14/52
Metriken für nichtfunktionale Anforderungen
Zeit bis zum Neustart nach FehlfunktionStabilität
Durchschnittliche Zeit bis zu einer FehlfunktionVerfügbarkeit
Zuverlässigkeit
Anzahl der plattformabhängigen ZeilenPortierbarkeit
SchulungsdauerAnzahl der Hilfeseiten
Benutzerfreundlichkeit
KilobytesGröße
Ausgeführte Transaktionen/SekundeReaktionszeit auf Benutzereingaben oder EreignisBildschirmaktualisierungszeit
Geschwindigkeit
MaßeinheitEigenschaft
•In der Praxis ist die quantitative Festlegung von Anforderungen oft schwierigKeine MetrikenAufwand zur Verifizierung kann sehr hoch sein
•Deshalb enthalten Pflichtenhefte oft Darstellungen von Zielen vermischt mit Anforderungen
Stephan Salinger 15/52
Benutzeranforderungen: Eigenschaften und Probleme
• Eigenschaften:Beschreibung funktionaler und nichtfunktionaler Anforderungen für den Systembenutzer (ohne detailliertes technischen Wissen/ Konzentration auf fundamentale Eigenschaften)Externes Verhalten des Systems festlegenCharakteristika des Systementwurfes so weit wie möglich vermeidenNatürliche Sprache, Formulare, einfache und intuitive Diagramme
• Probleme:Mangel an Genauigkeit• Präzise und widerspruchsfrei Verwendung von natürlicher Sprache
kann zu umfangreichen, schwer verständlichen Dokumenten führenVerwirrung bei Anforderungen• Kein klares Auseinanderhalten von funktionalen Anforderungen,
nichtfunktionalen Anforderung und Systemzielen.Verschmelzung von Anforderungen• Verschiedene Anforderungen werden als eine einzige ausgedrückt
Stephan Salinger 16/52
Systemanforderungen: Eigenschaften und Probleme
• Eigenschaften:Genauere Beschreibungen der BenutzeranforderungenKönnen als Basis für einen Vertrag über die Implementierung des System dienenSollten eine komplette und widerspruchsfreie Spezifikation des gesamten Systems darstellenStartpunkt des Systementwurfes
• Probleme:Möglichst keine Angaben darüber, wie die Implementierung aussehen wird. Dies ist schwierig da:• Anfängliche Architektur erleichtert Strukturierung der
Anforderungsspezifikation• Zusammenspiel mit bestehenden Systemen
Probleme mit der Mehrdeutigkeit und Überflexibilität der natürlichen Sprache
Stephan Salinger 17/52
Systemanforderungen: Notationen
Verwendung von einer programmiersprachenähnlichen Sprache, aber mit abstrakteren Funktionen zur Spezifikation der Anforderungen durch Definition eines Einsatzmodells des Systems.
Sprachen zu Entwurfs-beschreibung
Notationen, die auf mathematischen Konzepten aufbauen. Z.B.•Zustandsmaschinen•MengenViele Kunden verstehen formale Spezifikationen nicht und sind abgeneigt, sie als einen Vertrag über das System zu akzeptieren.
Mathematische Spezifikation
Zur Definition der funktionalen Anforderungen wird eine graphische Sprache, ergänzt durch Textvermerke, verwendet. Z.B.:•SADT (Schomann und Ross, 1977) •Anwendungsfallbeschreibungen (Jacobsen et al., 1993)
Graphische Notationen
Verwendung von Standardformularen oder Vorlagen, um die Spezifikation von Anforderungen auszudrücken
Strukturierte natürliche Sprache
BeschreibungNotation
Stephan Salinger 18/52
Systemanforderungen: Spezifikation in strukturierter Sprache
Spezifikation in strukturierter natürlicher Sprache (Pseudocode):• Ziele:
Erzeugung einer eingeschränkten Form der natürlichen SpracheErhalten der Ausdruckskraft und Verständlichkeit der natürlichen SpracheSicherstellung, dass eine gewisse Einheitlichkeit erzwungen wirdEinschränkung der benutzten Terminologie
• Mittel:Verwendung von VorlagenEinbeziehen von aus Programmiersprachen abgeleiteten SteuerkonstruktenVerwendung von graphischen Hervorhebungen zur Unterteilung der Spezifikation
• Wege:Die Spezifikation kann unterschiedlich aufgebaut werden:• Um die Objekte herum, die das System manipulieren• Um die durch das System unterstützten Funktionen• Um die durch das System verarbeiteten Ereignisse
Stephan Salinger 19/52
Systemanforderungen: Spezifikation in strukturierter Sprache
• Ein Standardformular zur Spezifikation funktionaler Anforderungen sollte folgenden Informationen enthalten:
Eine Beschreibung der spezifizierten Funktion oder EntitätEine Beschreibung ihrer Eingabedaten und deren HerkunftEine Beschreibung ihrer Ausgaben und deren ZielEin Hinweis darauf, welche anderen Entitäten benutzt werdenBei funktionalen Methoden: Festlegung einer Vorbedingung und einer NachbedingungEine Beschreibung der Seiteneffekte
Stephan Salinger 20/52
Schema eines Lastenheftes nach Balzert
•Ergänzungen und spezielle Anforderungen (z.B. „Spracheingabe erforderlich“)Ergänzungen
•Wichtigste Qualitätsanforderungen und die jeweils geforderten Qualitätsstufen (z.B. Zuverlässigkeit, Benutzbarkeit etc.)
Qualitätsanforderungen
•Gestellte Leistungsanforderungen an Hauptfunktionen u. Hauptdaten (z.B. Zeit und Genauigkeit) (/LLnn/)
Produktleistungen
•Langfristig zu speichernde Hauptdaten und deren voraussichtlicher Umfang aus Benutzersicht (/LDnn/)
Produktdaten
•Hauptfunktionen des Produktes aus Auftraggebersicht•Nennung typischer Arbeitsabläufe, die mit dem zu erstellenden Produkt durchgeführt werden sollen•(Jede Funktionsanforderung ist durch eine vorangesetze Zahl und ein vorangesetzes LF (Lastenheft Funktion), eingeschlossen in Schrägstrichen (z.B. /LF 20/) zur späteren eindeutigen Referenzierung zu versehen.)•Die Funktionalität kann mit Hilfe von Akteuren und Geschäftsprozessen oder mit Hilfe von Schnittstellen und Datenflüssen systematisch ermittelt werden.•Grafiken können direkt oder im Anhang eingefügt werden.
Produktfunktionen(Benutzeranforderungen)
•Gibt einen meist graphischen Überblick über die Produktumgebung, z.B. durch ein Umweltdiagramm
Produktübersicht
•Festlegung der Anwendungsbereiche und der Zielgruppen, für die das Produkt vorgesehen ist
Produkteinsatz
•Welche Ziele sollen durch den Einsatz des Produktes erreicht werdenZielbestimmung
BeschreibungKapitel
Stephan Salinger 21/52
Schema eines Pflichtenhefts nach Sommerville, basierend auf IEEE-Standard
•Ggf. mehrere Indizes (z.B. alphabethischer Index und Index von Diagrammen)Index
•Anwendungsspezifische Informationen. Z.B. Hardware- und Datenbankbeschreibungen.
Anhänge
•Festlegung von Systemmodellen, die die Beziehung zw. den Systemkomponenten und dem System und seiner Umgebung aufzeigen.•Evtl. Klassen-, Datenfluss- und semantische Datenmodelle.
Systemmodelle
•Genaue Beschreibung der funktionalen und nichtfunktionalen Anforderungen•Definition von Schnittstellen zu anderen Systemen
Spezifikation der Systemanfor-derungen
•Grober Überblick über die erwartete Systemarchitektur•Wiederverwendete Komponenten kennzeichnen
Systemarchitektur
•Darstellung der für die Benutzer bereitgestellten Dienste•Darstellung der nichtfunktionalen Anforderungen•Natürliche Sprache, Diagramme, für Kunden verständliche Notationen•Festlegung Produkt- und Entwicklungsstandards
Definition der Benutzeranforderungen
•Technische Fachbegriffe festlegenBegriffe
•Notewendigkeit des Systems•Kurz Funktionen und Zusammenarbeit mit anderen Systemen darlegen•Kurz auf Übereinstimmung des Systems mit den gesamtwirtschaftliche oder strategische Ziele des Auft4raggebers eingehen
Einleitung
•Erwartete Leserschaft festlegen•Versionsgeschichte beschreiben (Begründung für neue Version, Zusammenfassung der Änderungen)
Vorwort
BeschreibungKapitel
Abnahmekriterien ?
Stephan Salinger 22/52
Softwareanforderungen
Inhalt
1. Anforderungen und ihre Beschreibung (Darstellung der Dienste und Einschränkungen)
Benutzeranforderungen vs. SystemanforderungenLastenheft vs. PflichtenheftFunktional vs. nichtfunktionale AnforderungenBeispielstruktur LastenheftBeispielstruktur Pflichtenheft
2. AnforderungsanalyseProzess des Herausfindens, Analysierens und Überprüfens der Dienste und Einschränkungen
Stephan Salinger 23/52
Abläufe bei der Anforderungsanalyse
• Es gibt vier allgemeine, auf der obersten Ebene stattfindende Aktivitäten bei der Anforderungsanalyse:
SystemdurchführbarkeitsstudieBestimmung und Analyse der AnforderungenSpezifikation von Anforderungen und deren DokumentationValidierung der Anforderungen
Stephan Salinger 24/52
Abläufe bei der Anforderungsanalyse
Durchführ-barkeitsstudie
Anforderungs-bestimmungund -analyse
Anforderungs-spezifikation
Anforderungs-validierung
Pflichtenheft
Benutzer- und System-
anforderungen
Systemmodelle
Durchführbar-keitsbericht
Im weiteren liegt hier der Fokus auf der
Anforderungsbestimmung
Systemmodelle sind graphischeDarstellungen, die das zu lösendeProblem und das zu entwickelnde
System beschreiben. Z.B.:Kontextmodelle, Verhaltensmodelle
Objektmodelle
Stephan Salinger 25/52
Anforderungsbestimmung und -analyse
• Projektbeteiligte (stakeholder) mit direktem oder indirektem Einfluss auf die Systemanforderungen:
Endbenutzer, die das System verwenden werdenTechnische SoftwareentwicklerEntwickler, die andere Systeme entwickeln oder wartenWirtschaftsmanagerExperten des AnwendungsbereichesGewerkschaftsvertreter…
Stephan Salinger 26/52
Anforderungsbestimmung und -analyse
• Schwierigkeiten:Projektbeteiligte wissen, abgesehen von den allgemeinsten Dingen oft nicht, was sie von dem (Computer-)System erwarten (Formulierungsschwierigkeiten, unrealistische Forderungen (z.B. bzgl. Kosten))Projektbeteiligte verwenden bei der Formulierung implizites Wissen (ihrer eigenen Arbeit)Verschiedene Projektbeteiligte haben unterschiedliche Anforderungen und können sie auf verschiedene Weise ausdrücken.• Anforderungsanalytiker müssen
– alle potentiellen Ursachen von Anforderungen finden und– Übereinstimmungen und Konflikte herausarbeiten.
Stephan Salinger 27/52
Anforderungsbestimmung und –analyse:Ablauf
Anforderungs-überprüfung
Anforderungs-spezifikation
Klassifizierung
Anforderung-sammlung
Konfliktlösung
Verstehen des
AnwendungsbereichesSetzen von Prioritäten Pflichtenheft
Prozessbeginn
Stephan Salinger 28/52
Anforderungsbestimmung und –analyse: Techniken
• Techniken zur AnforderungsbestimmungViewpointsSzenarienEthnographieStrukturierte AnalysePrototypen
• Achtung: Es gibt keine perfekte, universell anwendbare Methode zur Anforderungsbestimmung und –analyse. Man muss gewöhnlich mehrere verschiedene Methoden anwenden, um ein vollständiges Verständnis und eine vollständige Analyse entwickeln zu können.
Stephan Salinger 29/52
Anforderungsbestimmung: Viewpoint-orientiert
• Verschiedenen Typen von Endbenutzern• Die verschiedenen Typen haben unterschiedliche
Blickwinkel (Viewpoints) auf das SystemVerschieden Viewpoints betrachten das Problem auf unterschiedliche WeisePerspektiven sind allerdings nicht total unabhängig (Überlappungen)
• Viewpoint-orientierte Methoden beachten die verschiedenen Sichtweisen und benutzen sie zur Strukturierung und Organisation sowohl
des Bestimmungsprozesses als auchder Anforderungen selber
Stephan Salinger 30/52
Anforderungsbestimmung: Viewpoint-orientiert
• Verschiedenen Methoden vertreten unterschiedliche Ansichten darüber, was mit einem Viewpoint gemeint ist
Eine Datenquelle oder ein Datenfluß: Viewpoints sind für die Erzeugung oder Abnahme von Daten verantwortlich.Ein Darstellungsrahmen: In diesem Fall wird ein Viewpoint als eine bestimmte Art von Systemmodell angesehen. Verschiedene Entwickler könnten ein Entity-Relationship-Modell, ein Zustandsmodell usw. entwickeln. Jede Methode der Analyse deckt verschiedenen Dinge über das analysierte System auf.Ein Empfänger von Diensten: In diesem Fall liegen die Viewpoints außerhalb des Systems und empfangen Dienste vom System. Viewpoints können Daten für diese Dienste oder Steuersignale bereitstellen.
Stephan Salinger 31/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen
• Vorteile des dienstorientierten Rahmen zur Anforderungsbestimmung und –analyse:
Natürliche Art der Strukturierung der Anforderungsbestimmung, da die Viewpoints außerhalb des Systems liegenViewpointbestimmung ist einfach. Sie müssen auf eine bestimmte Weise mit dem System zusammenarbeiten.
Stephan Salinger 32/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Beispiel für dienstorientierten Rahmen zur Anforderungsbestimmung und –analyse: VORD-Methode (VORD – Viewpoint-Oriented RequirementsDefinition; Kotonya und Sommerville)
Viewpoint-Bestimmung
Viewpoint-Strukturierung
Viewpoint-Dokumentation
Viewpoint-Systemzuordung
Auffinden vofan
mun
rei n Vgg
tge P f
von
der
ste ür
den Emp
SD,
Bestim
jedem
VP be
llten SD
Gruppieru
ndt
rch ng
er
isi
verwa
VP,
Hiera
erung
Verfeinerun
eib
ne
g d
un
n V
er
Beschr
g der
gefunde
P und SD
Bestimm
u
Obj
bje
ng
ekkto de
teriefes
utz
tinf r nti
uunordes o
ert
nte
g d
ma en
Entwur
r
Ben
er
Diens
tionen
VP: Viewpoint/SD: Systemdienst
Stephan Salinger 33/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Viewpoint- und Dienstinformationen werden in VORD mit Hilfe von Standardformularen gesammelt:
KontoinhaberFremdkunde
Der Name von Unter-ViewpointsUnter-
Viewpoints
Bargeld abhebenKontostandabfrage
Der Verweis auf einen Satz von DienstbeschreibungenDienste
Transaktion beginnenDienst auswählenTransaktion abbrechenTransaktion beenden
Ein Verweis auf eine Menge von Ereignisszenarien, die die Reaktion des Systems auf Viewpoint-Ereignissebeschreiben
Ereignisse
KontonummerPIN
Attribute mit Viewpoint-InformationenAttribute
KundeDer Viewpoint-NameBezeichnung
BeispielGeldautomatensystem
Viewpoint-Formular
Stephan Salinger 34/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
Bestätigten Bargeldbetrag innerhalb einer Minute auszahlen
Verweis auf einen Satz nichtfunktionaler Anforderungen, die den Dienst einschränken
Nicht-funktionale Anforderungen
Wird später ausgefülltVerweis auf eine Liste von Systemobjekten, die den Dienst bereitstellen
Anbieter
KundeListe der Namen von Viewpoints, die den Dienst in Anspruch nehmen
Viewpoints
Benutzer wählen diesen Dienst, indem sie den Barabhebungsknopf drücken. Dann geben sie den benötigten Betrag ein und bestätigen ihn. Wenn es der Bargeldbestand erlaubt, wird der Betrag ausgezahlt.
Verweis auf eine Liste von Dienstspezifikationen. Diese können in verschiedenen Notationen dargestellt werden
Spezifikation
Zur Verbesserung des Kundendienstes und zur Verringerung des Schriftverkehrs
Grund zur Bereitstellung des DienstesBegründung
Bargeld abhebenDer DienstnameBezeichnung
BeispielGeldautomatensystem
Dienst-Formular
Stephan Salinger 35/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Erster Schritt – die Bestimmung möglicher Viewpoints – ist die schwierigste Etappe
• Lösungsmöglichkeit: Brainstorming bei Treffen aller Projektbeteiligten zur Ermittlung möglicher
Potentieller ViewpointsSystemdiensteDateneingabenNichtfunktionaler AnforderungenSteuerereignisseAusnahmen
• Ergebnis Blasendiagramm• Hier ist es noch nicht Angebracht, dem Diagramm eine Struktur zu
verleihen.• Informationsquellen: Dokumente über
das Gesamtziel des SystemsWissen der SW-Entwickler aus früheren ProjektenErfahrungen des Kunden
Stephan Salinger 36/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Beispiel Blasendiagramm zur Erkennung möglicher Viewpoints: Geldautomatensystem
Kontostandabfragen
Kunden-datenbank
GestohleneKarte Manager
Transaktionenabfragen
Transaktions-protokoll
Barabhebung
FremdkundeKassierer
SchecksanfordernUpgrade der
Steuerungs-software
Software-größe
Zuver-lässigkeitSystemkosten
Hardware-wartung
Weiterreichen vonNachrichten
SicherheitKontoauszug
anfordern
Fern-diagnose
Konto-inhaber
ÜberweisungDrucker
Kartenüber-prüfung
Stephan Salinger 37/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Nachfolgender Schritt: Zuordnung der Dienste zu den Viewpoints
Kontoauszug anfordern
Kontoauszug anfordern
Transaktionsliste
Nachricht senden
Schecks anfordern
Kontostand abfragen
Bargeld abheben
Dienstliste
Kontoinhaber
Kontostand abfragen
Bargeld abheben
Dienstliste
Fremdkunde
Nachricht senden
Papier nachfüllen
Geld nachfüllen
Fehlerdiagnose anstellen
Dienstliste
Kassierer
Stephan Salinger 38/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Viewpoints nehmen nicht nur Dienste entgegen, sondern stellen auch Eingaben für diese Dienste bereit.
• Außerdem liefern Viewpoints Steuerungsinformationen, um zu bestimmen, ob und wann Dienste geleistet werden.
• Daten und Steuerungsinformationen zu einem VP werden in der frühen Phase des Prozesses durch ihren Namen bestimmt. Z.B. für den Kontoinhaber:
NachrichtDienst wählen
Benötigter GeldbetragTransaktion beenden
PINTransaktion abbrechen
KartendetailsTransaktion beginnen
DateneingabenSteuerungseingaben
Stephan Salinger 39/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Die Viewpoint-Informationen werden dazu benutzt,Viewpoint-Formulare auszufüllenViewpoints in einer Vererbungshierarchie anzuordnen• Aufzeigen von Gemeinsamkeiten von Viewpoints• Wiederverwendung von Viewpoint-Informationen
AlleViewpoints
Kunde
Konto-inhaber
Fremd-kunde
ManagerKassierer Entwickler
Bank-personal
Dienste
Kontostand abfragenBargeld abheben
Schecks anfordernNachrichten sendenTransaktionslisteKontoauszug anfordernGeld überweisen
Dienste
Stephan Salinger 40/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD
• Die Schritte des Prozesses dienen dem Auffinden detaillierter Informationen über
die bereitgestellten Dienstedie benötigten Datenund deren Steuerung
• Anforderungen werden durch die Projektbeteiligten bestimmt, die mit jedem Viewpoint verbunden sind.
• Viewpoint- und Dienstformulare sowie Ereignisszenarien werden für alle bestimmten Viewpoints und Dienste aufgestellt.
Da hierbei eine große Menge von Informationen erzeugt wird, ist VORD wie andere Analysemethoden in der Praxis nur mit der Unterstützung von CASE-Werkzeugen
Stephan Salinger 41/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD/Szenarien
• SzenariosBei Viewpoints/VORD Ereignisszenarios: Dokumentation der Reaktion des Systems auf Viewpoint-EreignisseAllgemein: Beschreibung der Rolle eines Subjektes im Zusammenhang mit einem Softwaresystem
• Szenarios eignen sich insbesondere zum Hinzufügen von Details zu einer groben Anforderungsbeschreibung
• Zusammenarbeit von Anforderungsentwicklern mit Projektbeteiligten
Stephan Salinger 42/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD/Szenarien
• Im Allgemeinen sollte ein Szenario folgendes enthaltenSystemzustandsbeschreibung zu Beginn des SzenariosBeschreibung des normalen Ereignisverlaufes im SzenarioBeschreibung, was falsch laufen kann und wie damit umgegangen wirdInformationen über andere Aufgaben, die zur selben Zeit ablaufen könnenBeschreibung des Systemzustandes nach dem Abschluss des Szenarios
Stephan Salinger 43/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD/Szenarien
Ereignisszenario: Beginn einer Transaktion
PIN anfordern
Zeitabgelaufen
Karte Ausgeben
UngültigeKarte
GestohleneKarte
Karte
PIN Konto-Nummer
PIN
Benutzerüberprüfen
UngültigePIN
PIN nochmalseingeben
UngültigePIN
Karteausgeben
Konto-Nummer
Dienstauswählen
Karte eingeführt
Benutzer OK
Gültige Karte
Karte Ausgeben
Karte Ausgeben
Durch einen Viewpoint gelieferte Daten
Steuerungsinformationen
Daten
Ausnahmen und Fehler. Gibt es mehrere möglicheAusnahmen, werdendiese in einem Kastendargestellt
Name desnächstenerwartetenEreignisses
Stephan Salinger 44/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: VORD/Szenarien
• Zusammenfassung Konventionen für die Darstellung von Ereignisszenarien
In Ellipsen werden durch einen Viewpoint oder zu einem Viewpoint gelieferte Daten dargestelltSteuerungsinformationen erreichen und verlassen jeden Kasten von und nach obenDaten verlassen jeden Kasten nach rechts.Ausnahmen und Fehler werden unterhalb des Kastens dargestellt. Gibt es mehrere mögliche Ausnahmen, werden diese in einem Kasten dargestellt.Der Name des nächsten erwarteten Ereignisses nach dem Abschluss des Szenarios wird in einem schattierten Kasten dargestellt.
• Jede Ausnahme kann durch die Erstellung eines eigenen Diagramms zur Daten- und Steuerungsanalyse genauer definiert werden.
Stephan Salinger 45/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: Anwendungsfälle
• Anwendungsfälle (use cases) sind eine szenariobasierte Technik, die erstmals in der Objectory-Methode (Jacobsen et. al., 1993) Verwendung fand.
• Merkmal der UML-Notation zur Beschreibung objektorientierter Systemmodelle
• use cases werden im deutschen oft auch als Geschäftsprozesse übersetzt:
Balzert: „Ein Geschäftsprozess (use case) – auch Arbeitsablauf genannt – besteht aus mehreren zusammenhängenden Aufgaben, die von einem Akteur durchgeführt werden, um ein Ziel zu erreichen bzw. ein Gewünschtes Ergebnis zu erstellen.“Genau genommen sollte unterschieden werden:• use case: bzgl. UML/Objektorientierung und
Benutzerkommunikation mit Softwaresystem• Geschäftsprozess: „Unternehmensprozess“ oder
„Arbeitsablauf der mit Hilfe einer Software durchgeführt wird“
Stephan Salinger 46/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: Anwendungsfälle
• Ein Geschäftsprozess wird formal, semiformal (use casetemplates) oder informal (umgangssprachlich) beschrieben.
• Beispiel für Grundlagen der Notation von Geschäftsprozessdiagrammen: Ausleihen eines Buche (Akteur als Strichmännchen/Interaktionen als bezeichnete Ellipsen):
• Die Menge der Anwendungsfälle repräsentiert alle möglichen Interaktionen, die in den Systemanforderungen festgehalten sind.
Ausleihdienste
Stephan Salinger 47/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: Anwendungsfälle
• Achtung: Es gibt unterschiedliche Auffassungen darüber, ob
ein Anwendungsfall selbst ein Szenario ist oderob ein Anwendungsfall eine Reihe von Szenarien einschließt, die im Anwendungsfall eigene Handlungsstränge verfolgen.
• Im allgemeinen können Anwendungsfalldiagramme in UML aus folgenden Elementen bestehen:
AkteureNamen von GeschäftsprozessenGeneralisierung zw. AkteurenAssoziationen (zw. Akteuren und Geschäftsprozessen)Strukturierungen von Geschäftsprozessen• include-Beziehung• extend-Beziehung• Generalisierungen
Stephan Salinger 48/52
Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: Geschäftsprozessdiagramm
• Geschäftsprozess-diagramm UML (aus Balzert)
• Ggf. um Sequenzdiagramme etc. erweitern.
Stephan Salinger 49/52
Anforderungsbestimmung: Validierung
• Die Validierung soll zeigen, dass die Anforderungen wirklich das System definieren, das der Kunde erwartet.
• Ziel: Vermeidung von evtl. immensen Nachbereitungskosten durch falsche Anforderungen
• Verschieden Arten von PrüfungenGültigkeitsprüfungen• Gültigkeit des (zwangsläufigen) Kompromisses zw. Anforderungen
unterschiedlicher Benutzer(gruppen)Konsistenzprüfungen• Keine sich widersprechenden Anforderungen, Beschränkungen oder
Beschreibungen für die selbe SystemfunktionVollständigkeitsprüfungen• Enthaltensein von allen durch den Systembenutzer erwarteten
Funktionen und BeschreibungenRealisierbarkeitsprüfungen• Prüfung der Anforderungen gegen vorhandene Technologie, Budget
und Zeitplan.Verifizierbarkeitsprüfungen• Die Anforderungen sollten so definiert sein, dass ihre Erfüllung
(durch Tests) verifizierbar wird.
Stephan Salinger 50/52
Anforderungsbestimmung: Validierung
• Techniken zur Anforderungsvalidierung:Anforderungsreviews• Analyse durch ein Team von Gutachtern
Prototypen• Den Endbenutzern und Kunden wird ein funktionsfähiges
Modell des Systems zur Verfügung gestellt
Testfallerzeugung• Anforderungen sollten Idealerweise gestestet werden
können. Werden die Tests für die Anforderungen als ein Teil des Validierungsprozesses erarbeitet, eröffnet dies oft Probleme bei den Anforderungen.
Automatische Konsistenzanalyse• Bei der Formulierung von Anforderungen als Systemmodell in
einer strukturierten oder formalen Notation (durch CASE-Werkzeuge).
Stephan Salinger 51/52
Anforderungsbestimmung: Validierung: Anforderungs-Reviews
• Anforderungs-ReviewVon Hand durchgeführter ProzessBeteiligte von Kunden- sowie von AnbieterseiteÜberprüfung des PflichtenheftesKann auf die selbe Weise wie Programminspektionen durchgeführt werdenEntwicklungsteam führt Kunden durch die Systemanforderungen. Das Review-Team untersucht jede Anforderung auf• Konsistenz• Verifizierbarkeit• Verständlichkeit• Nachvollziehbarkeit• Anpassungsfähigkeit
Stephan Salinger 52/52
Danke
top related