LE 5: Richtigkeit Praktikum Softwaretechnik … · Lastenheft vs. Pflichtenheft Funktional vs. nichtfunktionale Anforderungen Beispielstruktur Lastenheft Beispielstruktur Pflichtenheft

Stephan Salinger 1/52

LE 5: Richtigkeit

Softwareanforderungen

Praktikum Softwaretechnik Sommersemester 2004



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



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


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)


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.


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.“


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".


Zielgruppen Spezifikationsarten

• Lastenheft/BenutzeranforderungenManager des KundenEndbenutzer des SystemsTechniker des KundenManager des Softwareherstellers

• Pflichtenheft/SystemanforderungenEndbenutzer des SystemsTechniker des KundenSystemarchitektenSoftwareentwickler


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.


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.


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.


Beispiele nichtfunktionale Anforderungen

• ProduktanforderungenEffizienzanforderungen• Leistungsanforderungen• SpeicherplatzanforderungenPortierbarkeitsanforderungenBenutzbarkeitsanforderungen

• UnternehmensanforderungenLieferanforderungenVorgehensanforderungen

• Externe AnforderungenKompatibilitätsanforderungenRechtliche Anforderungen• Datenschutzanforderungen• Sicherheitsanforderungen


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.


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


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


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


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


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


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


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


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 ?



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


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


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


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…


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.


Anforderungsbestimmung und –analyse:Ablauf

Anforderungs-überprüfung

Anforderungs-spezifikation

Klassifizierung

Anforderung-sammlung

Konfliktlösung

Verstehen des

AnwendungsbereichesSetzen von Prioritäten Pflichtenheft

Prozessbeginn


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.


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


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.


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.


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



• 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



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



• 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



• 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



• 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



• 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



• 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



• 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


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



• 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



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



• 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.


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“



• 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



• 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


Anforderungsbestimmung: Viewpoint-orientiert:dienstorientierter Rahmen: Geschäftsprozessdiagramm

• Geschäftsprozess-diagramm UML (aus Balzert)

• Ggf. um Sequenzdiagramme etc. erweitern.


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.


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).


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


Danke

Documents

LE 5: Richtigkeit Praktikum Softwaretechnik … · Lastenheft vs. Pflichtenheft Funktional vs. nichtfunktionale Anforderungen Beispielstruktur Lastenheft Beispielstruktur Pflichtenheft