Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Requirements Engineering Virtuelle Forschungsumgebungen Dozent Prof. Dr. M. Thaller Referentin Nadya Steinert 1.

Ähnliche Präsentationen


Präsentation zum Thema: "Requirements Engineering Virtuelle Forschungsumgebungen Dozent Prof. Dr. M. Thaller Referentin Nadya Steinert 1."—  Präsentation transkript:

1 Requirements Engineering Virtuelle Forschungsumgebungen Dozent Prof. Dr. M. Thaller Referentin Nadya Steinert 1

2 Anforderungen und Ziele sind die Hauptbausteine von Requirements Engineering. Es kann nicht nach einer Lösung gesucht werden, ohne das es ein gut definiertes Problem gibt. Die meisten abgebrochenen Projekte hatten nur ungenügend geklärte Anforderungen und konnten Änderungen der Anforderungen nicht beherrschen. Oft erreichen Projekte ihre Ziele nicht, weil diese nicht sauber formuliert wurden Requirements Engineering 2

3 Erfolgsfaktoren für Produktentwicklung Ergebnisorientierte Vorgaben Zielorientierte Prozesse Kompetentes Produkt- und Projektmanagement Standardisierte und optimierte Infrastruktur Fokus auf Anforderungen, Änderungen und Risiken im Projekt Risiken und Fehler durch Anforderungen 3

4 Risiko 1: Fehlende Anforderungen Bestimmte Anforderungen werden übersehen Typen von Anforderungen: funktionale Anforderungen, Qualitätsanforderungen, Rahmenbedingungen, Produkt-,Markt- und Komponentenanforderungen Für vollständige Anforderungsdokumentation müssen alle diese Typen hinterfragt werden Testfälle müssen alle diese Kategorien von Anforderungen abdecken Risiken und Fehler durch Anforderungen 4

5 Risiko 2: Falsche Anforderungen Fehler werden erst bei Test und Abnahme des Produkts entdeckt: die Korrektur wird aufwendig Anforderungen werden oft von Kunden- und Benutzerinterviews übernommen; sie müssen aber erweitert und präzisiert werden Fehler werden frühzeitig durch Verifikation und Validierung entdeckt (Checklisten und Szenarien wichtiger Abläufe) Risiken und Fehler durch Anforderungen 5

6 Falsche Anforderungen entstehen, wenn Bedarf und Lösung gemischt oder verwechselt werden Es sollen immer zwei Spezifikationsdokumente geführt werden: Liste der Anforderungen (Lastenheft) und Liste der Lösungsspezifikationen (Pflichtenheft) Entwickler verstehen Anforderungen falsch: es kommt zu Verzögerungen, hohen Kosten, zusätzlichem Entwicklung-, Korrektur-, und Testaufwand Risiken und Fehler durch Anforderungen 6

7 Risiko 3: Sich ändernde Anforderungen Nicht beherrschbare Änderungen an Anforderungen führen zu Kosten- und Terminüberschreitungen und reduzieren die Qualität Es gibt meistens eine gewisse Basis an Anforderungen, einige Punkte sind offen und werden im Laufe der Zeit geklärt Unzureichende Einbeziehung der Benutzer führt zu nicht akzeptierte Produkte und unzufriedene Kunden Risiken und Fehler durch Anforderungen 7

8 Bis bestimmten Meilensteinen soll die Änderungsmenge reduziert werden Rückwärtsplanung von Ausgabe zurück ins Projekt zeigt, wie früh es keine parallel Arbeit mehr zulässig ist 8 Risiken und Fehler durch Anforderungen

9 Produktivitätsverbesserung: 30-50% des Entwicklungsaufwands sind für Fehlerbehebung; die Hälfte der Fehler kommt von unzureichenden Anforderungen und unkontrollierten Änderungen Bekannte Anforderungen und klare Verantwortungen im Projektteam führen zu verbesserte Projektplanung und Ressourceneinteilung, weniger Verzögerungen und Termintreue 9 Der Nutzen von Requirements Engineering

