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

1

Requirements EngineeringVirtuelle Forschungsumgebungen

Dozent Prof. Dr. M. ThallerReferentin Nadya Steinert

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

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

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


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)


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


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


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


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

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

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

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?


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


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.

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


16

Komponentenanforderungen Anforderungen an eine Komponente eines

Produkts Werden auch im Pflichtenheft spezifiziert Das sind z. B. Anforderungen an ein

Betriebssystem oder an ein RauchmelderDas vermischen der Produkt- und

Komponentenanforderungen führt zu einem Strukturbruch, der schwer zu handhaben ist


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

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


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


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

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.

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.

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.

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.

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

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

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

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 suchtEin Lieferant, der diese Anforderungen in eine Lösung umgesetzt liefertBeide Seiten können vom Projektmanager nicht optimiert werden, aber man muss die Argumente der anderen Seite verstehen

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


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


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

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


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)


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


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.


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


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


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


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


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:

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


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


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 ?


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.


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.


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


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


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


49

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


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

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

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

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

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

Anforderungen verifizieren und validieren

55

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

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

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

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

Ä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.

Ä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

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)

Werkzeugunterstützung

62

Vielen Dank!!!

Documents

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