anforderungsanalyse und kapitel spezifikation teil...

89
ANFORDERUNGSANALYSE UND SPEZIFIKATION 3. Kapitel SPEZIFIKATION TEIL 1 Software Engineering Prof. Dr. Wolfgang Schramm

Upload: lebao

Post on 06-Aug-2019

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

ANFORDERUNGSANALYSE UND‐SPEZIFIKATION

3. KapitelSPEZIFIKATION

TEIL 1

Software Engineering

Prof. Dr. Wolfgang Schramm

Page 2: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Übersicht1

1. Einführung in das Software Engineering2. Softwareprozesse3. Anforderungsanalyse und -Spezifikation4 Softwareentwurf4. Softwareentwurf5. Entwurfsmuster6. Programmierung7. Software-Qualitätssicherung und -Prüfung8. Konfigurationsverwaltung

f9. Software-Wartung

Page 3: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Lernziele des Kapitels2

Sie lernen die wichtigsten Begriffe des Requirements Engineering (RE) kennenRequirements Engineering (RE) kennen.

Sie verstehen, warum der Anforderungsprozess wichtig ist.

Sie lernen die verschiedenen Arten von Sie lernen die verschiedenen Arten von Anforderungen kennen.

Sie lernen, welche Tätigkeiten zum Anforderungsprozess gehören und wie g p gder Anforderungsprozess abläuft.

Sie lernen, welche Personen an der Anforderungsphase beteiligt sind.

Sie lernen welche Dokumente erstellt werden müssen und wie sie aufgebaut sind.

Sie lernen wie man mit Anforderungen und mit Kunden umgeht.

Sie lernen verschiedene Techniken für die Erhebung der Anforderungen kennenErhebung der Anforderungen kennen.

Page 4: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Inhalt3

3. Anforderungenf h /3.1. Einführung / Motivation

3.2. Requirements Engineering (RE)3.3. Bestandteile der Dokumentation3.3. Bestandteile der Dokumentation3.4. Erhebung von Anforderungen3.5. Zielgruppen der Anforderungen3.6. Anforderungsarten3.7. Notation für Anforderungen3 8 Dokumentation der Anforderungen3.8. Dokumentation der Anforderungen3.9. Aufbau und Inhalt der Spezifikation/ des Pflichtenhefts3.10. Erheben der Anforderungen, Techniken der Erhebung3.11. Anforderungsmanagement3.12. Qualitätssicherung von Anforderungen3 13 Änderungsmanagement3.13. Änderungsmanagement3.14. Anwendungsfälle für die Anforderungsanalyse

Page 5: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Die 10 wichtigsten Erfolgsfaktoren bei IT‐Projekten4

1 Executive support 18%1. Executive support 18%2. User involvement 16%3 E i d j t 14%3. Experienced project manager 14%4. Clear business objectives 12%5. Minimized scope 10%6. Standard software infrastructure 8%7. Firm basic requirements 6%8. Formal methodology 6%gy9. Reliable estimates 5%10. Other criteria 5%

[Quelle: CHAOS Report, Standish Group International, Inc.]

10. Other criteria 5%

Page 6: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Die 10 wichtigsten Erfolgsfaktoren bei IT‐Projekten5

1 Executive support 18%1. Executive support 18%2. User involvement 16%3 E i d j t 14%3. Experienced project manager 14%4. Clear business objectives 12%5. Minimized scope 10%6. Standard software infrastructure 8%7. Firm basic requirements 6%8. Formal methodology 6%gy9. Reliable estimates 5%10. Other criteria 5%

[Quelle: CHAOS Report, Standish Group International, Inc.]

10. Other criteria 5%

Page 7: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Warum Anforderungen?6

50 % der im Quellcode gefundenen Fehler sind auf mangelhafte Anforderungen zurückzuführenAnforderungen zurückzuführen.

Die Beseitigung eines Fehlers der in der Programmierphase gefunden wird, ist um den Faktor 20 teurer als die Beseitigung während der Anforderungsphase. Im Abnahmetest Faktor 100.

[Poh08]

Page 8: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Warum Anforderungen?7

Kosten senken: Geringere Herstellungskosten.

(Senken der Fehlerkosten!) Weniger Reklamationen und Nachbesserungen. Geringere Pflegekosten.

Risiken verkleinern: Kundenerwartungen besser erfüllen. Zuverlässigere Prognosen für Termine und Kosten.g g

Aber : Die wirtschaftlicheWirkung von RequirementsAber : Die wirtschaftliche Wirkung von RequirementsEngineering ist immer indirekt; das RE selbst kostet nur!

Page 9: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsanalyse und –spezifikation: Wirtschaftlichkeit8

Page 10: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Requirement9

RequirementKunde im

Mittelpunkt

(1) A condition or capability needed by a user to solve a problem or achieve an objective.

(2) A condition or capability that must be met or possessed by a system or a ( ) p y p y ysystem component to satisfy a contract, standard, specification, or other formally imposed documents.

(3) A documented representation of a condition or capability as in (1) or (2).

Requirements AnalysisRequirements Analysis(1) The process of studying user needs to arrive at a definition of system, 

hardware, or software requirements.The process of studying and refining system hardware or software(2) The process of studying and refining system, hardware, or software requirements.

l ( d ( ))IEEE‐Glosar (IEEE Std. 610.12 (1990))

Page 11: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Begriffe10

Eine Anforderung (engl. requirement) ist: Eine Bedingung oder Eigenschaft, die ein System oder eine 

Person benötigt, um ein Problem zu lösen oder ein Ziel zu i herreichen.

Eine Bedingung oder Eigenschaft, die ein System oder eine Systemkomponente aufweisen muss um einen Vertrag zuSystemkomponente aufweisen muss, um einen Vertrag zu erfüllen oder einem Standard zu genügen.

Page 12: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderung11

Anforderungenallgemeinallgemein

Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.

Software AnforderungenEine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen. (IEEE 610.12‐1990)formell bestimmtes okument u erfüllen. (I 6 0. 990)

Anforderungen an ein System beschreiben– die Dienste, die ein Kunde von einem System erwartet, und

– die Gegebenheiten, unter denen es entwickelt wird und laufen soll.

Page 13: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Requirements Engineering ‐ Ziel12

Requirements Engineering – Verstehen und beschreiben, was h b hdie Kunden wünschen oder brauchen.

Eine menschenzentrierte Sicht. Ziel: zufriedene Kunden

Was sind Kunden? Warum wünschen oder brauchen? Warum nicht gleich programmieren?