10 Fokus auf jene Aktivitäten und Inhalte, die Wert schaffen. Knapp die Hälfte aller Funktionen eines Softwaresystems werden nicht genutzt. Weniger Anforderungen reduzieren die Komplexität und machen die Qualität besser. Bessere Kundenzufriedenheit durch konsistentes Verständnis über die wirklichen Anforderungen 10 Der Nutzen von Requirements Engineering

11 Was ist eine Anforderung?: Sie beschreibt, was der Kunde oder Benutzer vom Produkt erwartet: Eine Eigenschaft oder Bedingung - die von einem Benutzer zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird - die ein System oder eine Systemkomponente erfüllen muss, um einen Vertrag oder Spezifikation zu erfüllen Eine dokumentierte Repräsentation einer Eigenschaft oder Bedingung, wie oben beschrieben 11 Konzepte des Requirements Engineering

12 Anforderungen können mehrdeutig, überspezifisch, unvollständig, kontextspezifisch, unmöglich oder falsch sein, aber immer zu viele. Bei Anforderungen stellen sich viele Fragen: Ist die Anforderung wichtig? Sind alle Inhalte gleichermaßen wichtig und wie korrelieren sie? Wie ist der Status der Anforderung? Wer ist für die Anforderung verantwortlich? Ist die Anforderung machbar? Welche Einflüsse hat sie? 12 Konzepte des Requirements Engineering

13 Wurde diese Anforderung geändert und durch wen? Wo sind die Analyseergebnisse dokumentiert? Wie wird die Anforderung validiert? Wie konkretisiert sich die Anforderung? Requirements Engineering hat die Aufgabe, verschiedene Interessen und Sichtweisen unter einen Hut zu bringen. Es begrenzt und steuert die Verluste, die im Projekt auftreten 13 Konzepte des Requirements Engineering

14 Marktanforderungen Anforderungen an ein Produkt aus Sicht des Kunden warum ein Projekt durchgeführt werden soll? Werden im Lastenheft dokumentiert Es muss Priorisierung aus betriebswirtschaftlicher Sicht geben Z. B. Marktanforderungen an einer Digitalkamera gehen sehr konkret auf Benutzungsaspekte ein: Lebensdauer der Akkus, Pixelzahl, Bildschirmschärfe usw. 14 Sichten auf Anforderungen

15 Produktanforderungen Anforderungen an ein Produkt aus Sicht der Realisierung einer späteren Lösung Beschreiben, was verschiedene Benutzer mit dem Produkt machen können Sie werden im Pflichtenheft dokumentiert Betrachten Softwareprodukt oder Dienst innerhalb der Umgebung, in der das System einmal arbeiten muss 15 Sichten auf Anforderungen

16 Komponentenanforderungen Anforderungen an eine Komponente eines Produkts Werden auch im Pflichtenheft spezifiziert Das sind z. B. Anforderungen an ein Betriebssystem oder an ein Rauchmelder Das vermischen der Produkt- und Komponentenanforderungen führt zu einem Strukturbruch, der schwer zu handhaben ist 16 Sichten auf Anforderungen

17 Funktionale Anfoerderungen Beschreiben eine vom System bereitzustellende Funktion, was das System tun soll Sie lassen sich leicht verfolgen und verifizieren Man kann für eine bestimmte Funktion sogar einen Testfall schreiben, der später in verschiedenen Phasen geprüft wird 17 Arten von Anforderungen

18 Qualitätsanforderungen Beschreiben eine qualitative Eigenschaft, die das System oder eine Funktion aufweisen müssen Sie ergänzen die funktionalen Anforderungen: Beispiele sind Zuverlässigkeit, Verfügbarkeit, Wartbarkeit Sind schwer zu spezifizieren und zu testen Schwierige und oft unzureichende Diagnose und Fehlermanagement 18 Arten von Anforderungen

