Projektmanagement & Requirements Engineering

Ein "+" bedeutet, dass der Effekt zur Ursache positive / verstärkend in Beziehung steht -> Mehr Eier = Mehr Hühner | weniger Eier = weniger Hühner

Ein "-" bedeutet, dass der Effekt zur Ursache negaitv / ausbalancierend in Beziehung steht -> Mehr Road crossings = weniger Hühner | weniger Road Crossings = mehr Hühner

1. Top Down
   1. Von der Blackbox zur Whitebox; Zu frühe Auseinandersetzung mit Details verhinder oft den Blick für das Wesentliche (Betrifft Untersuchung des Problemfeldes, Ausgangssituation und Entwurf der Lösung)
2. Variantenbildung - Denken in Varianten
   1. Das Prinzip der Variantenbildung, des Denkens in Alternativen, halten wir für einen unverzichtbaren Bestandteil guter Planung. Dies ist eine methodische Grundhaltung und muss – bei Beachtung des Vorgehensprinzips Vom Groben zum Detail – nicht zu einem nennenswerten zusätzlichen Planungsaufwand führen.
3. Projektphasen
   1. Gliedern eines Projekts nach zeitlich-logischen Gesichtspunkten zur Kontrolle von Komplexität
   2. «Das Phasenkonzept stellt die logische Erweiterung der Vorgehensprinzipien «Vom Groben zum Detail» und «Variantenbildung» dar.
4. Problemlösungszyklus
   1. Systematisches Vorgehen bei Auftreten jeder Art von Problemen in jeder Phase eines Projekts führen zu belastbaren Lösungen.
   2. «Der Problemlösungszyklus stellt als vierter Baustein des SE-Vorgehensmodells eine Art Mikro-Logik dar, die als Leitfaden zur Behandlung von Problemen oder Aufgabenstellungen in jeder Phase des Projekts zur Anwendung kommen kann. »

Situationsanalyse:

• Grundlegendes Verständniss des Problem schaffen, Ursachen identifizieren
• Strukturierung und Abgrenzung des Problem
• Definition des Eingriffs- und Gestaltungsbereich für die Lösungsuche
• Schaffung der nötigen Informationsbasis

Zielformulierung

• Vollständig
• Präzise uns verständlich
• Realistisch
• Lösungsneutral

Synthese

Zweck der Synthese ist die Sammlung und Ausarbeitung von Lösungsalternativen. Die Synthese von Lösungen ist ein kreativer, aufbauend-konstruktiver Schritt, welcher auf den Resultaten der Situationsanalyse (Situationskenntnis, Problemverständnis, Zielformulierungen, Anforderungskatalog) aufbaut -> Kreativitätstechniken

Analyse

Zweck der Analyse ist es, grundsätzlich die Machbarkeit einer Lösungsalternative zu verifizieren - ohne diese bereits zu werten oder mit weiteren Alternativen zu vergleichen - dies erfolgt später in der Auswahlphase. Die Analyse ist ein kritischer, analytisch-destruktiver Schritt. Erfüllt eine Lösungsalternative die Ansprüche nicht, so kann sie entweder verworfen werden oder muss überarbeitet werden.

Bewertung

• Es müssen mindestens 2 echte Lösungsalternativen existieren,
• Es müssen Bewertungskriterien - bezogen auf die Zielformulierung(en) - definiert sein,
• Die "Bewerter" müssen über die Fähigkeit verfügen, die Alternativen hinsichtlich der Bewertungskriterien beurteilen zu können.

Entscheid

• Basierend auf den Bewertungsergebnissen eine Entscheidung treffen.

Es kann wohl sein, dass der PLZ keine zufriedenstellende Variante hervorbringt oder es sich herausstellt, dass das Problem mit den verfügbaren Mitteln (Personal, Finanzen, Material) nicht realisieren lässt. In diesem Fall sind folgende Schlussfolgerungen möglich:

• Projektabbruch
• Sistierung der Zusammenarbeit mit Systementwicklern
• Zielreduktion
• Auf höhere Systemebene zurück, um eventuell auf anderen Wegen zum Ziel zu kommen
• Das Problem wird neu umschrieben/definiert

