Requirements Engineering

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? RequirementsEngineering (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 (CapabilityMaturity 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