19 Randbedingungen Eine organisatorische oder technische Anforderung, die die Art und Weise einschränkt, wie ein System realisiert werden kann Sie ergänzen funktionale Anforderungen und Qualitätsanforderungen; Kosten, Geschäftsprozesse, Gesetze sind typische Beispiele Organisatorische Randbedingungen spielen auch eine Rolle, obwohl sie nicht als Anforderungen zugegeben werden 19 Arten von Anforderungen

20 Requirements Engineering (RE) ist das disziplinierte und systematische Vorgehen zur Ermittlung, Spezifikation, Analyse, Vereinbarung, Validierung und Verwaltung von Anforderungen, um Bedürfnisse und Ziele in ein Produkt umzusetzen RE ist eine Kerndisziplin aller Ingenieurwissenschaften und damit auch der Softwaretechnik und Systemtechnik 20 Was ist Requirements Engineering?

21 Re wird sowohl bei neuen Produkten, als auch bei Änderungen bestehender Produkte angewandt. Re wird vor dem Projektstart und während der gesamten Laufzeit eines Projekts eingesetzt. Die Techniken unterscheiden sich dabei, aber die Aktivitäten von der Ermittlung bis zur Verwaltung sind immer Pflicht. 21 Was ist RE?

22 Das Ziel von RE ist es, qualitativ gute – nicht perfekte – Anforderungen zu generieren, die es erlauben, das Projekt mit einem akzeptablen Risiko zu beginnen. Der zweck des RE ist es, ein Einverständnis zwischen dem Kunden und dem Software Projekt(also dem Lieferanten) über jene Anforderungen zu erreichen, die durch das Softwareprojekt abgedeckt wurden. 22 Was ist RE?

23 Ein grundlegendes Standard der System und Softwaretechnik ist das CMMI (Capability Maturity Model Integration); es basiert auf die Erkenntnis, dass die Zusammensetzung von einzelnen besten Praktiken keine Lösung verspricht. Man muss den gesamten Lebenszyklus von der Konzeption bis zur Lieferung durchgängig betrachtet, wenn man etwas nachhaltig verbessern will. Andere Standards sind die ISO/IEC, IEEE, VDI-Richtlinie. 23 Standards und Normen

24 Die Methodik des RE basiert auf einem Kundenorientierten Ansatz, der die Wünsche verschiedener Interessengruppen erfasst, bewertet und verbindet. Nur unter diesen Bedingungen kann ein motiviertes Projektteam, mit gemeinsamer Mission geformt werden. 24 Methodik des RE

25 Strategie und Konzeption- Upstream-Phase in der Produktentwicklung vor Beginn des Projekts; es wird festgesetzt welche Anforderungen berücksichtigt werden; Inhalte, Ziele und Meilensteine werden vereinbart; die Produktvision entsteht: z. B. welche Märkte in welcher Form adressiert oder nicht adressiert werden RE in der Planungsphase bezieht sich unter anderem auf die Analyse der Systemumgebung, des Benutzerverhaltens und der späteren Entwicklungsschritte 25 Lebenszyklus

26 Entwicklung – Umsetzung der Anforderungen in ein funktionsfähiges Produkt unter vereinbarten Einschränkungen(Kosten, Zeit etc.) Grundlegende Prozesse in dieser Phase sind Management der Anforderungen, Entwicklung einer Architektur oder Entwurf, Verifikations- und Validierungsstrategie, Implementierung, Paketierung und Qualitätskontrolle 26 Lebenszyklus

27 Markteintritt – relevant für die Aufnahme und Akzeptanz eines Produkts; er beeinflusst den wahrgenommenen Nutzen: eine neue hervorragende Serverplattform in einer Anwendung, die sich nicht verkauft ist nicht nützlich Evolution(Wartungsphase) – wird durch zwei Änderungsarten am existierenden Produkt bestimmt : Fehlerkorrekturen und Erweiterungen, was zu einem neuen Produkt führt RE spielt bei Wartungsprojekten sehr große Rolle: bei jeder Änderung muss man abwägen, ob sie in die gesamte Strategie passt 27 Lebenszyklus