Page 14: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Requirements Engineering13

Anforderungsanalyse und ‐spezifikation (Requirements Analysis & Specification) heißt der Prozess desSpecification) heißt der Prozess des Herausfindens (Elicitation), Analysierens (Analysis), Dokumentierens (Specification) und Dokumentierens (Specification) und Überprüfens (Validation)dieser Anforderungen.

Anforderungen verwalten (Requirements Management): Freigabe (Baselining) Freigabe (Baselining) Änderung (Modification) Verfolgung (Traceability)

Requirements Engineering     =  Requirements Specification +

Requirements Management

Page 15: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Weg der Anforderungen (vereinfacht)14

Spezifikation Entwurf

Anforderungs-sammlung

Code

Kunde

Entwickler

Page 16: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsanalyse und ‐spezifikation: Zusammenhang 15

Achtung: in der Literatur werden dieselben

Bestimmung und Analyse der

gBegriffe oft für verschiedene Dinge benutzt.Z.B. wird der Begriff Anforderungsanalyse oftfür Analyse und Spezifikation zusammenverwendetAnforderungen verwendet.

Spezifikation der AnforderungenLastenheft Anforderungen

Pflichtenheft

Page 17: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsspezifikation16

Anforderungsspezifikation

Die Zusammenstellung aller Anforderungen an ein System.

S A f d d k t Synonym: Anforderungsdokument.

Der Begriff „Spezifikation“ ist im Alltag nicht immer eindeutig:

Dokument oder Prozess Dokument oder Prozess.

Anforderungs‐, Lösungs‐ oder Produktspezifikation.

Page 18: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Pflichtenheft17

Wird nicht einheitlich verwendet:

Synonym zu Anforderungsspezifikation.

Spezifikation + Überblick über Lösung Spezifikation + Überblick über Lösung.

Spezifikation + Elemente der Projektabwicklung.

Also:  „Pflichtenheft“ mit Vorsicht verwenden, d.h. vorher klären, was der 

Kunde darunter versteht.

Page 19: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Probleme bei der Anforderungsanalyse und ‐spezifikation18

Alan Chapman

Page 20: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Detaillierungsgrad der Anforderungsbeschreibungen19

Anforderungen können sehr abstrakt oder sehr detailliert sein (bis hin zu funktionalen Spezifikationen)Spezifikationen).

Anforderungen erfüllen zwei Aufgaben

Basis für eine Ausschreibung für eine Software: Die Erledigung der Aufgaben muss interpretierbar sein, d.h. einer Lösung darf nicht vorgegriffen werden. Die Anforderungen müssen so beschrieben werden, dass sich mehrere Interessenten um den Zuschlag bewerben können, die sich zum Beispiel durch verschiedene Lösungsansätze 

h dunterscheiden.

Basis für einen Vertrag über eine Software‐Entwicklung: Die Aufgaben der Software müssen detailliert festgelegt sein

• Anforderungssammlung Lastenheft

A f d ifik ti Pfli ht h ft• Anforderungspezifikation Pflichtenheft

• Beide Dokumente zusammen Anforderungsdokument (RequirementsDocument) des Systems (nach [Dav93])) y ( [ ])

Page 21: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungen versus Entwurf20

Volksweisheit: WAS = Spezifikation/Anforderung, WIE = Entwurf

Aber: Ist folgender Satz eine Anforderung oder eine bereits eine Entwurfsentscheidung?

„Das System druckt eine wahlweise nach Namen oder Land alphabetisch sortierte Liste von Teilnehmern mit Nummer, Name, Vorname Mitgliedschaft und Land Auf jeder Seite sind unten linksVorname, Mitgliedschaft und Land. Auf jeder Seite sind unten links das Erstellungsdatum und unten rechts die Seitenzahl aufgedruckt.“

WAS vs. WIE ist kontextabhängig und liefert keine brauchbare Abgrenzung zwischen Anforderungen und Entwurfsentscheidungen.

Auch in der Anforderungsphase werden Entscheidungen über die Ausgestaltung des Systems getroffen.Ausgestaltung des Systems getroffen. 

Page 22: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Lastenheft/Pflichtheft21

Was?

Vision

Wie?

Was?

Lasten-heft

Auftrag-geber

Wie? Pflichten-

heft

geber

Auftrag-nehmer

h [P h08]nach [Poh08]

Page 23: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

„Was?“ versus „Wie?“22

Sukzessive Einschränkung des Lösungsraums

abstrakt konkret

Visi

on Was

Wie

Was

Wie

Was

Wie

Was

Wie

FertigesSystem

AnforderungenEntwurf der A hit kt

Entwurf der K t

ImplementierungAnforderungen Architektur Komponenten

h [P h08]WAS? = ProblembeschreibungWIE ?= Lö b h ib nach [Poh08]WIE ?= Lösungsbeschreibung

Page 24: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Vom Benutzerwunsch zum System23

BenutzeranforderungenAussagen in natürlicher Sprache, Diagramme zur Beschreibung der Dienste, die das System leisten soll und Randbedingungen, unter denen es betrieben wird.

• Systemanforderungen, PflichtenheftDetailliere Festlegung der Dienste und Beschränkungen. Soll präzise sein. Kann g g g pVertrag zwischen Kunde und Softwareentwickler sein.

• Spezifikation des SoftwareentwurfsAbstrakte, grobe Beschreibung des Softwareentwurfs. Grundlage für den exakten Feinentwurf und dessen Umsetzung. Hier werden weitere Details zu den Systemanforderungen hinzugefügt.

nach [Som01]nach [Som01]

Page 25: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Wer braucht welche Information?24

Problem-Beschreibung

BenutztesSystem

Benutzung Ausschreibung:Lastenheft,

Kunden-Anforderungen

BenutzbaresSystem

Akzeptanztest

Lastenheft, Benutzeranforderungen

Vertragsgrundlage:Entwickler-

AnforderungenAusführbares

SystemSystemtest, Integrationstest

Vertragsgrundlage:Pflichtenheft,

funktionale Spezifikation, Systemanforderungen

System-Entwurf

Reproduktion desKomponenten-Anforderungen

AusführbareKomponente

KomponententestReproduktion des

Pflichtenhefts für den Entwickler-internen Gebrauch

Komponenten-Entwurf

K tKomponenten-Implementierung

Page 26: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Zielgruppen für Anforderungen25

• Manager des KundenE db t d S t

Benutzer-anforderungen

