Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Projektmanagement - Block 5 Softwareanforderungen Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische Universität.

Ähnliche Präsentationen


Präsentation zum Thema: "Projektmanagement - Block 5 Softwareanforderungen Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische Universität."—  Präsentation transkript:

1 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

2 © 2006 - Christian Gütl 17.05.2014 2 Prozessgruppen

3 © 2006 - Christian Gütl 17.05.2014 3 Buchempfehlung Software Engineering 7 Ian Sommerville ISBN: 0-321-21026-3 Publisher: Addison-Wesley Copyright: 2005 Format: 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

4 © 2006 - Christian Gütl 17.05.2014 4 Agenda Arten von Softwareanforderungen Lastenheft und Pflichtenheft Softwareanforderungsbestimmung und – analyse Validierung der Softwareanforderungen

5 © 2006 - Christian Gütl 17.05.2014 5 Abschnitt 1 Softwareanforderungen im Überblick

6 © 2006 - Christian Gütl 17.05.2014 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

7 © 2006 - Christian Gütl 17.05.2014 7 Zielgruppen vs. Spezifikationsarten

8 © 2006 - Christian Gütl 17.05.2014 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.

9 © 2006 - Christian Gütl 17.05.2014 9 Einteilung von Anforderungen

10 © 2006 - Christian Gütl 17.05.2014 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

11 © 2006 - Christian Gütl 17.05.2014 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)

12 © 2006 - Christian Gütl 17.05.2014 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.

13 © 2006 - Christian Gütl 17.05.2014 13 Nichtfunktionale Anforderungen 1 Nichtfunktionale Anforderungen –Betreffen nicht funktionale Anforderungen –Beschreiben vielmehr Softwareeigenschaften Z.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

14 © 2006 - Christian Gütl 17.05.2014 14 Nichtfunktionale Anforderungen 2

15 © 2006 - Christian Gütl 17.05.2014 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)

16 © 2006 - Christian Gütl 17.05.2014 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

17 © 2006 - Christian Gütl 17.05.2014 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

18 © 2006 - Christian Gütl 17.05.2014 18 Benutzeranforderungen

19 © 2006 - Christian Gütl 17.05.2014 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

20 © 2006 - Christian Gütl 17.05.2014 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

21 © 2006 - Christian Gütl 17.05.2014 21 Benutzeranforderungen 3 Beispiel Benutzeranforderung [Sommerville 2001] 3.5.1 Hinzufügen von Knoten zu einem Entwurf 3.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

22 © 2006 - Christian Gütl 17.05.2014 22 Systemanforderungen

23 © 2006 - Christian Gütl 17.05.2014 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 Systemen Vorgabe der Nutzung v. bestimmten Entwurf

24 © 2006 - Christian Gütl 17.05.2014 24 Systemanforderungen 2

25 © 2006 - Christian Gütl 17.05.2014 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

26 © 2006 - Christian Gütl 17.05.2014 26 Strukturierte natürliche Sprache 1 Standardformulare sollen folgende Informationen beinhalten 1.Beschreibung der Funktion oder Entität 2.Beschreibung der Eingabedaten und Herkunft 3.Beschreibung der Ausgabedaten und Ziel 4.Hinweis welche andere Entitäten verwendet werden 5.Bei Beschreibung funktionaler Methoden: Vor- und Nachbedingungen 6.Beschreibung von Seiteneffekten Achtung: Zusammenhang zwischen Benutzer- u. Systemanforderung soll ersichtlich sein !

27 © 2006 - Christian Gütl 17.05.2014 27 Strukturierte natürliche Sprache 2 Mytool/DE/SA/Abschnitt 3.5.1 [Sommerville 2001] FunktionKnoten hinzufügen BeschreibungFü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. EingabenKnotentyp, Knotenposition, EntwurfsID HerkunftKnotentyp u. Position durch Benutzer, EntwurfID durch Datenbank AusgabeEntwurfsID ZielEntwurfsdatenbank (am Ende d. Operation) BenötigtEntwurfsgraphen, gekennzeichnet durch EntwurfsID des Rootknotens VorbedingungEntwurf geöffnet und am Bildschirm dargestellt NachbedingungEntwurf ergänzt um hinzugefügten Knoten SeiteneffekteKeine Benutzeranforderung: Mytool/DE/BA/Abschnitt 3.5.1