28 Interessenvertreter(Stakeholder), Perspektiven und Zielgruppen Im RE gibt es zwei grundsätzlich verschiedene Rollen: Ein Auftraggeber(Benutzer, Kunde), der eine Lösung für seine Bedürfnisse sucht Ein Lieferant, der diese Anforderungen in eine Lösung umgesetzt liefert Beide Seiten können vom Projektmanager nicht optimiert werden, aber man muss die Argumente der anderen Seite verstehen 28 Rollen, Verantwortungen, Kompetenzen

29 Diese Rollentrennung ist wichtig in Situationen, wo der Kunde oder Benutzer nicht direkt ansprechbar ist; beispielweise bei Konsumgütern, eingebetteter Software oder Anwendungen für die noch kein Markt existiert. Also muss jemand von der Seite des Lieferanten diese Rolle effektiv einnehmen Neben diese zwei Hauptrollen, gibt es auch andere: Marketing und Vertrieb, Produktmanager, Geschäftsleitung, Entwicklung, Qualitätssicherung etc. Es ergeben sich immer Konflikte zwischen diesen Rollen, die gemeistert werden müssen 29 Rollen, Verantwortungen, Kompetenzen

30 Schlüsselpersonen und Interessengruppen zu kennen und mit ihnen richtig umgehen zu können, ist wesentlicher Erfolgsfaktor von RE. Es muss zuerst festgestellt werden, welche Interessenvertreter für das Projekt eine Rolle spielen, und welche für das spätere Produkt 30 Rollen, Verantwortungen, Kompetenzen

31 Auftraggeber, Kunde – erwartet eine Lösung innerhalb bestimmter Rahmenbedingungen; kommt typischerweise von außerhalb des Unternehmens, die Verhältnisse werden vertraglich geregelt; kann aber auch innerhalb des Unternehmens sitzen; kommuniziert je nach Projektumfang mit dem Projektmanager, Vertrieb, Geschäftsleitung Benutzer – sie betreiben oder nutzen das System, stehen häufig auf Kundenseiten, in vielen Fällen aber muss scharf getrennt werden; für Benutzer ist Funktionalität wichtig, für Auftraggeber die Kosten 31 Aufgaben, Rollen und Organisationsstruktur

32 Projektmanager – ist für das Projekt verantwortlich; bringt die verschiedenen Anforderungen zusammen, sorgt dafür das Anforderungen, Zeitdauer und Aufwand mit den vorhandenen Ressourcen korrespondieren; wird am Erfolg des Projektes(Projekt im Rahmen der akzeptierten Randbedingungen liefern) gemessen 32 Aufgaben, Rollen und Organisationsstruktur

33 Produktmanager – ist für das Produkt( verschiedene Versionen, Varianten, Dienstleistungen) über den gesamten Produktlebenszyklus verantwortlich; hat Interesse an langfristigem Produkterfolg; seine Kernaufgabe ist Wirtschaftlichkeitsrechnung aufzustellen( entscheidet, was zu welchem Preis geliefert wird) 33 Aufgaben, Rollen und Organisationsstruktur

34 Marketing, Vertrieb – sorgt dafür das ein bestmöglicher Markt adressiert wird; versteht die Bedürfnisse der Kunden; sind für Re eine wichtige Quelle für Anforderungen und deren Änderungen Requirements- ingenieur – ist Bindeglied zwischen Kunden, Benutzer, Marketing/Vertrieb, Produktmanagement und Entwicklung ; für Dokumentation der Kundenbedürfnisse zuständig ; gemeinsam mit dem Kunden plant und spezifiziert Softwaresysteme und begleitet die Umsetzung, gleicht verschiedene Randbedingungen gegeneinander ab, um Konflikten zwischen Stakeholder zu entschärfen und zu Win-win- Situationen zu kommen 34 Aufgaben, Rollen und Organisationsstruktur