• Endbenutzer des Systems• Techniker des Kunden• Manager des Softwareherstellers• Systemarchitekten• Systemarchitekten

Systemanforderungen,Pflichtenheft

• Endbenutzer des Systems• Techniker des Kunden• Systemarchitekten; ProjektmanagerPflichtenheft Systemarchitekten; Projektmanager• Softwareentwickler

Spezifikation desS f f

• Techniker des Kunden• Systemarchitekten

Softwareentwurfsy

• Softwareentwickler

Page 27: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Ablaufschema der Anforderungsanalyse26

Durchführbar- Bestimmung d A l dkeitsstudie und Analyse der

AnforderungenSpezifikation der Anforderungen

Validierung der A f d

Anforderungen

Durchführbar- AnforderungenDurchführbarkeitsbericht

Benutzer- und

System-modelle Benutzer- und

System-anforderungen

Pflichtenheft

nach [Som01]

Page 28: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Aufgaben einer Anforderungsanalyse und ‐spezifikation27

Anforderungen als Grundlage fürGrundlage für

SystemarchitekturKommunikation Ausschreibung und Vertragsgestaltung

Systemintegration, Wartung und

Pflegeg

SekundäreSekundäre Aufgaben

Erhöhung der Mitarbeiter-

Eröffnung von Rationalisierungs-

Optimierung des Kundennutzens

zufriedenheitg

potenzialenKundennutzens

Page 29: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Konkreter Ablauf der Anforderungsanalyse und Systemspezfikation 

28

Page 30: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Abstraktionsebenen von Anforderungen29

Beispiel: Geschäft «Auf dem bestehenden Schienennetz sollen mehr 

Leute transportiert werden.» System «Die Minimaldistanz zwischen zwei Zügen ist immer 

größer als der maximale Bremsweg des nachfolgenden Zuges »Zuges.»

Software «Der maximale Bremsweg muss alle 100 ms neu berechnet werden »berechnet werden.»

Quelle: M Glinz / Zürich /RE VorlesungQuelle: M.Glinz / Zürich /RE-Vorlesung

Page 31: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beispiele für Anforderungen30

R1: Die Bedienungsschnittstelle für den Hausbesitzer muss einfach zu handhaben seinhandhaben sein.

R2: Das Hausinformationssystem soll monatlich eine Aufstellung der erlaubten und verweigerten Zugänge zum Hausinneren generieren.

R3: Ist die an der Tastatur des Zugangssystems eingegebene PIN korrekt hebt das System die Sperre der Zugangstür auf undkorrekt, hebt das System die Sperre der Zugangstür auf und protokolliert den Zugang mit Datum, Uhrzeit und eingegebener PIN.

R4: Das System soll spätestens am 1.Mai 2009 auf dem Markt verfügbar sein.

R5: Die Freigabe des Schließungsmechanismus soll bei korrektR5: Die Freigabe des Schließungsmechanismus soll bei korrekt eingegebener Pin spätestens nach 0,8 Sekunden erfolgen.

aus [Poh08]

Page 32: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsarten 1/232

Funktionale Anforderungen (auch Verhaltensanforderungen)d fi i S t b it t ll d F kti d S i… definieren vom System bereitzustellende Funktionen oder Services.

Beispiele: Daten: Struktur, Verwendung, Erzeugung, Speicherung, Übertragung, , g, g g, p g, g g,

Veränderung. Funktionen: Ausgabe, Ablauf der Verarbeitung, Eingabe von Daten. Verhalten: Sichtbares dynamisches Systemverhalten Zusammenspiel Verhalten: Sichtbares dynamisches Systemverhalten, Zusammenspiel 

der Funktionen (untereinander und mit den Daten). Fehler: Normalfall und Fehlerfälle.

Qualitätsanforderungend fi i i li i Ei h f d S i… definieren eine qualitative Eigenschaften des gesamten Systems einer 

Komponente oder einer Funktion.Beispiele: Benutzerfreundlichkeit, Zuverlässigkeit.p , gWo immer möglich: messbare Angaben!

Page 33: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsarten 2/233

Rahmenbedingungen (Constraints / Problembereichsanforderungen)i d i t i h d t h l i h A f d l h di… sind organisatorische oder technologische Anforderungen, welche die 

Art und Weise einschränken, wie ein Produkt entwickelt wird.Beispiele: Einzuhaltende/zu verwendende Schnittstellen. Normen und Gesetze.

Datenschutz Datensicherung Datenschutz, Datensicherung. Explizite Vorgaben des Auftraggebers.

