Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Requirements Engineering

Ähnliche Präsentationen


Präsentation zum Thema: "Requirements Engineering"—  Präsentation transkript:

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

2 Requirements Engineering
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

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

4 Risiken und Fehler durch Anforderungen
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 Risiken und Fehler durch Anforderungen
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 Risiken und Fehler durch Anforderungen
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 Risiken und Fehler durch Anforderungen
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 Risiken und Fehler durch Anforderungen
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 Der Nutzen von Requirements Engineering
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

10 Der Nutzen von Requirements Engineering
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

11 Konzepte des Requirements Engineering
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

12 Konzepte des Requirements Engineering
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 Konzepte des Requirements Engineering
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 Sichten auf Anforderungen
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.

15 Sichten auf Anforderungen
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 Sichten auf Anforderungen
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

17 Arten von Anforderungen
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

18 Arten von Anforderungen
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 Arten von Anforderungen
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 Was ist Requirements Engineering?
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

21 Was ist RE? 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.

22 Was ist RE? 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.

23 Standards und Normen 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.

24 Methodik des RE 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.

25 Lebenszyklus 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

26 Lebenszyklus 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

27 Lebenszyklus 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

28 Rollen, Verantwortungen, Kompetenzen
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

29 Rollen, Verantwortungen, Kompetenzen
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 Rollen, Verantwortungen, Kompetenzen
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 Aufgaben, Rollen und Organisationsstruktur
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

32 Aufgaben, Rollen und Organisationsstruktur
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 Aufgaben, Rollen und Organisationsstruktur
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 Aufgaben, Rollen und Organisationsstruktur
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 Aufgaben, Rollen und Organisationsstruktur
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 Aufgaben, Rollen und Organisationsstruktur
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 Aufgaben, Rollen und Organisationsstruktur
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 Aufgaben, Rollen und Organisationsstruktur
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 Aufgaben, Rollen und Organisationsstruktur
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 Anforderungen ermitteln
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:

41 Anforderungen ermitteln
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 Anforderungen ermitteln
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 Anforderungen ermitteln
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 Anforderungen ermitteln
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 Anforderungen ermitteln
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 Anforderungen ermitteln
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 Anforderungen ermitteln
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 Anforderungen ermitteln
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 Anforderungen ermitteln
Randbedingungen reduzieren den möglichen Lösungsraum, Beispiele sind gesetzliche Bestimmungen wie der Datenschutz im Softwaresystem

50 Anforderungen spezifizieren
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

51 Anforderungen spezifizieren
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

52 Anforderungen modellieren und analysieren
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

53 Anforderungen modellieren und analysieren
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

54 Anforderungen verifizieren und validieren
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

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

56 Anforderungen vereinbaren
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

57 Anforderungen vereinbaren
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

58 Änderungen managen Ä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

59 Änderungen managen 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.

60 Werkzeugunterstützung
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

61 Werkzeugunterstützung
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)

62 Vielen Dank!!!


Herunterladen ppt "Requirements Engineering"

Ähnliche Präsentationen


Google-Anzeigen