35 Entwicklung – stellet die Ressourcen bereit, um das Projekt auszuführen und Lösung zu entwickeln; Entwickler bringen durch ihre Sichtweise oft eine ganze Reihe von weiteren Anforderungen; geben wichtige Hinweise um Anforderungen zu präzisieren; Tester gehören auch zu Entwickler; Tests sollen noch am Anfang durchgeführt werden und nicht im nachhinein; wichtige Rolle im RE da sie die Anforderungen neutral und vom Hintergrund betrachten. 35 Aufgaben, Rollen und Organisationsstruktur

36 Qualitätssicherung – unabhängiger Kontrollorgan, sichert die Erfüllung von Qualitätsanforderungen an Produkt und Prozesse Änderungskomitee(engl. Change Control Board) – eine formal definierte Gruppe verschiedener Repräsentanten von Interessensphären, die über alle Änderungen zu Konfigurationsbasis des Projekts entscheiden 36 Aufgaben, Rollen und Organisationsstruktur

37 Projektkernteam/Leitungsgruppe – für die gesamte Steuerung des Prozesses nach innen und außen verantwortlich; besteht aus Projekt-,Produkt-, Marketingmanager, Vertreter von Entwicklung, Betrieb, Qualitätssicherung und Service die sich einmal wöchentlich trifft Geschäftsleitung – die Projekte sollen zu den geschäftszielen des Unternehmens passen 37 Aufgaben, Rollen und Organisationsstruktur

38 Produktmanagement – verantwortet Markt- und Produktanforderungen; balanciert Umsatz und Kosten Projektmanagement – prüft ob Anforderungen klar definiert sind und ob die für alle Rollen im Projekt verständlich sind; bestimmt über alle Anforderungen und deren Änderungen; achtet bei wiederverwendeten Komponente, Wartungsprojekte und Unteraufträge darauf, das die Codebasis gemeinsam mit Anforderungen, Testfällen und Prüferergebnisse geliefert wird 38 Aufgaben, Rollen und Organisationsstruktur

39 Soft Skills – Win-win-Sutuationen ergeben sich aus verschiedene Elemente: Realistische Projekte Zusammensetzung der Anforderungen und Bewertung hinsichtlich unterschiedlicher Sichtweisen Risikomanagement gemeinsam mit dem Kunden; Abschwächung eines Risikos auf Kundenseite oftmals einfacher und billiger 39 Aufgaben, Rollen und Organisationsstruktur

40 Vor Ermittlung der Anforderungen muss ein Ziel oder eine Vision stehen, die über die Anforderungen selbst hinausgehen muss. Ziel der Ermittlung der Anforderungen ist wichtige Kunden, Märkte und Wettbewerber zu identifizieren und zu verstehen. Eine Produktvision orientiert sich an folgenden Fragen: 40 Anforderungen ermitteln

41 Was wird das Produkt verändern? Warum ist das Produkt für die Kunden nötig? Welche Erfahrung soll der Kunde damit machen? Wer wird durch das Produkt profitieren? Wie? Wie wird durch das Produkt Geld verdient? Welche Kosten und Risiken sind wir bereit zu tragen? Die Wahl der Ziele hat einen erheblichen Einfluss auf das bestehende Produkt und auf das Entwicklungsprozess 41 Anforderungen ermitteln

42 Produktideen und Produktvisionen orientieren sich an folgenden Einflüssen: Kunden: Kundenziele, Umgebung des Kunden, Wettbewerbssituation, Kundeninformationen, Kundenzufriedenheit, verfügbare Ressourcen Strategie: Unternehmensstrategie, Marktpositionierung, Umsatzentwicklung Wettbewerb: Wettbewerbsdaten, Marktanteil, Marktentwicklung 42 Anforderungen ermitteln