Leistungsanforderungen Datenmengen (durchschnittlich/im Extremfall). Verarbeitungs‐ /Reaktionsgeschwindigkeit (durchschnittlich/im Verarbeitungs‐ /Reaktionsgeschwindigkeit (durchschnittlich/im 

Extremfall). Verarbeitungszeiten und ‐intervalle.Wo immer möglich:messbare Angaben!Wo immer möglich: messbare Angaben!

Page 34: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Funktionale vs. nichtfunktionale Anforderungen35

Der Begriff nichtfunktionale Anforderung (NFR) ist ein Sammelbegriff für ungenügend spezifizierte funktionale Anforderungen oder qualitativeungenügend spezifizierte funktionale Anforderungen oder qualitative Anforderungen.

Die Abgrenzung zwischen nicht‐funktionalen und funktionalen Anforderungen ist nicht scharfist nicht scharf.

Eine nicht‐funktionale Anforderung:   „Das System muss den unauthorisierten Zugriff auf die Kundenstammdaten 

verhindern soweit dies technisch möglich ist “verhindern, soweit dies technisch möglich ist.   

Durch Verfeinerung werden daraus funktionale Anforderungen:  „Der Zugriff auf die Kundenstammdaten muss über eine Login‐Prozedur mit 

P t hüt t d “Passworten geschützt werden“. 

Traditionell: Unterscheidung nur in funktionale vs. nicht-funktionale Anforderungen.• Das ist zu ungenau (s o )• Das ist zu ungenau (s.o.).• In der Praxis werden weniger klare Anforderungen gerne als NFR eingeordnet,

ohne sie zu hinterfragen. Dadurch fließen unterspezifizierte Anforderungen in den Entwicklungsprozess ein.

Page 35: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Qualitätsanforderungen38

. . . .. .

Qualitätsmodell nach ISO/IEC 9126Qualitätsmodell nach ISO/IEC 9126

Page 36: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beschreibung von Qualitätsanforderungen39

Typisches Vorgehen:  Fragen stellen: 

«Wie fehlertolerant soll das System sein?» 

Antworten quantifizieren mit Maßen und Abnahmebedingungen. 

direkte Maße:  «Die Fehlertoleranz wird in MTTF gemessen und soll grösser als 106 

Betriebsstunden sein »Betriebsstunden sein.» 

indirekte Maße:  «Die Bedienung des System gilt als erlernbar wenn pro Person nicht «Die Bedienung des System gilt als erlernbar, wenn  pro Person nicht 

mehr als zwei Tage Schulung aufgewendet werden  müssen.» « Für jede Hauptfunktion beträgt der Lernaufwand für ihre 

erfolgreiche Anwendung im Mittel weniger als eine Stunde.»

Page 37: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beispiele für Qualitätsanforderungen40

Es soll möglich sein, dass die gesamte nötige Kommunikation zwischen der APSE (Entwicklungsumgebung für Ada) und demzwischen der APSE (Entwicklungsumgebung für Ada) und dem Benutzer durch den Ada‐Standardzeichensatz ausgedrückt wird.

Der Systementwicklungsprozess und lieferbare Dokumente sollen dem Vorgehen und den Ergebnissen entsprechen, die i XYZC SP STAN 95 d fi i t i din XYZCo‐SP‐STAN‐95 definiert sind.

Das System soll den Benutzern des Systems keine persönlichen Informationen über Kunden preisgebenpersönlichen Informationen über Kunden preisgeben, abgesehen vom Namen und der Referenznummer.

Zu beachten: (Nicht nur) Qualitätsanforderungen sollen so formuliert 

werden, dass sie eindeutig geprüft werden können.

Page 38: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beispiele für Verhaltensanforderungen41

Der Benutzer soll die gesamte anfängliche Menge der Datenbanken durchsuchen oder eine Teilmenge davon auswählen könnendurchsuchen oder eine Teilmenge davon auswählen können.

Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentenspeicher lesen kann.

Jeder Bestellung soll ein eindeutiger Bezeichner (ORDER_ID) zugeordnet werden und der Benutzer soll diesen in denzugeordnet werden, und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können.

Zu beachten: genau: Vermeiden von Mehrdeutigkeiten

k i k i Wid ü h i h A f d konsistent: keine Widersprüche zwischen Anforderungen vollständig: Beschreibung des gesamten Systems In der Praxis (fast) nicht möglich! In der Praxis (fast) nicht möglich!

Page 39: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beispiele für Problembereichsanforderungen42

Es sollte eine Standardbenutzungsschnittstelle zu allen D t b k b di f d Z39 50 St d d b i tDatenbanken geben, die auf dem Z39.50‐Standard basiert.

Aus urheberrechtlichen Gründen müssen einige Dokumente direkt bei der Ankunft gelöscht werden Abhängig von den Anforderungenbei der Ankunft gelöscht werden. Abhängig von den Anforderungen des Benutzers werden diese Dokumente entweder lokal auf dem Systemserver ausgedruckt, um manuell zum Benutzer verschickt zu werden, oder sie werden an einen Netzwerkdrucker weitergeleitet.

Zu beachten: Problembereichsanforderungen ergeben sich aus dem speziellen 

Anwendungsumfeld in dem das System eingesetzt werden sollAnwendungsumfeld, in dem das System eingesetzt werden soll. Sie enthalten oft wesentliche Hintergrundinformationen. Fachleute aus dem Anwendungsumfeld lassen oft "offensichtliche " Fachleute aus dem Anwendungsumfeld lassen oft  offensichtliche   

Informationen weg.

Page 40: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Das System im Kontext44

Page 41: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Der Systemkontext45

… ist der Teil der Umgebung eines Systems, der für die f fDefinition und das Verständnis der Anforderungen an das 

System relevant ist. 

Irrelevante Umgebung

SystemkontextSystemgrenze

SystemKontextgrenze

Page 42: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Bedeutung des Kontexts46

Anforderungen werden für einen bestimmten Kontext fdefiniert.

Erst die Kenntnis des Kontexts macht die Anforderungen i t ti b d b ti t d U finterpretierbar und bestimmt den Umfang.

Anforderung: Das geplante Beförderungsmittel soll den Anforderung: Das geplante Beförderungsmittel soll den Reisenden eine sichere und schnelle Reise zum Ziel ermöglichen.ermöglichen.

Kontext: Personen sollen vom Festland auf eine Insel transportiert werden. Die Insel hat keinen Platz für einen p fFlughafen.

Also: die Dokumentation des Kontexts ist notwendig

Page 43: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Darstellung des Systemkontexts47

Kontext‐Diagramme

Q ll M Gli / Zü i h/ V l REQuelle: M.Glinz/ Zürich/ Vorlesung RE

Page 44: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

7 Hauptprobleme bei der Anforderungsbeschreibung50

Unklare Zielvorstellungen. Hohe Komplexität. Sprachbarrieren. Sich ständig verändernde Anforderungen (requirements 

creeping). Schlechte Qualität. Unnötige Merkmale. Ungenaue Planung.

Page 45: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Gründe für Probleme bei der Analyse51

Wenn die Spezifikation selbst keine Rolle spielt, dann ist auch die Analyse von sehr geringer Bedeutungdie Analyse von sehr geringer Bedeutung.

Viele Entwickler sehen nicht, dass der Kunde meist keine Veränderung will, auch wenn er eine Verbesserung will.Veränderung will, auch wenn er eine Verbesserung will.

Entwickler denken oft, dass sie wissen, was der Kunde will oder braucht.

Der Kunde lässt den Analytiker verhungern, u.a. weil er nicht versteht, dass so etwas Geld kostet (nur Code darf Geld kosten)kosten).

Kunden halten Anforderungen bewusst oder unbewusst zurück und präsentieren sie spät.zurück und präsentieren sie spät.

Der Kunde (besser: bestimmte Mitarbeiter des Kunden) sehen ihre Privilegien dahin schmelzen, sie sabotieren die Analyse.

Page 46: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsanalyse und –spezifikation:7 Ideal‐Merkmale

52

Adäquatheit Beschreibt das was der Kunde will bzw braucht angemessenAdäquatheit Beschreibt das, was der Kunde will bzw. braucht angemessen.

Vollständigkeit Beschreibt alles, was der Kunde will bzw. braucht.

Widerspruchsfrei-heit

Sonst ist die Spezifikation nicht realisierbar.

V tä dli hk it Fü ll B t ili t K d i I f tikVerständlichkeit Für alle Beteiligten, Kunden wie Informatiker.