28 © 2006 - Christian Gütl 17.05.2014 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

29 © 2006 - Christian Gütl 17.05.2014 29 Sprachen zur Entwurfsbeschreibung 1 Sprachen der Entwurfsbeschreibung bzw. 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

30 © 2006 - Christian Gütl 17.05.2014 30 Sprachen zur Entwurfsbeschreibung 2 class ATM { // Deklarationen public static void main (String args[]) throws InvalidCard { try { thisCard.read(); // Kann die Exception // Invalid Card auslösen pin = 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]

31 © 2006 - Christian Gütl 17.05.2014 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

32 © 2006 - Christian Gütl 17.05.2014 32 Anforderungsdokumente

33 © 2006 - Christian Gütl 17.05.2014 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.

34 © 2006 - Christian Gütl 17.05.2014 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

35 © 2006 - Christian Gütl 17.05.2014 35 Das Pflichtenheft 2

36 © 2006 - Christian Gütl 17.05.2014 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

37 © 2006 - Christian Gütl 17.05.2014 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)

38 © 2006 - Christian Gütl 17.05.2014 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

39 © 2006 - Christian Gütl 17.05.2014 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. WAS 3.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!!!

40 © 2006 - Christian Gütl 17.05.2014 40 Abschnitt 2 Abläufe der Anforderungsanalyse

41 © 2006 - Christian Gütl 17.05.2014 41 Durchführbarkeitsstudie 1

42 © 2006 - Christian Gütl 17.05.2014 42 Durchführbarkeitsstudie 2 Durchführbarkeitsstudie –Vgl. Idea & Prelaunch Stage der Project Process Architecture (PPA) –Lt. Sommerville soll die Studie folgenden Fragen beantworten 1.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

43 © 2006 - Christian Gütl 17.05.2014 43 Anforderungsbestimmung u. -analyse 1

44 © 2006 - Christian Gütl 17.05.2014 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

45 © 2006 - Christian Gütl 17.05.2014 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

46 © 2006 - Christian Gütl 17.05.2014 46 Ablauf- und Analysemodell 1

47 © 2006 - Christian Gütl 17.05.2014 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

48 © 2006 - Christian Gütl 17.05.2014 48 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 …

49 © 2006 - Christian Gütl 17.05.2014 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

50 © 2006 - Christian Gütl 17.05.2014 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

51 © 2006 - Christian Gütl 17.05.2014 51 Viewpoint-orientierte Bestimmung 3 Vorschlag für Vorgehensweise 1.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

52 © 2006 - Christian Gütl 17.05.2014 52 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

53 © 2006 - Christian Gütl 17.05.2014 53 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 enthalten 1.Systemzustand zu Beginn des Szenarios 2.Beschreibung des normalen Ereignisablaufs 3.Beschreibung von möglichen Fehlern und deren Behandlung 4.Hinweis auf anderen Aufgaben, die parallel ablaufen können 5.Beschreibung des Systemzustandes nach Abschluss des Szenarios

54 © 2006 - Christian Gütl 17.05.2014 54 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

55 © 2006 - Christian Gütl 17.05.2014 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

56 © 2006 - Christian Gütl 17.05.2014 56 Validierung von Anforderungen 1

57 © 2006 - Christian Gütl 17.05.2014 57 Validierung von Anforderungen 2 Umfasst verschiedene Arten der Prüfung 1.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 !!!

58 © 2006 - Christian Gütl 17.05.2014 58 Validierung von Anforderungen 3 Techniken der Anforderungsvalidierung 1.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

59 © 2006 - Christian Gütl 17.05.2014 59 Fragen und Anmerkungen! Danke! Thanx!

60 © 2006 - Christian Gütl 17.05.2014 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] Lastenheft http://www.quality.de/lexikon/lastenheft.htm


Herunterladen ppt "Projektmanagement - Block 5 Softwareanforderungen Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische Universität."

Ähnliche Präsentationen


Google-Anzeigen