43 Produkte: Produktalter, Innovationsgrad, Wartungsanteil, Fehlerkosten, Verfügbarkeit, Nutzungsgrad, Kostenreduzierung, Technologien: ablösende/innovative Technologien, neue Forschungsergebnisse, neue Komponente, Werkzeuge, Lieferanten etc. Verfügbare Ressourcen als Restriktion : Zeit, Fähigkeiten, Mitarbeiter, Beherrschung von Technologien die Schlüsselfrage an jeder Produktvision lautet: Was wird bei den Kunden oder Benutzern anders sein, wenn das Produkt ausgeliefert ist ? 43 Anforderungen ermitteln

44 Den Kunden verstehen: häufig wird dem Kunden gebracht, was er braucht und nicht was er will. Ein Produkt muss immer den Kunden zufriedenstellen Es sollen keine unrealistische Termine und Preise gesetzt werden, da dies zu ungewünschte Resultate führen kann. 44 Anforderungen ermitteln

45 Techniken zur Ermittlung von Anforderungen: Anforderungen müssen einen Zusatznutzen bieten, für den ein Kunde bereit ist zu zahlen. Es geht darum zu verstehen was den Kunden oder Benutzer bewegt und wie das zukünftige Produkt einen positiven Einfluss darauf nehmen kann. Quellen für Anforderungen sind: Marktforschung und Marktstudien, Internet(Foren, Bewertungen), eigene Forschung und Entwicklung, Kundeninterviews, Seminare Workshops etc. 45 Anforderungen ermitteln

46 Unbekannte Anforderungen sind schwer zu ermitteln; es gibt Bereiche wo der Kunde und der Lieferant etwas nicht wissen. Es sollen negative Anforderungen benutzt werden, um Szenarios zu beschreiben, die nicht eintreten dürfen. Um an Anforderungen zu kommen kann man unterschiedliche Techniken benutzen: Fragebögen, Interviews, Brainstorming, Rollenspiele 46 Anforderungen ermitteln

47 Die Anforderungen werden analysiert und priorisiert und dann wird entschieden intern oder extern welche Annahmen, Randbedingungen und Einschränkungen übernommen werden Workshops mit verschiedenen Interessengruppen sind ideal, um Anforderungen zu ermitteln; die unterschiedlichen Bedürfnisse und daraus resultierende Konflikte werden offen ausgetragen Teilnehmer an ein Workshop: Auftraggeber, Benutzer(die mit dem System arbeiten), Benutzer (die installieren, pflegen ), Marketing, Entwickler, Lieferanten 47 Anforderungen ermitteln

48 Qualitätsanforderungen Benutzbarkeit: der Grad, zu dem ein Produkt durch bestimmte Benutzer im bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv und effizient zu erreichen Funktionale Sicherheit: die Summe der Eigenschaften eines Produkts, die dazu beitragen, dass es frei von nicht vertretbaren Risiken oder Gefahren ist Informationssicherheit: bedeutet, dass das Produkt mit dem von ihm verarbeitete oder gespeicherte Informationen, nichts tut, was von ihm nicht erwartet wird 48 Anforderungen ermitteln

49 Randbedingungen reduzieren den möglichen Lösungsraum, Beispiele sind gesetzliche Bestimmungen wie der Datenschutz im Softwaresystem 49 Anforderungen ermitteln

50 Durch die Spezifikation werden Details klar, Zusammenhänge transparent Anforderungen testbar und entscheidbar beschreiben Aufgaben und Lösungsbeschreibung müssen klar getrennt werden Schritte zur Spezifikation: Die verschiedenen Interessengruppen identifizieren Vision und Zielsetzung definieren Anforderungen ermitteln 50 Anforderungen spezifizieren

51 Anforderungen strukturiert spezifizieren Systemumgebung beschreiben Lösungsraum bestimmen Kundenkontakte beschreiben Anforderungen: vorläufige Analyse Klassifizieren und Priorisieren der Anforderungen Prüfen der Anforderungen Das Problemraum modellieren Lösungsraum modellieren und beschreiben 51 Anforderungen spezifizieren