Das Ziel der Architekturgestaltung ist es, eine Architektur zu entwickeln, die einen zuvor definierten Wert bzw. Zweck/Ziel/Funktion erfüllt.

Die Konzeptgestaltung (nebst der Architekturgestaltung) folgt der Logik des oben erläuterten PLZ. In einer Konzeptgestaltung geht es darum, eine gewählte Architektur konkret und detailliert auszugestalten. Dazu wird in einem Top-Down-Ansatz der PLZ mehrmals durchlaufen.

Ziel dieses Teilprozesses ist es, eine erste unternehmerische Rechtfertigung des Vorhabens sowie Entscheidungsgrundlagen für ein GO/NO-GO vorliegen zu haben.

Resultat/Lieferobjekt -> Mini-Business Case

• Welches Problem genau soll adressiert werden?
• Welche grundlegenden Ziele(Grobziele) muss eine zukünftige Problemlösung erfüllen?
• Eventuell auch bereits: Welche grundlegenden Anforderungen muss die Lösung erfüllen (-> Systemanforderungen)?
• Welchen Nutzen soll und welche Kosten (einmalige wie auch wiederkehrende) darf die zukünftige Lösung aufweisen?
• Bis wann soll die Lösung verfügbar sein?
• Eventuell auch bereits: Welche grundlegenden Architekturvarianten (grobe Lösungsvarianten) stehen im Vordergrund?

Wenn diese Fragen beantwortet sind kann ein Projektantrag erstellt werden, welcher das Lieferobjekt deises Schrittes ergibt. Anhand dieses Projektantrag können die Planungsaktivitäten im nächsten Schritt gestartet weden.

Zielen kommt eine entscheidende Bedeutung zu; Ziele sollen die Lösungssuche steuern und nicht umgekehrt eine Lösung nachträglich rechtfertigen. Ziele müssen ausformuliert, verabschiedet und allen Beteiligten kommuniziert sein. Ziele dienen zur Erfolgsbestimmung eines Projektes.

(Muss-Ziele, Soll-Ziele, Wunsch-Ziele)

Abwicklungsziele

• Leistungsziele, was muss geliefert werden?
• Qualitätsziele, in welchem Zustand?
• Zeit-/Terminziele, bis wann?
• Kostenziele, zu welchen Kosten?

Systemziele

• Akzeptanz und
• Wirtschaftlichkeit

des im Projekt zu erstellenden Systems. Sie unterteilen sich hierarchisch in Globalziele, Gruppenziele und Detailziele.

Ziel:

• Ein zu erreichender Zustand
• Meist im umfassenden Sinn

Anforderung:

• Eine zu erreichende Eigenschaft
• Meist konkret

Bei einer Delphi-Befragung wird einer Expertengruppe ein Fragen- oder Thesenkatalog des betreffenden Fachgebiets vorgelegt. Die Befragten haben in zwei oder mehr sogenannten Runden die Möglichkeit, die Thesen einzuschätzen. Ab der zweiten Runde wird Feedback gegeben, wie andere Experten geantwortet haben, in der Regel anonym. Auf diese Weise wird versucht, der üblichen Gruppendynamik mit sehr dominanten Personen entgegenzuwirken.

Dauer[Tage] = Aufwand [PT] / Personen [P]

