AnforderungsanalyseSoftware Engineering I
WS 2010/2011
Dr.-Ing. Ina Schaefer1
Software Systems EngineeringTU Braunschweig
1Mit Folien von Prof. Dr. K. Ostermann/Dr. Chr. Kästner und Dr. A. Herrmann
Ina Schaefer SE I - WS 2011/2011 1
Inhalt der Vorlesung
1. Motivation für Anforderungsanalyse
2. AnforderungsanalyseGrundbegriffeAufgabenAnforderungsanalyse und Anforderungsvalidierung
3. Beschreibung von AnforderungenAnwendungsfälleLastenheft
Ina Schaefer SE I - WS 2011/2011 2
Motivation für Anforderungsanalyse
Motivation!"#$%&'()&*"+&,(-./(0$1
2(%34.)#%0&(%&*($&563/'")$/$-.%(78Ina Schaefer SE I - WS 2011/2011 3
Motivation für Anforderungsanalyse
Warum Anforderungsanalyse?
Problemquellen bei Software-Projekten:
• Unvollständige Anforderungen 13.1%• Kunden nicht ausreichend einbezogen 12.4 %• Mittel nicht ausreichend 10.6 %• Unrealistische Erwartungen 9.9 %• Mangelnde Unterstützung durch Management 9.3 %• Änderungen in den Anforderungen 8.7 %• mangelnde Planung 8.1 %
(nach [CHAOS Report, Standish Group 1995])
Ina Schaefer SE I - WS 2011/2011 4
Motivation für Anforderungsanalyse
Probleme bei der Anforderungsanalyse
• Kunden wissen nicht was sie wirklich wollen.• Kunden benutzen ihre eigene Fachsprache.• Verschiedene Stakeholder2 können widersprüchliche
Anforderungen haben.• Politische und organisatorische Faktoren können Anforderungen
beeinflussen.• Anforderungen ändern sich während der Analyse und
Entwicklung.• Neue Stakeholder mischen sich ein.
2Stakeholder = Interessierte / Betroffene / Projektbeteiligte / AnspruchsgruppenIna Schaefer SE I - WS 2011/2011 5
Anforderungsanalyse Grundbegriffe
Stakeholder
Einzelpersonen und Organisationen
• die aktiv an einem Projekt beteiligt sind.• deren Interessen als Folge der Projektdurchführung oder des
Projektabschlusses positiv oder negativ beeinflusst werdenkönnen.
• die das Projekt und seine Ergebnisse beeinflussen.
Ina Schaefer SE I - WS 2011/2011 6
Anforderungsanalyse Grundbegriffe
Anforderungen
Benutzeranforderungen
Aussagen in natürlicher Sprache, sowie Diagramme zur Beschreibungder Dienste, die das System leisten soll, und der Randbedingungen,unter denen es betrieben wird.(Systembeschreibung aus Kundensicht, Lastenheft)
Systemanforderungen
Detaillierte Festlegung von Funktionen, Diensten undBeschränkungen. Beschreibung, was implementiert werden soll.(Systembeschreibung aus technischer Sicht, Pflichtenheft)
Ina Schaefer SE I - WS 2011/2011 7
Anforderungsanalyse Grundbegriffe
Zusammenhang Benutzer- und Systemanforderungen
!"
#$%&'()'*$+,-.&/*0)$1)
#$234,)!"#"$%&'()(*#"+",
5$16*'%
#$%&'()'*$+,-5'07113*$+
!-%./+-%&%)$"%*+0+$($+1),
84,1)0-9&()337)'*$+
!"#"$%&'&12%**+)3,
#$%&'()'*$+,-8:);7%7/217&$
<=2,1)$>)%1<!
"-%./+-%&%)$""4%0+5+0($+1),
?%37@>1)$>)%1
"#$%&'()%*+,-.,/(0(&*'()%!
"#"$%& "4%0+5+0($+1)1
A*$()$-#$%&'()'*$+)$
B2,C7,1CD5E =2,1)$> ?%37@>1)$> FF# 85?G9=
Ina Schaefer SE I - WS 2011/2011 8
Anforderungsanalyse Grundbegriffe
Funktionale und Nicht-funktionale Anforderungen
Funktionale Anforderungen Nicht-funktionale Anforderungen
• Was soll das Systemleisten?
• Welche Dienste soll esanbieten?
• Eingaben,Verarbeitungen,Ausgaben
• Verhalten in bestimmtenSituationen, ggf. was solles explizit nicht tun
• Wie soll dasSystem/einzelneFunktionen arbeiten?
• Qualitätsanforderungenwie Performanz undZuverlässigkeit
• Anforderungen an dieBenutzbarkeit desSystems
Ina Schaefer SE I - WS 2011/2011 9
Anforderungsanalyse Grundbegriffe
Beispiel: Funktionale Anforderungen
Funktion "Vorlesung in Vorlesungverzeichnis eintragen"• Eingaben: Raum, Zeit und Titel einer Vorlesung.• Verarbeitungsschritte:
I Prüfe, ob der Vorlesungstitel schon vergeben istI Prüfe, ob der Raum zur angegebenen Zeit schon vergeben istI Wenn nicht, wird die neue Vorlesung eingetragen und die Daten der
Vorlesung werden angezeigt.I Falls vergeben, wird die Vorlesung nicht eingetragen und eine
entsprechende Fehlermeldung wird angezeigt.
• Ausgaben: Die Vorlesung wird angezeigt oder ein Fehler wirdgemeldet.
Ina Schaefer SE I - WS 2011/2011 10
Anforderungsanalyse Grundbegriffe
Beispiel: Funktionale Anforderungen (2)
• Aktionen, die vom System ausgeführt werden sollen
Bsp.: Das System muss Vorlesungen in die DB aufnehmenkönnen.
• Systeminteraktionen, die dem Nutzer ermöglicht werden
Bsp.: Das System muss es dem Administrator beim Eintrageneiner Vorlesung ermöglichen ermöglichen, Raum, Zeit und Titeleinzugeben.
• allg. funkt. Vereinbarungen u. Einschränkungen
Bsp.: Der Client ist für den Kommunikationsaufbau zuständig.
Ina Schaefer SE I - WS 2011/2011 11
Anforderungsanalyse Grundbegriffe
Nicht-funktionale Anforderungen!"#$%&'()*%"+),-./0)'+12.1()3.)
4")'5$1()3/")/2"./6+'%7,1.%.#$)"*89
Ina Schaefer SE I - WS 2011/2011 12
Anforderungsanalyse Grundbegriffe
Nicht-funktionale Anforderungen (2)
• NFR3 umfassen Qualitätsanforderungen an Produkt und Prozess.• Beschreibung von NFR oft vernachlässigt, oft unsystematisch und
ungenau.• NFR müssen integriert mit FR erfasst und spezifiziert werden.• NFR priorisieren nach Kosten/Nutzen.• NFR werden in der Praxis meist sehr ungenau erfasst.
3NFR = Non-functional RequirementsIna Schaefer SE I - WS 2011/2011 13
Anforderungsanalyse Grundbegriffe
Beispiele für Nicht-funktionale Anforderungen
• Technische Anforderungen:
Das System muss mit Java entwickelt werden und muss in derSun Java VM 1.5 laufen.
• Ergonomische Anforderungen
Das System muss die gespeicherten Objekte formatiert ausgebenkönnen (Formatvorgabe).
Die Benutzerführung erfolgt in deutsch.
• Anforderungen an die Dienstqualität
Das System muss jede Anfrage des Benutzers innerhalb von 30Sekunden ausführen (auf System XY).
Der Speicherbedarf darf 512MB nicht übersteigen.
Ina Schaefer SE I - WS 2011/2011 14
Anforderungsanalyse Grundbegriffe
Beispiele für Nicht-funktionale Anforderungen (2)
• Zuverlässigkeit
Die Verfügbarkeit des Systems muss bei 99.999 % liegen.
• Anforderungen an den Entwicklungsprozess
Der Entwickler muss mit dem Kunden monatliche Reviews der zuerstellenden Dokumente durchführen.
• Rechtlich-vertragliche Anforderungen
Der Kunde leistet für jeden abgenommenen Meilenstein ein Drittelder vertraglich vereinbarten Summe für die Entwicklung desSystems.
Die deutsche Datenschutzrichtlinie muss erfüllt sein.
Ina Schaefer SE I - WS 2011/2011 15
Anforderungsanalyse Aufgaben
Bestandteile der Anforderungsanalyse
• Anforderungsermittlung• Anforderungsspezifikation• Anforderungsanalyse• Anforderungsvalidierung• Anforderungsmanagement
Ina Schaefer SE I - WS 2011/2011 16
Anforderungsanalyse Aufgaben
Aufgaben in der Anforderungsanalyse
• Anforderungsermittlung:Sammeln einer vollständige Menge von Anforderungen vonStakeholdern.
• Anforderungsformulierung:ermittelte Anforderungen so beschreiben, dass sie eindeutig,testbar und verständlich sind.
• Anforderungsanalyse:Klassifizierung, Bewertung, Vergleich und Prüfung der ermitteltenAnforderungen
Ina Schaefer SE I - WS 2011/2011 17
Anforderungsanalyse Aufgaben
Aufgaben in der Anforderungsanalyse (2)
• Anforderungsvalidierung:Die Kunst, zu richtigen und widerspruchsfrei formuliertenAnforderungen zu gelangen.
• Anforderungsmanagement:Prüfung und Änderung von Anforderungen.
Ina Schaefer SE I - WS 2011/2011 18
Anforderungsanalyse Aufgaben
Methoden zur Anforderungsermittlung
• Interviews• Focus Group• Fragebögen• Dokumentenanalyse• Beobachtungen• Prototyping
Ina Schaefer SE I - WS 2011/2011 19
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Qualitätsmerkmale für Software
nach ISO 9126/ DIN 66272:• Funktionalität
I AngemessenheitI SicherheitI Genauigkeit der BerechnungI InteroperabilitätI Konformanz zu Standards
• BenutzbarkeitI VerständlichkeitI ErlernbarkeitI Bedienbarkeit
• EffizienzI ZeitverhaltenI Verbrauchsverhalten
Ina Schaefer SE I - WS 2011/2011 20
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Qualitätsmerkmale für Software (2)
• ZuverlässigkeitI ReifeI FehlertoleranzI Wiederherstellbarkeit
• ÄnderbarkeitI AnalysierbarkeitI ModifizierbarkeitI StabilitätI Prüfbarkeit
• ÜbertragbarkeitI AnpassbarkeitI InstallierbarkeitI Konformanz zu StandardsI Austauschbarkeit
Ina Schaefer SE I - WS 2011/2011 21
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Was sind gute Anforderungen?
• eindeutig (nur eine mögliche Interpretation)
• vollständig ( alle nicht-funktionalen Anforderungen, alleSystemreaktionen - auch auf ungültige Eingaben, expliziteKennzeichnungen von offenen Punkten)
• konsistent (keine Widersprüche, konsistente Terminologie)
• korrekt (nur ‘’richtige” Anforderungen)
Ina Schaefer SE I - WS 2011/2011 22
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Was sind gute Anforderungen? (2)
• verifizierbar (durch ein Verfahren, z.B. Messen, überprüfbar)
• gewichtet (priorisiert bzgl. Wichtigkeit und Stabilität)
• änderbar (klare Struktur, keine Redundanz)
• nachvollziehbar (Quelle der Anforderungen festhalten, eindeutigeIdentifikatoren)
[IEEE Std. 830-1998]
Ina Schaefer SE I - WS 2011/2011 23
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Klassifikation von Anforderungen
• Zusammengehörigkeit und Überlappungen von Anforderungen ineiner großen Menge erkennen(z.B. von unterschiedlichen Autoren)
• Vollständigkeit der Anforderungen prüfen• fehlende Anforderungen erkennen• Ausschnitte aus dem Anforderungsdokument für bestimmte
Rollen erzeugen (“Sichten”)
Ina Schaefer SE I - WS 2011/2011 24
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Kriterien zur Klassifikation
• Vermarktbarkeit (Features)• Abhängigkeiten, z.B. technische Abhängigkeiten• Gegenstand der Anforderung: Systemfunktionalität, Benutzer-
schnittstelle, Datenbank, Kommunikation, NFA (z.B. Performanz)• Betroffene Benutzergruppe: System-Administrator, Verwaltungs-
angestellter, Lagerarbeiter, ...• Priorität der Anforderung: essentiell, notwendig, wünschenswert• Kosten einer Anforderung
Ina Schaefer SE I - WS 2011/2011 25
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Priorisierung von Anforderungen
• Grundlage von technischen und Managenemt-Entscheidungen• Kompromisse zwischen in Konflikt stehenden Anforderungen
finden• Releases der Software planen (zuerst die wichtigen
Anforderungen)
Ina Schaefer SE I - WS 2011/2011 26
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Prioritäten von Anforderungen
• Essentiell: die Anforderung muss implementiert werden, sonst istdas System nutzlos
• Notwendig: das System ist ohne Umsetzung dieser Anforderungweniger effizient/effektiv
• Wünschenswert: das System wäre mit dieser Anforderungattraktiver
Ina Schaefer SE I - WS 2011/2011 27
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Prüfung von Anforderungen
• Wird der Bedarf des Kunden vollständig abgedeckt?• Verständlich formuliert?• Konsistent mit anderen Anforderungen?• Realistisch mit Budget und Technologie?• Anforderung prüfbar?• Änderbar ohne Einfluss auf andere Anforderungen?
Wichtig:
• Regelmäßige Reviews• Kunden und potentielle Benutzer in Anforderungsanalyse
einbeziehen.
Ina Schaefer SE I - WS 2011/2011 28
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Abgrenzungskriterien
Was soll nicht gemacht werden?
• Sinnvoll, dies expliziert zu klären.• Dem Kunden klar machen, worauf er verzichtet.• Schutz vor Änderungsanträgen
Ina Schaefer SE I - WS 2011/2011 29
Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung
Abgrenzungskriterien (2)
Beispiele:
• Kein Fokus auf intuitive Bedienung, sondern Spezialsoftware fürgeschulte Benutzer.
• Schützt nicht vor Fehlern des Benutzers
• Multilinguale Benutzeroberfläche nicht geplant
Ina Schaefer SE I - WS 2011/2011 30
Beschreibung von Anforderungen Anwendungsfälle
Anwendungsfälle (Use Cases)
Grundidee:
Gliederung der Funktionalität in logisch zusammengehörige undhandliche funktionale Einheiten, Beschreibung in standardisierter Form
Anwendungsfall
Abgeschlossene, zusammenhängende Einheit; Teil der Funktionalitätdes Systems
Ina Schaefer SE I - WS 2011/2011 31
Beschreibung von Anforderungen Anwendungsfälle
Anwendungsfallbeschreibung
• Titel:• Kurzbeschreibung:• Aktoren:• Vorbedingungen:• Beschreibung des Ablaufs:• Auswirkungen:• Anmerkungen:
Ina Schaefer SE I - WS 2011/2011 32
Beschreibung von Anforderungen Anwendungsfälle
Beispiel Anwendungsfall
• Titel: Vorlesung eintragen• Kurzbeschreibung: Dozent gibt Raum, Zeit und Titel einer
Vorlesung ein und legt einen Vorlesungseintrag an.• Aktor: Dozent• Vorbedingungen: Eine Vorlesung mit diesem Titel gibt es noch
nicht.• Beschreibung des Ablaufs:
I Prüfe, ob der Raum zur angegebenen Zeit schon vergeben istI Wenn nicht, wird die neue Vorlesung eingetragen und die Daten der
Vorlesung werden angezeigt.I Falls vergeben, wird die Vorlesung nicht eingetragen und eine
entsprechende Fehlermeldung wird angezeigt.• Auswirkungen: Die Vorlesung wird angezeigt oder ein Fehler wird
gemeldet.• Anmerkungen:
Ina Schaefer SE I - WS 2011/2011 33
Beschreibung von Anforderungen Anwendungsfälle
Aktoren
AktorObjekt der Systemumgebung, das mit dem System interagiert (undeinen oder mehrere Anwendungsfälle auslösen kann).
• Aktoren können Personen (System-Nutzer), externe Geräte odermit dem System verbundene Nachbarsysteme sein.
• Aktoren tauschen mit dem System Nachrichten aus und könnenals Sender und/oder Empfänger von Nachrichten auftreten.
• Aktoren sind i.a. selbst nicht Bestandteile des Systems. Oftmüssen Daten über sie jedoch (z.B. zur Regelung derZugangsberechtigung) verwaltet werden.
Ina Schaefer SE I - WS 2011/2011 34
Beschreibung von Anforderungen Anwendungsfälle
Use Case Diagramme
Bestandteile:• Aktor• Use Case mit Bezeichner B• Systemgrenze mit
Systembezeichner S• Kommunikationsbeziehung
zwischen Aktoren undAnwendungsfällen
• Beziehung zwischenAnwendungsfällen
!"#$#%&#'()%'*%+#%,-%./01"",21.31$$#%
!2%0453-%.'2%',2#'6)0&+13#K%289:
! *8&)3;'
! *%+#%,-%.01""'$2&'
<#=#275%#3'<;'
! 6>/&#$.3#%=#'?$2&'
6>/&#$@#=#275%#3'6A;
! B)$$-%281&2)%/@#=2#5-%.'
?=+2/75#%'*8&)3#%'-%,'
*%+#%,-%./0C""#%A
! <#=2#5-%.'=+2/75#%'
*%+#%,-%./0C""#%
!
"
##$%&$'())*+++++++
##,'-./($))
Ina Schaefer SE I - WS 2011/2011 35
Beschreibung von Anforderungen Anwendungsfälle
Beziehungen zwischen Use Cases
!"#$"%&'("')#*$+,%"')-'*"'.&'(+/011"')
2$'/3%4&'()$').$")56/7*84"7",%'$9::
! -&+/3%4&'();6')-'*"'.&'(+/811)-)+,%1$"<7).$")-&+/3%4&'();6')-'*"'.&'(+/811)!)"$'=)
! !+>?)@-&/748()A"84A"$7"'@)+,%1$"<7)@B8%1&'();"48'18++"'@)"$'=
! -&+/3%4&'();6')-'*"'.&'(+/811)-)98'')C&'7"4)A"+7$DD7"')!".$'(&'("'E)"4*"$7"47)*"4."').&4,%)"$'")-&+/3%4&'();6')-'*"'.&'(+/811)!=)
! !+>?)!"$D)@-&/748()A"84A"$7"'@)*$4.)F /811+)"$'")-'/48(").8/34);6418()F '6,%)"$')G87816();"4+8'.7=
! -'*"'.&'(+/811)-)("'"481$+$"47)-'*"'.&'(+/811)!H).=%=)!)+7"%7)/34)"$'")I"'(");6')5>"#$81/011"');6')-=))
! !+>?)@-&/748()A"84A"$7"'@)("'"481$+$"47)@G8&/8&/748()A"84A"$7"'@)&'.)@J"498&/+8&/748()A"84A"$7"'@)
!!"#$"%&''(((((((
!!)%*+,&"''
-
.
-
.
-
.
• Ausführung von Anwendungsfall A schließtdie Ausführung von Anwendungsfall B ein.
Beispiel: Auftrag bearbeiten schließt Zahlungveranlassen ein.
Ina Schaefer SE I - WS 2011/2011 36
Beschreibung von Anforderungen Anwendungsfälle
Beziehungen zwischen Use Cases (2)!"#$"%&'("')#*$+,%"')-'*"'.&'(+/011"')
2$'/3%4&'()$').$")56/7*84"7",%'$9::
! -&+/3%4&'();6')-'*"'.&'(+/811)-)+,%1$"<7).$")-&+/3%4&'();6')-'*"'.&'(+/811)!)"$'=)
! !+>?)@-&/748()A"84A"$7"'@)+,%1$"<7)@B8%1&'();"48'18++"'@)"$'=
! -&+/3%4&'();6')-'*"'.&'(+/811)-)98'')C&'7"4)A"+7$DD7"')!".$'(&'("'E)"4*"$7"47)*"4."').&4,%)"$'")-&+/3%4&'();6')-'*"'.&'(+/811)!=)
! !+>?)!"$D)@-&/748()A"84A"$7"'@)*$4.)F /811+)"$'")-'/48(").8/34);6418()F '6,%)"$')G87816();"4+8'.7=
! -'*"'.&'(+/811)-)("'"481$+$"47)-'*"'.&'(+/811)!H).=%=)!)+7"%7)/34)"$'")I"'(");6')5>"#$81/011"');6')-=))
! !+>?)@-&/748()A"84A"$7"'@)("'"481$+$"47)@G8&/8&/748()A"84A"$7"'@)&'.)@J"498&/+8&/748()A"84A"$7"'@)
!!"#$"%&''(((((((
!!)%*+,&"''
-
.
-
.
-
.
• Anwendungsfall A kann (unter bestimmtenBedingungen) erweitert werden durchAnwendungsfall B.
Beispiel: Bei Auftrag bearbeiten wird - fallsangefragt - noch Katalog versandt.
• Anwendungsfall A generalisiertAnwendungsfall B, d.h. B steht für eineMenge von Spezialfällen von A.
Beispiel: Auftrag bearbeiten generalisiertKaufauftrag bearbeiten und Verkaufsauftragbearbeiten.
Ina Schaefer SE I - WS 2011/2011 37
Beschreibung von Anforderungen Anwendungsfälle
Beispiel: Use Case Diagramm
!"#$%#"&'("#)("#)*+,-"$(.)/")01)2$*+&&0#+23+44(
5#)*6-31)2(#)(0#"(78*9/+3"9",-)#:;<
! !"#$%&'()#$%*+,+-&/#30(013,-(0")(=1)0")(>?(.1984+9")@")19A"3B(+1$2"&C$9D(0"3("#)"(E")2"(F8)(G8$")D(H&+$,-")(80"3(=#$9")(A136,:2"@")(/#&&I(
!"$,-3"#@1)2(0"$(.@&+1*$'
! E#9(J"0"4(A136,:2"2"@")")(796,:("3-C-9(0+$(7K$9"4(0#"(.)A+-&(0"3(3"2#$93#"39")(796,:"($8/#"(0#"(L+2"$2"$+49+)A+-& *63(0#"(@"93"**")0"(=+9"283#"I(
! M"))(0"3(=1)0"(+&&"(796,:"(+@2"&#"*"39(-+9D(036,:9("3("#)")(N1#991)2$:)8%* 1)0("3-O&9("#)"(N1#991)2(6@"3(+&&"(+@2"&#"*"39")(796,:"(1)0(0"3")(P"$+49+)A+-&I
Q%"3+983
!")19A"3
!""#$%&'(%&)*+&
,&-./
0%#-./$"1"2
,&+**'
3+&"24523"#2
6"#7.8&
"#9&"::"2
Ina Schaefer SE I - WS 2011/2011 38
Beschreibung von Anforderungen Anwendungsfälle
Beispiel: Use Case Diagramm (2)
Anwendungsfallbeschreibung
• Title: Stück zurückgeben• Kurzbeschreibung: Rückgabe von Leergut• Aktor: Kunden (= Automatenbenutzer)• Vorbedingung: Automat akzeptiert Leergut,• Beschreibung des Ablaufs:
I Bei Eingabe, Erhöhung von Anzahl der registrierten Stücke sowiedie Tagesgesamtanzahl für die betreffende Kategorie.
I Bei Druck auf Quittungsknopf, Ausdruck von Quittung über alleabgelieferten Stücke und deren Gesamtanzahl.
• Auswirkungen: Quittung wird ausgegeben.• Anmerkungen:
Ina Schaefer SE I - WS 2011/2011 39
Beschreibung von Anforderungen Anwendungsfälle
Beispiel: Größeres Use Case Diagramm!"#$"%"&'("#&)#"*+',-."-/0-1&23**/#31%344
56
!!"#$%&'())
!!"#$%&'())
!!"#$%&'())
Ina Schaefer SE I - WS 2011/2011 40
Beschreibung von Anforderungen Lastenheft
Lastenheft
LastenheftVom Auftraggeber festgelegte Gesamtheit der Forderungen an dieLieferungen und Leistungen eines Auftragnehmers an den Auftrag.
[DIN69905]
• Knappe Beschreibung der fachlichen Basisanforderungen• aus Sicht des Auftraggebers/Kunde• Beschreibung des WAS und WOFÜR• Grundlage für das Pflichtenheft4
• Festes Gliederungsschema
4Beschreibung des Systemrealisierung aus Sicht des Auftragnehmers/EntwicklersIna Schaefer SE I - WS 2011/2011 41
Beschreibung von Anforderungen Lastenheft
Gliederungsschema des Lastenhefts
• ZielbestimmungI Welche Ziele sollen durch den Einsatz der Software erreicht
werden?
• ProdukteinsatzI Für welche Anwendungsbereiche und Zielgruppen ist die Software
vorgesehen?
• ProduktübersichtI In welcher Umgebung oder welchem Kontext soll die Software
arbeiten?
Ina Schaefer SE I - WS 2011/2011 42
Beschreibung von Anforderungen Lastenheft
Gliederungsschema des Lastenhefts (2)
• ProduktfunktionenI Was sind die Hauptfunktionen des Produktes aus Sicht des
Auftraggebers?I Die Hauptfunktionen (Kernfunktionen) werden typischerweise
einzeln gekennzeichnet um sich in späteren Dokumenten auf siebeziehen zu können.
I Hauptfunktionen sind beispielsweise Anzeigefunktionen,Änderungs- und Löschfunktionen, Erinnerungsfunktionen,Suchfunktionen, ...
• ProduktdatenI Was sind die (permanent gespeicherten) Hauptdaten des
Produktes?I Einheitliche Kennzeichnung der HauptdatenI Hauptdaten sind beispielsweise Konfigurationsdaten,
Benutzerdaten, History-Daten, ...
Ina Schaefer SE I - WS 2011/2011 43
Beschreibung von Anforderungen Lastenheft
Gliederungsschema des Lastenhefts (3)
• ProduktleistungenI Werden für bestimmte Funktionen besondere Ansprüche in Bezug
auf Zeit, Datenumfang oder Genauigkeit gestellt? Wenn ja, welche?I Einheitliche Kennzeichnung der ProduktleistungenI Produktleistungen werden eventuell durch andere Produkte wie
beispielsweise von einer relationalen Datenbank bewerkstelligt. Beieiner Messwerterfassung sollten hier die Sollbedingungen stehen.
• QualitätsanforderungenI Zuverlässigkeit, Robustheit, Benutzungsfreundlichkeit, Effizienz, ...
• Ergänzungen
Ina Schaefer SE I - WS 2011/2011 44
Beschreibung von Anforderungen Lastenheft
Lastenheft - Beispiel nach Balzert
13
SE 2 – Lastenheft / Pflichtenheft
© Prof. Dr. Liggesmeyer
Lastenheft
Beispiel
Ina Schaefer SE I - WS 2011/2011 45
Beschreibung von Anforderungen Lastenheft
Lastenheft - Beispiel nach Balzert (2)
14
SE 2 – Lastenheft / Pflichtenheft
© Prof. Dr. Liggesmeyer
Lastenheft
Beispiel
Ina Schaefer SE I - WS 2011/2011 46
Beschreibung von Anforderungen Lastenheft
Lastenheft - Beispiel nach Balzert (3)
15
SE 2 – Lastenheft / Pflichtenheft
© Prof. Dr. Liggesmeyer
Lastenheft
Beispiel
Ina Schaefer SE I - WS 2011/2011 47
Beschreibung von Anforderungen Lastenheft
Stilratgeber
• Kurze Sätze und kurze Absätze (max. ca. 7 Sätze), da dasmenschliche Kurzzeitgedächtnis begrenzt ist.
• Nur eine Aussage pro Satz, Verschachtelungen vermeiden.• Konsistente Terminologie, Abkürzungen sparsam verwenden.• Offene Punkte kennzeichnen: „TBD“, „ToDo“.• Generalität vermeiden, klare Referenzen verwenden.• Verbindlichkeit klar formulieren: „Muss, kann, soll“ etc. mit
Bedacht verwenden.• Aktiv formulieren: „Das System . . . .“.
Ina Schaefer SE I - WS 2011/2011 48
Beschreibung von Anforderungen Lastenheft
Identifizierbarkeit von Anforderungen
• Eindeutiges, nicht änderbares Kürzel/ID für Anforderungen• Codierung z.B. von den Typ der Anforderung, Herkunfts-
dokument, ...Beispiele:
I LH-FA11= Funktionale Anforderung 11 im LastenheftI PA17 = Performanzanforderung 17I LH-FA-Temp19= Funktionale Anforderung 19 des Teilsystems
Temperatur im Lastenheft
• Gruppierung ähnlicher Anforderungen
Ina Schaefer SE I - WS 2011/2011 49
Zusammenfassung
• Motivation und Ziel der Anforderungsanalyse• Funktionale und Nicht-funktionale Anforderungen• Aufgaben der Anforderungsanalyse• Use Cases (Text und Diagramme)• Lastenheft
Ina Schaefer SE I - WS 2011/2011 50