46 KiB
Ausdruck
Montag, 5. Februar 2018
15:34
{width="8.333333333333334in" height="11.75in"}
Software Engineering
Anforderungsanalyse
Klaus Ostermann
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Agenda
Funktionale und nichtfunktionale Anforderungen
Benutzeranforderungen
Systemanforderungen
Schnittstellenspezifikation
Das Pflichtenheft
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Warum Anforderungsanalsyse?
Software Engineering
3
{width="8.333333333333334in" height="11.75in"}
Bauen wir das Richtige?
{width="6.125in" height="4.302083333333333in"}
{width="8.333333333333334in" height="11.75in"}
{width="7.96875in" height="3.7916666666666665in"}
{width="8.333333333333334in" height="11.75in"}
Beispiel (Fortsetzung)
'Naja, eigentlich brauchen wir ein Formular das wir per
Email verteilen können und einen Ort (HTML) wo wir die
ausgefüllten Formulare ablegen können und einen
Algorithmus der uns ausrechnet wann wir uns Treffen
können. Achja, am besten wäre es wenn, falls nicht alle
können, irgendwie berücksichtigt wird dass alle wichtigen
Personen dabei sind. Es wäre auch toll, wenn es eine
Möglichkeit gäbe ob jeder so ein Formular ausgefüllt hat.
Wenn nicht sollte es am besten eine Liste der übrigen
Personen geben. Und wenn's irgendwie möglich ist sollte
auch eine automatische Einladung an alle beteiligten
Personen geschickt werden können.
Wie kommt man hier zu klaren Anforderungen?
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Probleme
Kunden wissen nicht was sie wirklich wollen
Kunden benutzen ihre eigene Fachsprache
Verschiedene Stakeholder* 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
{width="1.9895833333333333in" height="1.28125in"}
* Stakeholder = Anspruchträger / Interessierte / Betroffene / Projektbeteiligte / Anspruchsgruppen
Software Engineering
Erfasster Bildschirmausschnitt: 05.02.2018 15:45
{width="8.333333333333334in" height="11.75in"}
Wann sind wir fertig?
Szenario: Neue Firma, 3 Mitarbeiter (Gehalt 45.000 EUR)
Bekommen Auftrag von Firma $BigCooperation
geschätzter Aufwand 9 Bearbeiterjahre
Festpreis 500.000 EI-JR, 250.000 EUR sofort, Rest nach
Abnahme
Fertigstellung nach 3 Jahren
Firma verweigert Abnahme, fordert Nacharbeiten
-> Schuldenfalle
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Anforderungen
Software Engineering
9
{width="8.333333333333334in" height="11.75in"}
Definition: Anforderung
Benutzeranforderungen sind Aussagen in natürlicher
Sprache sowie Diagramme zur Beschreibung der Dienste,
die das System leisten soll, und der Randbedingungen,
unter denen es betrieben wird.
Systemanforderungen legen die Funktionen, Dienste und
Beschränkungen detailliert fest. Das Pflichtenheft (auch
funktionale Spezifikation genannt) sollte präzise sein. Es
muss genau definieren, was implementiert werden soll.
Es kann als Teil des Vertrages zwischen dem Käufer und
dem Softwareentwickler dienen.
10
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Beispiel
Definition einer Benutzeranforderung
1. LIBSYS soll alle Daten nachverfolgen, die von den Lizenzagenturen in Großbri-
tannien und anderswo benötigt werden.
Spezifikation der Systemanforderungen
1.1 Bei der Anforderung eines Dokuments von LIBSYS soll dem Antragsteller ein
Formular angezeigt werden, das Einzelheiten iiber den Benutzer und die Anfor-
derung aufnimmt.
1.2 LIBSYS-Anforderungsformulare sollen vom Datum der Anforderung an fünf Jahre
lang auf dem System gespeichert werden.
1.3 Alle LIBSYS-Anforderungsformulare müssen nach dem Benutzer, dem Titel des
angeforderten Materials und dem Lieferanten indiziert werden.
1.4 LIBSYS soll ein Protokoll aller Anforderungen unterhalten, die an das System
gestellt wurden.
1.5 Bei Material, das Leihrechten unterliegt, müssen die Angaben der Ausleihvor-
gänge monatlich an die in LIBSYS registrierten Lizenzagenturen gesendet werden.
11
{width="8.333333333333334in" height="11.75in"}
{width="7.947916666666667in" height="5.208333333333333in"}
{width="8.333333333333334in" height="11.75in"}
Festlegung der Anforderungen: Schritte
Anforderungsermittlung: Sammeln von (funktionalen
und nicht-funktionalen) Anforderungen
z.B. durch Anwendergespräche, Dokumenten-Studium
Anforderungsanalyse: Klassifizierung, Bewertung,
Vergleich und Prüfung
z.B. Kosten-/Nutzen-Aspekte, Konsistenz, Vollständigkeit
Anforderungsbeschreibung: Beschreibung in
einheitlicher Form (z.B. als Anwendungsfälle)
Anforderungsrevision: Erneute Prüfung/Änderung von
Anforderungen
ggf. nur in formellem Änderungsverfahrens
13
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Inhalt der Anforderungsbeschreibung
Zielsetzung
allgemeine Beschreibung
Definitionen und Abkürzungen
Produktumfeld
funktionale Anforderungen
nicht-funktionale Anforderungen
Abnahmekriterien
Glossar, Index, Referenzen
14
IEEE 830-98
Standard für
Anforderungs-
dokumente
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Funktionale vs. nichtfunktionale Anforderungen
Funktionale Anforderungen
Was soll das System
leisten?
Welche Dienste soll es
anbieten
Eingaben, Verarbeitungen,
Ausgaben
Verhalten in bestimmten
Situationen, ggf. was soll
es explizit nicht tun
15
Nichtfunktionale Anforder.
Wie soll das System/
einzelne Funktionen
arbeiten?
Qualitätsanforderungen
wie Performanz und
Zuverlässigkeit
Anforderungen an die
Benutzbarkeit des
Systems
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Beispiel: Funktionale Anforderungen
Funktion: Vorlesung eintragen
Eingaben: Raum, Zeit und Titel einer Vorlesung.
Verarbeitungsschritte:
Prüfe, ob der Vorlesungstitel schon vergeben ist
Prüfe, ob der Raum zur angegebenen Zeit schon vergeben ist
Wenn nicht, wird die neue Vorlesung eingetragen und die
Daten der Vorlesung werden angezeigt.
Falls vergeben, wird die Vorlesung nicht eingetragen und eine
entsprechende Fehlermeldung wird angezeigt.
Ausgaben: Die Vorlesung wird angezeigt oder ein Fehler
wird gemeldet.
16
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Beispiele: Funktionale Anforderungen
Aktionen, die vom System ausgeführt werden sollen
Bsp.: Das System muss Ausleihgegenstände in den Bestand
aufnehmen können.
Systeminteraktionen, die dem Nutzer ermöglicht werden
Bsp.: Das System muss es dem Administrator bei der
Aufnahme eines Ausleihgegenstandes in den Bestand
ermöglichen, den Autor, den Titel und die ISBN einzugeben.
allg. funkt. Vereinbarungen u. Einschränkungen
Bsp.: Der Client ist für den Kommunikationsaufbau zuständig.
17
Software Engineering
{width="8.333333333333334in" height="11.75in"}
{width="8.364583333333334in" height="5.614583333333333in"}
{width="8.333333333333334in" height="11.75in"}
Beispiele: Nicht-funktionale Anforderungen
technische Anforderungen
Das System muss mit Java entwickelt werden und muss in der
Sun Java VM 1.5 laufen
ergonomische Anforderungen
Das System muss die gespeicherten Objekte formatiert
ausgeben können (Formatvorgabe).
Die Benutzerführung erfolgt in deutsch
Anforderungen an die Dienstqualität
Das System muss jede Anfrage des Benutzers innerhalb von 30
Sekunden ausführen (auf System XY).
Der Speicherbedarf darf 512mb nicht übersteigen
19
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Beispiele: 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
zu erstellenden Dokumente durchführen.
rechtlich-vertragliche Anforderungen
Der Kunde leistet für jeden abgenommenen Meilenstein ein
Drittel der vertraglich vereinbarten Summe für die Entwicklung
des Systems.
Die deutsche Datenschutzrichtlinie muss erfüllt sein
Interoperabilität
Das System muss Daten mit MS Excel austauschen können
20
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Überprüfbarkeit
Alle Anforderungen müssen überprüfbar sein
Ein objektiver Dritter muss entscheiden können
Notfalls Abnahme vor Gericht durchsetzen
in Systemziel
Das System sollte für erfahrene Benutzer einfach zu bedienen und so aufgebaut sein,
dass Fehler durch den Benutzer minimiert werden.
Eine verifizierbare nichtfunktionale Anforderung
Es soll erfahrenen Benutzern möglich sein, nach einer Schulung von insgesamt nvei
Stunden alle Systemfunktionen Zu verwenden. Nach dieser Schulung sollte der
durchschnittliche Wart gemachter Fahler bei orfahranon Benutzern nicht höher als
ei pro Tag sein.
21
Software Engineering
{width="8.333333333333334in" height="11.75in"}
{width="1.5104166666666667in" height="4.510416666666667in"}
Erfasster Bildschirmausschnitt: 05.02.2018 15:51
Messbarkeit
Beste Überprüfbarkeit bei messbaren Metriken
Ausgeführte Transaktionen'Sekunde
Reaktionszeit au' Benutzereingabe Oder frevgnis
Si ungszeit
Kilobyte
Anzahl der Speicherbausteine
Anzahl der Hilfeseiten
Durchschnittliche Zeit bis zu einer Fehlfunktion
Wahrsöeinlichkeit der Nichtverfügbarkeit
Quote für das Auftreten von Fehlern
Verfügbarkeit
Zeit bis zum Neustart nach einer Fehlfunktion
Anteil der Ereignisse, die tu Fehlfunktionen führen
Wahrs&einlichkeit für Oatenzerstörung bei Fehlfunktion
Anteil der Wattforrnabhängigen Anweisungen
Anzahl der Üelsysteme
Software Engineering
22
{width="8.333333333333334in" height="11.75in"}
Messbarkeit (Beispiele)
Das System soll zügig reagieren
80 % aller Anfragen sollen unter 0.1 Sekunde beantwortet
werden, 99.99 % aller Anfragen unter 2 Sekunden (Test-
Hardware spezifizieren!)
Das System soll auch im Mehrbenutzerbetrieb schnell
reagieren
Auf XY-Server Verarbeitung von 200 Anfragen pro Sekunde von
10 unterschiedlichen Systemen mit 100mbit Ethernet-
Anbindung
Das System soll stabil und ausfallsicher sein
Verfügbarkeit von 99.99 %, Neustart innerhalb von 30
Sekunden, das System darf nicht aufgrund falscher Eingaben
abstürzen
23
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Messbarkeit (Beispiele 2)
Das System soll gut getestet werden
Automatisierte Unit-Tests erzielen eine Testabdeckung von
insgesamt 95% und 100% in Modul X
Durchführung eines Benutzbarkeittests mit zwei nicht-
eingewiesenen Nicht-Informatik-Studenten, diese können
Aufgabe X ohne Erklärung durchführen
Integrationstests:
28 Tests. 27
erfolgreich
I schlägt wegen
Rechte fehl
• Gesamtdauer 30
Sekunden
Live- Test:
Das System wird mit
Simulator X für 2 Wochen
fehlerfrei im Dauerbetrieb
ausgeführt
24
Belastungstest:
mit Linuxprogramm " ab"
virtueller Server bei
webvariants
1000 Anfragen, 10
gleichzeitig:
Foreniibersicht
• 11.68 Anfragen pro
• 23.09.2009 bis
Sek linde
07.10.2009
428 Sekunden insg.
leider FeedBack erst
• max. 6.5 Sekunden
ab 01.10.2009
{width="8.333333333333334in" height="11.75in"}
Nachvollziehbarkeit
Dokumentieren woher Anforderungen kam
Wer hat sie aufgestellt, für wen ist sie wichtig
Vermeidet Phantome
Strukturiert Diskussionen
Erlaubt gezielte Rückfragen/Prüfen ob erfüllt
25
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Abgrenzungskriterien
Was soll nicht gemacht werden?
Manchmal sinnvoll dies expliziert zu klären
Dem Kunden klar machen worauf er verzichtet
Teils Schutz vor Änderungsanträgen
Beispiele
Kein Fokus auf intuitive Bedienung, sondern Spezialsoftware
für geschulte Benutzer
Schützt nicht vor Fehlern des Benutzers
Festplattenspeicher wird als nicht-limitiert betrachtet
Multilinguale Benutzeroberfiäche nicht geplant
Software Engineering
26
{width="8.333333333333334in" height="11.75in"}
Prüfung von Anforderungen
Wird der Bedarf des Kunden vollständig abgedeckt?
Verständlich formuliert?
Konsistent mit den anderen Anforderungen?
Realistisch mit Budget und Technologie?
Anforderung prüfbar?
Änderbar ohne Einfluss auf andere Anforderungen?
Regelmäßige Reviews
Kunden und potentielle Benutzer in Anforderungsanalyse
mit einbeziehen
27
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Anwendungsfälle
Software Engineering
28
{width="8.333333333333334in" height="11.75in"}
Anwendungsfälle
Grundidee: Gliederung der Funktionalität in logisch zusammengehörige
und handliche funktionale Einheiten, Beschreibung in standardisierter
Form
Anwendungsfall: abgeschlossene, zusammenhängende Einheit; Teil der
Funktionalität des Systems
Anwendungsfallbeschreibung:
Titel:
Kurzbeschreibung:
Aktoren:
Vorbedingungen:
Beschreibung des Ablaufs:
Auswirkungen:
Anmerkungen:
Die Gliederung ist nicht fix und sollte je nach Bedarf erweitert werden (z.B.
Hinzufügen von Prioritäten, Stakeholdern „
29
Software Engineering
{width="8.333333333333334in" height="11.75in"}
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:
Prüfe, ob der Raum zur angegebenen Zeit schon vergeben ist
Wenn nicht, wird die neue Vorlesung eingetragen und die Daten der
Vorlesung werden angezeigt.
Falls vergeben, wird die Vorlesung nicht eingetragen und eine
entsprechende Fehlermeldung wird angezeigt.
Auswirkungen: Die Vorlesung wird angezeigt oder ein Fehler wird
gemeldet.
Anmerkungen:
Software Engineering
30
{width="8.333333333333334in" height="11.75in"}
Aktoren
Aktor:
Objekt der Systemumgebung, das mit dem System interagiert
(und einen Oder mehrere Anwendungsfälle auslösen kann).
Aktoren können Personen (System-Nutzer), externe Geräte oder
mit dem System verbundene Nachbarsysteme sein.
Aktoren tauschen mit dem System Nachrichten aus und können als Sender und/
oder Empfänger von Nachrichten auftreten.
Aktoren sind i.a. selbst nicht Bestandteile des Systems. Oft müssen Daten über sie
jedoch (z.B. zur Regelung der Zugangsberechtigung) mit verwaltet werden.
31
Software Engineering
{width="8.333333333333334in" height="11.75in"}
{width="3.2083333333333335in" height="3.96875in"}
Elemente von Anwendungsfalldiagrammen
Aktor,
Anwendungfall mit
Bezeichner B,
Systemgrenze (mit
Systembezeichner S),
Kommunikationsbeziehung
(zwischen Aktoren und
Anwendungsfällen)
Beziehung zwischen
Anwendungsfällen
Software Engineering
S
32
Erfasster Bildschirmausschnitt: 05.02.2018 15:54
{width="8.333333333333334in" height="11.75in"}
Beziehungen zwischen Anwendungsfällen
Ausführung von Anwendungsfall A schließt
die Ausführung von Anwendungsfall B ein.
Bsp: "Auftrag bearbeiten" schließt "Zahlung
veranlassen" ein.
Ausführung von Anwendungsfall A kann
(unter bestimmten Bedingungen) erweitert
werden durch eine Ausführung von
Anwendungsfall B.
Bsp: Beim "Auftrag bearbeiten" wird - falls
eine Anfrage dafür vorlag - noch ein Katalog
versandt.
Anwendungsfall A generalisiert
Anwendungsfall B, d.h. B steht für eine
Menge von Spezialfällen von A.
Bsp: "Auftrag bearbeiten" generalisiert
"Kaufauftrag bearbeiten" und
"Verkaufsauftrag bearbeiten"
Software Engineering
33
{width="2.4270833333333335in" height="5.177083333333333in"}
{width="8.333333333333334in" height="11.75in"}
Beispiel: ein einfaches Anwendungsfalldiagramm
{width="5.96875in" height="2.3125in"}
Stück zurückgeben wird durch den Kunden (z Automatenbenutzer) ausgelöst, der
eine Menge von Dosen, Flaschen oder Kisten zurückgeben will.
Beschreibung des Ablaufs:
Mit jedem zurückgegebenen Stück erhöht das System die Anzahl der
registrierten Stücke sowie die Tagesgesamtanzahl für die betreffende Kategorie.
Wenn der Kunde alle Stücke abgeliefert hat, drückt er einen Quittungsknopf und
erhält eine Quittung über alle abgelieferten Stücke und deren Gesamtanzahl.
34
Software Engineering
{width="8.333333333333334in" height="11.75in"}
{width="8.166666666666666in" height="6.1875in"}
{width="8.333333333333334in" height="11.75in"}
Anwendungsfälle
Erstellen von Anwendungsfällen ist Textarbeit
Anwendungsfalldiagramme sind nur zur Ubersicht,
ersetzen aber nicht die textuelle Beschreibung
36
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Pflichtenheft
Software Engineering
37
{width="8.333333333333334in" height="11.75in"}
Pflichtenheft
Offizielle Aufstellung was von Entwicklern erwartet wird
Enthält Benutzer- und Systemanforderungen
Hat bei externen Kunden Vertragscharakter
38
Software Engineering
{width="8.333333333333334in" height="11.75in"}
{width="6.947916666666667in" height="5.979166666666667in"}
Erfasster Bildschirmausschnitt: 05.02.2018 15:58
{width="8.333333333333334in" height="11.75in"}
Aufbau des Pflichtenhefts nach IEEE Standard
Einleitung (introduction)
Ziel (purpose)
Anwendungsbereich (scope)
Definitionen, Akronyme, Referenzen
Allgemeine Beschreibung (description)
Produktperspektiven
Produktfunktionen
Benutzercharacteristika
Allgemeine Beschränkungen
Voraussetzungen und Abhängigkeiten
Spezifische Anforderungen (requirements)
funktionale und nicht-funktionale Eigenschaften (umfangreichster
Teil)
Anhänge
40
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Struktur eines Pflichtenhefts (nach Sommerville)
Vorwort
Einleitung
Glossar
Definition der Benutzeranforderungen
Systemarchitektur
Spezifikation der Systemanforderungen
Systemmodell
Systementwicklung
Anhänge, Index
41
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Evolution eines Pflichtenhefts
Pflichtenhefte sollten "lebendige Dokumente" sein
Spagat zwischen PH als Vertrag und PH als Dokumentation des
aktuellen Projektverstädnisses
Zögern Sie nicht, das PH zu ändern wenn
Sich ihr Verständnis des Projekts geändert hat und das PH dies noch
nicht reflektiert
Sie im Einverständnis mit dem Kunden Dinge ändern möchten
Dokumentieren Sie die Entwicklung des PH
Wer hat was wann geschrieben?
Wieso wurde etwas geändert?
Kann manuell dokumentiert werden
Empfehlung: PH als Textdokument in die Versionsverwaltung
aufnehmen
42
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Pflichtenheft und "The Mytical Man-Month"
{width="5.854166666666667in" height="1.96875in"}
Fred Brooks: "Adding manpower to a late software project makes it later"
Grund: Kommunikationsaufwand wächst quadratisch zur Entwickleranzahl
Ein gutes Pflichtenheft kann helfen, den Kommunikationsaufwand wieder
linear zu machen.
43
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Sprache im Pflichtenheft
Ein Pflichtenheft ist ein technisches Dokument
Fokus auf Präzision und Verständlichkeit
Keine langen, verschachtelten Sätze, keine unnötigen
Fremdworte, keine überflüssigen Informationen
Sollte für alle Projektbeteiligten verständlich sein
Definition von wichtigen Worten im Glossar
Vorsicht bei der Nutzung von Templates
Ist die Struktur des Templates wirklich adäquat für das
Projekt?
Für jedes Projekt sollte die Struktur des PH an das Projekt angepasst
werden
44
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Diskussion Pflichtenheft
Pflichtenheft kann sehr umfangreich und aufwendig
werden...
Vertragscharakter oder Richtlinie?
Aufteilung in Muss-/Soll-/Kann-/Abgrenzungskriterien?
Veraltet bevor fertig gestellt?
Hilft inkrementelles Vorgehen?
Kein übermäßiger Einsatz informeller grafischer Notation
UML, Use Case Diagramme etc.
Diese Diagramme dienen zur Illustration aber sind alleine nicht
präzise genug
45
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Zusammenfassung
Anforderungsanalyse zentral für Projekterfolg
Kunde und Entwickler müssen sich auf eine
Anforderungsbeschreibung einigen. Hier treten viele
Probleme auf.
Es werden funktionale und nichtfunktionale
Anforderungen an eine Anwendung unterschieden.
Einen Überblick über die funktionalen Anforderungen
geben Anwendungsfalldiagramme.
46
Software Engineering
{width="8.333333333333334in" height="11.75in"}
Diskussion: Foto-Editor
Was wären denkbare Anforderungen und
Anwendungsfälle bei einem Foto-Editor?
47
Software Engineering