Requirements Engineering

Slides:



Advertisements
Ähnliche Präsentationen
Identifizierung und Ausbildung von Führungskräften
Advertisements

Developing your Business to Success We are looking for business partners. Enterprise Content Management with OS|ECM Version 6.
Risiko-Management im Projekt
Vorgehensmodell - Wasserfallmodell
Leitbilderstellung der Samtgemeinde Am Dobrock
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil3.
Das „Vorgehensmodell“
Die Präsentation des Praktikums
Modelle und Methoden der Linearen und Nichtlinearen Optimierung (Ausgewählte Methoden und Fallstudien) U N I V E R S I T Ä T H A M B U R G November 2011.
1 JIM-Studie 2010 Jugend, Information, (Multi-)Media Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme MuSofT LE Capability Maturity Model Tailoring Tailoring bedeutet ungefähr: Maßschneidern.
Was ist und wie prüft man Qualität
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Was ist Refactoring? Bevor man die Integration angeht, mag es angebracht sein, den.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.2- LM 8 - LO 9 Definitionen zu LM 8.
Risiken und Chancen Risiko Beurteilung: Dazu gehört die Identifikationen von Risiken, ihre Analyse und das Ordnen nach Prioritäten. Risiko Kontrolle: Dazu.
Was ist Qualität ? Qualität von Produkten oder Dienstleistungen ist das Gesamtergebnis aller Aktivitäten in jeder Phase des gesamten Leistungsprozesses.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
Es gibt viele Arten von Risiken
es gibt (fast) nichts, was nicht anders gemacht werden könnte
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil2.
Rational Unified Process (RUP) - Definitionen
Vererbung Spezialisierung von Klassen in JAVA möglich durch
Software Risk Evaluation Method (SRE)
eXtreme Programming (XP)
Der „virtuell cube“ : Die drei Bewegungen
Die Bank von morgen - eine neue Welt für IT und Kunden? 23. Oktober 2001.
Gesundes Führen lohnt sich !
Rechneraufbau & Rechnerstrukturen, Folie 12.1 © W. Oberschelp, G. Vossen W. Oberschelp G. Vossen Kapitel 12.
2 Distanzbasierte Sprachkommunikation für Peer-to-Peer-Spiele.
Kontrollfragen zu Kapitel 1
1. 2 Schreibprojekt Zeitung 3 Überblick 1. Vorstellung ComputerLernWerkstatt 2. Schreibprojekt: Zeitung 2.1 Konzeption des Kurses 2.2 Projektverlauf.
Vorgehensmodelle: Schwergewichtige Modelle
Software Engineering WS 2009
Spezifikation von Anforderungen
Das Wasserfallmodell - Überblick
Software Engineering SS 2009
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering WS 2006 / 2007Folie 1 Agile Vorgehensweisen Hintergrund –in den letzten Jahren hat.
Steigerung der Wertschöpfung Unternehmergespräche 15./16. Mai 2006 Carlo von Ah.
20:00.
Das Pflichtenheft Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth
1 Fachtagung am Seniorenorientiertes Design und Marketing ThyssenKrupp Immobilien Design for all - Anpassungen im Wohnungsbestand 1.Demographie.
Service Design by EstherKnaus® Der Benchmark für Dienstleistungen
Balanced Scorecard Knut Hinkelmann
© 2005, informations-broker.netinformations-broker.net© 2005, informations-broker.netinformations-broker.net Folie-Nr Basel II: Rating verbessern.
Dokumentation der Umfrage
REQUIREMENTS ENGINEERING
Requirements Engineering
PROCAM Score Alter (Jahre)
Spice Info-Point 2008 Urs Frei.
Symmetrische Blockchiffren DES – der Data Encryption Standard
MINDREADER Ein magisch - interaktives Erlebnis mit ENZO PAOLO
IT Kosten Reduzierung und effizientere Dienstleistungen Wir optimieren Strukturen und Prozesse und reduzieren dabei Ihre IT Kosten Ihr OPTICONSULT International.
1 (C)2006, Hermann Knoll, HTW Chur, FHO Quadratische Reste Definitionen: Quadratischer Rest Quadratwurzel Anwendungen.
Schutzvermerk nach DIN 34 beachten 20/05/14 Seite 1 Grundlagen XSoft Lösung :Logische Grundschaltung IEC-Grundlagen und logische Verknüpfungen.
Management, Führung & Kommunikation
xRM1 Pilot Implementierung
Von Unternehmen und Unternehmern
Unified Process Historisch-Kulturwissenschaftliche Informationsverarbeitung Übung: Planung von Softwareprojekten Dozent: Christoph Stollwerk WS 2014/2015.
Systematisches Requirements Engineering Anforderungen ermitteln, spezifizieren, analysieren und verwalten AM2 – Planung von Softwareprojekten Dozent:
1 Medienpädagogischer Forschungsverbund Südwest KIM-Studie 2014 Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.
Erfolgsfaktor Unternehmenskultur bei Fusionen:
Requirements Engineering Universität zu Köln Medienkulturwissenschaften/Medieninformatik Kurzreferat in Planung von Softwareprojekten bei Herrn Christoph.
Qualitätsmanagement nach ISO 9001:2000 in der Zahnarztpraxis
Müller Christoph1 Projektmanagement und MS Project Pädagogisches Institut.
4) Kaufmännische Realisierung
Projektentstehung und Projektumfeld
Prof. Dr. Andrea Back Krems-Kurs Herbst 2008 Seite 1 Zehn Fachbegriffe zur Strategy Map (nach Kaplan/Norton, 2004, deutsch) Vorlage für Ihre persönlichen.
Betriebswirtschaftliche Projekte Management-Systeme Zertifizierungen ISO 9001, ISO 14001, ISO und weitere Sicherheit und Gesundheitsschutz am Arbeitsplatz.
 Präsentation transkript:

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

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

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

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

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)

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

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

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

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

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

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

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?

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

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.

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

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

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

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

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

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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)

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

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.

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

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

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

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

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:

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

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

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 ?

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

Ä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

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

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

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)

Vielen Dank!!!