Upload
nadja-schlup
View
105
Download
2
Embed Size (px)
Citation preview
Projektmanagement - Block 5
Softwareanforderungen
Institut für Informationssysteme und Computer Medien (IICM)Fakultät für Informatik - Technische Universität Graz, Austria
Christian Gütl
Version 1.00
block5_ss2009.ppt
© 2006 - Christian Gütl11.04.23 2
Prozessgruppen
Softwareentwicklungs-Prozess
Softwarespezifikation
Softwareentwurf und –implementierung
Software Verifikation & Validierung
Softwareweiterentwicklung
© 2006 - Christian Gütl11.04.23 3
Buchempfehlung
Software Engineering 7 Ian SommervilleISBN: 0-321-21026-3Publisher: Addison-WesleyCopyright: 2005Format: Cloth; 784 pp
Ausverhandelter Preis mit dem Pearson Verlag im Rahmen der LV
€ 59,95 (statt 67,95)
http://www.pearson-studium.de/main/main.asp?page=bookdetails&ProductID=117567
© 2006 - Christian Gütl11.04.23 4
Agenda
• Arten von Softwareanforderungen
• Lastenheft und Pflichtenheft
• Softwareanforderungsbestimmung und –analyse
• Validierung der Softwareanforderungen
© 2006 - Christian Gütl11.04.23 5
Abschnitt 1
Softwareanforderungen im Überblick
© 2006 - Christian Gütl11.04.23 6
Allgemeines
• Softwareanforderungs-Prozess ist zentraler Punkte des Softwareengineering-Prozesses
• Lastenheft und Pflichtenheft• In Praxis Spannungsfeld zwischen
– notwendiger Festlegung der Anforderungen– Zur Verfügung stehenden Ressourcen
• Identifizieren u. Beschreiben der Anforderungen– Komplexer Prozess– Verschiedenste Benutzerkreise involviert
Zentraler Punkt des Projektmanagement
© 2006 - Christian Gütl11.04.23 7
Zielgruppen vs. Spezifikationsarten
Benutzeran-forderungen
Manager des Kunden
Manager des Softwarehersteller
Endbenutzer
Beschreibung in abstrakter Form
Für Nichttechniker verständlich
Systeman-forderungen
System-architekten
Software-entwickler
Endbenutzer und Manager
Detaillierte Bechreibung
Rechtliche Verbindlichkeit
Spezifikation d. Softwareentwurfs
System-architekten
Software-entwickler
Techniker des Kunden
Abstrakter Softwareentwurf
Weitere Detail-anreicherung
© 2006 - Christian Gütl11.04.23 8
Benutzer vs. Systemanforderung
Beispiel einer Benutzeranforderung
1. Die Software muss über Mittel zur Darstellung externer, von anderen Werkzeugen erzeugter Dateien verfügen und auf sie zugreifen können.
Beispiel einer Systemanforderung
1.1 Der Benutzer sollte über Möglichkeiten zur Definition externer Datentypen verfügen.
1.2 Jeder externe Dateityp kann eine damit verknüpfte Anwendung besitzen, 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 Symbols für externe Dateitypen durch den Benutzer dargestellt werden.
1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Datei repräsentiert, so soll die durch dieses Symbol dargestellte Datei mit der Anwendung geöffnet werden, die mit dem entsprechenden externen Dateityp verknüpft ist.
© 2006 - Christian Gütl11.04.23 9
Einteilung von Anforderungen
Funktionale Anforderungen
Nichtfunktionale Anforderungen
Problembereichs-anforderungen
Beschreiben den Umfang der bereitzustellenden Dienste
Beschreiben Funktionen die nicht bereitgestellt werden
schränken ein
Anforderungen der Anwendungsdomaine
besteht aus besteht aus
© 2006 - Christian Gütl11.04.23 10
Einteilung von Anforderungen
• Funktionale Anforderungen beschreiben– Dienste, die das System leisten soll– Reaktionen des Systems auf Eingaben– Situationsabhängiges Verhalten des Systems– Funktionen, die nicht Teil d. Systems sind
• Nichtfunktionale Anforderungen– Beschränkungen durch das System gebotene
Funktionen und Leistungen– U.a. Standards, Entwicklungsprozessvorgaben, …
• Problembereichsanforderungen– Anforderungen aus dem Anwendungsbereich– Besteht wieder aus Funktionalen u.
Nichtfunktionalen Anforderungen
© 2006 - Christian Gütl11.04.23 11
Funktionale Anforderungen 1• Funktionale Anforderungen
– Beschreiben• Funktionalitäten des Systems• Dienste des Systems• Nichtfunktionen
– sollen prinzipiell …• vollständig sein
alle Funktionen von allen Benutzergruppen• konsistent sein
Anforderungen dürfen keine widersprüchlichen Festlegungen enthalten
• Aus der Praxis• Größere Komplexere Systeme sind nie vollständig
und auch nicht konsistent• Viele Probleme kommen aus der Ungenauigkeit der
Festlegung der Anforderungen (Mehrdeutigkeit bei der Interpretation das Einfachste wird umgesetzt)
© 2006 - Christian Gütl11.04.23 12
Funktionale Anforderungen 2
• Beispiele (Auszüge aus Anforderungen an ein Bibliothekssystem)
1. Der Benutzer soll die gesamte Menge der Dokumente oder eine ausgewählte Teilmenge durchsuchen können.
2. Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentkorpus lesen kann.
3. Jeder Bestellung soll ein eindeutiger Bezeichner (Order ID) zugeordnet werden, und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können.
© 2006 - Christian Gütl11.04.23 13
Nichtfunktionale Anforderungen 1
• Nichtfunktionale Anforderungen– Betreffen nicht funktionale Anforderungen– Beschreiben vielmehr
• SoftwareeigenschaftenZ.B. Zuverlässigkeit, Reaktionszeit,
Speicherbedarf• Beschränkungen des Systems
z.B. Datenaustausch durch Systemschnittstelle
• Anmerkungen– Beziehen sich i.a. auf das ganze System
Nichteinhalten von „Nichtfunktionalen Anforderungen“ wirken sich viel stärker aus als Nichteinhalten einzelner „Funktionaler Anforderungen“
– Wirken i.a. einschränkend auf das System und die Systemfunktionen
© 2006 - Christian Gütl11.04.23 14
Nichtfunktionale Anforderungen 2
Produkt-anforderungen
Unternehmens-anforderungen
Externe Anforderungen
Nichtfunktionale Anforderungen
Benutzbarkeits-anforderungen
Effizienz-anforderungen
Zuverlässigkeits-anforderungen
Portierbarkeits-anforderungen
Liefer-anforderungen
Umsetzungs-anforderungen
Vorgehens-anforderungen
Kompatibilitäts-anforderungen
Ethische Anforderungen
Rechtliche Anforderungen
© 2006 - Christian Gütl11.04.23 15
Nichtfunktionale Anforderungen 3
• Unterteilung– Produktanforderungen
• Beschreibt das Verhalten des Produktes• Z.B. Performance, Zuverlässigkeit, Portierbarkeit
und Benutzbarkeit
– Unternehmensanforderungen• Sind bestimmt durch Unternehmenspolitik und
Arbeitsweisen von Auftragnehmer und Auftraggeber• Z.B. Systementwicklungsprozess SP-STAN 2003
– Externe Anforderungen• Alles außerhalb des Systems und seines
Entwicklungsprozesses• Z.B. Kompatibilität zu anderen Systemen, Einhaltung
von Gesetzen (z.B. Datenschutzgesetz)
© 2006 - Christian Gütl11.04.23 16
Problembereichsanforderungen 1
• Problembereichsanforderungen– Sind geprägt vom Anwendungsbereich
• Widerspiegelt – allgemeine Arbeitsweisen des Bereiches– Standards– Vorschriften, Regulierungen
– Sind in der Praxis wichtig• Werden diese nicht berücksichtigt, dann
– kann das System unbrauchbar sein– bzw. nicht zufriedenstellend arbeiten
– Können wiederum sein• Funktionale Anforderungen• Nichtfunktionale Anforderungen
© 2006 - Christian Gütl11.04.23 17
Problembereichsanforderungen 2
• Beispiele– Bibliothekssystem
• Funktionale Problembereichsanforderung– Vormerkfunktion (wenn Buch verborgt, stelle
Vormerkfunktion zur Verfügung)
• Nichtfunktionale Problembereichsanforderung– Unterstützung von Klassifikationssystem
z.B. Dewey Decimal Classification
– Buchhaltungsprogramm (Vorschriften gemäß Finanzsteuerrecht)
• Funktionale Problembereichsanforderung– Splitbuchung (Aufteilung des Rechnungsbetrages auf
verschiedene Konten)
• Nichtfunktionale Problembereichsanforderung– Einhaltung der Vorschriften von BAO, UStG, EStG
© 2006 - Christian Gütl11.04.23 18
Benutzeranforderungen
Benutzeran-forderungen
Manager des Kunden
Manager des Softwarehersteller
Endbenutzer
Beschreibung in abstrakter Form
Für Nichttechniker verständlich
Systeman-forderungen
System-architekten
Software-entwickler
Endbenutzer und Manager
Detaillierte Bechreibung
Rechtliche Verbindlichkeit
Spezifikation d. Softwareentwurfs
System-architekten
Software-entwickler
Techniker des Kunden
Abstrakter Softwareentwurf
Weitere Detail-anreicherung
© 2006 - Christian Gütl11.04.23 19
Benutzeranforderungen 1
• Benutzeranforderungen– Abstrakt, für Nichttechniker verständlich
Auch für den Systembenutzer verständlich– Aussagen in natürlicher Sprache– Ggf. zusätzlich Abbildungen, Diagramme zum
besseren Verständnis
– Es soll nur das externe Verhalten des Systems festgelegt werden ermöglicht mehrere Systemlösungen verschiedener Anbieter
– Charakteristika des Systementwurfs soll vermieden werden Anforderungen nicht durch Implementierungsmodelle beschreiben
• Hinweis aus der Praxis: Zu viele Informationen schränkt die Freiheit des Systementwicklers ein, innovative Lösungen zu finden
© 2006 - Christian Gütl11.04.23 20
Benutzeranforderungen 2
• Anmerkungen und Hinweise– Nutzung eines Standardformates ist sinnvoll
• Versäumnisse weniger wahrscheinlich• Leichter überprüfbar
– Formatierungen• Hervorhebung wichtiger Aussagen
– Begründungen sind hilfreich für Systementwickler und Systemwarter (Nachvollziehbarkeit)
– Nutzung einer einheitlichen Ausdrucksweisen• „sollen“ Verbindliche Anforderungen • „sollten“ wünschenswerte Anforderungen• Vermeiden von Computerjargon• Ausdrücke des Fachbereiches lassen sich kaum
vermeiden
© 2006 - Christian Gütl11.04.23 21
Benutzeranforderungen 3• Beispiel Benutzeranforderung [Sommerville 2001]
3.5.1 Hinzufügen von Knoten zu einem Entwurf3.5.1.1
Der Editor soll dem Benutzer die Möglichkeit bieten, Knoten eines bestimmten Typs zum Entwurf hinzuzufügen
3.5.1.2 Beim Hinzufügen von Knoten sollen folgende Vorgänge stattfinden
• Der Benutzer soll den hinzuzufügenden Knotentyp auswählen.• Der Benutzer soll den Cursor in die Nähe der Knotenposition im
Diagramm bewegen um die ungefähre Position festzulegen.• Der Benutzer soll dann das Knotensymbol auf die endgültige
Position ziehen.Begründung: Der Benutzer kann am besten entscheiden, wo der Knoten im Diagramm zu platzieren ist. Diese Methode gibt dem Benutzer die direkte Kontrolle.
Systemanforderung: Mytool/DE/SA/Abschnitt 3.5.1
© 2006 - Christian Gütl11.04.23 22
Systemanforderungen
Benutzeran-forderungen
Manager des Kunden
Manager des Softwarehersteller
Endbenutzer
Beschreibung in abstrakter Form
Für Nichttechniker verständlich
Systeman-forderungen
System-architekten
Software-entwickler
Endbenutzer und Manager
Detaillierte Bechreibung
Rechtliche Verbindlichkeit
Spezifikation d. Softwareentwurfs
System-architekten
Software-entwickler
Techniker des Kunden
Abstrakter Softwareentwurf
Weitere Detail-anreicherung
© 2006 - Christian Gütl11.04.23 23
Systemanforderungen 1
• Systemanforderungen– Sind genauere Beschreibungen der
Benutzeranforderungen– Sollten vollständig und widerspruchsfrei sein– Wird als Startpunkt des Softwareentwurfs
verwendet– Ggf. zusätzliche Verwendung von Systemmodellen
– Systembeschreibungen sollen festlegen, was das System tut und nicht wie es implementiert wird.
– Praktisch ist es unmögliche, jegliche Entwurfsinformationen auszuschließen,z.B.
Grobe Systemarchitektur Integration mit anderen SystemenVorgabe der Nutzung v. bestimmten Entwurf
© 2006 - Christian Gütl11.04.23 24
Systemanforderungen 2
Notationen für Systemanforderungen
Sprachen zur Entwurfsbeschreibung
Strukturierte natürliche Sprache
Natürliche Sprache
Graphische Notationen
Mathematische Notationen
© 2006 - Christian Gütl11.04.23 25
Systemanforderungen 3
• Notationen der Systemanforderungen– Natürliche Sprache
• Nachteil:– Verständnis hängt von Autor und Leser ab– Überflexible: Verschiedene Darstellungsarten– Schwierig zu Modularisieren (Abhängigkeiten finden)
– Strukturierte natürliche Sprache– „Künstliche“ Sprache, Standardformulare u. Vorlagen
– Sprachen zur Entwurfsbeschreibung (PDL)– Sprachen ähnlich einer Programmiersprache
– Grafische Notationen– Graphische Sprache mit Textvermerken ergänzt
(z.b. SADT oder Use Cases)
– Mathematische Notationen– Mathematische Konzepte wie endliche
Zustandsmaschinen oder Mengen
© 2006 - Christian Gütl11.04.23 26
Strukturierte natürliche Sprache 1
• Standardformulare sollen folgende Informationen beinhalten1. Beschreibung der Funktion oder Entität2. Beschreibung der Eingabedaten und Herkunft3. Beschreibung der Ausgabedaten und Ziel4. Hinweis welche andere Entitäten verwendet
werden5. Bei Beschreibung funktionaler Methoden:
Vor- und Nachbedingungen6. Beschreibung von Seiteneffekten
• Achtung: Zusammenhang zwischen Benutzer- u. Systemanforderung soll ersichtlich sein !
© 2006 - Christian Gütl11.04.23 27
Strukturierte natürliche Sprache 2Mytool/DE/SA/Abschnitt 3.5.1 [Sommerville 2001]
Funktion Knoten hinzufügen
Beschreibung Fügt einen Knoten zu einem vorhandenen Entwurf hinzu. Der Benutzer wählt Typ und Position des Knotens. Aktueller Knoten ist nach Einfügen ausgewählt. Benutzer bestimmt die exakte Knotenposition durch die Stelle der Cursor Position.
Eingaben Knotentyp, Knotenposition, EntwurfsID
Herkunft Knotentyp u. Position durch Benutzer, EntwurfID durch Datenbank
Ausgabe EntwurfsID
Ziel Entwurfsdatenbank (am Ende d. Operation)
Benötigt Entwurfsgraphen, gekennzeichnet durch EntwurfsID des Rootknotens
Vorbedingung Entwurf geöffnet und am Bildschirm dargestellt
Nachbedingung Entwurf ergänzt um hinzugefügten Knoten
Seiteneffekte Keine
Benutzeranforderung: Mytool/DE/BA/Abschnitt 3.5.1
© 2006 - Christian Gütl11.04.23 28
Strukturierte natürliche Sprache 3
• Anwendung von Standardformularen– Sinnvoll für „Funktionale Anforderungen“ – Geeignete Vorlagen zur Verfügung stellen
• Vorteil von Standardformularen– Ausdruckskraft und Verständlichkeit der
natürlichen Sprachen bleibt erhalten– Einheitlichkeit der Systemanforderungen
• Verhindert Übersehen von wichtigen Informationen• Leichtere Prüfbarkeit
• Nachteil– Komplexe Vorgänge schwer darstellbar– Mehrdeutigkeit der Sprache bliebt erhalten
© 2006 - Christian Gütl11.04.23 29
Sprachen zur Entwurfsbeschreibung 1
• Sprachen der Entwurfsbeschreibungbzw. Program Description Language (PDL)= an Programmiersprachen angelehnte Sprache mit
zusätzlichen abstrakten Konstrukten
• Motivation– Mehrdeutigkeiten der natürlichen Sprache
entgegenzuwirken
• Anwendung– Um komplexere Abläufe von Vorgängen zu
beschreiben, ergänzend zu Formular-basierten A.– Festlegung von Hard- u. Softwareschnittstellen
(Schnittstellenobjekte und Typen festlegen) als vollständiger Ersatz schwerer lesbar
© 2006 - Christian Gütl11.04.23 30
Sprachen zur Entwurfsbeschreibung 2
class ATM {// Deklarationenpublic static void main (String args[]) throws InvalidCard { try { thisCard.read(); // Kann die Exception // Invalid Card auslösenpin = KeyPad.readPIn(); attempts = 1;while (!thisCard.pin.equals (pin) & attempts < 4){ pin = KeyPad.readPin(); attempts = attempts + 1;}if (!thisCard.pin.equals (pin)) throw new InvalidCard (“Bad PIN”);thisBalance = thisCard.getBalance();do { Screen.prompt(“Please select a service “); service = Screen.touchKey(); switch (service) { …… }// Andere Funktionsbeschreibungen default break; } }
[Sommerville 2001]
© 2006 - Christian Gütl11.04.23 31
Sprachen zur Entwurfsbeschreibung 3
• Vorteile– Eindeutige Beschreibung– Abläufe gut Darstellbar
• Nachteile– Notation nur für Menschen verständlich, die
Kenntnisse über Programmiersprachen haben– Gewählte Sprache kann u.u. zu Ausdrucksschwach
sein, um alle Systemfunktionen zu beschreiben– Kann von Projektbeteiligten für
Entwurfsspezifikation gehalten werden
• Anmerkung aus der Praxis– Gut kombinierbar mit strukturierten natürlichen
Sprache
© 2006 - Christian Gütl11.04.23 32
Anforderungsdokumente
© 2006 - Christian Gütl11.04.23 33
Das Lastenheft
• Lastenheft ([QMLexikon] nach DIN 69905)– „Gesamtheit der Forderungen des Auftraggebers
an die Lieferungen und Leistungen eines Auftragnehmers.“
– „Im Lastenheft sind die Forderungen aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollten qualifizierbar und prüfbar sein. Im Lastenheft wird definiert, was für eine Aufgabe vorliegt und wofür diese zu lösen sind.“
• Anmerkungen– Inhalt entspricht den Benutzeranforderungen.– In Praxis stellen Kunden selten ein Lastenheft zur
Verfügung. Meist steht nur eine grobe Beschreibung zur Verfügung.
© 2006 - Christian Gütl11.04.23 34
Das Pflichtenheft 1
• Pflichtenheft– Beinhaltet im Allgemeinen
• Benutzeranforderungen• und Systemanforderungen
• Anmerkungen– Meist sind Benutzeranforderungen und
Systemanforderungen in einem Dokument Systemanforderungen umfangreicher Systeme werden in mehreren Dokumenten beschrieben
– Benutzeranforderungen und Systemanforderungen sollen einander referenzieren
– Ist offizielle Aufstellen was umgesetzt werden soll– Basis für die Abnahme– Kann Bestandteil des Vertrages sein
© 2006 - Christian Gütl11.04.23 35
Das Pflichtenheft 2
Systemkunde
Legt Anforderungen fest, prüft Dokument auf
gewünschten Umfang
Quelle für Anforderungsänderungen
Manager
Angebotserstellung
Planung des Systementwicklungsprozesses
Systementwickler
Quelle zur Systementwicklung
Systemtester Verifikation und Validierung
Systemwarter Verständnis für das System
Pfli
chte
nhef
t
© 2006 - Christian Gütl11.04.23 36
Struktur des Pflichtenheftes 1
Abschnitt 1: Allgemeines– Vorwort
• Versionsgeschichte (Was ist neu und Warum?)• Zielgruppen des Dokumentes
– Einleitung• Begründung / Notwendigkeit des Systems• Adressierung strategischer Ziele d. Unternehmens• Funktionsweise im Überblick• Zusammenwirken mit anderen (bestehenden)
Systemen
– Begriffe und Abkürzungen• Technische Fachbegriffe• Abkürzungen
– Verweise auf referenzierte Literatur
© 2006 - Christian Gütl11.04.23 37
Struktur des Pflichtenheftes 2
Abschnitt 2: Anforderungsbeschreibung– Benutzeranforderungen
• … in natürlicher Sprache, sowie Diagramme und andere, für Kunden, verständliche Beschreibungen
– Systemarchitektur• Grobe Überblick über die Funktionsarchitektur
(Gruppierung von Funktionen zu Systementeilen Block 4)
– Systemanforderungen• Detaillierte, technische Beschreibung der
Benutzeranforderungen– Systemmodelle
• Ein oder mehrere Systemmodelle, die Beziehungen zwischen Systemteilen und Systemumgebung aufzeigt
• Dient der speziellen Darstellung von besonderen Systemeigenschaften (z. Datenflussdiagramm)
© 2006 - Christian Gütl11.04.23 38
Struktur des Pflichtenheftes 3
Abschnitt 3: Anhang– genauere, spezifische Informationen zu
bestimmten Details, u.a.• Hardwarebeschreibung• Datenbankbeschreibung• Zusammenarbeit mit anderen Systemen• …
– Projektbeteiligte bzw. Stakeholder• Spezifische Anforderungen• Widersprüche• Konfliktauflösung• Kompromisse mit Begründung
© 2006 - Christian Gütl11.04.23 39
Das Pflichtenheft 4
• Kennzeichen eines guten Pflichtenheftes
1. Es soll leicht verständlich sein. 2. Es soll nur das äußere Systemverhalten
beschrieben werden. WAS3. Es soll leicht zu verändern sein.4. Es sollen die Veränderungen leicht
nachvollziehbar sein.
Anmerkungen– Kunden sind häufig nicht einsichtig, das Kosten
für eine Spezifikation anfallen.– Ein gut erstelltes Pflichtenheft kann nachträglich
viel Ärger und Kosten vermeiden!!!
© 2006 - Christian Gütl11.04.23 40
Abschnitt 2
Abläufe der Anforderungsanalyse
© 2006 - Christian Gütl11.04.23 41
Durchführbarkeitsstudie 1
Durchführbar-keitsstudie
Bestimmung u. Analyse der
Anforderungen
Spezifikation d. Anforderungen
Validierung d. Anforderungen
Durchführbar-keitsbericht
SystemmodelleBenutzer- u.
System-anforderungen
Anforderungs-dokument
(Pflichtenheft)
© 2006 - Christian Gütl11.04.23 42
Durchführbarkeitsstudie 2
• Durchführbarkeitsstudie– Vgl. „Idea & Prelaunch Stage“ der Project Process
Architecture (PPA)– Lt. Sommerville soll die Studie folgenden Fragen
beantworten1. Beitrag zur Erreichung der Gesamtziele?2. Kann System unter Nutzung gegenwärtiger
Technologien (Hardware u. Software) innerhalb Kosten und Zeitressourcen umgesetzt werden?
3. Arbeitet System mit vorhandenen Systemen zusammen?
1. Punkt in Idea Stage 2. und 3. Punkt in Prelaunch Stage
© 2006 - Christian Gütl11.04.23 43
Anforderungsbestimmung u. -analyse 1
Durchführbar-keitsstudie
Bestimmung u. Analyse der
Anforderungen
Spezifikation d. Anforderungen
Validierung d. Anforderungen
Durchführbar-keitsbericht
SystemmodelleBenutzer- u.
System-anforderungen
Anforderungs-dokument
(Pflichtenheft)
© 2006 - Christian Gütl11.04.23 44
Anforderungsbestimmung u. -analyse 2
• Anforderungsbestimmung u. –analyse– Auftragnehmer (Projektleiter, Softwareentwickler)
arbeitet mit Kunden und Systembenutzern eng zusammen
– Bestimmung von• Anwendungsbereich• vom System zu leistende Dienste• erforderlichen Funktionen• Einschränkungen
– Einfluss auf die Anforderungen nehmen die Projektbeteiligten bzw. Stakeholder
© 2006 - Christian Gütl11.04.23 45
Anforderungsbestimmung u. -analyse 3
• Probleme / Blick aus der Praxis– Stakeholder können Erwartungen an System
schwer ausdrücken, meist mit impliziten Wissen ihrer Tätigkeiten Fachbereichswissen notwendig
– Stakeholder haben zum Teil unrealistische Forderungen Hinblick Ressourcen
– Verschiedene Stakeholder haben unterschiedliche Anforderungen andere Ausdrucksweise vs. Übereinstimmung und Konflikte
– Interne und externe Unternehmensumwelt ist veränderlich Bedeutung von Anforderungen können sich verändern
– Auswirkung von U-politischen Faktoren auf Anforderungen Manager wollen ihre Macht erhalten oder ausbauen
© 2006 - Christian Gütl11.04.23 46
Ablauf- und Analysemodell 1
Pflichtenheft
Anforderungs-sammlung
Klassifikation
Konfliktlösung
Verstehen d. Anwendungsbereiches
Setzen von Prioritäten
Anforderungs-überprüfung
Anforderungs-spezifikation
Start
© 2006 - Christian Gütl11.04.23 47
Ablauf- und Analysemodell 2
• Allgemeines Ablauf- und Analysemodell– Verstehen des Anwendungsbereiches
• Systemanalytiker braucht Einblick in Fachbereich– Anforderungssammlung
• Aktivitäten um Anforderungen zusammen zu tragen• Wissen über Anwendungsbereich erweitert sich
– Klassifizierung• Ordnen der Anforderungen zu Gruppen
– Konfliktlösung• verschiedene Anforderungen durch Projektbeteiligte
finden und lösen von Konflikten – Setzen von Prioritäten
• Wichtige von unwichtige Anforderungen trennen– Anforderungsüberprüfung
• Siehe „Validierung der Anforderungen“
© 2006 - Christian Gütl11.04.23 48
Anforderungsbestimmung
• Anforderungsbestimmung– Prozess der Informationssammlung von
• vorgeschlagenen Systemen• vorhandenen Systemen
– Informationsquellen dafür sind• Dokumentationen / Dokumente• Stakeholder• Beschreibung ähnlicher Systeme
– Unterstützende Techniken• Viewpoint-orientierte Bestimmung• Interviews• Szenarien (z.B. Use-cases)• Ethnografie• …
© 2006 - Christian Gütl11.04.23 49
Viewpoint-orientierte Bestimmung 1
• Viewpoint-orientierte Bestimmung– Projektbeteiligte haben verschiedene Sichtweisen
auf das System• Perspektiven
– Ergänzen sich– Überlappen sich– Widersprechen sich
– … betrachtet diese verschiedenen Sichtweisen, organisiert und strukturiert den Prozess und die Anforderungen nach den Sichtweisen
– Vorteil:• Existenz vieler Perspektiven wird beachtet• Hilft Anforderungen zu identifizieren• Hilft Konflikte/Widersprüche aufzudecken
© 2006 - Christian Gütl11.04.23 50
Viewpoint-orientierte Bestimmung 2
• Arten von Viewpoints– Interactor Viewpoint
• Personen oder andere Systeme, die direkt mit dem System interagieren
– Indirect Viewpoint• Stakeholders, welche das System nicht selbst
benutzen, aber die Anforderungen beeinflussen
– Domain Viewpoint• Fachbereichseinflüsse, die sich auf die
Anforderungen auswirken
• Organisation in Hierarchien– Gemeinsam gültige Anforderungen sind in den
oberen Hierarchien– Für speziellere Viewpoint können spezifische
Anforderungen identifiziert werden
© 2006 - Christian Gütl11.04.23 51
Viewpoint-orientierte Bestimmung 3
• Vorschlag für Vorgehensweise1. Identifizieren von Viewpoints, Dienste,
Dateneingaben u. nichtfunktionalen Anforderungen am besten durch Brainstorming
2. Bestimmung der Viewpoints zuordnen v. Diensten u. Eingaben zu Viepoints nicht zugeordnete Dienste neuer Viewpoint
3. Ausfüllen von– Viewpoint-Formularen– Dienst-Formularen
4. Bilden von Viewpoint-Hierarchien identifiziert allgemeine Dienste, Vererbung nach unten Spezifische Dienste darunter vs. Konflikte
5. Beschreiben detaillierter Informationen über die benötigten Dienste und Daten
© 2006 - Christian Gütl11.04.23 52
Interviews
• Interviews– Interviews mit ausgewählten Stakeholdern sind im
Anforderungsprozess weit verbreitet– Dabei unterscheidet man
• Kontrolliertes Interview vordefinierte Fragestellungen
• Offenes Interview Erörterung von verschiedenen Themen und Fragestellungen
– Anmerkungen aus der Praxis• Meist Mix aus offenen und kontrollierten Interview
nur offenes Interview wenig erfolgreich • Gut geeignet um Überblick der Arbeitsweisen der
Stakeholder zu bekommen und wie sie mit System umgehen
• Nicht gut für Organisatorische Anforderungen
© 2006 - Christian Gütl11.04.23 53
Szenarien
• Szenarien– Menschen finden es einfacher, einen Bezug durch
reale Beispiele herzustellen– Sie können durch Szenarien die Rollen und den
Umgang mit Systemen leichter verstehen
• Ein Szenario sollte enthalten1. Systemzustand zu Beginn des Szenarios2. Beschreibung des „normalen“ Ereignisablaufs3. Beschreibung von möglichen Fehlern und deren
Behandlung4. Hinweis auf anderen Aufgaben, die parallel
ablaufen können5. Beschreibung des Systemzustandes nach
Abschluss des Szenarios
© 2006 - Christian Gütl11.04.23 54
Use-cases
Bibliotheksbenutzer
Artikelsuche
Benutzerverwaltung
Artikelausdruck
Admin
• Use-cases– Ist eine Szenario-basierte Technik– Ist Bestandteil von UML– Stellt Akteure und die verfügbaren
„Anwendungsfälle“ dar Details durch Textbeschreibung od. Sequenzdiagramm
© 2006 - Christian Gütl11.04.23 55
Ethnografie
• Ethnographie– Softwaresysteme sind keine isolierte Systeme
in soziales u. wirtschaftliches Umfeld eingebettet– Soziale u. wirtschaftliche Anforderungen müssen
auch berücksichtigt werden Projekterfolg– … ist eine beobachtende Technik um Einblick zu
gewinnen – beobachtet tägliche Arbeit der Stakeholder und
ihre Zusammenarbeit– Kann damit implizite Anforderungen aufdecken– Beispiel: Büroautomatisierungssysteme
• Tatsächliche Arbeit viel reichhaltiger und komplexer als durch die Systeme abgedeckt
• Mögliche Ursache dafür, dass die Systeme keine Effizienzsteigerung brachten
© 2006 - Christian Gütl11.04.23 56
Validierung von Anforderungen 1
Durchführbar-keitsstudie
Bestimmung u. Analyse der
Anforderungen
Spezifikation d. Anforderungen
Validierung d. Anforderungen
Durchführbar-keitsbericht
SystemmodelleBenutzer- u.
System-anforderungen
Anforderungs-dokument
(Pflichtenheft)
© 2006 - Christian Gütl11.04.23 57
Validierung von Anforderungen 2
• Umfasst verschiedene Arten der Prüfung1. Gültigkeitsprüfungen
haben die Anforderungen für alle Nutzer des System Gültigkeit Achtung: meist Kompromiss für verschiedene Stakeholder
2. Konsistenzprüfungen keine Widersprüche o. unterschiedl. Beschreibungen
3. Vollständigkeitsprüfungen Berücksichtigung aller erwarteten Anforderungen
4. Realisierbarkeitsprüfungen vs. Technologie, Budget u. Zeitressourcen
5. Verifizierbarkeitsprüfung Anforderungen sollen eindeutig überprüfbar sein sonst bei Abnahme Problempotential !!!
© 2006 - Christian Gütl11.04.23 58
Validierung von Anforderungen 3
• Techniken der Anforderungsvalidierung1. Anforderungsreviews
– Mehrere Personen– Informell (Entwicklungsteam)
– Anforderungen mit Projektbeteiligte diskutieren– Formell (Entwicklungsteam und Kunde)
– Sind Anforderungen verständlich, verifizierbar, nachvollziehbar, anpassbar?
2. Prototypen ein System zum Experimentieren dem Kunden zur Verfügung gestellt Einblick ob tatsächliche Bedürfnisse erfüllt werden
3. Testfallerzeugung Anforderungen sollen testbar sein im Vorfeld Testfälle erzeugen Probleme bei Erstellung lässt auf Anforderungsprobleme schließen
© 2006 - Christian Gütl11.04.23 59
Fragen und Anmerkungen!
Danke!Thanx!
© 2006 - Christian Gütl11.04.23 60
Quellen 1
[Sommerville 2001]Sommerville, Ian: Software Engineering; 6. Auflage, München, Germany, 2001.
[Sommerville 2005]Sommerville, Ian: Software Engineering 7; 7. Auflage, Addison-Wesley, Boston, USA, 2005.
[QMLexikon]Lastenhefthttp://www.quality.de/lexikon/lastenheft.htm