Termintreue [%] = (#eingehaltene Termine / #Termine) * 100

Fortschrittsgrad = (ISTaufwand * 100) / Planaufwand

Zeitlicher Fortschrittsgrad [%] = (Dauer [Wochen] / prognostizierte Gesamtdauer [Wochen]) * 100 -> zu einem Zeitpunkt x

zeitl . FGplan = ISTDauer / geplannte Dauer

zeitl. FGist = ISTDauer / voraussichtliche Dauer

EV = Fortschrittsgrad tx * plankosten

Burned Value = Differenz zwischen denk Plan Kosten und den effektiv angefallenen Kosten

Scheduled Performance Index = EV / PV

Cost Performance Index = EV / BV

Anforderungen entsprechen nicht dem Kundenwunsch, sind zu wenig detailiert beschrieben oder fehlen ganz -> System entspricht nich dem, was der Kunde/Nutzer wollte

Häufigster Fehler sind falsch Annahmen von Stakeholdern.

• Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
• Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
• Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft.

Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.

Dem Requirements Engineering im Entwicklungsprozess kommt die Aufgabe zu, die Anforderungen der Stakeholder zu ermitteln, zweckmäßig zu dokumentieren, zu überprüfen und abzustimmen sowie die dokumentierten Anforderungen über den gesamten Lebenszyklus des Systems hinweg zu verwalten

Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

• Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.
• Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren sowie die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.
• Kann als abgeschlossene Phase in Projekten vorkommen (Wasserfall) aber auch als begleitender Prozess.

• Glossar
• Formale Beschreibungssprache (UML ...)
• Art der Kommunikation (Gestik, Sprache...)

• Steht im Mittelpunkt des Geschehens
• Pflegt oft als einziger direkten Kontakt zu allen Stakeholdern
• Analytisches Denken
• Empathie
• Kommunikationsfähigkeit
• Konfliktlösungsfähigkeit
• Moderationsfähigkeit
• Selbstbewusstsein
• Überzeugungsfähigkeit

• Funktionale Anforderungen
  • Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll.
• Qualitätsanforderung
  • Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.
  • Quantitative definieren, damit diese überprüft werden können
  • Stehen fast immer in Beziehung zu finktionalen Anforderungen und müssen zwingend so ausgewiesen werden
  • Performace
  • Sicherheit
  • Zuverlässigkeit
  • Bentzbarkeit
  • Änderbarkeit
  • Übertragbarkeit
• Randbedingung
  • Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.

von innen nach aussen 

System | Systemgrenze&Systemabgrenzung | Systemkontext | Kontextgrenze & Kontextabgrenzung | irrelevante Umgebung

Mögliche Elemente die im System eingezeichnet werden können:

• Personen
• Systeme
• Prozesse
• Ereignisse
• Dokumente

Die Systemgrenze separiert das geplante System von seiner Umgebung. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in der Umgebung ab, die durch den Entwicklungsprozess nicht verändert werden können.

Die Kontextgrenze separiert den relevanten Teil der Umgebung eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen dieses Systems hat.

Stakeholder (zur Überischt eine Stakeholderliste machen!)

Dokumente

Systeme die bereits in betrieb sind

Der RE...

• Spricht die Sprache der Stakeholder
• Arbeitet sich in das Fachgebiet gründlich ein
• Erstellt ein Anforderungsdokument
• Kann die Arbeitsergebnisse verständlich formulieren
• Pflegt einen respektvollen Umgang mit den Stakeholdern
• sorgt dafür, dass das spezifizierte System den funktionalen und qualitativen Ansprüchen der Stakeholder gerecht wird.
• organisiert die Planung und Koordination der Kommunikationswege sowie eine strukturierte Terminplanung für die durchzuführenden Requirements-Engineering-Aktivitäten mit den Stakeholdern.

Der Stakeholder...

• führt den Requirements Engineer in das Fachgebiet ein,
• versorgt den Requirements Engineer mit Anforderungen,
• formuliert die Anforderungen zielgerecht und gewissenhaft,
• trifft Entscheidungen zeitgerecht,
• priorisiert die Anforderungen,
• befolgt den vorgegebenen Änderungsprozess,

Mit dem Kano-Modell wird eine Anforderungskategorisierung gemacht. Es gibt drei Arten von Katgorien:

• Basisfaktoren (unterbewusstes Wissen)
  • Müssen zwingend erfüllt werden
  • Weden vorallem durch bereits vorhandene Systeme geprägt
  • Zur Ermittlung eignen sich Beobachtungstechniken und dokumentzentrierte Techniken
• Leistungsfaktoren (bewusstes Wissen)
  • Stakeholder fordern diese bewusst und explizit
  • Erfüllung erzeugt Stakeholderzufriedenheit
  • Zur Ermittlung eignen sich Befragungstechniken
• Begesiterungsfaktoren (unbeswusstes Wissen)
  • sind Systemmerkmale die der Stakeholder nicht kennt und erst während der Benutzung als angenehme und nützliche Überaschung entdeckt
  • Wird erst durch ausprobieren erkannt oder wenn vom RE vorgeschlagen
  • Zur Ermittlung eignen sich Kreativitätstechniken 

Das Kano-Modell sagt aus, dass mit der Ziet aus Begeisterungsfaktoren Leistungsfaktoren und schlussendlich Basisfaktoren werde, denn der Nutzer gewöhnt sich an Merkmale eines Systems.

[Grafik]

Kreativitätstechniken

• Brainstorming
• Brainwriting
• 6-3-5 Methode
• Brainstorming paradox
  • Sammeln von Ergebnissen die nicht errreicht werden sollen
• Perspektivenwechsel
• Analogietechnik

 Dokumentenzentrierttechnik

• Systemärchologie
  • Alte Systeme
• Perspektivenbasiertes Lernen
  • Dokument aus vorbestimmter Perspektive lesen
• Wiederverwendung
  • Wiederverwendung von erarbeiteten Anforderungen

Beobachtungstechniken

• Feldbeobachtung
  • Vor Ort bei den Spezialisten oder Nutzern eines System
• Apprenticing
  • Erlernen und Ausführen der Tätigkeiten der Stakeholder

Unterstüzende Techniken

• Mindmaping
• Workshops
• CRC-Karten
  • Class Respnsibility Collaboration - Kontextaspekte auf Karteikarten notieren und daraus die Anforderungen erarbeiten
• Audio- und Videoaufzeichnungen
• Use-Case-Modellierung
• Prototyping
  • Eignet sich zum Überprüfen und Hinterfragen von bereits definierten Anforderungen

Einflussfaktoren auf die Wahl

• Unterscheidung nach bewussten, unberwussten und unterbewussten Anforderungen
• Termin- und Budgetvorgaben sowie die verfügbarkeit der Stakeholder
• Erfahrung des RE mit entsprechenden Ermittlungstechniken
• Chancen und Risiken des Projekts

Risikofaktoren

• Menschliche Einflüsse
  • Klären der Anforderungsart, angestrebte Detailierungsebene, und die Erfahrung des RE und der Befragten mit der Ermittlungstechnik
• Organisatorische Einflüsse
  • Festpreis- oder Werkvertrag, Verfügbarkeiten, Neu- oder Altsystem usw.
• Fachlich inhaltliche Einflüsse
  • Bei hohem Komplexitätsfaktor empfiehlt es sich strukturierende Ansätze zu verwenden um die Komplexität der fachlichen Inhalte in verstehbare Teile zu zerlegen

Eine Anforderungsspezifikation ist eine systematisch dargestellte Sammlung von Anforderungen (typischerweise für ein System oder eine Komponente), die vorgegebenen Kriterien genügt.

• Anforderungen sind die Basis für die Systementwicklung
• Anforderungen sind rechtlich relevant (Vertrag)
• Anfoderungsdokumente sind Komplex
• Anforderungen sollten allen Beteilligten zugänglicih sein

Qualitätsmerkmale:

• Eindeutig und Konsistenz
• Klare Struktur
• Modifizierbarkeit und erweiterbarkeit
• Vollständigkeit
• Verfolgbarkeit

Strukturperspektive

• Struktur von Ein- Ausgabedaten
• Staatisch-strukturelle Aspekte von Nutzungs- und Abhängigkeitsbeziehungen (zu nutzende Diesete eines externen Systems)

Funktionsperspektive

• Welche Daten aus dem Systemkontext durch das System manipulliert werden und welche vom System ausgehen

Verhaltensperspektive

• System und dessen Einbettung in den Systemkontext
• Raktionen auf Ereignisse
• Bedingungen eines Zustandswechsel

• Abgestimmt
• Eindeutig
• Notwendig
• Konsisten
• Prüfbar
• Realisierbar
• Verfolgbar
• Vollständig
• Verständlich