Eindeutigkeit Vermeidet Fehler durch Fehlinterpretationen.

Prüfbarkeit Feststellen können, ob das realisierte System die Anforderungen erfüllt.g

Risikogerechtheit Umfang umgekehrt proportional zum Risiko, das man eingehen will.

Page 47: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsanalyse – wie geht‘s weiter?54

Die Inhalte kennen sie jetzt!j

… aber wie werden sie dokumentiert?

Page 48: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Was trifft am besten?55

Haus VillHaus Villa

Page 49: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Techniken der Analyse57

Auswertung vorhandener Dokumente und Daten. Beobachtungen Befragung mit

geschlossenen strukturierten offenen Fragen

Interview Modell‐Entwicklung Experimente Prototyping Partizipative Entwicklung (Analyseanteil)

Page 50: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Was ist zu tun bei der Analyse?58

Analytiker soll die einschlägigen Vorschriften und Regelnh h f l bsichten und die Aussagen herausfiltern, die seine Arbeit

betreffen.W ö li h llt d tä li h A b it d Wenn möglich sollte er an der täglichen Arbeit derBetroffenen (die mit der Software arbeiten, deren Funktiondurch die Software ersetzt wird) teilnehmen: er wird Dingedurch die Software ersetzt wird) teilnehmen: er wird Dingesehen und hören, die ihm niemand erzählt.

Der Analytiker kann den Kunden systematisch befragen (am Der Analytiker kann den Kunden systematisch befragen (ambesten per persönlichem Gespräch) erkennen von Lücken.

Wenn abstrakte Vorstellung vom Zielsystem nicht ausreichtg yausprobieren (Experiment, Modell, Prototyp).

Partizipative Entwicklung Aufhebung von Analyse undEntwicklung, Software wächst in die Umgebung hinein.

Page 51: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Notationsformen für die Anforderungen59

Schnittstelle Verhalten Struktur AblaufNatürliche Sprache

Standardisierte Formulare

Standardisierte Dokumente

Formale Sprachen

Datenflussgraphen

Struktogramme gEntity-Relationship- Diagramme

Logische Spezifikationen

Funktionale Spezifikationen Funktionale Spezifikationen

Axiomatische Spezifikationen

Entscheidungstabellen

Z t d t b ll Zustandstabellen

Petri-Netze

UML

Page 52: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsbeschreibung in natürlicher Sprache ‐Beispiel

60Beispiel

Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und 

b D B di d t d G t ä k t i d dausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertastekann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfeneskann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.

a) Lesen Sie den Text zügig durch Fallen Ihnen irgendwelche Probleme auf?a) Lesen Sie den Text zügig durch. Fallen Ihnen irgendwelche Probleme auf?

b) Lesen Sie den Text nochmals langsam und sorgfältig und markieren Sie alle Problemstellen.

Page 53: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Anforderungsbeschreibung in natürlicher Sprache ‐Probleme im Beispiel

61Probleme im Beispiel

Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten BetragSobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45sGetränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeitabgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann g gentweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.

Unklarheit: Reihenfolge von Auswahl und Bezahlung?Fehler: Was ist bei Betragsgleichheit?Mehrdeutigkeit: Ist und“ oder oder“ gemeint?Mehrdeutigkeit: Ist „und oder „oder gemeint?Unklarheit: Abbruch während der Ausgabe des Getränks?Widerspruch: Die oben geforderte Möglichkeit der Annullierung wird ausgeschlossen.

Page 54: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Natürliche Sprache Vor‐ und Nachteile62

Vorteile Leicht verständlich. Hilfreich für eine oberflächliche, einführende Beschreibung.

h l Nachteile Mehrdeutig.

Überfle ibel Überflexibel. Keine Möglichkeit, Vollständigkeit und Konsistenz (automatisch) zu 

überprüfen. Keine Möglichkeit, formale Verifikation oder Beweise anzuwenden.

Page 55: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Natürliche Sprache63

Die Qualität natürlichsprachiger Anforderungsspezifikation lässt p g g p

sich systematisch verbessern durch:

geeignete Strukturierung des Dokuments,

Regeln zur sprachlichen Formulierung von Anforderungen,

kontrollierten Umgang mit Redundanz,

konsequente Verwendung eines Glossars konsequente Verwendung eines Glossars.

Page 56: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Regeln für natürlichsprachliche Anforderungen64

Sätze mit vollständiger Satzstruktur zum jeweiligen Verb bilden.A f d i Ak i f li i d fi i S bj k Anforderung im Aktiv formulieren mit definiertem Subjekt.