52 Die Analyse beschäftigt sich mit der Beschreibung der Lösung und die genauen Schritten dazu. Das Ergebnis der Analysephase ist die Spezifikation eines Lösungsmodells. Die Beschreibung der Lösung führt zu neuen Fragen und weiteren Anforderungen. Die Analysephase wird zweitgeteilt; nach einer ersten Analyse vom Lieferant zum Zweck des Angebotserstellung, wird eine zweite Analyse zum Projektstart durchgeführt 52 Anforderungen modellieren und analysieren

53 Analyse beschreibt Funktionen, Schnittstellen, Informationsaustausch, Zustände und die Interaktion mit der Umgebung; sie liefert mehrere Modelle dynamisch und statisch) Die Modelle beschreiben keine exakte Implementierung; die unterstützen die Kommunikation der Aufgaben- und Lösungsbeschreibung 53 Anforderungen modellieren und analysieren

54 Verifikation und Validierung sind die Schlüssel um Fehler in Anforderungen und Spezifikationen zu finden. Validierung: doing the right things; vergleicht Anforderungen an das Produkt mit verfügbaren Ergebnissen; externe Sicht Verifikation: doing things right; vergleicht Prozessanforderungen mit Prozessergebnissen; Prozesssicht 54 Anforderungen verifizieren und validieren

55 Qualitätskriterien für Anforderungen : Geschäftsnutzen, Korrektheit, Eindeutigkeit, Verständlichkeit, Vollständigkeit, Konsistenz, Nachverfolgbarkeit, Relevanz 55 Anforderungen verifizieren und validieren

56 Ausgewählte Anforderungen werden einem Projekt zugewiesen, erst dann können realistische Vereinbarungen mit dem Kunden geschlossen werden und man kann mit den Entwicklungsarbeiten beginnen. Da Anforderungen unstabil sind, heißt vereinbaren nicht einfrieren; Ab dem Projektstart müssen alle Anforderungen verbindlich kontrolliert werden, Änderungen unterliegen dem Änderungsmanagement 56 Anforderungen vereinbaren

57 Produkte sind dann erfolgreich, wenn Der Eintrittstermin stimmt Die Qualität den Anforderungen des Markts genügt Der Preis konkurrenzfähig ist Ein Bedarf an dem Produkt besteht oder erzeugt werden kann 57 Anforderungen vereinbaren

58 Änderungen müssen sorgfältig geprüft werden, in das Projekt aufgenommen und verfolgt werden. Ein gutes Projekt beherrscht die Änderungen und wird nicht von Ihnen beherrscht. Änderungen in der Umgebung verursachen Änderungen der Anforderungen Anforderungen können sich zu jedem Zeitpunkt ändern, denn man lernt ständig etwas neues zu dieser Anforderung 58 Änderungen managen

59 Anforderungen und deren Änderungen müssen kontrolliert und verfolgt werden, um ihren Einfluss im Projekt zu erkennen. Für einen Tester ist wichtig zu wissen, welche Testfälle sich auf welche Anforderungen beziehen. 59 Änderungen managen

60 Spreadsheets – selbstgemachte Templates in einer Tabellenkalkulation; sie erlauben eine wirksame Kontrolle von Anforderungen in kleinen Projekten Wikis – erlauben den unmittelbaren Zugriff verschiedener Benutzer zur Organisation von Anforderungen; man kann ein vorhandenes Template oder ein komplettes Hosting von einer externen Quelle übernehmen und entsprechend anpassen 60 Werkzeugunterstützung

61 Workflow- Tools – sie beschreiben eine Abfolge von Schritten, beispielweise von der Ermittlung bis zur Freigabe, die dann an verschiedenen Personen weitergeleitet werden kann; Bugzilla, Mylyn(Pflege von Verknüpfungen) 61 Werkzeugunterstützung

62 62 Vielen Dank!!!


Herunterladen ppt "Requirements Engineering Virtuelle Forschungsumgebungen Dozent Prof. Dr. M. Thaller Referentin Nadya Steinert 1."

Ähnliche Präsentationen


Google-Anzeigen