Nur Begriffe verwenden, die im Glossar definiert sind. Nomen mit unspezifischer Bedeutung ( die Daten“ der Kunde“ Nomen mit unspezifischer Bedeutung („die Daten , „der Kunde , 

„die Anzeige“,...) hinterfragen und durch spezifische Nomen ersetzen oder mit präzisierenden Zusätzen ergänzen.

Für Verben, die Prozesse beschreiben, feste Bedeutungen festlegen.

Nominalisierungen hinterfragen; sie können unvollständig Nominalisierungen hinterfragen; sie können unvollständig spezifizierte Prozesse verbergen.

Anforderungen in Hauptsätzen formulieren. Nebensätze nur zur Vervollständigung (wann, mit wem, unter welchen Bedingungen, ...).

Pro Einzelanforderung ein Satz Pro Einzelanforderung ein Satz.

Page 57: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Spezifikation mittels Szenarien69

Ein Szenario … beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung 

eines oder mehrerer Ziele.  enthält typischerweise eine Folge von Interaktionsschritten und setzt enthält typischerweise eine Folge von Interaktionsschritten und setzt 

diese in Bezug zum Systemkontext. wird meist in natürlicher Sprache beschrieben. ist gut geeignet um Information über den Kontext zu dokumentieren:

Personen oder andere Systeme, die mit dem System interagieren.V b di di B i S i füllt i ü Vorbedingungen, die zu Beginn es Szenarios erfüllt sein müssen.

Reale oder imaginäre Örtlichkeiten, in der die Ausführung eines Szenarios stattfindet.

Page 58: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Szenario ‐ Beispiel70

Karl möchte mit seinem PKW zum Potsdamer Platz 1 nach Berlin fahren. Karl benutzt das Navigationssystem des Fahrzeugs, um diefahren. Karl benutzt das Navigationssystem des Fahrzeugs, um die kürzeste Wegstrecke zu ermitteln. Er wählt „Ziel eingeben“. Das Navigationssystem zeigt im Display „Bitte Ort nennen oder manuell eingeben“ an. Karl wähl die Spracheingabe und spricht „Berlin“. g p g p „Aufgrund von Hintergrundgeräuschen und der schlechten Aussprache erkennt das System das Wort nicht eindeutig. Es zeigt das wahrscheinlichste Wort an „Schwerin“. Es zeigt zudem an „ Ihr 

b k h d k d “ dEingabe konnte nicht eindeutig erkannt werden“ sowie die folgenden Interaktionsmöglichkeiten: Zielort akzeptieren (ja/nein) Neueingabe (neu) Ähnliche Ort anzeigen (ähnlich) Manuelle Eingabeg

Karl spricht „ähnlich“, und das System listet die Orte „Schwerin“, „Berlin“ etc. auf.  Karl spricht „Berlin“ und das System wähl Berlin als Zielort aus.Zielort aus. 

Page 59: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Spezifikation mittels Szenarien: Vor‐ und Nachteile72

+  Szenarien können zur Strukturierung von f kAnforderungsdokumenten verwendet werden.

+  Szenarien verdeutlichen den Mehrwert von Anforderungen fü hi d St k h ldfür verschiedene Stakeholder.

+  Szenarien unterstützen die Kommunikation zu den Stakeholdern und helfen damit weitere Anforderungen zuStakeholdern und helfen damit weitere Anforderungen zu identifizieren.

+ Szenarien können zur Validierung eingesetzt werden+  Szenarien können zur Validierung eingesetzt werden.– Zu viele Szenarien beschreiben denselben Sachverhalt.

S i d Bli k fü d All i ülti– Szenarien versperren den Blick für das Allgemeingültige.

Page 60: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Regeln zur Formulierung von Szenarien73

Sprache/Grammatik

1. Schreiben sie Szenarien in der Gegenwartsform.

2. Schreiben sie Szenarien in der Aktivform.

h b f h3. Schreiben sie in einfachen Sätzen.

4. Vermeiden sie Modalverben (z.B. müssen, können, sollen,  wollen, mögen, dürfen)dürfen).

Struktur

5. Trennen sie jede Interaktion deutlich von anderen Interaktionen.

6. Beschreiben sie aus dem Blickwinkel eines Außenstehenden.

7. Benennen sie explizit die Akteure.

8. Benennen sie das Ziel des Szenarios explizit.

9. Fokussieren sie bei der Szenariobeschreibung auf die Erfüllung des Ziels. [Poh08]

Page 61: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Spezifikation mit Anwendungsfällen74

Ein Anwendungsfall (use case) spezifiziert Aktionsfolgen (Szenarien) einschließlich Ausnahmesequenzen die ein System oder eineeinschließlich Ausnahmesequenzen, die ein System oder eine Systemkomponente bei der Interaktion mit externen Objekten ausführt, um einen Mehrwert zu erbringen.

Anwendungsfälle gruppieren verschiedene Szenarien. Informal durch Text, z.T. formatiert durch Schlüsselworte. Teilformal, z.B. mit Zustandsautomaten.

[RJB05]

Page 62: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Spezifikation mit Anwendungsfällen: Vor‐ und Nachteile

75Nachteile

+ Modellierung aus Benutzersicht: leicht verstehbar und überprüfbar.+ Hilft bei der Abgrenzung zwischen System und Kontext.+ Dekomposition möglich.

Zusammenhänge / Abhängigkeiten wischen S enarien nicht modelliert– Zusammenhänge / Abhängigkeiten zwischen Szenarien nicht modelliert.– Statische Struktur nicht modelliert.

Page 63: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Szenario vs. Use‐Case76

Ein Szenario ist kontextreicher: Kann mehrere Anwendungsfälle in Beziehung setzen. Kann aber auch eine konkrete Ausgestaltung eines Anwendungsfalls 

seinsein.

Ein Anwendungsfall ist allgemeiner. Ein Anwendungsfall wird immer von einem Akteur initiiert Ein Anwendungsfall wird immer von einem Akteur initiiert. Ein Szenario kann das Zusammenspiel mehrerer Akteure 

darstellendarstellen .

Page 64: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Datenflussdiagramme (DFD)77

Geben den Datenfluss eines Prozesses oder einer Tätigkeit b (wiederzugeben (z. B. die Datenverwendung und Veränderung 

bei der Angebotserstellung in einem Handelsunternehmen). G b i f kti l P kti d S t i d Geben eine funktionale Perspektive des Systems wieder

Sie nützlich um Sequenz von Aktionen  zu verdeutlichen( i b d d ) vom Input (Eingabe des Anwenders)

bis zum Output (Ausgabe des Systems) 

Page 65: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beispiel DFD78

Bild aus: http://www.visualcase.com/tutorials/images

Page 66: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Datenflussdiagramme ‐ Notation79

Input/Output (Terminator)Name

NFunktion (Prozess)

NameFunktion (Prozess)

Datenbank (File)Name

DatenflussName

Page 67: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Verhaltensspezifikation mit Automaten

82

Modellierung des Modellierung des zeitlichdynamischen Systemverhaltens.

Basis: Zustandsautomaten. Teilformales, konstruktives 

VerfahrenVerfahren.+ Leicht nachvollziehbar und 

simulierbar.+ Dekomposition möglich.– Aktionen meist nur genannt, 

aber nicht modelliertaber nicht modelliert.– Statische Struktur nicht 

modelliert.

Page 68: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Atomare Anforderungen – ein wichtiges Qualitätskriterium

85Qualitätskriterium

Eine Anforderung ist atomar, wenn diese Anforderung einen isolierten Sachverhalt beschreibt. Sie kann nicht weiter untergliedert werden.

Folgende Information gehören dazu:

Anforderungsnummer:  ein eindeutiger Identifier, zur Zuordnung/Verfolgbarkeit über den gesamten Life Cyclegesamten Life‐Cycle.

Typ der Anforderung: Constraints , Funktionale Anforderung, Nichtfunktionale Anforderung, …

Beschreibung: der Inhalt der Anforderung.

Begründung: Die Motivation hinter der Anforderung.

Quelle: Person, die die Anforderung zum ersten Mal erwähnt hat.

Fit Kriterium: Die messbare Beschreibung der Anforderung die erlaubt zu überprüfen ob die Fit Kriterium: Die messbare Beschreibung der Anforderung, die erlaubt zu überprüfen, ob die Anforderung erfüllt ist.

Event/Use Case: Verweis auf den Geschäftsvorfall aus dem die Anforderung erwachsen ist.

Priorität Wie wichtig ist die Anforderung im Hinblick auf das gesamte Produkt Priorität: Wie wichtig ist die Anforderung im Hinblick auf das gesamte Produkt.

Konflikte: Gibt es Anforderungen, denen die Anforderung widerspricht.

Andere Materialien: Verweis auf Dokumente oder andere Artefakte, die für diese  Anforderung von Bedeutung sind. 

Page 69: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beispiel: Atomare Anforderungen86

Anforderungsnummer: 75 Typ der Anforderung: Funktionale Anforderung Typ der Anforderung: Funktionale Anforderung Beschreibung: Das Produkt soll einen Alarm auslösen, wenn die 

Wetterstation die eingelesenen Daten nicht übertragen kann. B ü d F hl b i d Üb ittl D t kö i Hi i Begründung: Fehler bei der Übermittlung von Daten können ein Hinweis auf einen Defekt in der Wetterstation sein, die evlt. Wartung benötigt. Die Daten zur Vorhersage des Straßenlage können aus diesem Grund unvollständig sein. u o stä d g se

Quelle: Karl‐Heinz Müller Fit Kriterium: Für jede Wetter Station soll die Anzahl der pro Stunde 

übermittelten Daten innerhalb des durch den Hersteller definiertenübermittelten Daten innerhalb des durch den Hersteller definierten Wertebereiches liegen. 

Event/Use Case:  UC 3.4 WerteÜbertragen  Priorität: Hoch Priorität: Hoch Konflikte: Keine Andere Materialien: Herstelleranleitung der Wetterstation IN34.67

Beispiel angelehnt an [RR06]

Page 70: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beschreibung NFRs90

Typisches Vorgehen:  Fragen stellen: 

«Wie fehlertolerant soll das System sein?» 

Antworten quantifizieren mit Maßen und Abnahmebedingungen 

direkte Maße:  «Die Fehlertoleranz wird in MTTF gemessen und soll grösser als 106 

Betriebsstunden sein »Betriebsstunden sein.» 

indirekte Maße:  «Die Bedienung des System gilt als erlernbar wenn pro Person nicht «Die Bedienung des System gilt als erlernbar, wenn  pro Person nicht 

mehr als zwei Tage Schulung aufgewendet werden  müssen » « Für jede Hauptfunktion der Lernaufwand für ihre erfolgreiche 

Anwendung im Mittel weniger als eine Stunde beträgt.»

Page 71: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Regeln zur Formulierung von NFRs/Zielen91

1. Formulieren sie NFRs kurz und prägnant .2. Verwenden sie Aktivformulierung.3. Formulieren sie überprüfbare NFRs.4. Verfeinern sie nicht überprüfbarer NFRs.5. Formulieren sie den Mehrwert eines NFRs.6. Geben sie eine Begründung für das NFR an.7. Vermeiden sie Lösungsansätze.e e de s e ösu gsa sät e

Page 72: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Personas94

Imaginäre Repräsentation/Beschreibung der Zielgruppe/Nutzergruppeg p / g g pp / g pp

Sollte so detailliert beschrieben werden, dass jeder im  Team das Gefühl hat, diese Person(a) zu kennen.d h llFür 1‐2 der wichtigsten Nutzerrollen.

Der „Benutzer“ wird ersetzt durch die Persona.

Page 73: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Rahmenwerke für Anforderungsdokumente95

VDI/VDE Standard 3694: Referenzstruktur für Lasten‐ und fl h h fPflichtenheft

IEEE Standard 1233‐1998: Referenzstruktur für Systems R i t S ifik tiRequirements Spezifikationen

IEEE Standard 830‐1998 für Software RequirementsspezifikationenRequirementsspezifikationen

Volere Template von Robertson & Robertsonhttp://wwwvolere co uk/template htmhttp://www.volere.co.uk/template.htm

Template von Sören Lauesenhttp://www itu dk/people/slauesen/Papers/RequirementsSL‐http://www.itu.dk/people/slauesen/Papers/RequirementsSL07.doc

Page 74: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Standard‐Formular96

Page 75: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Pflichtenheft [nach IEEE/ANSI 830‐1998] 1/297

1. Einleitung (introduction)

1 1 Zi l d A f d d k t1.1. Ziel des Anforderungsdokuments (purpose)1.2. Anwendungsbereich des Produkts (scope)1 3 Definitionen Akronyme und Abkürzungen (definitions)1.3. Definitionen, Akronyme und Abkürzungen (definitions)1.4. Referenzen (references)1.5. Überblick über den Rest des Dokuments (overview)

2. Allgemeine Beschreibung (description)

2.1. Produktperspektive (perspective)2.2. Produktfunktionen (functions)2 3 Benutzercharakteristika (characteristics)2.3. Benutzercharakteristika (characteristics)2.4. Allgemeine Beschränkungen (constraints)2.5. Voraussetzungen und Abhängigkeiten (assumptions and dependencies)g g g ( p p )

Page 76: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Pflichtenheft [nach IEEE/ANSI 830‐1998] 2/298

3. Spezifische Anforderungen (requirements)

3 1 funktionale Anforderungen (Stark abhängig von der Art des3.1 funktionale Anforderungen (Stark abhängig von der Art des Softwareprodukts)

3.2. nicht‐funktionale Anforderungen3.3 externe Schnittstellen3.4 Design Constraints3.5 Anforderungen an Performance3.6. Qualitätsanforderungen3 7 S ti A f d3.7. Sonstige Anforderungen

4. Anhänge (appendices)

5. Index

Page 77: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Gliederungsrichtlinie: Beispiel sd&m99

aus: Andreas Birk (2004). Anforderungsspezifikation in großen IT-Projektengroßen IT-Projekten. Jahrestagung der GI-Fachgruppe Requirements Engineering, Kaiserslautern.

Page 78: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Pflichtenheft [nach DIN 66905]100

1. Zielbestimmung 4. Produkt-Funktiong1.1. Muss‐Kriterien1.2. Wunsch‐Kriterien

5. Produkt-Leistungen

6. Benutzer-Schnittstelle1.3. Abgrenzungskriterien

2. Produkt‐Einsatz2 1 A d b i h

7. Qualitäts-Zielbestimmung

8. Globale Testfälle2.1. Anwendungsbereiche2.2. Zielgruppen2.3. Betriebsbedingungen

9. Ergänzungen

3. Produkt‐Bedingungen3.1. Software3.2. Hardware3.3. Orgware3 4 Produkt Schnittstellen3.4. Produkt‐Schnittstellen

Page 79: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Struktur des Pflichtenhefts (nach [Som01]) 1/2101

Kapitel Beschreibung

Vorwort Sollte erwartete Leserschaft des Dokuments festlegen und Versionsgeschichte beschreiben. Begründung für die Entwicklung einer neuen V i Z f d V ä dVersion. Zusammenfassung der Veränderungen durch die Version.

Einleitung Notwendigkeit des Systems. Kurzbeschreibung der Funktionen und Zusammenspiel mit anderen u o e u d usa e sp e a de eSystemen. Übereinstimmung des Systems mit den Zielen des Unternehmens.

Begriffe Festlegung der verwendeten Fachbegriffe (A h L h t k i E f h it(Annahme: Leser hat keine Erfahrung mit Fachwissen).

Definition der Benutzeranforderungen Dienste für Benutzer. Nichtfunktionalen Anforderungen. Zu befolgende Produkt- und g gEntwicklungsstandards.

Systemarchitektur Grober Überblick über erwartete Systemarchitektur-zeigt die Verteilung der Funktionen auf S t d l K i h i d d tSystemmodule. Kennzeichnen wiederverwendeter Komponenten.

Page 80: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Struktur des Pflichtenhefts (nach [Som01]) 2/2102

Kapitel Beschreibung

Spezifikation der Systemanforderungen Genauere Beschreibung der funktionalen und nichtfunktionalen Anforderungen. Ggf. weitere Einzelheiten zu nichtfunktionalen Anforderungen (B D fi iti S h itt t ll d(Bsp. Definition von Schnittstellen zu anderen Systemen).

Systemmodelle Beziehungen zwischen den Systemkomponenten und dem System und seiner Umgebung (Klassen-, y g g ( ,Datenfluss-, semantische Datenmodelle)

Systementwicklung Grundlegende Voraussetzungen, auf denen das System basiert. Erwartete Veränderungen.

Anhänge Genauere spezifische Informationen die sich aufAnhänge Genauere spezifische Informationen, die sich auf die Anwendung beziehen.

Index Fachbegriffe, Diagramme, Funktionen

Page 81: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Volere Template 1/3103

PROJECT DRIVERS:

1 The Purpose of the Product1. The Purpose of the Product2. Client, Customer, Stakeholders3. Users of the Product

PROJECT CONSTRAINTS:

4 M d d C i4. Mandated Constraints5. Naming Conventions and Definitions6. Relevant Facts and Assumptionsp

FUNCTIONAL REQUIREMENTS:

7. The Scope of the Work8. The Scope of the Product9 Functional and Data Requirements9. Functional and Data Requirements

Page 82: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Volere Template 2/3104

NON‐FUNCTIONAL REQUIREMENTS:

10 Look and Feel10. Look and Feel11. Usability and Humanity12. Performance13. Operational14. Maintainability and Support15 S it15. Security16. Cultural and Political17. Legal g

Page 83: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Volere Template 3/3105

PROJECT ISSUES:

18 Open Issues18. Open Issues19. Off‐the‐shelf Solutions20. New Problems21. Tasks22. Migration to the New Product23 Ri k23. Risks24. Costs25. User Documentation26. Waiting Room27. Ideas for Solutions

Page 84: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Qualitätskriterien für Anforderungsartefakte107

Vollständigkeit Nachvollziehbarkeit Korrektheit Eindeutigkeit Verständlichkeit Konsistenz ÜberprüfbarkeitÜbe p ü ba e t Bewertet nach Wichtigkeit und Stabilität

Für einzelne Anforderungen aber auch für das ganze Dokument!

Page 85: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Darstellungsregeln108

Einzelanforderungen in kleinen Einheiten fassen: eine Kernaussage pro EinzelanforderungKernaussage pro Einzelanforderung.

Zu jedem geforderten Resultat die Funktion und die Eingabedaten, welche das Resultat erzeugen, spezifizieren.Eingabedaten, welche das Resultat erzeugen, spezifizieren.

Mögliche Ausnahmesituationen spezifizieren. Implizite Annahmen aufdecken und explizit formulieren. Implizite Annahmen aufdecken und explizit formulieren. Leistungs‐ und Qualitätsanforderungen quantitativ 

spezifizieren. All‐Quantifizierungen kritisch hinterfragen. Anforderungen strukturieren (zum Beispiel durch 

l l d )Kapitelgliederung). Redundanz nur dort, wo für leichtes Verständnis notwendig.

P ä i ifi i Präzise spezifizieren.

Page 86: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Zielgruppen für das Pflichtenheft109

• Festlegen von Anforderungen• Überprüfen ob die AnforderungenSystemkunden Überprüfen, ob die Anforderungen

geeignet sind• Verantwortlich für Änderungen

Manager• Erstellen des Angebots

• Planung des Entwicklungsprozesses

Systementwickler • Verstehen, was für ein System entwickelt werden soll

Systemtester • Entwickeln von Validierungstests

Systemwarter• Verstehen des Systems und der

Beziehungen zwischen seinenSystemwarter Beziehungen zwischen seinen Bestandteilen

Page 87: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Beispiel: Lastenheft und Pflichtenheft110

1. Die Software muss über Mittel zur Darstellung externer, von anderen Werkzeugen erzeugter Dateien verfügen und auf sie zugreifen können.

1 1 D B ll üb Mö li hk i D fi i i1.1 Der Benutzer sollte über Möglichkeiten zur Definition externerDateitypen verfügen.

1.2 Jeder externe Dateityp kann eine damit verknüpfte Anwendungb it it d di D t i b b it t i dbesitzen, mit der die Datei bearbeitet wird.

1.3 Jeder externe Dateityp kann als bestimmtes Symbol auf dem Bildschirm des Anwenders dargestellt werden.

1.4 Es sollten Möglichkeiten zur Definition des externen Symbols für externe Dateitypen durch den Benutzer bereitgestellt werden.

1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Datei1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Dateirepräsentiert, so soll die durch dieses Symbol dargestellte Datei mitder Anwendung geöffnet werden, die mit dem entsprechendenexternen Dateityp verknüpft ist.

Page 88: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Entwickleranforderung111

Page 89: ANFORDERUNGSANALYSE UND Kapitel SPEZIFIKATION TEIL 1services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel03_01.pdf · Übersicht 1 1. Einführung in das Software Engineering

Literatur113

Klaus Pohl,